December 04, 2006
ESL 2.0 = EDA 4.0 … Continued
Please note that contributed articles, blog entries, and comments posted on 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.
Peggy Aycinena - Contributing Editor

by Peggy Aycinena - Contributing Editor
Posted anew every four weeks or so, the EDA WEEKLY delivers to its readers information concerning the latest happenings in the EDA industry, covering vendors, products, finances and new developments. Frequently, feature articles on selected public or private EDA companies are presented. Brought to you by If we miss a story or subject that you feel deserves to be included, or you just want to suggest a future topic, please contact us! Questions? Feedback? Click here. Thank you!

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.

Shiv Tasker - The answer is different with every customer. Every customer has different needs, and will want to migrate up to higher level of abstraction in a different way, so we'll take a language-neutral stance. We have both SystemC and SystemVerilog as host languages. Originally Bluespec's emphasis was on SystemVerilog, but now we have SystemC, as well. The important thing we changed is the concurrency model. In SystemC, the concurrency model is exactly the same in SystemVerilog, Verilog, or VHDL. The engineer is responsible for doing all of the scheduling of the design. If you're responsible for all the scheduling, you can easily make mistakes, and you'll have a long
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.

« Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 |  href='/nbc/articles/view_weekly.php?articleid=330353&page_no=15'>15  Next Page »

You can find the full EDACafe event calendar here.

To read more news, click here.

-- Peggy Aycinena, Contributing Editor.

Review Article
  • New menu ESL December 05, 2006
    Reviewed by 'Hemanth'
    Peggy, nice expository article. Electronic System Level or Extended System Level or whatever it is atleast one thing is certain, that there is a necessity for it and people are trying out. So going by the discussion above it looks like a range of concepts can co-exist under the umbrella of ESL but the common theme being that it will assist us in doing the job better and more efficiently. I work for a large technology company and infact recently worked on a project where systemC is being newly adopted as the environemnt for initial architectural validation and subsequest functional verification. Building the new infrastructure suitable for systemc, I think, took a lot of effort and was time consuming but the idea is that the payoff is going to happen with better verification and the expected extensive re-use for next product lines. I cant really say if we realized any reduction in the whole process cycle as it was done from scratch but that may very well be so in the future.

      Was this review helpful to you?   (Report this review as inappropriate)

  • Good info, but needs condensing December 05, 2006
    Reviewed by 'John B.'
    I found some good points in these interviews, but 29 pages long? It's too much unless you're in EDA Marketing and want to see all these details. I'd prefer an excerpted interview and a distilled summary article. At least I see that you prefaced it with saying it's a "lengthy article"!
    This comment applies to many of the articles on this web site -- they are too many pages long and need tighter editing.

      2 of 3 found this review helpful.
      Was this review helpful to you?   (Report this review as inappropriate)

For more discussions, follow this link …

ClioSoft at DAC

Featured Video
Senior Electrical Engineer for Allen & Shariff Corporation at Pittsburgh, Pennsylvania
Upcoming Events
2018 FLEX Korea at Room 402/ 403, COEX Seoul Korea (South) - Jun 20 - 21, 2018
INTERSOLAR EUROPE 2018 at Munich Germany - Jun 20 - 22, 2018
DAC 2018 at Moscone Center West San Francisco CA - Jun 24 - 28, 2018
Symposium on Counterfeit Parts and Materials 2018 at College Park Marriott Hotel & Conference Center MD - Jun 26 - 28, 2018
ClioSoft at DAC
TrueCircuits: IoTPLL

Internet Business Systems © 2018 Internet Business Systems, Inc.
25 North 14th Steet, Suite 710, San Jose, CA 95112
+1 (408) 882-6554 — Contact Us, or visit our other sites:
AECCafe - Architectural Design and Engineering TechJobsCafe - Technical Jobs and Resumes GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy PolicyAdvertise