( DAC 02 Item 3 ) ----------------------------------------------- [ 9/10/02 ]
Subject: Celoxica, Forte, CoWare, SystemC, Seamless, Cadence Testbuilder
NO, THANK YOU (PART 2): The other "No, Thank You" part of the EDA industry
is from chip designers when you ask them about using C for HW design. It's
been this way for years, ever since the concept was first thrown out there
as a trial balloon some time ago. But in this sea of No-Thank-You's, if
you read very closely, you'll find a few voices speaking about how they
think SystemC can work for *architectural* design. That is, as long as
you're not trying to force kludgy SystemC into the gate level, these users
actually like what SystemC has to offer. Again, you'll have to look very
closely because there's an awful lot of people shouting them down here.
"C oriented EDA tools? Don't use 'em. We stick with HDL."
- Mark Wroblewski of Cirrus Logic
"Blah. Little/no interest in C EDA here. We build C cycle-accurate
models for co-sim with the s/w guys. That's about all, works great."
- [ An Anon Engineer ]
"C-based HW design tools are currently of no interest to us."
- Mehran Bagheri of Multilink Technology
"C? Not interested."
- Sean W. Smith of Cisco Systems
"The C market is way over crowded and appears to be a dogfight. I
think a major consolidation is inevitable, and eventually both
Synopsys and Cadence will get the lion share of this market."
- Weikai Sun of Volterra
"C is not ready for prime time, but making progress."
- Phil Hoppes of Intersil
"Over the long term, I think C will kill Verilog in most areas, simply
because people need lots of sim runs to build SOC, and that means
either a lot of Verilog sim licenses (at $20-40K a pop), or a single
tool (at $40K) to convert Verilog into C, and then run a bunch of
free C runs. Harware is free. Headless 2.5 GHz Linux boxes with
1G RAM are $900; it's the software that's expensive.
I can't tell which particular vendor will win the battle over the long
run, however."
- [ An Anon Engineer ]
"We like SystemC and are we are using it for architectual evaluation
and system (hw/sw) simulations with embedded cores. We are currently
using the free simulator and basic c++ compilers. We may look into
Synopsys Cocentric in the future. I think the days of Mentor's
Seamless tool are numbered. We are also very much like the Direct-C
features for VCS and Scirroco. Strange that ModelSim doesn't seem
interested in supporting C or SystemC any time soon."
- [ An Anon Engineer ]
"System Verilog will win in the Architecture/RTL design space. There is
an opportunity for C-based tools in the system space, when the HW/SW
partition is not yet decided."
- [ An Anon Engineer ]
"SystemC - C based hardware modeling language
Features:
1. SystemC is a set of C-libraries that add concurrency, hardware data
types and temporal constructs to the C++ language. SystemC is
compiled using GNU C-Compiler and models can be simulated waves
viewed with open source software. Synthesis tools from SystemC
design to gates or FPGA is becoming available from several EDA
companies. Other tools like better waveform viewers, simpler debug
tools may be purchased mainly for improving productivity.
2. Forte Design Systems has developed a kernel (recently donated to
SystemC group) that gives very good performance for the cycle
accurate SystemC models. Since it is an extension of C++, the
performance is good enough to build a platform for developing
embedded software and OS.
3. Library features for design & modeling have been quite standardized
and widely accepted in the EDA tool industry with the first product
for development and synthesis to gates (CoCentric system studio)
released from Synopsys.
Concerns:
1. For those purely interested in designing a chip SystemC is not a
good choice, Verilog being better due to all the tools and
familiarity. SystemC comes into the picture only when there is a
clear need for a unifying language for design, verification,
modeling for performance and software development.
2. Verification libraries are being discussed at the SystemC standards
committee, so it is going to take 6months to a year for the
standards to be approved and followed by any products.
3. Motorola is piloting a project with complete design with SystemC
and several FPGA designs appear to have done well at universities,
but haven't heard many stories of successful tape outs with
SystemC based ASIC design.
4. Current language constructs look more like C++ code (more lines
than Verilog). EDA vendors need to develop macros and libraries
before the language looks interesting for verilog designers. Forte
Design Systems has such libraries for its internal C++ libraries,
but not yet for the standard SystemC."
- Joe Sargunaraj of Allegro Networks
"I think the remaining C-based EDA tools might die a slow death. Nice
try, but they picked the wrong solution. I'm betting on Superlog to
be the next wide-spread language, unless the Verilog/VHDL people
start evolving the language faster."
- Tom Fairbairn of 3Com Europe
"These C tools look to be getting better, but it's extremely hard to get
HW designers interested in them. I expect slow growth in C for the
next several years at least. We are not using them, but remain
interested in the C system level modeling tools."
- [ An Anon Engineer ]
"To design 10M Gate ASIC, C based behavior synthesis is very important
to reduce complexity. But SystemC is very difficult for hardware
designer. Furthermore, algorithm developers will not use SystemC.
They continue to use ANSI-C. So I think SystemC will become the
interface language like EDIF. I believe that the translator from
ANSI-C to System-C is very useful. This feature must be added both
Cadence's and Sysnopsys's tool.
Regarding remaining C oriented EDA tools, we are benchmarking Cadence
TestBuilder and Future Design Automation. We are starting to use
TestBuilder, but I think it has a same learning curve problem as
SystemC. FDA's design prototyper uses ANSI-C for front end. We like
it, so we asked Future to develop ANSI-C to SystemC translator."
- Zenji Oka of Ricoh
"I found Cadence TestBuilder somewhat opaque, since I went the open
source route. Nonetheless, I believe that TVM is the right model for
complex verification. I'm now using Synapticad's TestBencher Pro to
develop the models, and that really makes things easier."
- Jay Abel of Shera International
"SystemC is most interesting because it is C++, open, wide industry
support and critical mass of users."
- Roland Lee of Ciena Corp.
"SystemC has won out over my technically superior Cynlib. Ultimately,
this won't make a difference, as Cynlib's superiority was at RTL, which
is mostly irrelevant for a C++ design environment. The key attribute
of SystemC (in fact, any C++ class library) is that it is layered. As
the higher level C classes -- channels, verification, inter-process
communication -- get defined, the effectiveness of modeling at higher
levels increases. That is happening now. This is why Handel-C won't
be a significant factor and the C features being added to NC-Sim and
VCS won't be all that important.
CoWare can be important if they ever actually support SystemC in their
tools (they now say Q1/03). Cadence Testbuilder will become the
verification classes in SystemC. I counted over 300 people at
the SystemC DAC lunch on Tuesday -- there is a lot of interest in it.
Synopsys is attacking this part of the market directly on all fronts.
Forte is also centered on SystemC, primarily synthesis. Synthesis is
the necessary technology to make SystemC a viable design environment,
and it is coming. When people see that higher-level synthesis from
SystemC actually works, the controversy will die away. Until that
time, only a few visionaries will do design in SystemC.
Sasake-san from NEC at the keynote address made the (obvious) point
that design methodology had to change in order to design large systems.
He gave an example of a project within NEC that produced a design 3x
as big in half the time using a C methodology vs. an RTL methodology.
(I don't think he said whether it was VHDL or Verilog.) The other
thing he pointed out was that using high-level synthesis (they have
their own C synthesizer) they could produce multiple designs with
different characteristics -- speed, area, power -- from the same
source model."
- John Sanguinetti of Forte Design Automation
"We use SystemC (OSCI version) in our Verilog verification environment,
for modeling hardware components and stimulus generators/checkers.
We evaluated Synopsys' CoCentric Studio, but ended up using our
homegrown PLI-based system for co-simulating SystemC with Verilog.
While we've managed to succeed with this approach, we've found it very
painful. I have a software background, so I can understand some of
the C++ issues. But the poor guys who are more hardware-centric REALLY
suffer when using SystemC. Things that are simple in Verilog are
difficult or impossible to do in SystemC. Granted, we are using it at
the RTL level, whereas SystemC marketing people seem to be aiming
it at higher, system level. Perhaps it's better for that space, though
I have doubts. Anyway, there are two main classes of problems:
1) Generic C++ problems, such as bad pointers, etc. Standard
software stuff, but doesn't happen with Verilog.
2) SystemC problems. Shoe-horning an HDL into C++ causes lots
of problems, since C++ is inherently unsuitable. Simple
example: ports and signals do not know their own names; they
need to be redunantly told with code, but that's not
always easy, such as when using arrays of signals.
My experience so far is that extending C++ with class libraries yields
a far inferior solution to what a dedicated HW language does. And
portability is not increased. I have not used Superlog, for example,
but I suspect it's a much better HDL. And it can call C just like
SystemC can."
- [ An Anon Engineer ]
"To me, the Synopsys VCS DirectC interface is merely a performance
optimization with respect to PLI. It does not add any new features.
In fact it is much less flexible. VCS can call C functions. But C
functions cannot call Verilog tasks, nor can they elapse time. So
C code is still second-class, just like PLI.
But it's probably a better solution than SystemC."
- [ An Anon Engineer ]
"I have been watching the attempts to put a "C" peg into a HDL hole,
with some concern. The result will be a language that is neither
true C, nor true HDL, and worse, will encourage those that 'did a
paper in C', that they can become hardware designers overnight.
Fortunately, these 'C' oriented EDA tools seem to not be catching on,
as enough designer input to the purchasing decisions is keeping a
sanity check on."
- [ An Anon Engineer ]
"C tools:
In design, I don't see any need for a C language based approach here.
Maybe people coming at this from a system designer background can C
the benefit, but I certainly don't.
In verification, C is widely used in simulation, and I expect that to
continue. The Direct-C features in NC-Sim and VCS should improve
simulation performance, and I think that's great."
- Matt Weber of Silicon Logic
"I don't think C is suitable for describing synthesizable hardware. It
generally turns out pretty akward. However being able to use C in
behavioural models and testbenches is a must. Thus, the C-features in
VCS are welcome, but the lack of standardization is inhibiting. (I
still use the PLI.)"
- Stefan Sandstrom of Axis
"I am a hardware designer and I am not going to use any other language
other than VHDL."
- Pascal Gouedo of STMicroelectronics
"I do not like C related coding tools. They are great for some abstract
form of non-existant HW out there someplace. But in my role of using
emulation and HW accelerators for large scale microprocessor designs
these days, I am not keen on C tools since they are nonacceleratable.
PLI to Verilog is as close as I get to any C.
Aso for new C features in NC-Verilog and VCS, I use them both daily
(simulators). Cannot say much for either's new improvements. If
anything, C features slow them down, and we need simulation speed."
- [ An Anon Engineer ]
"I haven't really focused on C oriented tools this year. Our concept
group is currently evaluating Handel-C and a board delivered by
Celoxica for rapid prototyping of their algorithms (image processing).
But we will not use Handel-C to make 'real' silicon."
- Raimund Soenning of Philips
"We evaluated CoWare and Synopsys CoCentric and have found that while
they're good tools, they are competing against a Verilog PLI that's
essentially free. This makes both of these tools are very expensive.
They want to be licensed at around 1.6 engineers per license or
thereabouts and at the prices we've been quoted this is not a cheap.
CoWare is OK if you're at a high level, but once you get down to where
the architecture is reasonably fixed then it's slow. They want you
make a paradigm shift which a more cynical colleague has interpreted
as it means that the CoWare tool doesn't do what he wants it to do!
He also described it as Hyndai quality for Rolls Royce prices.
Synopsys CoCentric is a nice design environment (we didn't look at the
algorithm design side of things which it can do) but too often the
tool 'gets in the way'. Importing our C class library proved to be
difficult and if we went for their (good looking) visualisation then
we'd be forcing our customers down that route, too. Given that we can
do much of what they're offering with Open Source tools, then the
price is a problem."
- Allan Cochrane of Arm
"They said ANSI C is very fast but not bit-wise accurate, while SystemC
is. Verilog and C arithmetic don't always get the same results,
particularly when your operands have mixed bit widths. They quoted
some speed numbers: ANSI C is 50X faster than Verilog, RTL accurate C
is 15X Verilog (note Summit claims 100X faster), and bit accurate C is
3X Verilog. This goes along with what I've heard for years: if you
take C and add all the things you need to make it understand
parallelism, delays, contention, etc. you eventually get another HDL
that is no better than the rest but looks sort of like C.
CoWare sells tools for the C-based design of platforms. Last year they
talked about using either SystemC or their own CoWare C, this year it
was only SystemC; the standard won. Their tool hooks into HDL
simulators for co-simulation and allows modeling at multiple levels of
abstraction and facilitates hardware/software co-design. One
interesting claim is that they can automatically synthesize interfaces
to standard on-chip busses like AMBA - mighty handy.
Future Design Automation sells a behavioral synthesis tool. It
takes ANSI-C (their subset is called FDAC) plus some directives in
comments/pragmas, and it outputs Verilog, VHDL or RTL-ish C.
Forte Design Systems was formed when Cynapps merged with Chronology.
Cynapps had a C++ to RTL synthesis tool. New for this year, their
tool will also take system C. Based on your timing constraints, your
behavioral code might synthesize into a variety of RTL alternatives.
They use a library of pre-characterized blocks like Tera Systems or
Intime does in design planning. They have scripts to characterize
blocks for Synopsys and Ambit; Magma and Synplicity are coming.
Mentor Seamless will help extract the processors out of a design and
run your target code on an instruction set simulator. It can work
along with Modeltech, NC and VCS.
LISATek sells several tools that use their Language for Instruction
Set Architecture (LISA) to do architectural tradeoffs and HW/SW
co-design.
CARDtools sells a tool for modeling your hardware and software at
various levels of abstraction, although it sounded like they
concentrated on performance modeling.
Accelchip sells a tool that goes from Matlab and also Simulink
graphical environment to synthesizable Verilog or VHDL, plus
automatically generated test benches, aimed at DSP designs for
FPGAs (especially that Xilinx and Altera ones that have built-in
multipliers).
Mathworks is selling translators from their Matlab to VHDL and
directly to Xilinx. They are looking at one to translate Matlab
to Verilog.
Agilent sells a tool for signal processing designs that is similar
to Cadence SPW.
Associated Compiler Experts (ACE) sells a development system for
C and C++ compilers, aimed in particular at DSP cores.
Archelon Inc. sells a system to customize a C compiler for your
machine. You fill out a big template describing your hardware and
presto - you have a compiler."
- John Weiland of Intrinsix
"I don't know too much about these tools. My comments are based only on
presentations of CoWare and Synopsys's SystemC. I particularly like
SystemC concept. I really think that we need to move up from
Verilog/VHDL based coding/simulation style to SystemC style. How
mature these tools are is anybody's guess.
We do a lot of fixed DSP based designs here at Conexant and our flow is
almost always coding the RTL and comparing it with the C model. Of
course, if the C model is not available then another person needs to
code the model. This redundance can be removed if I can go straight
from C to RTL to Gates. As far as I know, only SystemC can do this.
CoWare can not. I don't know about any other tools."
- Himanshu Bhatnagar of Conexant
"Forte (CynApps)? I attended a private demo. Their tools set would
represent a good solution for verification. Pros - very good on-site
customer support. Cons - no source code available - must use Rave.
Synopsys SystemC? Wave of the future that'll slowly catch on. Allows
for verification in early part of design cycle. The Synopsys CoCentric
synthesis tool is impressive for designing/simulating large systems.
CoWare? Don't know.
Cadence TestBuilder? This may be gaining momentum as it being adopted
by SystemC working group on verification. Also supported by ModelSim.
We should be testing this since it is open source.
Axys? Good ARM cycle-based simulation models.
Mentor's Seamless? We are using this for a project. We could be using
it more if we use in-line assembly for design specific part of code.
Denali? The only good solution for modeling 3rd party memories."
- Ed Strauch of Cirrus Logic
"One can only hope that the remaining C tools finally become extinct.
Personally, I would have appreciated it if Cadence would have gotten
their VHDL simulation engine and mixed-language simulation working
correctly before they added C to the mix."
- [ An Anon Engineer ]
"I say stuff C-oriented tools! VCS & NC-Verilog's style of being able
to call C routines will help in being able to integrate architectural/
algorithmic models into our hardware design test bench, but we're
certainly NOT planning to write our RTL (or higher-level) hardware
design in C/C++."
- Kris Monsen of Mobilygen Corp.
"The all-C-language fad is coming to a close. Maybe some EDA company
at DAC next year can hire a fat lady to sing the C-language farewell
song so it will be official."
- Cliff Cummings of Sunburst Design
|
|
