November 20, 2006
ESL 2.0 = EDA 4.0
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.
I think ESL is trying to target those people, those who have to think about a system in terms of functions. What should my product deliver? What are the real-time requirements? What kind of memory and system functions does it need? What do I do in software, and what do I do in hardware? What is the impact of my platform architecture and my bus load? These are not the same kinds of questions or tools users we've seen in the past.
Mitch Dale - I see ESL as the marriage of hardware and software design coming together. With that, it's creating quite a bit of issue with the hardware designers. Now they have to concern themselves with software, and higher levels of abstraction including power abstraction.
Hardware engineers have had a hard time writing in software-based languages. Things that are simple for C programmers, the hardware guys haven't been able to get their hands around. They're starting to, however. They're starting to be very successful with system-based design - capturing the system in ESL languages like C, C++, or even SystemVerilog - and using that as an entry point for the RTL. I think the hardware designers know that if you don't have something new to learn, you've stopped living.
Q - Define ESL.
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.
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.
You have to span all of these different specialist, and activities, to create this predictable path to predicable quality.
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.
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.
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.
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 data path, but control logic, as well.
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.
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.
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.
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.
Ken Karnofsky - ESL is about trying to connect the system-design world to the implementation effort.
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.
You can find the full EDACafe event calendar here.
To read more news, click here.
-- Peggy Aycinena, EDACafe.com Contributing Editor.