Warning: Undefined array key "upload_with_nude_flag" in /www/www_com/htdocs/get_weekly_feature_ad.inc.php on line 69


**********************************************

If you don't have something new to learn, you've stopped living.
- Mitch Dale

It takes courage and vision to move into the next technology.
- A.K. Kalekos

The adoption of ESL is inevitable, just as RTL was, but the important thing to remember here is that the older abstractions don't go away.
- Shawn McCloud

In the last 10 years, we've gone from 120,000 lines of code to 10 million lines of code. It's mind boggling to think how much software there is now.
- Shay Ben-Chorin

ESL should be thought of, not just as an abstraction, but as something with a system-wide scope.
- Steve Glaser

I have yet to hear about any organization that is doing all of their design at the ESL level. When I do, you all will be the first to know. If you hear about it before I do, can you give me a call?
- Larry Melling

ESL is turning from a nice, theoretical principle into some practical, mandatory flows that all companies are adopting. It's definitely not the last time you'll be writing an article about ESL.
- Frank Ghenassi

**********************************************

Welcome back to this lengthy discussion of ESL. If you missed the first installment of this conversation, please click here to read:

Part 1 - Fact or Fiction

* An Epic Story: ESL 2.0 = EDA 4.0
* Cliff Cummings
* Bob Brodersen
* Rudy Lauwereins
* John Derringer
* Gary Smith

Part 2 - Truths be Told

* Definitions & Dialog
* Mentor acquires Summit
* ESL agitation more on the hardware or the software side?
* ESL defined
* How long has the industry been debating ESL?

This week's installment is a continuation of Part 2 and is quite complex. It includes an update from OSCI, comments on ESL versus RTL, SystemC versus UML, SystemC versus SystemVerilog, simulation speeds at various levels of abstraction, the ESL-to-implementation flow and ESL synthesis, ESL and FPGAs, the current viability of the ESL market, global implications of the move to ESL, and various viewpoints about the roadmap going forward.

In other words, you're going to need a strong cup of coffee to get through it all. Hopefully, by the time you're done, you'll see some of the justification for concluding that ESL 2.0 = EDA 4.0

First, however, please re-visit the ESL Tools Table. Additional entries from Cadence and Esterel Technologies have been added.

We start with the list of contributors to this dialog:

**********************************************

The Contributors

A.K. Kalekos, Vice President of Marketing and Business Development at CoWare
Brett Cline, Vice President of Marketing at Forte Design Systems
Emil Girczyc, President and CEO at Summit Design
Eric Bantegnie, President and CEO, Esterel Technologies
Frank Ghenassi, at STMicro, Chair of the TLM Working Group within OSCI
George Zafiropoulos, Vice President of Marketing for Verification Group at Synopsys
Guri Stark, Vice President of Strategic Marketing at Synopsys
Hamid Agah, Senior Technical Marketing Manager at Xilinx
Jeff Jussel, Vice President Marketing and Americas General Manager at Celoxica
Jeff Roane, Vice President of Worldwide Marketing at VaST
Ken Karnofsky, Marketing Director for Signal Processing/Comm at The MathWorks
Larry Melling, Vice President of Marketing at Catalytic
Mitch Dale, Director of Product Marketing at Calypto
Shawn McCloud, High-level Synthesis Product Line Director at Mentor Graphics
Shay Ben-Chorin, Director of Business Development for System-Level Solutions at Synopsys
Shiv Tasker, CEO at Bluespec
Simon Davidmann, President and CEO at Imperas
Simon Napper, President and CEO at Synfora
Stan Krolikoski, CEO at ChipVision, Treasurer of OSCI
Steve Glaser, Corporate Vice President of the Verification Division Marketing at Cadence
Steve Pollock, Vice President of Marketing and Sales at JEDA
Vincent Perrier, Co-founder and Director at CoFluent

**********************************************

Part 2 - Truths be Told - Continued

**********************************************

* News from OSCI

December 4, 2006 - The Open SystemC Initiative (OSCI), an independent non-profit organization dedicated to supporting and advancing SystemC as an industry standard language for electronic system-level (ESL) design, today announced the delivery of the Draft SystemC Transaction-Level Modeling (TLM) 2.0 kit, containing proposed extensions to OSCI TLM API standards, an open-source library implementation, and interoperable modeling examples for world-wide public review by the SystemC community. Designed for use with the SystemC IEEE Std. 1666-2005 language and OSCI's standard TLM 1.0 transport API, the TLM 2.0 proposal extends the foundation upon which interoperable transaction-level communication can be built.

TLM 2.0 will broaden the standard by defining the content of transactions and how they are moved and controlled within the system. This includes new data structures and APIs for untimed programmer's view (PV) models of bus and network-on-chip based systems that can be used to enable concurrent development of embedded software and the hardware platform that work together to implement system-on-chip functionality. It also includes data structures and APIs for programmer's view with timing (PVT) models appropriate for architecture design and system performance analysis.

Design at the transaction-level enables users to efficiently develop SOC virtual prototypes to assist in architecture analysis and enable early software development, before any prototype can be completed. Transaction-level models can be used as golden reference models and directly embedded into functional verification environments, maximizing return on investment made in high-level modeling. In addition, transaction-level modeling enables the simulation performance required to meaningfully validate system functionality and co-simulate hardware and software. High simulation speed also allows the validation of IP in the context of the system. SystemC's ability to effectively span abstraction levels from algorithm to TLM to RTL makes it the ideal framework for high-level modeling and design as well as system validation.

**********************************************

* Questions & Answers

No. 1 - Define ESL.

Please scroll to the bottom of this article for a re-posting of the list of definitions provided by the contributors in the first installment. We add to that list, the following:

Eric Bantegnie - The definition I like most comes from Linda Prowse Fowler of Linda Prowse Fowler and Associates. She defines ESL broadly as, “The design and verification abstraction level above RTL,” and ESL synthesis as, “The ability to auto-generate the hardware, firmware, verification models, documentation, and debugger configuration files necessary to package IP and integrate platform SOCs while managing data and deliverables for the hardware and software teams as the design, requirements, and specifications evolve.”

No. 2 - Is there controversy around ESL?

Steve Pollock -- There is definitely a nomenclature controversy around how some people define ESL. For instance, Steve Glaser from Cadence has published an article where he says it's the whole enterprise, Enterprise System Level design. But in fact, the ESL controversy question is about the different levels of design. If you design at too low of a level, there's a spectrum of pure software issues you won't address. So you have to consider the different levels.

There's a level called PV, which is the Programmer's View. That's purely about the software. Then there's PVT, which is Programmer's View with Time, and it's the necessary level if you're starting to go toward bridging the hardware space. It's when you've got hardware with time and sequence involved, so it's not about pure software. Then there's the RTL level where you describe the hardware, but you can't run your software. SystemC runs from the highest transaction level all the way down to RTL. When you create your models, you do that at a high level and then follow the continuum down to the RTL. Of course, there are issues there. How do you automate? How do you synthesize? There are a lot of people trying to tackle these problems.

No. 3 - Is there acrimony between ESL and RTL?

Eric Bantegnie - I don't think so. RTL will remain the road to implementation in silicon. But the need for ESL is paramount as the design challenges increase to be able to have software-friendly virtual prototypes and a quicker path to implementation in RTL. Some ESL synthesis tools, like Esterel Studio, offer the dual capability of generating 100-percent consistent SystemC code for system-level design exploration, and RTL code for implementation in silicon. RTL generation is now working very well, and there are already large designs implemented in real silicon using such techniques.

Larry Melling - This question may get to the heart of the matter. System design is about having a holistic view, about what the end customer is really buying. It's not about the details of the chip inside. It has that whole product kind of view. If people paint this discussion as RTL versus ESL, they're missing the point.

Stan Krolikoski - To go from pre-implementation to implementation, there is a tension. One of my last jobs at Cadence was to try to figure out how system-level tools - a phrase I don't like too much - could be more physically aware. I asked the RTL group, "Is what you're getting from pre-implementation useful?" They told me that what they were getting wasn't useful. This was several years ago. The guys in pre-implementation clearly needed to start to be aware of implementation, so they wouldn't be asking for things that couldn't be designed.

Mitch Dale - ESL is a superset of RTL. It provides mechanisms to describe the hardware and the system, and provides verification orders of magnitude faster. Any RTL designer would want faster verification. So, regarding ESL versus hardware designers, they're starting to look at the scope of the power, functionality, and IP integration requirements, and they can see it's too hard to manage at the RTL level. They see they're going to need to be able to capture it all at higher levels of abstraction. Of course, they also know that at some point they're going to need to verify their RTL because that's what actually going to be built.

Also, an RTL designer may be limited in the types of power optimization he can deploy, the tools within synthesis or changes like clock gating. But if you move up to ESL, now you're actually able to do power tradeoffs at a much higher level with global strategies like power down or sleep mode. These things can only be done at the system level, taking into account the hardware, the various IP blocks, and the various applications running on the hardware. Even tradeoffs between having one microprocessor versus adding another one, and running them both at half speed where you achieve the same throughput, but with much less power - you can't do any of this with RTL. Designers can't get it done at the RTL level and verify it.

No. 4 - What is a virtual prototype or platform?

Simon Napper - What are people really trying to solve with ESL? I think it's the notion of a virtual prototype. With a camera chip or a video chip, I want to be able to simulate the whole chip. I want to see the interface running back and forth, but I don't care whether or not it's easy to simulate. I want a virtual platform that makes it easy to do system test. However, when I go down to implementing hardware, the solution may be entirely different.

Steve Glaser - Virtual prototypes can be used as a reference model for the implementation. They are also used in conjunction with some of the verification environments and advanced testbenches developed by the hardware team.

Jeff Roane - A virtual platform is a model of the real platform, and the accuracy and performance of that model are what matter. If you buy into the fact that you have to have concurrent engineering to have reasonably reduced risk equation and time to market, then your virtual model has to behave exactly like the actual thing. We sell to architects who are designing between the processors - the bus structures. Our solutions allow them to construct their candidate structures and verify them. Then they get a virtual model that can be handed off to the software developer, and is also handed off to the hardware developer for implementation. They get a model that's cycle-accurate when they're looking at a block that's written in SystemC. Then they create the RTL the same way everyone creates RTL today. After they design their RTL, they can swap it for the SystemC block, and simulate it within the RTL blocks. With our solutions, they get a virtual model that performs exactly as the architect intends it to.

If designers are not doing things this way, they're using English-based specifications, which are very ambiguous. A written spec can be several hundred pages long. Designers still read them today, but if they have questions they have to simulate the design to know with certainty it will perform in a certain way.

No. 5 - Why SystemC and not UML, or other languages?

Eric Bantegnie - UML, in general, is too large and general to fit the EDA world. However, we may very well see some variants of SysML system-level representations used in combination with SystemC code at the system design exploration level, just like UML and C++ are used together in the general purpose software design area.

Brett Cline - It's not about the language. C just happens to be the language it's written in. Software takes into account functionality, but the hardware guy also says it has to happen in a certain clock cycle, and within certain memory constraints. He cares not just about functionally.

