ESL 2.0 = EDA 4.0
When we spoke by phone, Dr. Brodersen told me, "We do chip design for various kinds of chips. We do lots of chips, and we don't want to take 5 years to do them. We are looking at structural projects to do chips a lot faster, and what's useful for companies to make this happen. We even have something called our Chip in a Day project."
"What's happened over the past is that we've used our tools to [build this] infrastructure, and then brought in more and more outside tools for the graduate students to use. Right now, we're using Simulink and tools from Cadence. We've scripted the back end to stay up with STMicro's foundry flow, and we also build to IBM, Intel, and TSMC, among others. But the real infrastructure, the high-level front end - that front end needs a handoff to the backend flow."
Q - So, how do you define ESL?
Bob Brodersen - The goal of ESL is, how do you get information to the algorithm people, and get them to use a language down to the hardware? There are a large number of users who want a path down to hardware.
Q - Can you respond to Cliff Cummings' statement distinguishing between companies involved with SystemC and true ESL companies?
Bob Brodersen - I agree with Cliff. The conversation has gone the wrong way if anything with C in the title is ESL. Because, solving the problem has nothing to do with C. From my point of view, the question is what do most ASIC-like designs look like? There are lots of things there that are stream based there, with streams of data coming in. So, what is the best way to describe that? That's a question that is clearly not related to C at all.
I'm pretty familiar with wireless applications, all of the processing that goes on in WiFi up until the maximum protocol layers, and it's difficult to describe that in C. There's a potential way to "fix C up" to handle architecture, but in actual fact you're starting from the wrong premise.
Q - What do you believe to be the best system-level design language?
Bob Brodersen - Well, we had textual languages - IMEC commercialized one of them - but once you have a new language that's different from the one the algorithm folks use, there are problems. SPW was a very similar attempt to provide a starting point, and most of the algorithm people thought it had the right structure. But, those languages really are hardware specific and are controlled by the CAD companies.
C is a sequential language, step by step, and processors are sequential. So, if you have a couple of cores, or a multi-core processor, you need a sequential language and C is fine for that, and C is familiar to most people. However, C doesn't have a structure that's close to final-chip architecture. RTL is the assembly-level code for hardware, so there really are two different languages needed.
The way we do high-level computation, WiFi chips, etc., we have lots of computational blocks - hundreds - and those blocks are interconnected between streams of data from one computational block to another. In hardware you need hundreds of things in parallel You can parallelize part of it and try to describe it in C, but you have to add hardware descriptors that say, I want to parallelize this and keep track of time. So, the question remains - if not C, what is the right higher-level language to get us where we need to go? You don't want to have to convince people to learn a whole new language.
You need a language like Simulink. You need to get your block diagrams connected together, and then you can take that and turn it into an architecture by directly mapping it. Simulink, which was not developed with the hardware in mind, but was developed for algorithms. It describes algorithms with block diagrams, adders, multipliers, etc., connected together - exactly the same kind of architecture that you use in hardware, except hardware is much faster. And, you can get pretty good results.
[Also], we get lots of students who can use Simulink and Matlab. My students have used these tools in classes, and can start right away in a language they already know. It's heavily used, especially by the algorithm people, and can give them the right feedback so they can modify their algorithms.
The goal of ESL, as I said, is to get the algorithm down to the hardware. Simulink doesn't have a path for that, but Xilinx has a system generator that works with Simulink. Synplicity also has something, and Altera does as well. So, there's a large number of users of these tools with a path down into hardware.
Q - So, you use FPGAs?
Bob Brodersen - Yes! Making chips is our goal in the end, and we can use the same descriptions for both an FPGA and an ASIC. That's the one strong point in the design flow we've developed. We can target an FPGA, play with the implementation, and then look at an ASIC as a target.
What I really hope to do in the long term is [to develop a] description that, later on, can target things either way. Simulink in the software world, a protocol in design, and several models. The key is that you want to get to the right description at the bottom, C code for processing, HDL code for hardware, and Simulink on top of this.
Q - What is the correct direction for the industry's conversation about ESL?
Bob Brodersen - In actual fact, hardware/software co-design is flawed. Although there is some kind of continuum between the software and hardware, the speed of the hardware is many orders of magnitude faster than the software part. As the hardware speeds up, the idea of one language that can be moved back and for the between the hardware and software [is less realistic]. The computational models between the hardware and software are fundamentally different. There are two different things going on there so the metrics, including performance and power, are really different.
[We believe] RTL designers won't work at the higher language level, but there's the same [reluctance] for the higher-level designers who won't work at the RTL level. That's why we need to get people working at a higher level, and not let them get bogged down with RTL code. Then, through modifications, you can make the design even more hardware optimized. That's the way to do it - to start with something that actually has that structure. The people you need to target are the architectural/algorithmic folks who can make use of all of this. If they're given enough tools, they'll take over.
Rudy Lauwereins is Vice President of IMEC and will be Chair of DATE 2007 next April in Nice. He was also a very visible presence at ICCAD 2006. In his talk on the system issues related to multi-core design, he described two widely-discussed gaps - the DFM gap defined as the RTL to implementation gap, and the ESL gap as the architecture to RTL gap.
Lauwereins said it's the next gap, however, which is above ESL that's of greatest concern. That gap is the challenge of software mapping onto the platform, which must allow for energy efficient, scalable applications on cheap hardware. This is the ultimate challenge in system design, he said, and added that the tools to meet this challenge are becoming more mature in the research communities. Such tools, however, are not yet available in the commercial sector.
IBM's John Darringer is a leader in system-level design and was a very visible presence at ICCAD in San Jose. In his talk on design concepts for multi-core systems, he parsed the ESL issue this way:
World 1 is post-RTL implementation, which comes with the familiar challenges - productivity, verification, physical design, and manufacturing, plus reuse to help with the verification.