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.
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.
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.
You can find the full EDACafe event calendar here.
To read more news, click here.
-- Peggy Aycinena, EDACafe.com Contributing Editor.