[Originally], Forte would have chosen SimLib, which was a class library on top of C++ that implemented bit accuracy, concurrency, and hierarchy. But, we got steamrolled by the Synopsys marketing machine. We did not believe at the time that SystemC was a better language. That was in 1999, before OSCI. At that time Synopsys was getting customers to say that SystemC was best. We fought the battle for a long time and there was a lot of tension. But we realized in the long run, that there was benefit to the user community to establish one standard. So we joined OSCI and implemented things in the standard from SimLib that were superior to SystemC. Now SystemC 2.1 is the IEEE standard for reference simulation.

Stan Krolikoski- We choose SystemC over ANSI C because there was a need for hardware constructs - electronic-design constructs, like channels - that were built into a language that was going to be used in the electronic design area. Doing that in ANSI C was feasible, but typically you'd get a superset of the answer. C++ is more malleable, so SystemC was created as a layer on top of C++. It was easier to add channels - something that's a special kind of communication protocol between two protocols in electronic design and that has certain properties that are difficult to capture.

The other factor that drove SystemC adoption was the fact that Synopsys, Cadence, Motorola, STMicro, and NXP-Philips were involved from early on. Actually, the companies that were involved aren't that important, it's that they gave the process momentum. Otherwise, the history might have been different.

Ken Karnofsky - There is an assumption that there are many, many C programmers out there. The EDA industry says there must be an environment where you can do software and hardware design simultaneously, but the software is becoming more important over time. Therefore, if the software developers use the language, let's use C. However, that's a flawed premise. Because if you add all of these constraints to C to makes it applicable to hardware, the software people don't like it. But if you use C as a sequential language, it doesn't serve any purpose to the hardware community. So the whole discussion is [stuck] in this nowhere land. C is not in the sweet spot for the software or hardware community. It's good for architectural exploration, but not for hardware design.

Simon Napper - Clearly in ESL, different people are taking different paths and at every level, you have degrees of confusion and complexity. If we could segment the move to ESL in terms of the dominant driver, it's the consumer market - cell phones, digital cameras, set-top boxes - and they all start of with a specification in C. People all want to get to silicon as quickly as possible, so we say if the spec is in ANSI C, why not take the implementation in ANSI C? We say we'll create the SystemC model from that, which allows you to fit it back into the environment.

Meanwhile, there are the MATLAB/Simulink guys who tend to be at the block level. Their users use MATLAB to come up with an implementation. AccelChip was sort of around that implementation path, but that's now used by Xilinx. [Xilinx purchased AccelChip.] And, once you've got a black box, you can use UML to export that IP to other groups. So, if you have a video codex, the interface is open to interpretation. But at every level, you have degrees of confusion and complexity here.

Hamid Agah - SystemC is a standard that came into existence a few years ago. It tried to solidify the industry behind one common high level of abstraction that has libraries or constructs that bring hardware aspects into the high-level languages. At Xilinx, we've always believed that solid standards will be adopted. We want to help those partners who have gone to higher levels of abstraction, and have tools that come from there into our system. SystemC came into the picture, and there are some who are standardizing on it. But that doesn't mean it's the only language out there, or the language for starting the design flow.

Shiv Tasker - English is a language, and how you use a language is important. You can write low-level stuff in SystemC. You can write RTL in SystemC. But if you write high-level SystemC, can you generate hardware from it? The answer in a lot of cases is no. So, the algorithmic synthesis guys require you to write SystemC in a specific way. We specify this is the way you must write SystemC to generate competitive hardware from it.

Shawn McCloud - The reason you're seeing multiple languages is that it's difficult to have one language for an entire implementation space. For example, in DSPs, C is a natural choice. It's already the dominant language of choice for DSP processor design. So, in that space, the natural path to take is to use C to [achieve] dedicated hardware. However, with a DMA controller or a network switch, there may be a language that is a better fit. I'm not going to comment on which, but one will bubble to the top. It's always about survival of the fittest.

From the verification point of view, both SystemC and SystemVerilog are being used to help verify designs. These two languages approach things from both ends of the design process. SystemVerilog is used by hardware verification and integration engineers to formally verify inter-block communication protocol. SystemC is used by system architects to create virtual prototypes to optimize system architecture. One starts at top-down, and one comes from bottom up. They're largely complementary for verification, although in the long run they may tend to merge in their capabilities.

From an implementation point of view, we think in order to achieve 10x to 100x improvements, we must move away from the HDLs and go to other languages. From Mentor's point of view, ANSI C++ has been attractive to our users when they're asking, "How do you get constraints into the design?" We're talking here about high-level synthesis, and there are two ways to get there.

One way is that you can embed it in the source, hardcoding it into the C-code description of the I/O protocol. Or, you can keep the C code neutral and use an external set of constraints, separate files that apply high-level synthesis tools to target C programs to certain hardware protocols. I like to call this the difference between ANSI C++ and Hardware C, where you're actually embedding details in the source.

Mentor does champion SystemC, and we have verification products that leverage the language. If you look at SystemC adoption today, the overwhelming use is for verification at the system level. But if you're looking to create new IP, new innovation, new design content - the better place is the higher abstraction in ANSI C++, and then using high-level synthesis to output RTL. The output, the RTL model, then fits into your verification environment, which allows you to use both worlds. It's hard to quantify how many people buy into this philosophy, but if you look at some of the research data, it's clear that the dominant verification language is SystemC. However, in ESL, you still see a combination of languages.

Steve Pollock - The nice thing about SystemC is that it's readily adoptable by software developers. It's C++ with the concepts of signals, and it's basically a programming language. It's also easy to adopt in two different areas, that of the system architect and that of the testbench engineer. These are two different markets and SystemC is used effectively in both.

Mitch Dale - I think SystemVerilog is catching on somewhere within the verification space, from talking to customers repeatedly over the last few years. But people have been writing C models pretty much forever, which is why it's SystemC [for ESL]. The difference between now and a few years ago, however, is that the C models used to be written by the architecture guys and then discarded. Today, you can't do that. You have to use those models for the software developers. There's too much fidelity there to throw them away. They include the assumptions those initial engineers are using to describe the system.

Vincent Perrier - Simulink is only a data aggregator and UML is really on the software side of things. It's not very good at representing the hardware side of things, and is absolutely not executable. So you can't really simulate with it, get a busload, a CPU load, or a real time load. Although, you can get that with CoFluent.

Frank Ghenassi - ANSI C and SystemC are very complementary, but ANSI C cannot describe parallelism, or communication between parallel blocks. That's what SystemC is providing. Actually, at ST that's the way we do it. We do our algorithms in C and wrap them in SystemC to model the parallelism and communication between the parts of the chip.

At one time, we were looking at SpecC, which was some very nice university work that tried to get into the industry but didn't succeed. Also, HandleC always remained a language from a startup company because it didn't include all of the features that we required at the time.

A.K. Kalekos - UML is a specification language mostly used for software design that is now trying to expand into hardware design. I think that UML may be a factor in ESL design, but it would be for a subset of the product platforms. UML is ideal for components that are brand new, but it's not necessarily the perfect environment for capturing the entire platform. If you're doing a new product, you're using a lot of legacy blocks, so UML theoretically attempts to start with a blank sheet of paper and allows you to refine and define the design. But that's too theoretical for what the products people are doing today.

Today, product development is about innovation and intelligent reuse, and ESL design using SystemC is a far more effective way to do that. Having the right kind of platform is a key concern for ESL design because hardware/software co-design is a big part of the value proposition.

No. 6 - So, ESL is about IP as well?

Mitch Dale - The whole ESL thing is fundamental to making IP really work. It's pretty exciting, because you can now provide a model for people to build their architecture around, so hardware and silicon can be built. The same model can be given to the software developers. From this standpoint, ESL is almost a necessity for having a very active IP market.

Steve Glaser - Yes, because the number one problem is that IP be qualified within the context of the system. But, IP blocks tended to have configurations that weren't verified, so it became a service business to modify them and make them work.

A.K. Kalekos - In IP, the SystemC models are not as far along as the RTL models because the RTL models have been around much longer, but SystemC models are catching up. And, thinking in terms of the supply chain, if you want to work with the semi guys you need to models in SystemC. Everybody still does RTL implementations, of course, but they're also providing SystemC models these days. [In fact], I think it's catching on a lot faster than RTL did. Over the last four years, we've seen more SystemC models [developed] than SystemVerilog models over the first four years of that language. We're rapidly approaching a critical mass of SystemC models. And although we're not quite there yet, but we're certainly at the tipping point.

No. 7 - Is there a SystemC versus SystemVerilog war brewing?

Jeff Jussel - I don't see SystemVerilog and SystemC as competitive. SystemVerilog is really an extension of the Verilog language, with added features but still an RTL-level description, not a behavioral-level description. SystemC can be an ESL language, though sometimes it is not applied that way, but certainly SystemC is a system-level language. However, whether a design is implemented in software or hardware, SystemVerilog is only for hardware.

Simon Napper - I don't think there's a war brewing in those camps like the VHDL/Verilog war in the past. The users just want things that are interoperable, so marrying SystemC and SystemVerilog may be very important. Someone at the system level may want to run a black box of IP, so the two languages are going to have to get along. [Nonetheless], I see SystemC as absolutely dominant from my personal perspective.

Simon Davidmann - People get bogged down in the SystemVerilog versus SystemC world. There might have been ambiguity seven or eight years ago, but it's over. Verilog, SystemVerilog, SystemC, or the next best thing - the real problem is the next generation of capabilities.

Hamid Agah - The question here is what is really at the heart of abstraction. Is it SystemC or SystemVerilog? In our view, it's whatever allows you to come into the design flow from any level that exists today.

Frank Ghenassi - SystemC is definitely not a competing language for RTL descriptions. However, it is a very powerful language - a higher-level language for hardware components.

Steve Pollock -- Well, it's a religious war as any kind of verification [debate] always has been - Verilog versus SystemVerilog. So there's a SystemC versus SystemVerilog war, too. However, the people I talk to certainly think that SystemC is the way to go for virtual prototypes. I think it's used as a point of reference. If you're a chip designer and living in the Verilog world, extending up with SystemVerilog gives you great testbenches, etc. But you really can't run your software, so I don't see anybody booting an OS with SystemVerilog. There are, however, lots of people doing it with SystemC.

Stan Krolikoski - My answer is no. I've been in SystemC from the beginning, so I don't speak as someone who is totally neutral. But speaking with my OSCI hat on, we have not run into people who are making the decision who say that they're using SystemC or SystemVerilog exclusively. We're finding that people are comfortable working at the pre-implementation level, who have been working with C++ and who are now comfortable in SystemC. Those designers who are raising their level of abstraction are usually very comfortable with SystemC.

There is also a certain overlap between SystemVerilog and SystemC, but there doesn't seem to be a real conflict there. But there's always overlap - even Verilog and SPICE overlap at the borders.

