|
The questions posed in this article arise from a
consecutive set of circumstances. First I had lunch with Simon
Napper and Vindod Kathail of Synfora, and that conversation
was quite compelling. Then I shared a cup of coffee with Shiv
Tasker and George Harper of Bluespec. That was also a
compelling conversation, in particular because Shiv and George
were interested – although they disagreed – with the article
published here in EDA Nation in January. That article was
about ESL Design and featured comments from Celoxica's Jeff
Jussel.
Finally, I moderated a panel about ESL at DATE in Munich
that included spokesmen for Verisity, Cadence, MIPS,
Synplicity, ChipX, and Xilinx. Again, it was a compelling
conversation, but I think it would have been a more robust
discussion had it included companies that actually position
themselves as providers of ESL technology. Therefore, herein
you'll find what I would consider a Dream Team Panel on
ESL.
The 'panelists' represent companies that I believe do
position themselves as players in the ESL market. The panel
also includes one analyst and one IP company that uses ESL
tools. The participants received the questions via e-mail and
provided their responses via e-mail, as well. They were only
allotted 600 words for their responses (although admittedly
some ran long), so they were asked to skip the questions that
were of lesser relevance to their particular message.
When next you have the chance, I would invite you to engage
any of these people in person on the topic of system-level
design. I think you'll see that these folks are definitely
focused on the ESL State of Mind.
The Panelists:
Dataquest
– Gary Smith, Chief EDA Analyst
Bluespec
– Shiv Tasker, CEO
Celoxica –
Jeff Jussel, Vice President of Marketing
CoWare
– Mark Milligan, Vice President of
Marketing
CriticalBlue – David Stewart,
CEO
Forte – Brett Cline, Vice President,
Customer Operations & Services
Ignios
– Mark Lippett, CTO
SpiraTech –
Simon Calder, CEO
Summit Design Automation
– Emil Girczyc, President and Chief Executive
Officer
Synfora – Simon Napper,
CEO
The MathWorks – Ken Karnofsky,
Marketing Director
The Questions:
Q.1 – Define ESL. Or perhaps it can't be
defined?
Gary Smith, Dataquest – Electronic-system
level (ESL) is the concurrent design of both hardware and
software. This is the official Dataquest definition.
Shiv Tasker, Bluespec – The best
definition I’ve heard for ESL is the design level above RTL.
This embodies system modeling and high-level implementation
activities. Whatever the definition, ESL solutions and flows
should improve entire designs and a broad application space,
not just sub-blocks in small niches.
Jeff Jussel, Celoxica – ESL is the
methodology and tools that support the design of electronic
products beginning from algorithmic software-based functional
models, usually written in C. The flow begins with functional
TLM modeling, then partitioning of the functionality across an
embedded architecture, and finally connecting the C-models to
an implementation flow in embedded software (compilers) or
hardware (behavioral synthesis).
Mark Milligan, CoWare – ESL is an industry
emerging between – and often before [in the design cycle] –
embedded software and EDA. The difficulty in defining “ESL” is
that we’ve been trying to define it in terms of a tool or set
of capabilities, instead of realizing it is a new industry.
Misnomers are typical with new industries. We use the analogy
of the horseless carriage. The $500 billion automotive
industry was originally defined in terms of older, familiar
technology, rather than in the context of a major new
industry. ESL shouldn’t be defined in terms of EDA; it is
becoming a new industry with unique attributes.
Companies in electronic design are facing enormous
cost pressures. Two ways out of that: create and maintain more
differentiated designs, or cut costs (or both). ESL helps
customers create and maintain differentiated designs – often
through software. ESL is about software-dominated design.
Underlying hardware features are driven by software, but both
can be optimized simultaneously early in the architecture
phase. It’s not just automating. It’s creating better designs
with more value and lasting differentiation. ESL also better
connects the design chain by connecting system architects to
customers, RTL designers, verification engineers, and
critically, to embedded software developers. This enables
geographically separated teams to work better together.
David Stewart, CriticalBlue – ESL is all
the stuff you need to do to design a product before you start
writing RTL or stitching together RTL. The key thing about ESL
is that it is implementation independent – major decisions
about architecture and hardware/software partitioning have not
yet been made and are still to be investigated. To emphasize
the point, ESL must include software development. Most
definitions of ESL are self-serving and cover a hideously
constrained subset of the space, for example, SystemC to
RTL.
Brett Cline, Forte – ESL by definition is
“Electronic System Level.” However, in practical terms, ESL
represents the next abstraction level above register transfer
level (RTL). There are two main components to ESL which are
hardware design and software design. Hardware design is
typically done behaviorally.
Mark Lippett, Ignios – ESL is a technology
which: enables the abstract architectural exploration of a
system before making firm decisions about the
software/hardware partitioning; enables efficient
software/hardware co-design; offers a virtual platform for
software development on a fast-executing model of a new
hardware architecture. Although the first of these represents
an exciting long-term opportunity for system design and
realization, this does not seem widely available (or at least,
used) at the moment.
Today, as system designers move away from the traditional
"single processor + peripherals" architectures, ESL fulfills a
vital role in providing a software development environment
which is both fast and reflective of the complexities of the
target platform.
Ken Karnofsky, The MathWorks – ESL is a
collection of EDA technologies that aim to provide a more
efficient way to model complex hardware. It aims to provide a
higher level of abstraction for faster simulation and
verification of those systems, and to enable pre-silicon
software development.
The EDA Consortium uses the terms System-Level Design and
System-Level Verification to describe similar concepts. They
encompass software tools that capture, simulate, partition,
validate, and verify systems that comprise both hardware and
software, including interfaces to code compilation, logic
synthesis, and logic simulation.
Simon Calder, SpiraTech – ESL is not a
level of abstraction, as its acronym would suggest. I would
argue that ESL is the evolutionary 'process' of raising the
level abstraction in IC design, verification and test to
somewhere above RTL. Any tool involved in that process can be
called an ESL tool, or any company involved can be called an
ESL company. (Therefore, pretty much every front-end
company.)
Emil Girczyc, Summit Design – ESL is not
just design above RTL, and it is not necessarily design in
SystemC. ESL addresses and supports the design decisions made
at the system level – system architecture tradeoffs,
hardware/software partitioning, IP component selection and
sizing, and system level verification of performance, power,
and functionality. Historically, these issues were solved by
simple static analysis using pencil and paper or Excel, but as
system complexity, competition, and time to market pressures
have increased, more accurate dynamic analysis is
required.
Simon Napper, Synfora – In the broadest
sense, ESL (electronic system level) design is about designing
entire electronic systems (printers, cell phones, cameras,
etc.) and meeting price, performance, and power requirements.
ESL is not about designing only specific components such as
processors, memories, and interconnects. In my view, ESL
design consists of these steps:
* 1) System Definition – This is where an engineer defines
the architecture of the system, including what goes into
hardware and what goes into software; which CPUs, buses, and
memories to use; what could be implemented using off-the-shelf
IP and what requires development of new IP, etc. System
definition requires an emphasis on modeling and analyzing
performance to make the right choices.
* 2) Custom IP Design – Many (or most) systems need custom
IP to meet price, performance, and power requirements.
Designing custom IP is a significant component of the overall
design in terms of design time and design cost. T he missing
ingredient in ESL design is automatic implementation, or
synthesis. RTL was an accepted level of design because RTL
synthesis eliminated the need to create gate-level
descriptions manually. Until there is a similar
capability—creating RTL automatically from an ESL
description—the adoption of ESL will not be successful.
* 3) System Integration and Verification – In this step,
the entire system, including custom and off-the-shelf IP, is
put together and verified for accuracy and performance.
* 4) RTL to GDSII – This is the traditional back-end
flow.
Q.2 – Explain why you agree/disagree with Gary
Smith's evaluation of the situation?
[Editor's Note: Gary Smith will be
publishing an article in an upcoming issue of Chip
Design Magazine that will layout his evaluation of
the situation.]
Shiv Tasker, Bluespec – We were pleased
Gary named Bluespec one of only three “must see at DAC” ESL
synthesis companies last year. I’m not familiar with his
evaluation, but will be interested in his assessment when he
completes his current ESL flow work and would be happy to
comment then.
Jeff Jussel, Celoxica – The definitions to
date have been hardware oriented and have defined ESL as an
extension of the existing RTL hardware design flow. ESL is a
revolution, not an evolution and goes much further than simply
bringing co-design elements to SoC designers. ESL brings the
possibility of using custom hardware to applications that
never could have used hardware before. In this way, it is
opening EDA to markets that haven't historically included
hardware designers.
David Stewart, CriticalBlue – I don’t
agree that more ESL design is happening; I think it has been
happening for as long as hardware and software have co-existed
in electronic products. What I see is more automation being
introduced into the processes, driven primarily by complexity
and time-to-market pressures.
Brett Cline, Forte – Gary has shown clear
insight in predicting that the market is moving away from RTL
and that the next abstraction level is necessary for timely
creation of complex systems. Gary is correct when he says that
it is important for methodologies to exist for a design style
to take off. Often design teams build on the RTL flow that
they have by augmenting it with higher-level tools. This
provides the advantage of the new tools while preserving the
investment in the old tools.
Mark Lippett, Ignios – I cannot comment on
the quantitative analysis in the SoC sector of Gary's
evaluation. However, we have qualitative feedback from the
engineering management in our target customer base of
companies designing complex SoCs. There is a growing
recognition that ESL is a mandatory part of the development of
all new software programmable platform chips. Software
development *has* to start before silicon is available. We
have also seen cases where existing chips, which are shipping
in volume today, are being retrospectively modeled in ESL
environments to facilitate end-user software development and
support.
Ken Karnofsky, The MathWorks – Gary has
accurately identified the segments currently being addressed
by EDA companies (both established and startups). He is also
correct in acknowledging the increasingly important role of
the system architects that The MathWorks serves, as well as
The MathWorks market-leading share. He also acknowledges that
ESL is a subset of “system-level design” (SLD), which
encompasses both electronic and mechanical elements. In other
words, ESL does not cover the whole system.
Many system engineers that The MathWorks serves are doing
“full” system-level design – encompassing hardware, software,
and mechanical systems, as well as the real-world environments
that they operate in (e.g., communications channels, noise
models, human perception) – not just the electronics. Others
are developing signal processing and control algorithms,
converting them to fixed-point, and evaluating their
performance and impact on overall system behavior. These
elements are necessary to make sure that the team is “building
the right thing” (meeting requirements) and getting it right
the first time (i.e., eliminating design flaws), as well as
simply testing to find flaws later in the development
process.
Simon Calder, SpiraTech – If I understand
Gary, correctly, Gary's position is that ESL is about
hardware/software co-design. This is hard to disagree with,
but somewhat out-of-character, because I think Gary is
understating ESL.
EDA has always been about reducing the time to revenue for
semiconductor IC's. That is what ESL is about. Absolutely,
making the software and hardware elements parallel tasks and
not serial is a massive gain, but using higher levels of
abstraction to hasten SoC and ASIC design, debugging,
validation and verification has just as much impact if
re-spins can be irradiated.
What has happened recently is that levels of abstraction
that had been useful for only hardware/software co-design have
been brought into the verification flow. This has been done by
bridging the gap between those pure un-clocked transaction
level domains with the perfectly cycle accurate world of
registers, gates and transistors.
Simon Napper, Synfora – Gary Smith is
stirring the pot. He’s encouraging thought and determining
whether there is a consensus. I think that there are some
pieces missing from a comprehensive and effective ESL
methodology. And I’d argue that synthesis is the big piece
that is missing. It’s high-level synthesis that will define
and drive the deployment of ESL much more broadly than where
it stands today.
Q.3 – Does working in SystemC = Working at the ESL
level?
Gary Smith, Dataquest – No. You can do RTL
design with SystemC. It's a dumb idea, but you can. Also, you
can work at the ES level with other languages. For instance, C
and e have been used for years. The
first ESL designs were actually done with VHDL.
Shiv Tasker, Bluespec – Working in SystemC
is, well, working in SystemC. As with many languages, you can
work with SystemC at different levels, from ESL to RTL. TX
modeling and testbench development with SystemC may be ESL,
but synthesizable SystemC is almost always RTL.
Jeff Jussel, Celoxica – SystemC as a
modeling language is part of the ESL flow, and coupled with
behavioral synthesis serves as an implementation language for
the 'back-end' of ESL where the algorithms are connected to
existing hardware RTL flows. However, simply adding a SystemC
interface does not make a hardware design tool suddenly part
of the ESL flow.
Mark Milligan, CoWare – Working in SystemC
does equal ESL. But ESL doesn’t necessarily always equal
SystemC. Algorithm and embedded processor development aren’t
necessarily done in SystemC, and they are definitely part of
ESL. Embedded software isn’t written in SystemC, yet modeling
for ESW development is a main driver for SystemC.
David Stewart, CriticalBlue – No. SystemC
is a hardware modeling language. Assuming you want to use
SystemC, there’s a lot of ESL activities before you get to the
point of wanting to model your hardware (see definition of ESL
above).
Brett Cline, Forte – Technically, working
at the ES level (or at ESL) is not the same as SystemC.
However, SystemC is the glue that links the methodology
together. SystemC provides the starting point for design
modeling as a superset of C/C++, easily supports verification
with a defined simulation standard, supports implementation
with SystemC synthesis tools such as Forte’s Cynthesizer,
works with the latest in debug and analysis technology, etc.
Because of SystemC, leading edge products from several vendors
easily work together. ANSI-C and other C dialects are locked
to proprietary vendor products.
Mark Lippett, Ignios – No, SystemC is not
necessarily equivalent to ESL. In theory SystemC can be used
to reflect an RTL abstraction, so it is vital to remain
cognizant of the target abstraction level when writing
SystemC.
In many ways SystemC is not the ideal choice for ESL. If we
agree that ESL should enable us to establish a
software/hardware partition, then in an ideal world the ESL
programming model would be seamlessly compatible with the
hardware or software development flow. This should mean that
at least some of the results at the ESL level would be
directly reusable in the final product. However, at present,
SystemC is neither of these – it is not a pragmatic route to
gates, nor is it a recognized kernel for runtime software.
Notwithstanding the programming model differences, SystemC
is not a new language. The principal advantage of SystemC is
its empowering effect on the comparatively huge amount of
expertise in the software engineering community who, with the
advent of ESL tools, are now capable of defining functionality
which may ultimately be embodied in hardware.
Ken Karnofsky, The MathWorks – Certainly
not. SystemC addresses a subset of the ESL challenges facing
electronics manufacturers, and a smaller subset of the
problems facing embedded software developers. In fact, it has
been proven that Model-Based Design with Simulink, including
automatic generation of C code, produces more efficient,
reliable software with dramatic reductions in development time
and effort. FPGA engineers are finding similar benefits using
Simulink and third party automatic RTL generation tools. In
addition, SystemC does nothing to address the needs of analog
and mixed-signal engineers who need to work at a higher level
of abstraction and collaborate ever more closely with digital
designers.
Finally, choosing SystemC as a system design language is
based on a false premise: that system architects choose C
because it is somehow a more productive approach. In fact,
most choosing that approach do so because it is freely
available, not because it is productive. Adding classes and a
scheduler masks the issues. C, C++, and SystemC are too low
level to do system-level design productively. This has been
demonstrated by the order-of-magnitude productivity gains
engineers achieve when they move to Simulink and Model-Based
Design to specify, implement, and verify systems.
The answer is to specify and verify designs with executable
models, and then generate the code automatically. The previous
leap in productivity wasn’t achieved by incrementally
improving logic design (or assembly code for software) – it
came from a leap in abstraction to higher level languages,
accompanied by synthesis and compiler technology. SystemC does
not provide the requisite leap for the next generation.
Simon Calder, SpiraTech – Yes and No. It
is difficult to imagine anyone using SystemC who has not
embraced a methodology that uses levels of abstraction higher
than RTL. But please remember SystemC can be and is being used
to make RTL style models. They run faster than Verilog or
VHDL, but not much. By my definition this is not ESL as the
level of abstraction remains unchanged, this can only be
considered accelerated RTL. SystemC does appear to have become
the modeling language of the transaction levels.
Emil Girczyc, Summit Design – NO! Please
see my answer to Question #1.
Simon Napper, Synfora – ESL refers to how
to design complex systems (or SoCs) in a limited amount of
time with limited resources. SystemC, on the other hand, is a
specific language, and possibly a specific methodology, that
is good for system-level modeling and verification (used in
Step 1 and parts of Step 3). There are multiple languages
available for this. Some people use MATLAB for system
modeling, and there’s nothing wrong with that. In fact, Gary
Smith has just added MATLAB and related tools as one of the
groups he tracks to measure ESL revenues.
SystemC is a subset of ESL. People are grasping for a sound
bite to encapsulate ESL, and for a lot of people that’s what
ESL means. I think that two years from now, it will be
understood to be a component of ESL.
Q.4 – Should the conversation about ESL be language
neutral? Is that possible?
Gary Smith, Dataquest – Yes and no. We had
a lot of RTL languages at one time (for instance, iHDL, nHDL,
etc.) However, Verilog put the methodology on the map. SystemC
has done the same for the ESL Methodology.
Shiv Tasker, Bluespec – The conversation
about ESL should not be restricted to one language, just as
RTL isn’t just Verilog. Certainly syntax is not directly
relevant, but semantics is crucial (e.g., elaboration, static
checking, computation models, composability). While the ESL
conversation should be language-neutral, it won't be to the
extent that certain semantic ideas are only expressed (easily)
in some languages.
Jeff Jussel, Celoxica – Languages are part
of the 'religion' of EDA and as such are always hot topics.
The ESL languages define important modeling and implementation
capabilities, and as standards provide much needed portability
and reuse. However, the discussion of ESL goes beyond
languages (and tools for that matter). We deliver ESL flows
with multiple language support.
David Stewart, CriticalBlue – ESL has
nothing to do with languages. Any language which relates to
some part of system design prior to implementation is relevant
to be included in an ESL discussion; such a discussion need
not be language neutral, it should just be language inclusive.
The idea that there will be a unified language of ESL (as per
my definition in #1) is ridiculous.
Mark Lippett, Ignios – From an idealistic
perspective: Yes. From a practical perspective: No. A common
language is needed for both software and hardware in order for
functionality to be migrated from one domain to the other in
the ESL space. There are far too many barriers to the adoption
of an HDL in the software engineering community. Therefore I
believe that the hardware community will have to rise to the
challenge of C/C++ based modeling. This does not necessarily
mandate the use of SystemC in particular, but this would be
the most pragmatic choice today.
Ken Karnofsky, The MathWorks – The
discussion should be about capabilities and methodologies that
are needed to solve customers’ problems. A debate about which
language is best suited to specific tasks is a productive
exercise.
Simon Calder, SpiraTech – Yes and Yes.
Raising the level of abstraction suggests a simplification,
but as everyone knows simplifying things is a complex process.
ESL is no different. There are so many things to be done in
raising the level of abstraction that no one language can do
it all well. Any language that saves time and money will
justify itself, as long as it is not maintained as a monopoly
by a single vendor.
Emil Girczyc, Summit Design – Ultimately,
customers decide what will work best for their projects and
within their particular flows. If a customer is already
working in a C environment, then the move to SystemC would
likely be natural and preferred for ease of use and
functionality. DSP designers would likely use Matlab for their
algorithmic development, but today's system design and
verification is not just about signal processing.
Simon Napper, Synfora – ESL is a solution
to a problem. The conversation should be about defining the
problem and how ESL could solve it. To us, the problem is
productivity and the cost to complete a complex SoC. We focus
on which flow a designer is trying to operate, and how is it
helping to increase productivity and reduce the cost of a
design.
Q.5 – Are the current standards efforts with
regards to SystemVerilog warranted if we're all just going to
move to SystemC?
Gary Smith, Dataquest – Yes, Verilog badly
needs upgrading and SystemVerilog is that upgrade.
SystemVerilog is an RTL language, not an ESL language, so the
two will co-exist.
Shiv Tasker, Bluespec – While SystemC is
gaining use for functional modeling and testbenches, the path
to RTL is murky at best. I suspect hardware designers would be
quite surprised to hear that we're all just going to move to
SystemC. From their viewpoint, it offers nothing compared to
SystemVerilog (and some would argue SystemC’s a big step
backward).
Mark Milligan, CoWare – Improvements to
Verilog such as SystemVerilog shouldn’t stop. This development
is warranted for incremental improvements to the
implementation and verification process. More automation for
EDA is good; getting dramatic design differentiation using ESL
is great.
David Stewart, CriticalBlue – It’s not
about languages. If some people want to use SystemVerilog
versus SystemC, let them get on with it. In the end, if the
language works for them and the tools exist that get them to
market on time, it’s a solution. It’s just important to
remember that getting from SystemVerilog or SystemC to RTL is
typically a small piece in a big puzzle.
Brett Cline, Forte – Yes, but for RTL
implementation and verification. SystemVerilog is the next
generation of Verilog and provides a good starting point for
RTL-based design. Even though the leading edge customers are
moving to SystemC, RTL design will still have a place for some
customers for the near future.
Mark Lippett, Ignios – I see SystemVerilog
as a useful extension to existing RTL design languages, not as
a candidate for ESL design (at least, as defined above). As a
semiconductor IP company with a synthesizable deliverable, we
have to be conservative in our expectations of our customers'
integration and synthesis flow. So, in the short and medium
term, Verilog and derivatives are the only pragmatic choice
for synthesis. Whilst that is the case, SystemVerilog will
provide value in lower level hardware embodiment and
testing.
Simon Calder, SpiraTech – Many customers
believe that SystemVerilog is best for designing test benches
and if nothing else it has the potential to make the whole RT
Level run better, which in itself is important. SystemVerilog
has an important role to play even though SystemC appears to
have won the TLM battle.
Emil Girczyc, Summit Design – The two
languages serve different needs, though some confusion about
SystemC for use at the RT-level did take up much press at one
time.
Simon Napper, Synfora – They have taken on
a life of their own. The focus of ESL should be on
significantly boosting designer productivity.
Q.6 – Aren't there always going to be problems
using C-based languages to describe parallelism?
Gary Smith, Dataquest – Coming up with a
Concurrent Software (C ?) Compiler is the most important
breakthrough technology needed for ESL Design.
Shiv Tasker, Bluespec – 'C-based'
encompasses two orthogonal approaches, with different
characteristics and issues:
* 1) Automatic parallelization of sequential C: Yes, there
will always be problems deriving good, parallel hardware
implementations from sequential C code, as demonstrated by 50
years of research on this topic. Researchers in the general
computing field of parallel programming have largely abandoned
this superficially seductive goal. EDA just hasn’t fully
caught on yet.
* 2) Explicit parallelism (e.g., constructs like SystemC's
SC_THREAD etc.): Synthesizable, but code is at no higher level
than RTL (and often messier).
With # 1, expressing a function is easy; producing good
hardware is hard/impossible. The only exception is a small
class of vectorizable/VLIW-mappable algorithms, those using
tightly nested FOR-loops with simple, linear indices (e.g. FIR
filters). But, what % of design is addressed by these code
fragments?
With # 2, expressing a function is hard; producing good
hardware is no harder than current RTL synthesis.
Transaction-level SystemC models require fundamental rewrites
for effective hardware synthesis – the concept of smooth
refinement to RTL is ridiculous, as sequential algorithms are
completely different from parallel ones.
Jeff Jussel, Celoxica – We use C languages
because they are good at describing algorithm behavior at a
high level, and because they are the language in common for
programming embedded processors. C-based implementation
languages such as SystemC and Handel-C add the constructs
needed to deal with concurrency, timing, interfaces, and other
hardware-oriented requirements without losing the high-level
advantages of the software-based language.
David Stewart, CriticalBlue – That’s a
hardware-centric statement typical of many EDA companies. If
you are trying to force fit a general purpose, feature rich
but sequential language like C into the parallel world of
hardware modeling and implementation then yes, you will have
to impose language subsets and coding styles. Note how many
vendors support “ANSI C”, i.e. the subset of C and coding
styles they support is ANSI compliant!
One of the EDA industry’s biggest opportunities is to
capitalize on the explosive growth of embedded software
content in today’s electronic products. To do this, they have
to recognize, as we have, that the embedded software developer
will not tolerate being constrained by modeling guidelines or
solutions which don’t allow them to express themselves in
unconstrained C/C++. Hardware centric solutions will appeal to
RTL designers trying to gain productivity by moving up in
abstraction level, but will not grow the EDA market into the
embedded software sector.
Brett Cline, Forte – This problem
definitely exists for ANSI-C, but not with SystemC. SystemC is
a C++ class library. That means that SystemC inherits all of
the power of C++ (and essentially C) while also implementing
additional abstract concepts such as parallelism, clock
accuracy, and bit accuracy necessary to accurately represent
hardware.
Designs written in SystemC can have explicit parallelism
without hokey proprietary pragmas used to describe things that
should happen in parallel.
Mark Lippett, Ignios – It depends whether
you wish to explicitly build a "structural" model of a
parallel system and then execute code on top of that, or
whether you wish to take "algorithmic" C code and infer
parallelism from that. I don't doubt that considerable
progress will be made in developing "parallel compilers" that
extract instruction-level (perhaps even thread-level)
parallelism from algorithmic code; however, this is some way
off. In the meantime, ESL-based methodologies that use C-based
languages to explicitly define a parallel architecture are
being used extensively and with considerable success.
Ken Karnofsky, The MathWorks – In order to
do so, you force the C code to look like HDLs. This satisfies
neither the software developers nor the hardware designers.
Simulink, in contrast, has built-in semantics for modeling and
simulating real-time, concurrent, multi-rate systems. Simulink
models map naturally to hardware and embedded software
implementations.
Simon Calder, SpiraTech – We at SpiraTech
like to think we have solved some of them.
Emil Girczyc, Summit Design – A variant of
C is the most successful HDL because Verilog is a C-based
language in the most general definition, and SystemVerilog is
adding more C/C++ concepts to Verilog. The HDL dataflow
programming style tends to be used at a fairly low level for
logic description. The most common HDL coding style is a
sequential, procedural programming language with a few
parallel (e.g. process) and hardware (e.g. generate)
statements. Getting similar constructs right in a more vanilla
C context can have similar success.
Simon Napper, Synfora – Your question
addresses the core issue of moving to a higher level of
abstraction. ESL is trying to increase designer productivity,
and increasing productivity means that the tools have to do
more of the work. If the tools cannot automatically infer and
exploit parallelism, ESL is not going to be an effective
solution. There will always be benefits to an experienced
designer guiding a tool, but the bulk of the work has to be
done automatically.
It also depends on if one is describing a system in terms
of functionality or as a collection of hardware components. A
system as a collection of hardware components requires a
method for describing parallelism, whereas functional
descriptions can stay with C for a large part of a system.
There are places in system description, especially at the
highest level, where you do need an explicit way to describe
parallelism, since the description at these levels is more as
a collection of components.
Q.7 – How close are we to getting from SystemC to
RTL, or is this perhaps the wrong question?
Gary Smith, Dataquest – If you mean
automatically, we still have a ways to go. Hopefully, it will
be here in two years. Until then, we'll rely on mapping.
Shiv Tasker, Bluespec – More accurately:
how close are we to synthesizing good hardware from
“high-level” SystemC? Synthesizing good hardware from
RTL-level SystemC is easy, but there's no benefit.
It is questionable whether SystemC offers anything in its
semantics that makes it easier to synthesize good hardware
from high-level descriptions. High-level models must be
manually re-written at an RTL level for synthesis. C-based
synthesis enhances niche applications:
Vectorizable/VLIW-mappable applications can be synthesized,
but are a narrow application space. For the rest, SystemC
synthesis is an RTL level tool.
Jeff Jussel, Celoxica – With the Agility
SystemC synthesis tool, Celoxica has an existing path from
SystemC to RTL. But maybe the question implies will SystemC
replace RTL? The answer to that is "No." SystemC is used at
higher levels of abstraction, but will not replace RTL any
more than RTL replaced gate-level design.
Mark Milligan, CoWare – It’s the wrong
question. We are talking about a fundamental difference in
designs with SoCs versus ASICs with RTL where synthesis was
the critical enabler. Now, designs can have hundreds of IP
blocks and the challenge is connecting them and designing-in
that key differentiation. This must be done with SystemC.
If the question is, “is behavioral synthesis going from
SystemC to RTL and are we there yet?” that will be useful, and
we’re getting there, but the real key for success is SystemC
modeling for IP reuse in SoC designs.
David Stewart, CriticalBlue – It’s the
wrong question, unless you happen to be an RTL designer
looking to gain productivity. The right question is when will
software tool solutions be available, which automate key parts
of the manual system design processes that have been used for
many years.
Brett Cline, Forte – Perhaps it is the
wrong question, because we’re already there. Our customers use
SystemC to model their designs and use our Cynthesizer SystemC
behavioral synthesis to create hardware in a fraction of the
time with better results. They are seeing greater than 50%
reductions in time-to-RTL with 33-50% of the resources
necessary – with better results.
Maybe the right question is – if this technology already
exists and my competitors are using it, how much of a lead do
I want to give them while I wait for it to become
‘mainstream’? Of course, I realize that this sounds pretty
cynical.
Mark Lippett, Ignios – Focusing on SystemC
as a route to RTL is not the wrong question - it's just not
the whole question. Referring back to the classification of
"structural" and "algorithmic" views of C-based languages in
the answer to question 6, there are certainly companies
claiming to offer SystemC to RTL *automatic* translation for
"algorithmic" descriptions. How efficient these are, and how
large the class of applications to which they can be applied,
remains to be seem.
Nonetheless, if we look at the structural view of SystemC,
this allows the *manual* migration from a fast-simulating
SystemC model, which can be rapidly refined, to an accurate
RTL implementation, through the use of a common verification
suite. This latter approach might be manual, but it is
potentially very productive; this is the approach that we use
internally for developing our IP cores.
Ken Karnofsky, The MathWorks – The
question is whether C or SystemC is the right entry point for
design. We contend that it is not, because it is too low a
level of abstraction for effective design space exploration,
analysis, and optimization. Untimed C has additional problems,
because there is no way to simulate the design to validate
timing or functional behavior.
Simon Calder, SpiraTech – We are there
today. But I suspect your question is; 'How long is it before
the RTL to TLM relationship is the same as the Gate Level to
RTL relationship of today' If so, my answer is 5-10 years.
Emil Girczyc, Summit Design – There are
several viewpoints, but two relevant ones are "We continue to
get closer." and "It doesn't matter." "We continue to get
closer" with advances in high-level synthesis tools, but more
importantly in methodology for IP reuse. If an IP developer
(internal group or commercial vendor) delivers a SystemC model
for their IP, there is a direct, and effective, path from
SystemC to implementation.
This is consistent with traditional system design at the
PCB-level based on existing chips. As design teams adopt
greater design / IP reuse, the path from SystemC to RTL is
implicitly available for an increasing amount of the design.
"It doesn't matter" if the value derived from ESL modeling of
the system provides enough value in and of itself. This is
becoming true for architectural analysis of large systems, and
for embedded SW developers who depend on high level models of
the HW to get enough simulation cycles to debug their
software.
Simon Napper, Synfora – How to design
custom IP most productively at the lowest cost is the right
question. There is debate about which is the correct language
for synthesis, and the real questions are: What does a
practical ESL synthesis capability look like? And, How does it
fit into the flow?
We argue that, in consumer electronics, the starting point
is complex reference algorithms such as H.264, imaging
pipelines, etc. written in C. The synthesis tools should take
sequential C, infer parallelism automatically, and then
automatically generate SystemC models to validate
multi-threaded or parallel behavior.
Q.8 – Are Asia and Europe ahead of the U.S. in ESL?
If so, why should the U.S. care?
Gary Smith, Dataquest – Yes, but only in
the algorithmic ESL methodology. There are other methodologies
needed to complete ESL Design.
Mark Milligan, CoWare – Europe and Asia
have definitely been ahead of the U.S. in adopting ESL
methodologies. But within the last twelve months, U.S.
companies have made great strides with pilot programs. The
U.S. should care because ESL offers huge opportunities in
creating software-differentiated designs and improving the
design chain.
David Stewart, CriticalBlue – It’s
slightly amusing to me that a successful and powerful nation
such as the USA spends so much time pondering about whether
they are getting left behind in design methodologies such as
ESL. This is usually the behavior of a small, less developed
country! My advice: design cool products, and use whatever
flows, tools and methodologies you need to get the job done.
If that includes ESL then great. However as long as you are
designing cool products at good prices on the market at the
right time, you’ll be just fine.
Brett Cline, Forte – Yes, the U.S. is
behind Asia and Europe. We should care in the U.S. because we
are struggling to find ways to make our products more
efficiently to try to keep a competitive edge, both in
functional concepts and price. Our goal has to be to design
better products in less time by making our engineers more
productive and the relative costs the same. We need to be the
innovators – but at the right cost. In Japan, there are
multiple methodologies that exist today and hopefully over
time these will flow to the U.S.
Mark Lippett, Ignios – Well, that
certainly seems to bear out our own experience. We use ESL
tools with our customers to explore the capabilities of new
chip architectures that include our IP core. We've spoken with
design groups around the world. We see far more extensive and
advanced use of ESL outside the U.S., but I cannot claim that
this has anything other than anecdotal relevance. The U.S.
will have to decide for itself if ESL is relevant.
Simon Calder, SpiraTech – I think
superficially the answer is yes. The Asians and Europeans
appear to have embraced a more 'Drains Up' approach. But if
you analyze it further, what has really happened is that they
have just been more willing to use the early ESL offerings
from the EDA industry. In reality, many U.S. end-users have
been using highly sophisticated internally developed tools and
methodologies for years. My belief is that the U.S. customers
will move rapidly when they see that there are tools available
that really will save them time and money, like they did with
Verisity.
Emil Girczyc, Summit Design – Europe and
Asia have adopted SystemC to a greater extent than U.S.
companies, largely because they moved to ESL after SystemC
existed and have a stronger belief in standards. However, U.S.
companies are accomplishing many of the same tasks using C and
C++. In many cases, the lack of adoption of SystemC in the
U.S. is because U.S. companies became adept at performing ESL
tasks in C/C++ and, having a working methodology, see no
reason to change. Once more commercial tools based on SystemC
demonstrate their value, design teams in the U.S. will be
quick to adopt them, as quick, or quicker than their
counterparts in Europe and Asia.
Simon Napper, Synfora – It’s not clear
that the U.S. should care, unless a lack of ESL capability
hurts productivity and makes it less competitive. We are still
in the early days of deployment, and despite all the talk
about ESL, there will continue to be reluctance by design
groups to adopt ESL until an effective and automatic way of
generating custom IP is established. Once that is established,
companies will be driven by competitive issues to get on board
with ESL.
Q.9 – Are European companies forced to guarantee
employment for their employees, and therefore forced to move
to new technology paradigms in order to find something for
everybody to do?
Gary Smith, Dataquest – Come on Peggy, you
can do better than that!
Mark Lippett, Ignios – No, although it is
tempting to think that labour laws are the same for every
country in the European Community, this is not the case. In
the U.K. we are certainly not required to guarantee
employment, which is one reason why the UK has a comparatively
vibrant startup community.
Simon Calder, SpiraTech – In the last
downturn, there were certainly European companies that had
more engineers than their surviving projects nominally
required. This talent was focused on projects with longer term
productivity gains in mind. I believe the U.S. companies cut
back deeper and did less longer term methodology planning.
That is changing rapidly and we see U.S. companies putting
more energy into their design methodologies.
Simon Napper, Synfora – No. We are all
competing worldwide and there are no places to hide. Europeans
are well aware of this and they are looking to boost
productivity to remain competitive. That’s why they also are
focused on the promise of ESL.
Q.10 – In other words, is productivity in Europe
& the U.S. versus that in Asia the real question
here?
Gary Smith, Dataquest – That has a place,
but the top priority is increasing functionality.
Brett Cline, Forte – Productivity directly
relates to cost and our costs are generally higher than the
costs in Asia.
Emil Girczyc, Summit Design – The real
issue to ESL adoption is not productivity, but rather one of
risk versus perceived value and need. The large companies in
Europe and Asia still have central CAD organizations chartered
to investigate and adopt new tools and methodologies (often
before they are fully mature). To convince U.S. companies with
no or a small central CAD group to adopt new tools and
methodologies, the value of tools must be quickly demonstrated
and the risk for use on a real project must be low.
We see our customers adopting ESL on the basis of the needs
of their project. In Japan, the high integration of IP within
the consumer electronics space is clearly being served by ESL.
In Europe, wireless device development calls for ESL. In the
U.S., the networking companies are modeling entire networks
with ESL. Again, it's a difference in project focus and needs
for modeling, design and verification.
Simon Napper, Synfora – Productivity
anywhere to compete everywhere is the real question.
Q.11 – Shall we let Asia have the consumer
electronics market and find other markets for the U.S. and
perhaps even Europe to pursue?
Gary Smith, Dataquest – Not out of the
question. "Consumer market" and "profits" don't always fit
into the same sentence.
Brett Cline, Forte – That is an option,
but I don’t believe that Intel, Motorola, HP, Broadcom,
Qualcomm, TI, Apple, Cisco (Linksys), PalmOne, Creative Labs,
NVidia, ATI, Microsoft, and others would concede that.
Simon Calder, SpiraTech – The U.S. still
dominates, processors, DSPs, communications, graphics, digital
music and embedded operating systems. Try and make a consumer
product without any or all of those! I believe that in 5 years
time at least 75% of ASSPs will have a mass-market consumer
use. The big brand names may become exclusively Asian and
European, but I will not bet against the U.S. semiconductor
companies maintaining if not increasing their market
share.
Simon Napper, Synfora – Good luck. I don’t
think U.S. and Europe can afford to cede that market unless
they are willing to tank their economies in the short term.
For the next few years, the consumer market is going to drive
semiconductor volumes, tools, and methodologies. The U.S. has
been in this position before – behind the eight ball – and has
always managed to compete.
Q.12a – Where is the ESL market? U.S.? Asia?
Europe?
Gary Smith, Dataquest – All of the above,
but it's somewhat methodology dependent.
Q.12b – How does your company play in the ESL
market? Which market is that? U.S.? Asia? Europe?
Shiv Tasker, Bluespec – Bluespec is
re-inventing hardware design. Bluespec's tools deliver
substantial productivity improvements in the design process
for all applications whether control or datapath dominated.
Its strong semantics (elaboration, static checking, state and
concurrency model, interfaces and composability) permit
smooth, correct refinement from abstract, "transaction-level"
models down to a level that, while still substantially higher
than RTL, can be synthesized into high quality hardware.
While other approaches may offer benefits to some
sub-blocks within a design, Bluespec accelerates the entire
chip design process. Bluespec is engaged with customers in the
U.S., Asia and Europe.
Jeff Jussel, Celoxica – Celoxica sells ESL
tools to system designers where the value in the system is the
algorithm and where time to market is a priority. Our
customers are in diverse fields including military/aerospace
systems implemented on FPGAs, consumer applications using
structured ASICs, and embedded systems used to accelerate
software for security or medical imaging or genome processing
to list a few.
Some of these customers are software designers, some are
hardware designers, and some are algorithm experts with no
implementation knowledge. The one thing they all have in
common is the need to quickly implement a software algorithm
across both an embedded processor and custom hardware. This
holds true across geographies with about 40% of our business
coming in Japan/Asia, 35% in the U.S. and 25% in Europe.
Mark Milligan, CoWare – CoWare enables
customers worldwide—in the U.S., Asia, Japan, and Europe—to
rapidly create differentiated algorithmic-, processor- and
software-centric SoC designs. In 2004, we believe CoWare was
the seventh largest EDA company. The larger companies are
public with predicted growth rates of 20% or less. CoWare’s
predicted growth rate is much higher, making us one of the
fastest growing companies.
We believe this growth results from a focus on ESL versus
the “automating the automated” focus of traditional EDA
companies. The software effort overtakes hardware at 130nm,
and the architecture effort overtakes physical design at 90nm.
ESL will only continue to grow in importance.
David Stewart, CriticalBlue – At
CriticalBlue, we have focused on the U.S. and European markets
for now. We also believe that Asia (especially Japan) will
also be a very good market for us. Our Cascade product is
generating significant interest because it works within
existing software and hardware development environments but
also delivers dramatic improvements in development time while
retaining a degree of software programmability. The
architecture, implementation and management of programmable
systems is the way forward because it ensures a route from
generic embedded software. Some day, all products will be
designed this way…
Brett Cline, Forte – Forte is leading the
charge in ESL by allowing designers to move up in abstraction
level. People have been using higher-level languages for
verification for some time now, but actual design is only now
enabled by viable high-level synthesis like Cynthesizer. We’re
leading the market in this area with more than 75 designs
completed, more than 10 currently in production now, and
several tapeouts already done. This is how to drive change and
that is what Forte is doing. Forte’s initial customers are
primarily in Japan, but we are now seeing serious activity in
Europe and more interest in the U.S.
Mark Lippett, Ignios – Ignios is a
semiconductor IP provider providing an efficient runtime
system management solution for heterogeneous multicore SoCs.
Commercially, we use ESL tools to demonstrate the value of our
solution, internally we use them for system level validation.
We engage with design teams around the world.
Ken Karnofsky, The MathWorks – The
MathWorks is the leader in Model-Based Design, which
encompasses embedded system and electronic system design and
verification, and integrates with downstream tools for
implementation. Model-Based Design with Simulink and MATLAB
solves the real problem facing electronics companies – that
design flaws introduced at the specification stage are not
detected until late in the process, causing delays and missed
market opportunities.
While ESL companies are talking about an upcoming age of
embedded software, MathWorks customers are using Simulink
today to design their embedded systems and automatically
generate production implementations on processors and FPGAs.
And while ESL companies are talking about modeling hardware at
higher levels of abstraction, MathWorks customers are using
MATLAB and Simulink to eliminate design flaws and achieve
multi-million dollar cost reductions and time-to-market
advantages because the chip works the first time.
Simon Calder, SpiraTech – We believe that
for the next 10 years the EDA front-end will be of
heterogeneous abstraction. More and more people are agreeing.
This means that for everything to work together, verification
components called 'Transactors' will be required by everyone,
everywhere. Transactors are the EDA devices that mix and match
the multiple levels of abstraction that exist at and above
RTL. SpiraTech makes transactors, but most importantly we are
the only company making tools which automate their creation.
We will supply a large library of transactors for common
protocols to all comers, make transactors for large companies
with proprietary interfaces to support and last but not least
sell our Transactor Compiler to those few companies who still
design major industry standard interconnects.
Transactors are used in simulation, test, debugging,
protocol checking, protocol coverage analysis and performance
profiling. Gary Smith reckons those 'ESL' markets should be
worth $600M by 2008.
Emil Girczyc, Summit Design – Summit
delivers System Architect to assist design teams with
architectural design and tradeoffs, and to analyze /
characterize system-level performance. System Architect was
first adopted in the U.S., and is now gaining momentum in the
other regions. Summit also recently announced Vista – the
first debug environment specifically designed for SystemC. It
is gaining traction first in Asia and Europe because this is
where the use of SystemC is more prevalent.
Simon Napper, Synfora – Synfora is
focusing on delivering a practical ESL synthesis that is a
practical capability for designing complete application
engines from C algorithms. We are focusing on the consumer
applications that are driven from C reference algorithms and
need custom application engines integrated into a platform
SoC.
We are focused on state-of-the-art algorithms such as the
H.264 video standard. Synfora’s focused on these projects
because designers are facing such a daunting design task. And
ESL synthesis becomes a lifeline to help them achieve design
project goals. These complex designs put significant demands
on the synthesis capability to produce complex hardware
structures, to automatically deal with unit-level and
system-level verification issues, and RTL-GDS issues such as
timing closure.
Q.13 – Do you agree with Wally Rhines' keynote
statement at DVCon that with the move to ESL, we can
anticipate 5 million people worldwide empowered to
design?
Gary Smith, Dataquest – Why not. We are
closing in on a million right now.
Jeff Jussel, Celoxica – Yes, and this is
the exciting thing about ESL. More than any other field, ESL
is opening doors for a wide variety of applications to use
semiconductors and in particular FPGA. They look at FPGA as a
way to accelerate their systems using a custom 'co-processor'.
The ESL tools are an enabling technology that will let EDA
sell into markets that up until now could not take advantage
of custom hardware. There are many more of these types of
applications than there are hardware design groups, or even
embedded software design groups.
David Stewart, CriticalBlue – I’m not sure
about the specific numbers but if you agree with my definition
of ESL above, then you can immediately include the majority of
the embedded software developers in our world; they all become
prospects for buying design automation solutions. If we, as an
industry, can harness that opportunity then the future is very
bright.
Brett Cline, Forte – There is no doubt
that moving up in abstraction allows additional people into
the mix more easily.
Mark Lippett, Ignios – It is our view that
the trend towards proportionately fewer silicon platforms that
have greater flexibility (i.e. programmability), will continue
unless design and fabrication costs become substantially
cheaper. For non-field reprogrammable hardware architectures,
this will restrict mainstream ESL usage to software
architectural exploration on a given hardware platform. On the
flip side, increasingly complex software programmable
platforms will mandate more representative environments for
software programmers; these environments can be created using
ESL tools.
Simon Calder, SpiraTech – Yes and no. I
think Wally was referring to the Embedded software developers
market.
An analogy that comes to mind is Gillette looking at China
and seeing 600 million new customers for Mach4. They know that
the percentage that can spend $25 on 4 razor blades today is
very small. Over the next 25 years that percentage will grow.
But Gillette already sells $6 Billion of razor blades at
margins we have not seen since the 1990's! We in EDA need a
quicker fix than that.
The worldwide semiconductor market as grown to $240
Billion, we in the EDA business should be at least 3% of that.
1.5% for time-to-revenue, 1.5% for yield enhancement, power
savings and die size. Getting our fair share from our existing
user base of lets say 100,000 is a much easier task than
turning 4.9 million people who currently pay nothing for
anything into profitable customers.
Q.14 – Is it fair to accuse any of the big EDA
players of standing in the way of the move to
ESL?
Shiv Tasker, Bluespec – No. The market
will drive the move to ESL, but only when solutions materially
impact overall chip projects, not just sub-blocks.
Jeff Jussel, Celoxica – The big EDA
players tend to be more conservative and let the innovation
and associated market risk play out among the start-ups. It's
not fair to say that they stand in the way of that innovation,
though at times their marketing machines create some confusion
that might slow things down a bit. In the end, they will join
in as the winning ESL methodologies and technologies become
apparent.
Mark Milligan, CoWare – It’s not fair to
accuse the big companies of standing in the way; they haven’t.
All are members and significant contributors to efforts like
OSCI. Some of them dabble in ESL in areas close to what they
do today. But it’s unfair to expect them to come up with
dramatic new breakthroughs—these typically come from new
companies. Partnerships are probably the best strategy in ESL.
Cadence, for example, partnered with CoWare to help accelerate
connectivity from ESL into EDA verification flows.
David Stewart, CriticalBlue – I’m not sure
that they are standing in the way of ESL. Rather, I think they
do not have the vision to first of all see the opportunity
that expanding into these new communities will bring. Second,
and perhaps more importantly, they don’t seem to realize that
the status quo – constraining EDA to the part between RTL and
GDSII – is barely sustainable and certainly isn’t a growth
opportunity. It’s in the name EDA – design automation – and we
need to spread that automation into other areas of the
electronic product chain. This is not optional, it must
happen, and if the big guys don’t do that us little guys
will.
Brett Cline, Forte – The big EDA players
have big revenue streams to protect. If a company has an RTL
product line that brings in $300-500M a year, they're going to
be very sensitive to maintaining that. It is very difficult
for the big companies to spend a lot of money on an R&D
group for a new product that will lose money for a bunch of
years before breaking out. This is one of the reasons that EDA
innovation traditionally comes from startups. But, make no
mistake – the budget money has to come from somewhere. With
the average customer budget increasing very modestly each year
(5% +/-), the ESL tools are getting money from the budget
traditionally allocated to RTL tools. This is why the big
companies eventually acquire the small companies – to get new
technology and grow.
Simon Calder, SpiraTech – No, I would
argue that I have seen more Start-ups mis-defining ESL and
distracting some of the investment that could be better
deployed in accelerating the natural evolution that is
occurring naturally. I would say that I have seen some of the
bigger guy's over estimate their influence on the customers
and make forlorn attempts to orchestrate the migration.
Emil Girczyc, Summit Design – I don't know
that it's fair to say that the big EDA players are standing in
the way of the move to ESL, but more appropriate to say that
they are trapped in the classic "innovators dilemma" as
described by Christensen – they don't see the solution because
it is not a natural extension of their business and their
existing customers are asking them for more and better of the
same tools for the same tasks.
The business of the EDA companies is based on hardware
groups designing larger and more complex chips that are then
programmed to build systems. With ESL, software applications
are designed, and then the hardware that best implements the
application is selected, often using large amounts of existing
IP blocks. ESL addresses new problems, and creates new
opportunities for companies that deliver solutions to those
problems.
Simon Napper, Synfora – They are not
standing in the way; they just don’t appear to be driving the
move. This is common behavior, as most significant
advancements in EDA technology have come from start-ups. They
(the big players) will start getting interested when they see
significant design wins by start-ups.
Gary Smith, Dataquest – Not really. They
are suffering from the same problem Calma, Applicon &
Computer Vision – Daisy, Mentor & Valid did when their
methodology changed. Let's see if Cadence, Synopsys and Mentor
can do better than those earlier industry leaders did.
[Editor's Note – Thanks to all of the
panelists for their contributions to this conversation. I'm
sure we'll be hearing more from all of you in various venues
over the coming months.]
Back
to Top | 
