December 04, 2006
ESL 2.0 = EDA 4.0 Continued
Please note that contributed articles, blog entries, and comments posted on EDACafe.com 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.
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.
You can find the full EDACafe event calendar here.
To read more news, click here.
-- Peggy Aycinena, EDACafe.com Contributing Editor.