|
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
|