I recognize language wars when I see them, and as far as language wars go, this one is a dud. It's a non-starter. I give credit to Dennis Brophy and Shrenik Mehta at Accellera, and Alain Clouard at OSCI. I also give a lot of credit to the guys on the boards of Accellera and OSCI, because we could have gotten into a reprise of the VHDL/Verilog wars, but that's exactly the opposite of what the industry needs. We need cooler heads to prevail. It's true, certain people just love SystemC or they just love SystemVerilog. But in general, people who have been managing the process have been talking to each other constantly and working together productively.

No. 8 - How is OSCI going?

Stan Krolikoski - OSCI was started in the last 1990's by Synopsys and CoWare. Cadence joined a year or two later, and then Mentor. I'm not aware of any problems that will prevent OSCI from going forward. Our mission is to continue to push the adoption of SystemC, and it's going very well. There are multiple ways to do that. We sponsored the IEEE effort that standardized SystemC last year - we gave financial aid. And we've made donations to the IEEE standard. Of course, we also do technical reports.

The excitement and the reason companies are joining is because people want to be part of the transaction modeling group. That's a method of modeling interfaces and communication between the blocks - modeling at the higher, pre-implementation level. We announced at DAC this year that we have 11 new corporate associate members. At the moment, we have 9 corporate members on the board and 21 associate corporate members, with a mixture of users and EDA companies. That's 30 companies in total for a group that only had 6 members a few years ago.

Frank Ghenassi - Standards bodies are mandatory for promoting and driving standards. That is happening with OSCI, and also with SPIRIT where I am involved as well. You need a place where all industrial players can meet, exchange ideas, and converge on some technical specifications. And it is mandatory for these technical specs to emerge. And then it's important to promote the specifications into the industry. In just the same way that even if you have a great product - a chip or a mobile phone - if you do nothing to promote it, you will have no market share.

Looking at the CAD companies involved in OSCI, Cadence, CoWare, and Forte have probably been the most active companies to promote and support and evolve SystemC. Mentor was not an initial participant, so it was not so involved in the early days, but lately they've been very involved. And, Synopsys is back in the system business these days, so that pretty much means that all of the EDA players are supporting OSCI. And that's not to say that other companies don't support it as well. As we integrate more and more IP into our chips, we have to have standard interfaces so we can simulate the IP models.

The reason we need standards, ultimately, is to promote competition between our suppliers. Competition means having an open market. Competition allows markets to grow, which means lower prices. Actually, all of the users - ST, Infineon, TI, Freescale, etc. - all these people and their suppliers - the EDA vendors - we all have an interest in standards which allow us to compete.

[Note: See the list of OSCI members and the Accellera members at the end of this article.]

No. 9 - Is a company involved in any way with SystemC necessarily an ESL company?

Jeff Roane - It all depends, which is a reflection of the ill-defined state of ESL.

Emil Girczyc - We've often said that SystemC does not equal ESL.

Vincent Perrier - It depends on how you use SystemC. If you're using SystemC 1.0 to design hardware, it can be seen as an HDL. But with 2.0, you're definitely doing ESL.

Steve Glaser - SystemC is not synonymous with ESL. It's the choice for the front end of the process, but it's not the entire definition. It only includes a small subset ESL - one or maybe two specialists are using it within the context of five or six specialists involved in design.

A.K. Kalekos - Not necessarily. SystemC happens to be the language for doing ESL design, but SystemC alone is not ESL design, because it can be used to do RTL design, or even gate-level design if someone is perverse enough to do it. SystemC, however, is the de-facto language standard for ESL design.

Stan Krolikoski - Not necessarily. Way, way back when Synopsys and CoWare wrote SystemC, I was at Cadence. The original SystemC spec looked like an HDL. I asked in an article I wrote at the time, "Is this actually HDL in a tuxedo?" But since then, we've added a lot of mechanisms for abstraction. You could do SystemC and it would be almost equivalent to SystemVerilog. The fact you're using SystemC doesn't mean you're doing ESL. You could also use an HDL to do pre-implementation work.

Brett Cline - Not every company that's involved with SystemC is an ESL company. Not everyone that uses our tools is an ESL design company. Some people just want a better way to do hardware design. They make high-level models of their design and use those models for verification or to generate hardware, but they have no intention of dealing with system-level issues. A lot of our customers are just building really cool ASICs, and they need a tool for that work.

Shiv Tasker - An ESL vendor has to meaningfully raise the level of abstraction and generate hardware. Mentor and Synfora are definitely ESL vendors. Other companies put themselves into the same category, but I don't have experience with those tools. The current ESL vendors handle datapath design, but not control logic. You can put control logic into Forte Design, but you're putting it in at an RTL level. RTL designers ask, what's the big deal there because you haven't saved any time or money?

Using SystemC isn't necessarily doing ESL, but neither is using SystemVerilog. If you're writing RTL in SystemVerilog and you're coding all the scheduling yourself, you're responsible for all module communication. But even if they're structured as interfaces, then you haven't raised the levels of abstraction. You've used some features to express structures more succinctly, but you're still just as susceptible to all the race conditions you would have writing and debugging regular RTL.

Guri Stark - In the ESL industry, standards are very important and we believe SystemC is one of those important standards. We support SystemC and, if you remember, Synopsys was one of the originators of the language standard. However, SystemC is just a standard and doesn't mean you have a system-level solution.

Simon Napper - SystemC does not necessarily equate to ESL. Because, SystemC is such a broad language, you can write a very broad model in SystemC. And, you can even do RTL in SystemC. Would you want to do that? If you want to describe a widget at a very high level, you only want 20 percent to be detailed. Of you want a specific interface at the detailed level, you're doing some modeling at a high level, and some at a low level.

Eric Bantegnie - I don't think so. Barely simulating SystemC code does not offer particular customer advantage. The common denominator for me between ESL companies is that they help customers architect large system designs into specific sub-systems, they design all the sub-systems with the relevant tools, languages and techniques - designing and efficiently verifying buses, complex control IP, intensive datapath and processors core requires very different technologies - and, they automate the integration of all the sub-systems in a seamless way. In a nutshell, it's the old "plan, divide and conquer story."

No. 10 - Cliff Cummings complains (in Part 1 of this article) that SystemC is too verbose. The simulation speeds are good, but it's not designed the way a hardware designer thinks. Can we achieve SystemC-like speeds in SystemVerilog?

Larry Melling -- SystemC and the C-based languages are absolutely too verbose and too abstract, and they leave way too much to the users. And, a C-based language doesn't have the concept of concurrency. Without concurrency, you have to build up that infrastructure yourself.

So, if you go to a C-based language, your options are - do I want to write my own simulator, or will I go to some standard tool? Naturally, designers walked to Verilog, which was C-like in its flexibility and abstraction when it came to implementation, but also took care of concurrency and the basic infrastructure that hardware people need.

To get to the system level, you need to lose some of the details if you're really going to execute system-level types of validation - you do have to give up some accuracy. And that's why SystemC and transaction-level modeling is really going to take it to another level of reducing the amount of processing that has to be done, so you can get to a much larger descriptions.

As far as the speeds are concerned, it's pretty much about the physics. You can do creative algorithms and things, and better event-based algorithms, but the bottom line is the number of events you have to process determines the speed with which you can simulate.

George Zafiropoulos - When comparing SystemC and the HDLs, speed is mostly a function of the abstraction level, not the language. Most people use SystemC at the transaction level, or above, and thus have very high perceived performance compared to the same design running at the RT level in Verilog or VHDL. SystemVerilog adds many new high-level modeling language constructs, such that you can very easily construct a model at a higher level of abstraction and get higher performance. In fact, for a given level of abstraction you may actually get even higher performance in SystemVerilog than SystemC, due to SystemVerilog's better handling of concurrency and multiple threads, as well as the years of performance optimization incorporated in SystemVerilog platforms like Synopsys' VCS solution.

Emil Girczyc - The language issue comes in two parts - the level of abstraction is not a language-specific discussion. There is an edge for SystemVerilog, but you don't write system software in SystemVerilog. You write it in SystemC, which is a derivative of C and C++. If you're doing hardware/software and moving to a higher level of abstraction, and trying to simulate as fast as you can, SystemC is the C-like paradigm [where you want to do that].

However, what's missing [in this whole discussion] are a couple of high-profile success stories. We've been focusing on sequential adoption, and we've seen things happening here in 2006, as many of the IP vendors have been delivering SystemC-flavor or versions of their IP. We've seen a couple of announcements, and we're seeing that things are happening. So there's a natural progression. If the models are coming in SystemC and the tools are there, or there is freeware that the vendors have put together, it's going to make the choice of going to SystemC much more compelling.

Jeff Roane - If you go and look at a lot of vendors out there, they tout SystemC, as we do. SystemC is an important standard, but the language's simulation speed is without cycle accuracy. With cycle accuracy, a simulation and a language are slow. So, the market has dissolved into providers with hybrid solutions that can be slow and accurate, or fast and not accurate. However, our solution is fast and accurate. What we're delivering is the necessary speed and accuracy to be able to enable concurrent hardware/software development.

Shiv Tasker - I completely agree with Cliff about SystemC. It has its plusses and minuses. However, there are lots of people who work as architects with a software background, and they're more comfortable in a C environment than HDLs. SystemVerilog has a lot of advantages for writing testbenches, but writing testbenches doesn't let you write a high-level design. So personally, I'm with Cliff that SystemVerilog is much more hardware centric, less verbose, and easier to learn. But the way we have implemented our concurrency implementation model, we don't give anything up to be in SystemC environment. In fact, on our website, we've got a couple of different challenges. We ask, "Can you do this in any other language as well as we've done it here in SystemVerilog?" So far no one's been able to meet the challenge, so there are a lot of things that I agree with Cliff on.

However, I also think customers come from their own set of constraints, and having the flexibility and being able to choose one over the other is important. We take a SystemC description that's unscheduled and our tools perform the scheduling, the power optimization, and the resource optimization. Then we write out a Verilog RTL file that can be easily synthesized by tools such as Design Compiler [Synopsys] or the Magma tools.

Brett Cline - I respect what Cliff has to say, because he has taken the time to educate himself on it. He's really studied the situation. But, verbose? There are some pieces in C++, in general, but frankly - once you have the template in place, it's no more verbose that any other high-level programming language, so our customers never complain about it. If you write in SystemC, you'll write 10 times less code, and therefore have a faster simulation, which means you'll have 10 times fewer bugs. You think you're losing control, but you're only losing control of mundane tasks.

From the early days of SystemC, people tried to write RTL code with it. What they found was that their simulations were no better than in SystemVerilog, because what you're comparing here is languages, not abstractions. You could argue that if you run SystemVerilog at a high-enough abstraction level, you would get speeds like in SystemC. But would people really do that? When you write behavioral code in SystemC - working at that higher level of abstraction - the number of things happening are significantly less than when it's written in SystemVerilog.

There's no way that SystemVerilog can be fixed. SystemVerilog is just the next version of Verilog. It's what Verilog should have been 10 years ago, with some neat stuff added. It does allow better handling of RTL-based design, passing pieces at a higher level, but it's still RTL-based design. At the end of the day, however, it won't simulate any faster than Verilog. There may be interesting ways to write SystemVerilog at an algorithmic level that don't care about resource scheduling, but the problem is that nobody knows how to do that. Algorithms are in C or C++, so from a simulation standpoint, and because of what people do in SystemVerilog, you'll get RTL.

