December 04, 2006
ESL 2.0 = EDA 4.0 … Continued
Please note that contributed articles, blog entries, and comments posted on are the views and opinion of the author and do not necessarily represent the views and opinions of the management and staff of Internet Business Systems and its subsidiary web-sites.
Peggy Aycinena - Contributing Editor

by Peggy Aycinena - Contributing Editor
Posted anew every four weeks or so, the EDA WEEKLY delivers to its readers information concerning the latest happenings in the EDA industry, covering vendors, products, finances and new developments. Frequently, feature articles on selected public or private EDA companies are presented. Brought to you by If we miss a story or subject that you feel deserves to be included, or you just want to suggest a future topic, please contact us! Questions? Feedback? Click here. Thank you!

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.

« Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 |  href='/nbc/articles/view_weekly.php?articleid=330353&page_no=15'>15  Next Page »

You can find the full EDACafe event calendar here.

To read more news, click here.

-- Peggy Aycinena, Contributing Editor.

Review Article
  • New menu ESL December 05, 2006
    Reviewed by 'Hemanth'
    Peggy, nice expository article. Electronic System Level or Extended System Level or whatever it is atleast one thing is certain, that there is a necessity for it and people are trying out. So going by the discussion above it looks like a range of concepts can co-exist under the umbrella of ESL but the common theme being that it will assist us in doing the job better and more efficiently. I work for a large technology company and infact recently worked on a project where systemC is being newly adopted as the environemnt for initial architectural validation and subsequest functional verification. Building the new infrastructure suitable for systemc, I think, took a lot of effort and was time consuming but the idea is that the payoff is going to happen with better verification and the expected extensive re-use for next product lines. I cant really say if we realized any reduction in the whole process cycle as it was done from scratch but that may very well be so in the future.

      Was this review helpful to you?   (Report this review as inappropriate)

  • Good info, but needs condensing December 05, 2006
    Reviewed by 'John B.'
    I found some good points in these interviews, but 29 pages long? It's too much unless you're in EDA Marketing and want to see all these details. I'd prefer an excerpted interview and a distilled summary article. At least I see that you prefaced it with saying it's a "lengthy article"!
    This comment applies to many of the articles on this web site -- they are too many pages long and need tighter editing.

      2 of 3 found this review helpful.
      Was this review helpful to you?   (Report this review as inappropriate)

For more discussions, follow this link …

Featured Video
Senior Electrical Engineer for Allen & Shariff Corporation at Pittsburgh, Pennsylvania
Upcoming Events
IEEE Women in Engineering International Leadership Conference at 150 W San Carlos St San Jose CA - May 21 - 22, 2018
SEMICON Southeast Asia 2018 at New Malaysia International Trade & Exhibition Centre (MITEC) Kuala Lumpur Malaysia - May 22 - 24, 2018
Methodics User Group Meeting at Maxim Integrated 160 Rio Robles San Jose CA - Jun 5 - 6, 2018
IEEE 5G World FOrum at 5101 Great America Parkway Santa Clara CA - Jul 9 - 11, 2018
DownStream: Solutions for Post Processing PCB Designs
TrueCircuits: IoTPLL

Internet Business Systems © 2018 Internet Business Systems, Inc.
25 North 14th Steet, Suite 710, San Jose, CA 95112
+1 (408) 882-6554 — Contact Us, or visit our other sites:
AECCafe - Architectural Design and Engineering TechJobsCafe - Technical Jobs and Resumes GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy PolicyAdvertise