ESL 2.0 = EDA 4.0 … Continued

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 | 15  Next Page »

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 …

SolidCAM - Break The Chains

Featured Video
Mid-Level Mechanical Engineer for Kiewit at lenexa, Kansas
Mechanical Engineer for Allen & Shariff Corporation at Pittsburgh, Pennsylvania
System Designer/Engineer for Bluewater at Southfield, Michigan
GIS Data Analyst for CostQuest Associates, Inc. at Cincinnati, Ohio
Geospatial Analyst/Programmer for LANDIQ at Sacramento, California
Product Manager for CHA Consulting, Inc. at Boston, Massachusetts
Upcoming Events
ESPRIT World 2018 at Indianapolis Marriott Downtown 350 West Maryland Street Indianapolis IN - Jun 11 - 15, 2018
HxGN LIVE 2018 at The Venetian Las Vegas NV - Jun 12 - 15, 2018
IMTS2018 International Manufacturing Tech Show at McCormick Place Chicago IL - Sep 10 - 15, 2018
4th International Conference on Sensors and Electronic Instrumentation Advances (SEIA' 2018) at Movenpick Hotel Amsterdam City Centre Amsterdam Netherlands - Sep 19 - 21, 2018
Kenesto: 30 day trial

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 EDACafe - Electronic Design Automation GISCafe - Geographical Information Services TechJobsCafe - Technical Jobs and Resumes ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy PolicyAdvertise