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!

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.

« 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
  • 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)

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

For more discussions, follow this link …

Featured Video
Peggy AycinenaWhat Would Joe Do?
by Peggy Aycinena
H-1B Visa: de Geus’ tragedy looms large
Peggy AycinenaIP Showcase
by Peggy Aycinena
IP for Cars: Lawsuits are like Sandstorms
More Editorial  
Staff Software Engineer - (170059) for brocade at San Jose, CA
Lead Java Platform Engineer IOT-WEB for EDA Careers at San Francisco Area, CA
Technical Support Engineer for EDA Careers at Freemont, CA
ASIC/FPGA Design Engineer for Palo Alto Networks at Santa Clara, CA
Technical Support Engineer EU/Germany/UK for EDA Careers at N/A, United Kingdom
Mechanical Designer/Engineer for Palo Alto Networks at Santa Clara, CA
Upcoming Events
2017 IoT Developers Conference at Santa Clara Convention Center California - Apr 26 - 27, 2017
Embedded Systems Conference ESC Boston 2017 at Boston Convention & Exhibition Center Boston MA - May 3 - 4, 2017
2017 GPU Tech Conference at San Jose McEnery Convention Center 150 West San Carlos Street San Jose CA - May 8 - 11, 2017
High Speed Digital Design and PCB Layout at 13727 460 Ct SE North Bend WA - May 9 - 11, 2017

Internet Business Systems © 2017 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — 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 Policy