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!

The other factor that drove SystemC adoption was the fact that Synopsys, Cadence, Motorola, STMicro, and NXP-Philips were involved from early on. Actually, the companies that were involved aren't that important, it's that they gave the process momentum. Otherwise, the history might have been different.

Ken Karnofsky - There is an assumption that there are many, many C programmers out there. The EDA industry says there must be an environment where you can do software and hardware design simultaneously, but the software is becoming more important over time. Therefore, if the software developers use the language, let's use C. However, that's a flawed premise. Because if you add all of these constraints to C to makes it applicable to hardware, the software people don't like it. But if you use C as a sequential language, it doesn't serve any purpose to the hardware community. So the whole discussion is [stuck] in this nowhere land. C is not in the sweet spot for the software
or hardware community. It's good for architectural exploration, but not for hardware design.

Simon Napper - Clearly in ESL, different people are taking different paths and at every level, you have degrees of confusion and complexity. If we could segment the move to ESL in terms of the dominant driver, it's the consumer market - cell phones, digital cameras, set-top boxes - and they all start of with a specification in C. People all want to get to silicon as quickly as possible, so we say if the spec is in ANSI C, why not take the implementation in ANSI C? We say we'll create the SystemC model from that, which allows you to fit it back into the environment.

Meanwhile, there are the MATLAB/Simulink guys who tend to be at the block level. Their users use MATLAB to come up with an implementation. AccelChip was sort of around that implementation path, but that's now used by Xilinx. [Xilinx purchased AccelChip.] And, once you've got a black box, you can use UML to export that IP to other groups. So, if you have a video codex, the interface is open to interpretation. But at every level, you have degrees of confusion and complexity here.

Hamid Agah - SystemC is a standard that came into existence a few years ago. It tried to solidify the industry behind one common high level of abstraction that has libraries or constructs that bring hardware aspects into the high-level languages. At Xilinx, we've always believed that solid standards will be adopted. We want to help those partners who have gone to higher levels of abstraction, and have tools that come from there into our system. SystemC came into the picture, and there are some who are standardizing on it. But that doesn't mean it's the only language out there, or the language for starting the design flow.

Shiv Tasker - English is a language, and how you use a language is important. You can write low-level stuff in SystemC. You can write RTL in SystemC. But if you write high-level SystemC, can you generate hardware from it? The answer in a lot of cases is no. So, the algorithmic synthesis guys require you to write SystemC in a specific way. We specify this is the way you must write SystemC to generate competitive hardware from it.

Shawn McCloud - The reason you're seeing multiple languages is that it's difficult to have one language for an entire implementation space. For example, in DSPs, C is a natural choice. It's already the dominant language of choice for DSP processor design. So, in that space, the natural path to take is to use C to [achieve] dedicated hardware. However, with a DMA controller or a network switch, there may be a language that is a better fit. I'm not going to comment on which, but one will bubble to the top. It's always about survival of the fittest.

From the verification point of view, both SystemC and SystemVerilog are being used to help verify designs. These two languages approach things from both ends of the design process. SystemVerilog is used by hardware verification and integration engineers to formally verify inter-block communication protocol. SystemC is used by system architects to create virtual prototypes to optimize system architecture. One starts at top-down, and one comes from bottom up. They're largely complementary for verification, although in the long run they may tend to merge in their capabilities.

From an implementation point of view, we think in order to achieve 10x to 100x improvements, we must move away from the HDLs and go to other languages. From Mentor's point of view, ANSI C++ has been attractive to our users when they're asking, "How do you get constraints into the design?" We're talking here about high-level synthesis, and there are two ways to get there.

One way is that you can embed it in the source, hardcoding it into the C-code description of the I/O protocol. Or, you can keep the C code neutral and use an external set of constraints, separate files that apply high-level synthesis tools to target C programs to certain hardware protocols. I like to call this the difference between ANSI C++ and Hardware C, where you're actually embedding details in the source.

Mentor does champion SystemC, and we have verification products that leverage the language. If you look at SystemC adoption today, the overwhelming use is for verification at the system level. But if you're looking to create new IP, new innovation, new design content - the better place is the higher abstraction in ANSI C++, and then using high-level synthesis to output RTL. The output, the RTL model, then fits into your verification environment, which allows you to use both worlds. It's hard to quantify how many people buy into this philosophy, but if you look at some of the research data, it's clear that the dominant verification language is SystemC. However, in ESL, you still see a
combination of languages.

Steve Pollock - The nice thing about SystemC is that it's readily adoptable by software developers. It's C++ with the concepts of signals, and it's basically a programming language. It's also easy to adopt in two different areas, that of the system architect and that of the testbench engineer. These are two different markets and SystemC is used effectively in both.

Mitch Dale - I think SystemVerilog is catching on somewhere within the verification space, from talking to customers repeatedly over the last few years. But people have been writing C models pretty much forever, which is why it's SystemC [for ESL]. The difference between now and a few years ago, however, is that the C models used to be written by the architecture guys and then discarded. Today, you can't do that. You have to use those models for the software developers. There's too much fidelity there to throw them away. They include the assumptions those initial engineers are using to describe the system.

Vincent Perrier - Simulink is only a data aggregator and UML is really on the software side of things. It's not very good at representing the hardware side of things, and is absolutely not executable. So you can't really simulate with it, get a busload, a CPU load, or a real time load. Although, you can get that with CoFluent.

Frank Ghenassi - ANSI C and SystemC are very complementary, but ANSI C cannot describe parallelism, or communication between parallel blocks. That's what SystemC is providing. Actually, at ST that's the way we do it. We do our algorithms in C and wrap them in SystemC to model the parallelism and communication between the parts of the chip.

At one time, we were looking at SpecC, which was some very nice university work that tried to get into the industry but didn't succeed. Also, HandleC always remained a language from a startup company because it didn't include all of the features that we required at the time.

A.K. Kalekos - UML is a specification language mostly used for software design that is now trying to expand into hardware design. I think that UML may be a factor in ESL design, but it would be for a subset of the product platforms. UML is ideal for components that are brand new, but it's not necessarily the perfect environment for capturing the entire platform. If you're doing a new product, you're using a lot of legacy blocks, so UML theoretically attempts to start with a blank sheet of paper and allows you to refine and define the design. But that's too theoretical for what the products people are doing today.

« 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
  • 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)

  • 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)

For more discussions, follow this link …
Synopsys: Custom Compiler


Featured Video
Peggy AycinenaWhat Would Joe Do?
by Peggy Aycinena
Reverie: All That Glitters is not Past
More Editorial  
Digital and FPGA Hardware Designer for Giga-tronics Incorporated at San Ramon, CA
Technical Support Engineer for EDA Careers at Freemont, CA
Development Engineer-WEB SKILLS +++ for EDA Careers at North Valley, CA
Technical Marketing Manager Valley for EDA Careers at San Jose, CA
Senior Physical Design Engineer for Ambiq Micro at Austin, TX
Upcoming Events
Zuken Innovation World 2017, April 24 - 26, 2017, Hilton Head Marriott Resort & Spa in Hilton Head Island, SC at Hilton Head Marriott Resort & Spa Hilton Head Island NC - Apr 24 - 26, 2017
2017 IoT Developers Conference at Santa Clara Convention Center California - Apr 26 - 27, 2017

Internet Business Systems © 2017 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — 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 Policy