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.
Languages are moving targets over time. They mature at a speed that's dictated by their adoption. It's not really important whether it's SystemC or SystemVerilog, a language will evolve until it has everything that it needs to be productive. SystemVerilog is an outgrowth of Verilog, whereas the customers that we see are overwhelming demanding SystemC. SystemC is a standard, and standards enable the tools to work together in the context of the flow - they accelerate the development of a certain class of tools. Propriety formats prevent that from happening.
verification cycle. You're not really abstracting anything, and you're doing all the work.
So, at one level I don't care - I've got SystemVerilog and SystemC products - but a lot of people with an architect title, who have a system overview responsibility, or don't have a hardware background, want to be in C++ environment, especially since software is more and more important. In my mind, however, it makes no sense whatsoever to take an excellent HDL guy and make him a mediocre SC guy. So we started with SystemVerilog, put a concurrency model out there, and then implemented it in SystemC as well.
Vincent Perrier - I can understand why people from the hardware world know how to use VHDL and Verilog. And I can understand why it may be tough for them to use SystemC. They may be a huge learning gap for those people. But there is technology that's useful for executing models and connecting the two things together. From the execution point of view, it's okay. But from the interoperability point of view, there's still a lot of improvement needed between the standards, and between the blocks.
Our philosophy at CoFluent is, if you don't want to write in SystemC you don't have to. We have software implementation graphics that everyone can understand, and we create the SystemC automatically. And if you want to learn SystemC, this tool will help you.
No. 14 - Will it ever be possible to do hardware and software design with the same language?
Vincent Perrier - Yes, absolutely. Some kind of automation will be found to accomplish that. You can already see early ideas of what that will look like with the SystemC synthesizers. I think Forte is doing that kind of thing, and Mentor has Catapult.
No. 15 - So, can you, or can you not, sign off on a design at the ESL level?
Larry Melling -- I have yet to hear about any organization that is doing all of their design at the ESL level. When I do, you all will be the first to know. If you hear about it before I do, can you give me a call?
Emil Girczyc - You can not today, but you can do higher-level system verification and design in ESL, and then the lower RTL verification to make sure the pieces work together. There's lots of opportunity there, with some of the more advanced formal techniques available.
No. 16 - Is it possible today to work in SystemC, and have the design implemented in hardware without subsequent intervention?
Frank Ghenassi - If you're referring to synthesis tool, we do use Forte or CatapultC [Mentor] for behavioral synthesis - but mostly for signal processing. For most designs, however, we still handcraft our RTL. We do our verification environment and reference models in SystemC, and then the rest is done by hand.
That may be changing in two ways, however. The behavioral synthesis tools seem to be getting more interest from the design community, and more and more we have embedded cores in the subsystem that instantiate the control logic rather than implement it in hardware.
Shawn McCloud - Yes, for certain segments in the market like the wireless space and the video/image processing space. Basically in consumer products, you're seeing adoption in that space of ESL products. What's the flow? First, remember that no system is usually all described in C. Usually, a system contains 70 to 80-percent legacy RTL. So the question is, is there a path from the new IP blocks - that the 30 percent of the design that's new - down to implementation? High-level synthesis is being used with that, but in some cases it's still [about] using RTL methods.
There's nothing today that allows you to push a button and get optimal hardware and software. That's still a couple of years away. In high-level synthesis, there's CatapultC from Mentor. But in verification, it's still a battle. And in design, that one is lagging behind the most. There will be a natural evolution and survival of the fittest. There will be one or two products, and a bunch of little companies. Then you're going to see an actual [solution adopted by the design community].
The tool that allows you to insert concurrency will be highly interactive - it's a design process of transformation. So in high-level synthesis you can compile, schedule, do a datapath and finite state machine extraction, an RTL extraction, a backend optimization, and a netlist generation. Currently, in CatapultC, each one of these is a stopping point applied interactively by the users. Eventually [it will all be automated].
Ken Karnofsky - How you connect hardware and software together at the implementation level is still an open question. At the starting point of system design, it's how to partition it into software and hardware, and that's where Simulink is useful. We're seeing that in many places where the amount of code that needs to be written [is overwhelming], people are moving away from C to automatic code generation for models.
Product development schedules are too short to test all of that code. And in industries like automotive and aero, bugs simply can't happen. So people have found that you can get much better models with automatically generated C code. Our tools [support] a parallel structure, which allows you to model at one level and go into hardware and software at the next.
Jeff Jussel - In our case, we provide the path to implementation in an FPGA. Maybe [the solution] will be in hardware, or in the software, but we create verification models to reflect the functionality at the algorithmic level. While we do [provide the tools] that take C code and implement it in an FPGA, it's meant to be used as an acceleration tool. It's used for embedded design in applications like cameras or computers. [We believe] that's where ESL comes into its strength, not as a replacement for RTL. ESL enables using FPGAs as co-processors.
So, is there a path to implementation? Sure, there's a path, and it's as automatic as any RTL path created. Of course, Forte provides a path from SystemC to ASICs, and Mentor has a different flavor of synthesis tool. Those are paths from transaction level down to ASIC, and they're very productive.
Simon Napper - It's only recently that you've had a practical way to go from SystemC to hardware. Certainly from an untimed C or SystemC description, there are at least three vendors who offer solutions to that - Mentor, Forte, and Synfora.
Emil Girczyc - There's always intervention, but there's a lot of verification and design work going on in SystemC, in the transaction level and modeling paradigm. With standards-based OCP-IP, and companies like ARM, everyone is working at a transaction level through reuse, and through customers' detailed RTL-cycle accurate designs, to interface to the protocol. People are using TL2 and TL3, getting most of the design working, and then using lower-level [design flows] to put it together. You still have got to do some work at the lower level, however.
You can find the full EDACafe event calendar here.
To read more news, click here.
-- Peggy Aycinena, EDACafe.com Contributing Editor.