Consider the journalist's analogy. A journalist could hand write an entire article, or they could use a typewriter which would be faster than writing by hand, but without the editing capability you get with word processing. Or, an article could be written using a word processor, or using voice recognition, or sent by e-mail. In those cases, changes could be made really quickly. That's what behavioral synthesis is all about.

Simon Napper - Cliff is trying to make it better for the hardware designer, and obviously the faster the better. SystemVerilog is good for hardware, but people want to simulate the whole system. I have no doubt that SystemVerilog may be good for hardware designers, and it may be good for those who want to implement, but that's not the problem in ESL. [In fact], people have questions about whether SystemC is even fast enough.

I'm not disagreeing with Cliff, but the way we partition the problem - you've got architects and they like playing with C, designer like to play with C or MATLAB, and it's the verification people who are playing with SystemC. We think a lot of the drive to SystemC has come from the verification point of view. [However], it doesn't surprise me that designers aren't into SystemC, and would probably prefer SystemVerilog. However, you should also talk to the guys at ST. They've been very active in not just talking about SystemC, but about driving it into their product group. And they've been talking about how must faster they were able to come up with the design.

Frank Ghenassi - To me SystemVerilog is more of a design language, for people looking for an enhanced version of Verilog plus some verification features. Designers needing to tackle complex blocks should definitely go for SystemVerilog.

SystemC, however, is a much different approach. If you're designing a system and you're really tackling the system, you don't start on the problem by defining a piece of RTL. You need a more top-down approach, and SystemC is the language you should be looking for. It's a natural evolution to continue with SystemC to sustain those activities.

No. 11 - Why not simulate some parts of the model slowly, and some parts faster.

Simon Napper - Yes you can do that, but if you've got part of a span that's running at 100 miles per hour, and a part that's only running at 1 mile per hour, your aggregate speed moves down to 10 miles per hour.

No. 12 - So, nobody should hold their breath that SystemC is going to overtake SystemVerilog?

Shiv Tasker - That's absolutely true. Nobody's going to do RTL design in C. So the real question is, is there going to be something like Bluespec, or one of these algorithmic synthesis guys who propose different models around concurrency and communication, that will provide high levels of abstraction? The issue isn't how to do detailed design in SystemVerilog or SystemC. Neither of those languages are meaningfully changing the timelines or anything else. In themselves, they don't raise the level of abstraction.

Simon Davidmann - People aren't going to jump from SystemVerilog to SystemC, because SystemVerilog is for implementation, and SystemC is a modeling framework. The challenge is in the methodology.

No. 13 - So, is there a demand for SystemC versus the HDLs?

Brett Cline - Before SystemC was around, SystemVerilog looked more natural to an engineer because they asked, "How do you do timing in C, because the designs that are done in high-level C code are untimed?" However, when you integrate a block of functionality into hardware, you need an interface and some protocol, because you have to describe things in such a way that it's timing accurate, bit accurate. C and C++ don't have that capability, but SystemC does. SystemC is definitely being used for high-quality hardware design.

We recently asked the vice president of a major computer company if they have anyone on their hardware design team who knows C. He said, "Yes, our best and our youngest." That's been the trend as we've moved through these last few years. It's absolutely true that the younger designers just know C, but hardware-design knowledge is still at a premium. We can certainly give our tools to any young software designer and they can come up with hardware. Historically, it was the same thing with the move from gate level to RTL. It was the marketing guys who didn't want to make the transition. With SystemC, people will figure it out eventually.

Jeff Roane - At the RTL level, you see strong VHDL use in Europe, and Verilog use in the U.S. But at the system level, we're talking about using SystemC for doing high-speed simulations capable of developing software. Early in my career, with every new project we would switch languages. We went from our own internal LISP-like language, to early VHDL, to other vendors' proprietary languages. I remember our frustration. I had a mentor at the time who said, "Who cares? It doesn't really matter as long as the language is expressive enough."

Languages are moving targets over time. They mature at a speed that's dictated by their adoption. It's not really important whether it's SystemC or SystemVerilog, a language will evolve until it has everything that it needs to be productive. SystemVerilog is an outgrowth of Verilog, whereas the customers that we see are overwhelming demanding SystemC. SystemC is a standard, and standards enable the tools to work together in the context of the flow - they accelerate the development of a certain class of tools. Propriety formats prevent that from happening.

Shiv Tasker - The answer is different with every customer. Every customer has different needs, and will want to migrate up to higher level of abstraction in a different way, so we'll take a language-neutral stance. We have both SystemC and SystemVerilog as host languages. Originally Bluespec's emphasis was on SystemVerilog, but now we have SystemC, as well. The important thing we changed is the concurrency model. In SystemC, the concurrency model is exactly the same in SystemVerilog, Verilog, or VHDL. The engineer is responsible for doing all of the scheduling of the design. If you're responsible for all the scheduling, you can easily make mistakes, and you'll have a long verification cycle. You're not really abstracting anything, and you're doing all the work.

So, at one level I don't care - I've got SystemVerilog and SystemC products - but a lot of people with an architect title, who have a system overview responsibility, or don't have a hardware background, want to be in C++ environment, especially since software is more and more important. In my mind, however, it makes no sense whatsoever to take an excellent HDL guy and make him a mediocre SC guy. So we started with SystemVerilog, put a concurrency model out there, and then implemented it in SystemC as well.

Vincent Perrier - I can understand why people from the hardware world know how to use VHDL and Verilog. And I can understand why it may be tough for them to use SystemC. They may be a huge learning gap for those people. But there is technology that's useful for executing models and connecting the two things together. From the execution point of view, it's okay. But from the interoperability point of view, there's still a lot of improvement needed between the standards, and between the blocks.

Our philosophy at CoFluent is, if you don't want to write in SystemC you don't have to. We have software implementation graphics that everyone can understand, and we create the SystemC automatically. And if you want to learn SystemC, this tool will help you.

No. 14 - Will it ever be possible to do hardware and software design with the same language?

Vincent Perrier - Yes, absolutely. Some kind of automation will be found to accomplish that. You can already see early ideas of what that will look like with the SystemC synthesizers. I think Forte is doing that kind of thing, and Mentor has Catapult.

No. 15 - So, can you, or can you not, sign off on a design at the ESL level?

Larry Melling -- I have yet to hear about any organization that is doing all of their design at the ESL level. When I do, you all will be the first to know. If you hear about it before I do, can you give me a call?

Emil Girczyc - You can not today, but you can do higher-level system verification and design in ESL, and then the lower RTL verification to make sure the pieces work together. There's lots of opportunity there, with some of the more advanced formal techniques available.

No. 16 - Is it possible today to work in SystemC, and have the design implemented in hardware without subsequent intervention?

Frank Ghenassi - If you're referring to synthesis tool, we do use Forte or CatapultC [Mentor] for behavioral synthesis - but mostly for signal processing. For most designs, however, we still handcraft our RTL. We do our verification environment and reference models in SystemC, and then the rest is done by hand.

That may be changing in two ways, however. The behavioral synthesis tools seem to be getting more interest from the design community, and more and more we have embedded cores in the subsystem that instantiate the control logic rather than implement it in hardware.

Shawn McCloud - Yes, for certain segments in the market like the wireless space and the video/image processing space. Basically in consumer products, you're seeing adoption in that space of ESL products. What's the flow? First, remember that no system is usually all described in C. Usually, a system contains 70 to 80-percent legacy RTL. So the question is, is there a path from the new IP blocks - that the 30 percent of the design that's new - down to implementation? High-level synthesis is being used with that, but in some cases it's still [about] using RTL methods.

There's nothing today that allows you to push a button and get optimal hardware and software. That's still a couple of years away. In high-level synthesis, there's CatapultC from Mentor. But in verification, it's still a battle. And in design, that one is lagging behind the most. There will be a natural evolution and survival of the fittest. There will be one or two products, and a bunch of little companies. Then you're going to see an actual [solution adopted by the design community].

The tool that allows you to insert concurrency will be highly interactive - it's a design process of transformation. So in high-level synthesis you can compile, schedule, do a datapath and finite state machine extraction, an RTL extraction, a backend optimization, and a netlist generation. Currently, in CatapultC, each one of these is a stopping point applied interactively by the users. Eventually [it will all be automated].

Ken Karnofsky - How you connect hardware and software together at the implementation level is still an open question. At the starting point of system design, it's how to partition it into software and hardware, and that's where Simulink is useful. We're seeing that in many places where the amount of code that needs to be written [is overwhelming], people are moving away from C to automatic code generation for models.

Product development schedules are too short to test all of that code. And in industries like automotive and aero, bugs simply can't happen. So people have found that you can get much better models with automatically generated C code. Our tools [support] a parallel structure, which allows you to model at one level and go into hardware and software at the next.

Jeff Jussel - In our case, we provide the path to implementation in an FPGA. Maybe [the solution] will be in hardware, or in the software, but we create verification models to reflect the functionality at the algorithmic level. While we do [provide the tools] that take C code and implement it in an FPGA, it's meant to be used as an acceleration tool. It's used for embedded design in applications like cameras or computers. [We believe] that's where ESL comes into its strength, not as a replacement for RTL. ESL enables using FPGAs as co-processors.

So, is there a path to implementation? Sure, there's a path, and it's as automatic as any RTL path created. Of course, Forte provides a path from SystemC to ASICs, and Mentor has a different flavor of synthesis tool. Those are paths from transaction level down to ASIC, and they're very productive.

Simon Napper - It's only recently that you've had a practical way to go from SystemC to hardware. Certainly from an untimed C or SystemC description, there are at least three vendors who offer solutions to that - Mentor, Forte, and Synfora.

Emil Girczyc - There's always intervention, but there's a lot of verification and design work going on in SystemC, in the transaction level and modeling paradigm. With standards-based OCP-IP, and companies like ARM, everyone is working at a transaction level through reuse, and through customers' detailed RTL-cycle accurate designs, to interface to the protocol. People are using TL2 and TL3, getting most of the design working, and then using lower-level [design flows] to put it together. You still have got to do some work at the lower level, however.

Steve Pollock -- Forte and Bluespec are playing in that field and, in fact, a number of people are trying to tackle that problem. I haven't talked to any customers that have a pure SystemC flow yet, anyone who can push a button and get RTL. But the whole subject opens up a big verification challenge. If you have a high-level model and a low-level model, how do I verify the design? That's an equally daunting challenge to establishing a flow.

Eric Bantegnie - We believe at Esterel Technologies that the way to get the best of both worlds is to design high-level IP specifications in a domain-specific language (Esterel for control, MATLAB for datapath), and generate fast SystemC for transactional simulation and RTL for hardware acceleration on ESL emulation boards like EVE.

With this strategy, you get both a software-friendly representation in SystemC and hardware-accelerated performances if you require cycle accuracy. It is a must that auto-generated RTL from ESL synthesis tools does not suffer from any performance loss. Otherwise, customers have to do double work at ESL and RTL-level design and then loose all the benefits of high-level design. This is quite important for control-path intensive IP, because a good result one cycle too late has no value and can even break functionality.

