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.
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.
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
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.
You can find the full EDACafe event calendar here.
To read more news, click here.
-- Peggy Aycinena, EDACafe.com Contributing Editor.