Jeff Roane - There are behavioral synthesis tools and this is a field that's still in the early stages of development. Mentor and Forte have SystemC to RTL capabilities, but for the most part people still go the manual route because the tools are not useful enough for a broad set of descriptions. It's analogous to the early days of synthesis. In 1991, when I started at Synopsys, designers would never synthesize a processor. They would only synthesize logic. But as a technology matures, design styles and applications grow. So, although today we've got part of the [ESL to RTL] synthesis problem solved, we're still waiting for behavioral synthesis to expand and mature.

Shiv Tasker - We have a way of expressing behavior that's unscheduled, so it's at a very high-level with no clock concerns. Our compiler looks at that design and figures out how to generate quality hardware from it. There are tools from companies like Synfora, Poseidon, Forte, and Mentor that say, "Give me some math, and I'll give you an implementation."

But we say, "For any control-centric design, we will give you a way to raise the level of abstraction and express the design at a very high level." For datapath, there are absolutely tools today where you can create competitive RTL. For control logic, however, there is only Bluespec. The technique we came up with for doing that is very patent protected.

Brett Cline - Absolutely, look at our customer list. We've got 18 designs that have gone to production, 130 designs completed. One of the other ESL vendors said that SystemC is finally synthesizable, but our customers say that SystemC has been synthesizable for 5 years.

We take high-level algorithms in C, C++, and SystemC and automatically create hardware. For designs described in high-level algorithms, we use that design representation to create high-quality hardware, designed in a fraction of the time that it takes in RTL. We work in both ESL and emerging environments, on super high-level, top-down design implementation.

What we're doing is using designs described in C, not RTL designs, and we're creating high quality hardware. Behavioral synthesis handles fine-grained parallelism. The tool takes the place of allocating logic, but if your design requires that it all happen in one clock cycle, you may have to have somebody with some hardware knowledge create the model.

No. 17 - What is Forte's beef with John Cooley?

Brett Cline - Whether or not it is possible or practical to use SystemC for hardware design. John has a history that makes a solid argument. Ten years ago, there were ESL tools that are no longer around, [that claimed to work, but didn't]. He has a massive legion of RTL designers who don't want to move to higher levels of abstraction, but also can't get enough done. Now they're starting to embrace SystemC, but slowly.

No. 18 - Are customers having trouble distinguishing between the various "ESL" companies?

Eric Bantegnie - Yes, and this is linked to a lack of adequate segmentation of the ESL market. If we correctly segment ESL between system design exploration and virtual prototyping on one hand, ESL synthesis on the other hand, and ESL integration in a third part, you begin to have a map of this new territory.

I believe the ESL tools landscape is currently being segmented between:

* System-Level Design Exploration Tools, which essentially enable software developers to abstract away non-existing RTL implementations by providing an environment where cores, protocols, busses, IP, etc., can be very rapidly simulated in software-friendly representations -C, C++, SystemC. Typical examples are ARM RealView SoC Designer, CoWare, and VaST. SystemC is gaining rapid acceptance in this segment.

* ESL Synthesis Tools that use domain-specific representations to auto-generate the hardware, firmware, verification models, documentation, and debugger configuration files necessary to package IP and integrate platform SOCs while managing data and deliverables for the hardware and software teams as the design, requirements and specification evolve. Given the very different technical nature of datapath intensive IP and control-path intensive IP, you have typically two families of products there, with Forte Cynthesizer, Mentor CatapultC, Synfora Pico, Simulink HDL coder, etc., on one hand, and Esterel Studio and Bluespec in the control-path domain.

* ESL SOC Integration Tools, like Synopsys coreAssembler, that integrate various IPs coming from different environments. You can view EVE ZeBu hardware acceleration products in this segment, too.

Brett Cline - The marketing messages between the companies are nearly identical because I came up with most of them - time to market, productivity, and better results - and so it does become difficult to distinguish. At an executive level, we're not Mentor Graphics. And, we're not Bluespec.

The difference between us and Bluespec - the people who use our tools are focused on providing high-quality designs for mass volume. The Bluespec technology is conceptually the same as Forte's, but when you look at the technical implementation, Bluespec represents a very old design language, the welcome-to-hell language that asserts all of the things that won't happen. Hardware designers don't work that way, they tell us.

No. 19 - Contrast the embedded market and the ESL market.

Shay Ben-Chorin - The embedded software market is a mature market, in the range of $400 million to $500 million. That market is not growing, but the market we're talking about here within ESL is relatively new - $100 million to $150 million, plus $50 million in services - and the virtual platform is an excellent example of that. It's created to allow software development before the hardware is available, and it's why I think the term system level is a better term than ESL. We're seeing weekly examples [among our customers] of someone delaying a product release because of problems with the software, consumer products that suffer from poor integration [of the software onto the hardware].

Guri Stark - The real news is that embedded software is included today in most consumer electronics. And because that market is growing so fast, the point of pain is significant. Even a year ago, you probably had less than a million lines of code in a cell phone. Today, you've got 2 million lines of code, and by next year it will be 10 million. Suddenly, bugs in software are becoming a critical path item in terms of the product. So, it makes sense to invest in embedded solutions for that.

No. 20 - Is there a real market for ESL tools?

Guri Stark - That's a fair and good question, and we'll all be asking this for a while longer. Being a system architect is a very important job and very complicated, so if you can find a way to automate what they do, you would help them save on the costs of developing an SOC.

But there are only a few people out there [who do this work], so that makes it difficult for a vendor like us to get any kind of return [on tools in that area]. Some solutions available today are pretty good, but it's hard to get the return. For embedded software developers, however, the discussion is very different. There are tens of thousands or hundreds of thousands of them out there. So, there's definitely a market there, plus there is that link between the hardware and the software.

Shiv Tasker - Absolutely, and it's emerging rapidly over next several years. The markets are saying, "Let me experiment with ESL. Will it let me see about competitive hardware?" The more people get accustomed to it, the more it will be used. And, there's a whole bunch of stuff on John Cooley's site [that validates that].

Eric Bantegnie - We definitely think so. It is yet a fairly immature market, but the technologies are working and delivering an adequate level of performance. SPIRIT IP-XACT has now quick-started the integration between ESL synthesis and ESL integration, and we foresee a very rapid adoption of SPIRIT.

Brett Cline - This is a complex question. Yes, there's an ESL market. How big is it? That's a harder question to answer, and the reason is that you can measure the ESL market size a couple of different ways. For instance, how many dollars are spent on the tools? If you think back 20 years, was there a market for the Internet? Yes, there was but there was little or nothing being spent on it. So we shouldn't confuse the fact that the ESL market has some finite number - like $120 million - or some number that Gary Smith has put out there. Because, quite frankly, anybody doing RTL design today, will be doing ESL design in the future. Although, they're not necessarily spending money on it today.

Jeff Jussel - Today, there are a ton of ESL companies. Adding up all the ones reporting to EDAC, there are around 20. And then, there are another 8 or 10 above that. Unfortunately, not all of them are really focused on enabling something bigger. And of that group, the ESL market is only growing 8 percent a year. Celoxica is outstripping that by tapping into new markets for our tools. All of our stuff is about accelerating logic for parallel processes, while EDA overall is having trouble rising above the ASIC.

Vincent Perrier - Gary Smith has helped the ESL market by calling The MathWorks the largest ESL vendor. Still the ESL market is not quite there yet, and probably the future leaders of this market will not be known for a while, but they will emerge a few years from now. Mentor is the only one of the Big Three in EDA that has a clear vision of the software and embedded software worlds. They're the ones with the smart moves towards this whole trend behind system-level design and managing the challenges that system developers have to face now.

Larry Melling -- Today, the need for ESL tools is definitely established. There are a number of customers that absolutely require that things be validated at the system level. However making that need into a market is a very different side of the coin. Are there the right products today? Well, there are more today than there were a year or two ago. So, that's all improving in terms of the commercial products that are there. Is there a dominant player? Is there a "Synopsys" of the ESL market? That's missing today, in my opinion. Meanwhile, there are a lot of niche pieces that have to come together to make it happen.

Mitch Dale - Yes, there is a market. Just in the last year, I've seen tremendous strides with the tools and processes. We're moving from, "Does it work?" to, "Okay, it functionally works, so what are the 2nd order issues?"

So, there's an element here for the EDA guys, because if you go back to DesignCon earlier this year, there was a panel with customers from the U.S. They said they're having to develop most of their ESL tools in-house. That means the EDA industry is having to catch up. Now we're starting to see those tools on the market - things like synthesis and hardware/software co-design types of tools. And verification tools like Calypto's SLEC that can say if your RTL design matches your ESL design.

Ken Karnofsky - Part of the mission of The MathWorks is to serve the university community. Because of the alignment of the purposes of MATLAB and Simulink - to facilitate the idea that something can be simulated verified, and tested - the tools can be used for research purposes, and for exploration. They also serve the purpose of teaching. So, [above and beyond the commercial markets], the universities are important markets for us.

Simon Davidmann - There are already a number of companies - CoWare, VaST, Virtutech, ARM, AccelChip, which was purchased by Xilinx - and a $50 million to $60 million market. That's bigger than some of the niches in EDA. [In fact], there's a huge opportunity here for an ESL market of a couple billion dollars, but the EDA establishment, Synopsys and Cadence, are not really understanding the space. They're part of the old environment, which is about RTL to silicon, but ESL is a new space and the solutions won't come from them. The customers know it, and are not relying on the EDA establishment for the solutions.

Hamid Agah - Xilinx decided to grow an ecosystem in ESL by working with selected partners. We started about 8 months ago, and to date we have 14 ESL partners in our alliance. Some of them are startups just getting starting, and some are not. Celoxica, for instance, has been the 800-pound gorilla for quite a while. The Xilinx customers who believe their systems require an ESL solution can connect with our partners. We believe we have good technology that brings promise to ESL and FPGAs, and can enable this methodology to take place.

No. 21 - Is there one "uber" tool for ESL?

Larry Melling -- That's the question that gets back to is there a viable market? Since it's all about verification, one of the biggest requirements for such a tool is that it works and plays with a wide variety of models and capabilities. When you start talking at the system level, Catalytic's focus is in the MATLAB world. We're trying to create better connections between high-level math algorithms into the system simulation space, and then get them plugged into the hardware or software developer.

I don't think there will be an "uber" tool that knits it all together. It will, instead, be a well-constructed environment that allows for excellent integration. And that's why I think C is a natural place for people to go, because C is the common platform. If you look at all of the different things needed for ESL design, C becomes the point of integration. It becomes the platform of choice because there are more things that are exporting things to things that are C compatible.

No. 22 - What markets and geographies are represented with respect to ESL and SystemC?

Frank Ghenassi - People used to say that Europe was ahead of North America. European companies definitely say that they think in terms of the system, and they're very focused on designing at the system level. But, I think American companies wouldn't be able to design their chips if they didn't have that mindset as well. I can't believe that TI or Broadcom doesn't think about systems, or SystemC. I would say that European and Japanese companies, although in different ways, have adopted SystemC more widely than American companies, but again that doesn't mean that American companies don't think in terms of systems.

Vincent Perrier - In past years, clearly Europe and Japan may have had the lead. But, North America is catching up. There is more and more adoption of SystemC in North America, and more ESL activity. The big companies in the U.S. are starting to think about this at the corporate level. But from our own customers' point of view, we see mainly Europe and Japan.

Jeff Roane - Our customers include the automotive, wireless, and consumer markets, and are equally split one third each to North America, Europe, and Japan.

Mitch Dale - In Japan, Europe, and maybe even India, ESL is catching on. In Japan, some companies are on their third or fourth chipset done with ESL Whereas with some companies in the U.S., they're now just waking up and saying they're interested.

Brett Cline - Our market is still primarily in Japan, Korea, Europe and the U.S. We've got huge market share in Japan, above 80 percent, and so that's where we spend a lot of our time.

Shawn McCloud - We see Japan as one to two years ahead of Europe, and Europe as one to two years ahead of North America. The North American market is starting to take off, however, because they're starting to observe that they're lagging behind. Part of the reason that Japan is so aggressive on ESL is that they missed out on the RTL adoption phase. As a result, it cost them a lot, so this time around Japan is extremely sensitive to adopting new methodology.

Eric Bantegnie - Japan and Europe have clearly had a head start, but we see the U.S. and Asia adoption rates increasing.

Larry Melling -- There are definitely geographic differences in the ESL market. Europe has had very strong system technology, with lots of good system companies. As a consequence, they're a little more knowledgeable about what it takes to do system-level integration.

The U.S. is primarily built on a semiconductor backbone. But as SOCs become more complex, I think the U.S. companies are learning the lessons of system integration. You now find significantly larger software teams at these companies. TI, for instance, talks about their DaVinci Technology, which has 3x the number of software man-years in relation to hardware man-years. Definitely, the semi world is coming into the system space.

I see Japan as a kind of a hybrid. Japan has strong semiconductor companies, but also has some pretty strong system companies. There are companies that cover the whole gamut there. I would describe them as not quite as sophisticated on the system side as the European companies, but more practical in their outlook.

No. 23 - And ESL in India?

Shawn McCloud - There is definitely a globalization of resources. In today's industry, it's easier for companies to leverage high caliber talent from other regions if it makes sense from a cost perspective. India is definitely a very attractive region, given the quality and quantity of the engineers there. China is also a fast-growing region right now. Both of these regions have young and aggressive design communities. As these communities are open to adopting new methodologies, we definitely see them growing quickly.

No. 24 - Is part of the ESL discussion about an aging population of designers in North America?

Shawn McCloud - The adoption of ESL is inevitable, just as RTL was. And we're already seeing that in some segments. Eventually, all companies will have to adopt ESL, and we will see a huge growth in engineering jobs in the community [related to ESL]. And, you'll see some RTL designers adopt the ESL methodology.

But just like when schematic capture evolved to RTL, there was a percentage who refused to change. The important thing to remember here is that the older abstractions don't go away. We will still need the older design abstractions [even after ESL has been adopted].

Mitch Dale - Yes, there are some guys who are thinking if they don't look at systems, they'll get left behind. In my experience, you had two classes of people before the HDLs. One was experienced, yet willing to learn VHDL and Verilog. While the others were some designers who were a little long in the tooth who got left behind. Today, you need a hardware background in RTL and verification, and also software skills. But again, if you look at the analogy of when people moved from gates to RTL, the universities started teaching it and then it was fully embraced. What happens at that point is that the companies start saying, if we're not on the bandwagon then we'll be left behind. The wave then takes everybody forward with it.

By the way, the change doesn't come overnight. You can't just make the change and make it work - it takes a few turns. And as the tools get better, the engineers will learn how to use them and there will be iterations that will lead to a set of tools for ESL design and verification.

No. 25 - Wally Rhines has commented in recent keynotes that the global population of hardware designers, which stands at less than a million today, can grow to 5 million with tools to facilitate FPGA design. Is ESL evolution part of that?

Jeff Jussel - We see it the way Wally sees it, an increase in the number of FGPA designers. There will only be about 2000 ASIC starts this year, but 180,000 FPGA starts. Software designers at banks, in oil and gas, in genome processing, to name a few, are all using FPGAs to make computers go faster. There are people who couldn't use an ASIC before, but now can use the tools available to do custom logic.

Shawn McCloud - The whole advantage of ESL is that it maintains its technology neutrality until way late in the process. A customer may decide to target a design at an FPGA, but later want to re-target it for high volume and low cost [in an ASIC]. ESL allows you to convert from one technology to another. ASIC applications tend to be complicated, but now FPGAs are becoming larger and more capable for complex designs. FPGA designers will adopt ESL, and there's no question that in sheer volume there will be more FPGA designers.

Hamid Agah - ESL for FPGA will open this up for a lot of folks. Software people did not have the opportunity in the past to quickly execute in hardware. It has taken a lot of engineers to make that happen. Now, having the kind of technology that software designers, with little knowledge of FPGAs, will be able to easily implement in hardware will grow the base for potential users in this space. I'm don't know the specific numbers, but it will definitely grow.

However, let's forget for a moment about the FGPA aspects of the discussion. Let's instead ask why ESL is important. Recognizing the complexity of today's and future designs, with multiple millions of gates and the need for complex software on top of that to bring the whole system together, that's what drives ESL. That's the flow of the future.

No. 26 - What are the global labor implications in the ESL discussion?

Brett Cline - Be aware that Chinese society is turning out 500,000 engineers a year, and with the cost of an engineer there, they can put many more engineers on the same problem. Japan is the same way, but they've got a higher cost structure, not as high as ours but much higher than China. But Japanese semiconductors are not going to allow themselves to be left behind. They're going to stay ahead of the curve, so they want tools that will allow them to be competitive.

Eric Bantegnie - I see the emergence of two new roles that existed before, but were lacking adequate tooling. The architect role on one hand - there is a shortage of architects - and the integrator role, as well. Pure IP design jobs will probably stay stable, however.

No. 27 - Where were we 10 years ago in the ESL discussion?

Eric Bantegnie - 10 years ago, we saw the scientific foundations of ESL synthesis. These techniques are now coming to production.

Guri Stark - Who could have predicted 10 years ago what a cell phone would look like today? That it would include a camera, an MP3 player, and more - and that so much of that functionality is becoming programmable. I would have to say that was hard to predict that 10 years ago.

Shay Ben-Chorin - Even people who think about systems, and know there's a combination of hardware and software there, could not have predicted the difficulty of integration today. In the last 10 years, we've gone from 120,000 lines of code to 10 million lines of code. It's mind boggling to think how much software there is now. Ten years ago, it [would have been difficult to predict] the scale of integration problems today.

A.K. Kalekos - CoWare has just celebrated its tenth anniversary. Ten years ago, when the company was founded, CoWare was among the visionaries, but it was not unique. What's unique and special today about CoWare is that fact that today, ten years later, it's still standing. And, it's standing as an independent company.

The company has done several things right. We've had a strong technical and theoretical vision about how design can and should be done, and what the tools should like. Also, the first product the company produced - CoWare N2C, Napkin to Chip - really worked and customers stayed with it for six or seven years. The third thing is that the company made the decision to switch from NTC to SystemC, which was a smart and brave move. CoWare was one of the co-founders of OSCI because the company realized the importance of creating standards for reuse and interoperability of the models. Alan Naumann [CoWare CEO] has also played a significant role in charting the company's success through internal development, adherence to industry standards, and strategic acquisitions.

No. 28 - Where will we be in 5 years, and will there be a shakeout in the ESL market?

Frank Ghenassi - Where we will be in 5 years is anybody's guess.

Jeff Roane - Again, I hesitate to label what we do as ESL, because it's really focused on embedded design. Having said that, consider the example of the auto industry, which went from physical prototypes to virtual prototypes. Most modern autos today are developed without physical prototypes. In electronics, however, we are still using physical prototypes to do product development. In a Toyota Prius, 67 percent of the costs is in the electronics. There are over 70 processors, and the software content is going through the roof. So the question is, how do you design this complex distributed system in a week? You have to have virtual models to develop that architecture.

Also, if you look at traditional EDA, every year it becomes more true. There are further reductions in design starts, because a lot of the designs are being accomplished with embedded processors. Everything is shifting to software development, so the shakeout will develop around that shift. The companies that don't grow and shift will be marginalized.

Eric Bantegnie - "ESL2.0 = EDA 4.0" means that industrial consolidations will occur in parallel to the maturation of the market and customers getting their ROI by deploying ESL tools.

No. 29 - The future in 10 years - will we realize my Black Box Project where you input natural language specs, push a button, and out comes the optimized hardware implementation?

Guri Stark - I have no doubt that in 10 years there will be significantly more automation, but having that Black Box will require solving the entire problem. We may not be there in 10 years.

Shay Ben-Chorin - If you have a good library of implementation IP, and you have models that are driven to a high level, and can synthesize the production between the [input and the output], we might be there.

No. 30 - Your concluding message on ESL?

Mitch Dale - ESL is happening and as part of figuring that out, it will take cultural, educational, and attitude changes. It will take different people expanding what they currently believe is their responsibility - as with any evolution. As an industry, we have to recognize that this is taking place.

Frank Ghenassi - ESL is turning from a nice, theoretical principle into some practice, mandatory flows that all companies are adopting. It's definitely not the last time you'll be writing an article about ESL.

Steve Glaser - Enterprise system level is really the key to unleashing the great potential of ESL. Everything has to happen within a system environment. There is quite a flow involved and many different specialists within the flow for advanced customers.

There is the systems engineering group, which has a couple of goals - to do transaction-level modeling, and some architectural performance and validations models. There is a designer to link in some part of the software group by linking high-speed virtual prototyping and allowing certain parts of the team to develop the software. That pulls the verification team into the process early on to create the transaction-level verification environment. They're applying hardware verification techniques at the system level, using tools to generate all system scenarios - essentially stress testing and looking for corner cases. Then that same verification environment can be brought down to the RTL level.

Along with that, you need to have a complete verification plan and metric-driven aspects of the process, plus know how you're going to manage those planning tools. You need to have that plan, along with the testbenches and verification environment, as part of the beginning of the process that serves as an executable model that incorporates the different aspects of the system spec. Then the RTL and logic designer gets involved creating new IP and verifying things in the context of the system. Typically that's done by applying the same transaction-level testbench to the IP itself - potentially with part of the reference model. And that's how you do in-system logic verification. You've got your logic designer and your verification engineer all working on the plan and designing testbenches. You then need emulation and simulation to get golden RTL to put into the hardware/software process and that's where the verification team can help.

If the end goal is to achieve a path to quality, you need to look at both automation and management - what I call the enterprise level - from the plan all the way down to system closure. ESL should be thought of, not just as an abstraction, but as something with a system-wide scope. You need that at a high level, but also for developing advanced IP, and for doing system-wide validation. ESL means you absolutely must have an enterprise system solution.

Jeff Roane - Anytime you embed software on a piece of silicon, you've got a major design challenge. So, we go out of our way to talk about embedded system design and its design challenges, which is where we're laser focused. With anything that has more than 20 MIPS, you have to develop software after the chip has been fabbed. But with the escalation of software content, there's more time spent developing the software than the hardware. It takes a year to do the hardware design, and then there's another year or two to do the software.

In today's market, however, you can't tolerate that kind of lengthy design flow. Plus, there's a risk that if you discover a functional problem in the software, it's a year and a half after the fabrication, so your respin costs go through the roof, and your time to market costs are even greater. Clearly, you have to be able to develop your software and your hardware at the same time. You must have the capability to support early software development. Our high-speed simulator technology is cycle accurate - anywhere from 20 to 200 MIPS - and that's more than adequate for software development. The important piece is the cycle accuracy surrounded by real hardware with timing critical interactions. If you can't do the cycle-accurate piece, you've only got a crude snapshot that could blow up on you after the chip is fabbed.

Vincent Perrier - What is certain is that ESL will be joining the software, embedded software, and hardware tools This will be the junction between these two worlds. Clearly actors from the software world will have more and more to say, and offer more to the market, about why their perspective from the ESL point of view is the proper one.

Simon Davidmann - EDA is still stuck looking at RTL to silicon, but what's missing in EDA today is how do we specify concurrency, the architecture of the software. Any discussion of ESL [acknowledges] that the hardware world needs better modeling and abstraction, but more importantly the software world needs better models with concurrency. So what we've got is a fracture in the industry - which is what happened when EDA came into being in the first place - because software concurrency is the future.

Jeff Jussel - Moore's law is failing us. We can't get more speed on the processor side. We've got space, heat, cooling issues that make it really hard to get the required performance. Add two or more processors to the problem, and you've got even more heat. And you need custom logic, but usually you can't afford the NRE, plus there are programming problems.

[In light of all this], ESL is allowing us to apply custom logic in the form of an FPGA. The idea is to apply ESL to create custom logic in order to accelerate the system, and to cut down on the power and the cost. [Until now], the discussion about ESL has been too narrow. Is it any wonder that EDA as an industry is only growing at 4 percent per year?

It's an exciting time, but it's messy. I saw a survey recently that someone had done at DAC, asking who is the leader in ESL. There were 8 different answers! When you've got a market where 8 companies are being classified as the leader, that's a market that's not well defined. Celoxica made the list, but there are clearly a lot of different places where ESL is being used.

Hamid Agah - People have believed that ESL was smoke and mirrors. How can you target complex software to hardware without knowing how it's done? But we believe that over the last few years, as our devices have grown in complexity to meet the need, that the FPGA is an ideal platform for ESL. While you're trying to figure out what part goes in the hardware, and what part goes in software, you can move the line of programmability from hardware to software. You can move that line to anywhere you want to. The flexibility and programmability of the FPGA is our value proposition in ESL.

Simon Napper - SystemC is clearly in the early stages of deployment in product projects around the world, mainly driven by the system analysts, the need for virtual prototypes, and as a way to look at design variations. Tools are available to create efficiency for hardware engineers, to create a link going from untimed C and SystemC down to the implementation.

My view is that C is good for design, and SystemC is good for the analysis and verification. I think in the long term, there will have to be a continuum of interfaces between MATLAB and SystemC, between UML and SystemC, and between SystemC and SystemVerilog. A series of interfaces all the way through to provide a range of answers to the various constituencies of engineers.

Brett Cline - There really is no choice going forward. Our customers say it costs $30 million to develop an SOC and those costs are increasing. The main portion of that cost is in the engineering, but I can't double my headcount, so I need to figure out a way to make that same number of people more productive.

At the end of the day, you need somebody to design twice as many gates in half the time, and [that will only happen] through buying IP, design reuse, and better verification. Productivity is driving the process, and that has to include the software and firmware, as well as the hardware. The companies [facing all of this] have chosen ESL, and they've chosen SystemC, which has become the de-facto standard. They're doing better hardware design by starting above the RTL.

Shawn McCloud - The Holy Grail of ESL is hardware/software co-design. It's the ability to move software over to the hardware domain easily. But, that kind of partitioning optimization is a little way off. ESL is [also all about] time to market. If you miss the Christmas market, you miss the market completely. But the complexity of the design - 3G and 4G phones and HDTV, for instance - means that the rapid evolution of system architecture is driving companies to maintain competitive differentiation.

Our strategy has been to first focus on the application space of greatest need. In general, the design communities are reluctant to change. There's a risk/learning curve. The only time we see real change is when the pain becomes so large, that the design community has to use a new level of abstraction. We're certainly seeing that in the wireless and video markets, which we see as the key market drivers today.

We're also seeing the change as incremental. For certain segments, if you've got a block written in C, you can push a button and get RTL, or add RTL blocks. But the design community wants to see the datapath [capability extended] to control-logic design. We have a lot of technology under development, and when they have been proven for customer usage we'll announce. However, the time frame depends on our customers. For CatapultC, we have over three years of customer validation, and that includes a lot of attempts, failures, and successes. Mentor is always very conservative before we announce something.

Every time you move up in abstraction, you have to let automation do something for you. That's the way you speed up. Transistors to RTL allowed you to target gates. The thing that designers want is the idea of defining concurrency, and parallelism through automation. What we're saying is, now you can move up to a source description that has no notion of concurrency. Then you can use automation tools to insert the concurrency. We're saying that's the only way you're going to see gains in productivity.

Guri Stark - Obviously, one important message in ESL is the link to embedded software. But, the other message is the importance of models. Software is so critical, we must provide a link between the hardware and the software.

Steve Pollock -- ESL is about hardware/software co-design from an SOC perspective. A phenomenon you're seeing right now is something the industry's been talking about forever and that is platforms. Platforms are definitely here - Motorola, Freescale, TI - they all have platforms. It's easy for them to change their platforms and to modify them to get them into the hands of software developers easily. For instance, I've got a Treo and my boss has a Treo, but one is for Verizon and one is for Cingular. The hardware platform is the same in both instances, but they're differentiated through the software. Today, the software on these devices is becoming more and more important.

Typically, our customers at JEDA are developing single chip, or even multi-chip implementations. For instance, a next-generation printer controller that's very complex with multiple microprocessors, tons of complexity, and lots of complex software in the model. Everybody today - Canon, HP, Epson, etc. - is making a multi-purpose product where it's really the software that's differentiating the product.

Shiv Tasker - We're spending $10 million or $15 million to design a chip, and that has got to come down. I like to say it's roughly $1 per gate, so a 10 million-gate chip costs $10 million do develop. It's just ridiculous. The bulk of the money is being spent on the front end with modeling, architectural design, RTL implementation, and verification. And why are we spending all this money? Because chips are more complex. It's the complexity that jacks up the verification costs and the only way you can deal with the complexity is to raise the level of abstraction. Anything else is just a band-aid.

Also, people try to distinguish between a model of the system - usually some high-level functional model - and implementation, which is equated in their minds to the RTL. However, we don't differentiate between the model and the design. Raising the level of abstraction means moving beyond RTL, and that's the real issue in ESL - can you meaningfully raise the level of abstraction above RTL?

At Bluespec, we're saying you can raise it to higher levels of abstraction, and have tools that automatically implement. At the higher level, you get faster simulation speeds, but you can also get good hardware automatically from whatever that ESL level design description is.

Eric Bantegnie -The ESL tools are there. What is lacking - beyond tool vendor interoperability, which is basically achieved at the RTL level, IP level with SPIRIT, and SystemC level with virtual prototypes - is mostly the methodology of using the tools together in a way organized between the new roles within companies - defining the exact roles of architects, IP developers, IP integrators and verification teams. We need the methodology and the organizations to be matched together to actually achieve the high ROI potential of ESL.

Emil Girczyc - People have to take a step back and decide how to leverage the methodology at the ESL level. Logic design got much more efficient with the introduction of synthesis, but you still had to do the layout. It's the same thing today with ESL. It will get you through the phases of co-design and architectural analysis, but you still have to go through the detailed steps of getting the chip out.

You can't afford to do a design with 20 million gates and meet your time to market, if there's risk in verification. You have to reuse a lot of stuff to make that happen. But also, to be able to justify the cost of a 10-to-20 million-gate design, you have to have a huge market - something like a cell phone or a computer game station, or have a programmable part for multiple applications. More and more, the important function is now in the software. So people will do increasing amounts of their designs in ESL as the methodology matures, and those designs will be more and more plug-and-play.

Shay Ben-Chorin - When we look at Synopsys and the history of the company, it has provided EDA tools to bring customers' faster to solutions, and has added IP and verification IP, plus services. The combination of tolls and services and IP bring the customers to the market faster. With system level, we've got exactly the same philosophy and idea. System level model development tools, the largest library of IP in the market, plus services - it's the combination that makes the big difference and brings the most amount of value to the customers.

A.K. Kalekos - For the last 20 years in the EDA world, time to market has been the most important value proposition that EDA has put forward. In today's world, however, getting to market on time but with the wrong product is actually worse than not going to market at all. Time to market is essential, but not an opportunity for competitive differentiation. The right product is the opportunity for competitive differentiation.

And, if you're lucky enough to build the right platform, you also want to make sure that you put a design infrastructure in place for that platform that will allow you to create derivative products efficiently enough to save markets across locales, geographies, demographics, and so forth. If you're Motorola, you want to use your Razr platform across various markets, because Europeans will use the platform differently from North Americans, or customers in Japan. Teenagers differently from parents, or from professionals. ESL supports all of this, and promises better products with an increased ability to chase markets as they evolve over time.

When you realize that ESL is a disruptive technology, then you see that the EDA leaders have to cross over, to move into a new space. And, as history has shown, that hasn't happened very often. In the computer industry, it was not IBM who lead the market in minicomputers, it was DEC; when workstations came about it was not DEC who lead the market, it was SUN; and it was not SUN who lead in personal computers but rather newcomers like DELL and Gateway.  Same thing happened in design automation; the original CAD industry leaders such as Computervision, Calma and Applicon did not become the CAE leaders, it was newcomers like Daisy, Mentor and Valid who lead the CAE market, and later on in the transition to EDA it was again a new set of leaders like Cadence and Synopsys with only Mentor being able to make the transition to CAE.

Now today, when we're getting into ESL, you have to consider the likelihood that the leaders will have trouble making the transition. People underestimate the effort it takes to create an escape velocity - to build an ESL franchise out of an RTL franchise, especially when the vendors see the problems but not the benefits of moving there. The big EDA vendors are still focused on maintaining their position, so they're a lot less concerned about new opportunities in ESL.

It's not because they're not smart enough to do it, but they have a $1 billion beast to feed, and ESL can't support that in the next two-to-three years. If you're the CEO of one of the Big Three in EDA, you can look back over the last several months and say, "Not a single customer is beating me up about not having ESL tools, but they are beating me up on their RTL tool problems."

So, the CEOs don't feel the pressing need to get into ESL, as least not as much as the new people who can go in and see the real impact of ESL. Right now the big EDA vendors might look at a $2 million ESL opportunity in an account, versus a $15 million RTL opportunity in that same account. The people who have worked in these companies know exactly what we're talking about here. It takes courage and vision to move into the next technology.

**********************************************

* OSCI

Corporate Members
ARM Ltd.
Cadence Design Systems, Inc.
CoWare, Inc.
Forte Design Systems
Mentor Graphics Corp.
Royal Philips Electronics
STMicroelectronics
Summit Design, Inc.
Synopsys, Inc

Associate Members
Actis Design, LLC
Atrenta, Inc.
Bluespec, Inc.
Broadcom Corp.
Calypto Design Systems, Inc.
Canon Inc.
Carbon Design Systems
Celoxica Ltd.
ChipVision Design Systems AG
Denali Software Inc.
Doulos Ltd.
ESLX, Inc.
Fraunhofer Institute for Integrated Circuits
Freescale Semiconductor Inc.
GreenSocs Ltd.
JEDA Technologies Inc.
Intel Corp.
NEC Corp.
SpiraTech Ltd.
SpringSoft, Inc.
Synfora Inc.
Tenison EDA
VaST Systems Technology Corp.

**********************************************

* Accellera

Member Companies
(Companies bolded on this list also belong to OSCI)

Aldec, Inc.
ARM Ltd.
Cadence Design Systems
Denali Software Inc.
Freescale Semiconductor
IBM
Intel Corp.
JEITA
L-3 Communications
Magma Design Automation
Mentor Graphics
Nokia
Novas
Real Intent
Rockwell Collins
Silicon Canvas Inc.
Silvaco
SpiraTech Ltd.
ST Microelectronics
Sun Microsystems
Synopsys Inc.
Texas Instruments
Tharas Systems
Toshiba
Xilinx

**********************************************

* Addendum

No. 1 - Define ESL.

A.K. Kalekos - Initially, people identified ESL design as a level of modeling above RTL, because traditionally we went from resistors, to gates, to blocks, and each one was a level of abstraction above the last. Therefore, ESL design was seen as SystemC above Verilog, a level above RTL. But this is defining ESL in context of the old paradigm. ESL is creating a new reality, which is essential for the types of products that people need build today. ESL is a disruptive tech that looks like EDA, but is not EDA.

ESL design itself is the ability to capture product architecture and product descriptions efficiently, so you can explore a product definition and improve it. Then, having captured it, you have a path to hardware implementation and a path to software implementation. That means creating virtual hardware platforms delivered to the software developer who can develop applications without waiting for the physical [implementation]. ESL includes behavioral synthesis, using virtual hardware platforms that you've created for system-level verification as you proceed, architectural capture and exploration, and virtual platforms for software development.

Brett Cline - I think the way ESL is understood is two separate things - it's different things to different people. One set of people says it's the next abstraction level above RTL. I truly think customers think that's ESL, but they're creating RTL for hardware. For the second group, it's a flow that encompasses their system-level challenges and encompasses software, firmware development, FPGAs, and systems that lead to hardware implementation.

One of the main advantages of ESL is that you can take the model, which runs really fast and doesn't take long to write, and suddenly it's available to other people in the system. Hardware designers can work with different blocks. Software guys, or whomever, have access to different blocks and can use it with the hardware. A lot of ESL is just fancy verification - a way to reduce people's verification effort.

Emil Girczyc - ESL is the design of a system, which is really three components - large software, a large reuse component, and some design. The design is typically done with behavioral synthesis with tools like those from Forte, Mentor, or Celoxica, or it's done by hand by writing RTL. The biggest difference I've always believed, however, is that ESL is primarily about software and design.

Eric Bantegnie - The definition I like most comes from Linda Prowse Fowler, from Linda Prowse Fowler and Associates. She defines broadly ESL as: “The design and verification abstraction level above RTL,” and ESL synthesis as: “The ability to auto-generate the hardware, firmware, verification models, documentation, and debugger configuration files necessary to package IP and integrate platform SOCs while managing data and deliverables for the hardware and software teams as the design, requirements, and specification evolve.”

Frank Ghenassi - ESL is now turning from a nice theoretical principle into some practical, mandatory design flows that all companies are adopting. So this is definitely not the last time you'll be writing this article. I speak for STMicro, when I say for us, ESL is what you do above RTL, using higher-level models than RTL. At ST, we user high-level model for several things including functional verification, architectural analysis, and virtual prototyping. And we are using SystemC.

Guri Stark - It leads into the RTL flow for implementation and verification. In simple terms, ESL is everything above RTL, and it includes three things: algorithms, architectural design and exploration, and embedded software. These are the things traditionally addressed by the ESL tools in the market, although the focus on been on the first two. We recently acquired Virtio [spring 2006] because we want to link to the embedded software market. However, I like to use the term system-level solution, which includes the tool element, the IP element, and the services that enable the creation of models and solutions at the system level. Hamid Agah - ESL is the design flow that enables you to raise the level of abstraction from the existing RTL level to further up the flow. For example, that could be MATLAB, or ANSI C, or System C, or one of the proprietary languages from companies like Celoxica. Anything higher than RTL is an ESL flow.

Jeff Jussel - ESL is a big niche and the reason you'll get 20 different answers from 20 different people about how to define ESL is because people are necessarily application specific. People are starting at the system level to apply technology to a specific area. It's like the blind men touching the elephant. Each one defines the elephant differently. Some people are working on virtual processing, or it's models that improve the reusability of IP models, or power analysis at the system level, or the more traditional orientation towards ASIC design. These are all ESL tools, but they're all very different, and they all address different problems.

ESL is something that deals with algorithmic or functional level of design, as opposed to the implementation level. By the time you get down to anything dealing with an ASIC, you're dealing with RTL. Even if it's between the control path and the datapath implementation, if you've already made the decision between the control and the data, at that point it's an ASIC-level design tool, rather than an ESL tool.

Jeff Roane - The definition of a system has always been blurry. Anything outside the I/O of the chip became the system, so at Lockheed or Airbus, a system is a plane. For the automotive industry, it's a vehicle. All the companies that occupy this space, therefore, have a different definition and that contributes to the vagueness of the definition. Also, an SOC has been an ill-defined term. Now we know it's something that has bus structures, I/Os, processors, some ASIC content, and some software.

The definition of ESL goes back to companies like Escalade and Summit, the pioneers of ESL. One by one they folded, having not met with substantial success. Those companies came into being with the goal of being an outgrowth of traditional RTL design, with changes applied incrementally upstream.

Ken Karnofsky - ESL is about trying to connect the system-design world to the implementation effort.

Larry Melling - Our view on ESL comes from the system-level perspective. It's not so much an alternative or different design style, as it is where you see the most traction around verification as it relates to design. System-level verification is at a higher level, where people are trying to include the software in their verification process. So it's the software running on an embedded core inside a design. [All of it] needs to be looked at within the context of the system, how it communicates with the outside world.

Mitch Dale - The motivation for ESL is coming from the hardware space. There are problems out there for the hardware guys that they can't solve. For the guys who are writing system-level models, the architects and algorithm guys - while they're aware of these issues, they've been working in a friendly environment. They've been able to think and tinker, and come up with the next best algorithm. It doesn't really matter to them works, or is done on time. So in moving up to the ESL, you have this shift in focus. Now the system-level guy has to take a lot more responsibility if the model is the design entry point. It has to have fidelity, quality, and be able to be reused.

Shawn McCloud - ESL is composed of three categories - synthesis, verification, and design. A total system-level solution will be composed of executable technology in all three categories. And, we define ESL in terms of goals. It must produce a minimum of a 10x to 100x increase in productivity over existing RTL methods.

It's the process of using higher abstraction languages to produce higher-level models, which will simulate faster. A couple of orders of magnitude faster to get adequate system-level verification. The real goal is to create virtual prototypes, which allow you to do up-front system optimization, validation, and also early software validation. And, it absolutely must lead to implementation. The key piece of technology that allows ESL to become a reality is the ability to synthesize from higher-level abstraction models and get actual hardware.

Shay Ben-Chorin - Any design you do at the system level should be legally part of ESL. I like the term system-level design more than the description that ESL is anything above RTL

Shiv Tasker - ESL is a meaningful raising of the level of abstraction, at which you express a design from wherever you can create competitive hardware. It has to be generally applicable, and it should handle any kind of digital circuitry. Not just datapath, but control logic, as well.

Simon Davidmann - What ESL is trying to solve is how are we going to solve problems with tens of millions of lines of codes and hundreds of millions of transistors, and there are two sides to that. On the hardware side, that [requires] raising the abstraction level. On the software side, it [requires] verifying dozens of processors and a billion operations a second.

Simon Napper - ESL is moving up a level of abstraction. You're trying to have a description of the larger system that has less detail and runs faster, so you can encompass a larger model.

Stan Krolikoski - I would quit my job is I had a definition of ESL. Plus, I don't really like the term ESL. I think we're talking about pre-implementation. It's quite a bit more diverse than post-implementation, it's difficult to get, and there's a diversity of intention for pre-implementation.

At the top of pre-implementation, you've got pure algorithmic designers who are more mathematically oriented. They don't care about implementation. They don't know if their stuff will be in software or hardware. They don't care because they're just looking at the structure.

At the other end, you have concept engineers or microarchitects. They work just before implementation: What's the parts list? What's the schedule look like? How many multipliers should be used?

In the middle is the architect. More and more the architect is looking at the entire SOC. They're looking at structures, what the chip looks like, how the different parts will look to each other. They're having to worry about implementation features, but not the nuts and bolts. They don't have to worry about the challenges in silicon. But on the other hand, they can't be completely devoid of interest. So different people have different views within the ESL world.

Steve Glaser - My definition of ESL is not electronic system level, but enterprise system level design and verification. I mean that we have to look across the entire process, across all the different specialists in the enterprise, starting with system modeling and ending with system verification. It has evolved to include the people doing system-level verification, and system validation, plus links to the embedded software teams who need to verify the software with the hardware. So you now have the whole spectrum that includes the system engineer, IT designers, logic designers, hardware design, system validation engineers who need to give you a predictable path to system-level quality. You have to span all of these different specialist, and activities, to create this predictable path to predicable quality.

Steve Pollock - I see things a little differently, because there are a couple of different viewpoints. There are the people who are coming from the chip design world who have been living in Verilog. They're gravitating up to the system design world. There are people coming from the architectural design space, the world of C/C++, and they're coming down to the hardware, and they're adopting SystemC and C++. The whole goal is virtual prototyping. And the leverage there is not so much in the chip design, but in the software development and having platforms to rapidly start the software development.

Vincent Perrier - That's a tough question. I think there are as many ESL definitions as there are definitions of a system, and everyone has a definition of a system and what a tool should be in relation to that system. Traditional C and C++ can't describe hardware, and the HDLs cannot describe software. Those are two different worlds, modeling software or hardware. So ESL starts where HDL leaves off, and SDL starts.

**********************************************

Peggy Aycinena is Editor of EDA Confidential and a Contributing Editor to EDA Weekly. Peggy Aycinena is Editor of EDA Confidentialand a Contributing Editor to EDA Weekly.

You can find the full EDACafe.com event calendar here.

To read more news, click here.


-- Peggy Aycinena, EDACafe.com Contributing Editor.