( DAC 01 Item 8 ) ---------------------------------------------- [ 7/31/01 ]
Subject: Forte/CynApps, C-Level, CoWare, SystemC, Frontier, Y Explorations
THE NEXT GENERATION: On two levels, Synopsys has been horribly embarrassed
in pioneering SystemC as the "wave of the future". The first embarrassment
came from the poltical fiasco around getting SystemC out as a supposedly
"independent" standard. Too many people kept walking out loudly saying
SystemC was a Synopsys scam. And this happened multiple times! Ouch. The
second embarrassment for Synopsys here is, after all this grief, C-Level's
"System Compiler" is beating the crap out of Synopsys's "SystemC Compiler"!!
Three months ago at SNUG'01, Dan Joyce of Compaq reported the first C-Level
tape-out. Below, I have 6 more designers reporting either that they're
using C-Level "System Compiler" for current designs or that they've already
taped out with C-Level. In contrast, there's only 1 guy around talking
about using Synopsys "SystemC Compiler" for a design *plus* a lot of other
user letters saying how they tried but couldn't get SystemC to work! Ouch!
Forte/CynApps' special CynLibs flavor of C classes seems to be capitulating
to the massive marketing arm of Synopsys SystemC. They're talking about
'merging' their CynLibs with SystemC.
Frontier, Y Explorations, and CoWare seem to be forgotten sideshows here.
Out of the 182 customer responses I got for this report, these 3 companies
were only mentioned once (each).
"We use C-Level for a portion of our chip design (not the entire
chip). We wanted to prove out the process before committing a
larger piece of the design to this approach. We've maintained
this C-coded part of the design and have not had to do any editing
to the compilied Verilog. It does work.
Our current device is currently in final routing & timing closure
and tapeout is (knock on wood) expected in the next couple weeks."
- Michael Renault, Onex Communications
"Although not exactly a freebie, after getting a basketball at the
C-Level booth (cool give-away), you could walk over to the nearby
Forte (formerly CynApps) booth and they had ball needles to let
the air out of the C-Level claims! (Cute! -- plus it made it easier
to pack the basketballs to take home.)
- Cliff Cummings of Sunburst Designs
"We did an extensive evaluation of C-Level back in March. Based on
that we convinced upper management to fund the purchase even though
money was tight. We are using C-Level on two designs and plan to
make a presentation at our next internal design symposium."
- Harley Pritt, Alcatel USA
"* CynApps is still alive and well (or so they say), but they've merged
with Chronology and formed a new company called "Forte". They're
marketing themselves as providing major productivity improvement in
functional verification through system modeling, synthesis, and
simulation. I spoke with Dr. John Sanguinetti, the founder of VCS's
Chronologic, and he felt that the C languages will merge soon.
* Co-Centric SystemC Studio continues to look impressive as a modeling
design tool for chip development. Nokia seems to be the biggest user.
* C-Level has made a lot of progress with their tool. They have a
source code viewer that displays the C code and Verilog code in
parallel windows: if you select a line of code, the other window
shows the corresponding line of C or Verilog code. They also have
a waveform viewer and database links into the Debussey debugger, the
industry's best-of-class tool for debugging. I asked about
equivalence checking, model checking, in-line assertion checkers,
and MCL compatibility, and they are working on solutions for all of
these items -- they're working with Verplex for model & equivalence
checking, and they've started working with either Real Intent or
Zero-In for in-line assertion checkers. They also have an in-house
Verilog-to-C converter, and at my prompting, they admitted they plan
to bring it to market as a product.
C-Level has 4 tapeouts, and they expect 6 more before the end of the
year. When we have time, I think it should be fairly easy for us to
evaluate their tools."
- [ An Anon Engineer ]
"We've been working with C-Level Design since early last year and have
received very good support in using C Level's System Compiler to
convert our internal C code to Verilog. The majority of our design
was coded in C with portions being brought in as 3rd party IP in
Verilog or internally coded Verilog blocks. For the most part, the
C coded blocks have been leading the development of the Verilog
portions. The improved simulation performance in C has also allowed
our design and verification teams to perform much more testing on the
C coded blocks to this point.
We are targeting to have parts back this year."
- Barry Pangrle, Clearwater Networks
"I read with interest your comments and the mail you've received about
using C/C++ to design hardware. We have been using C-Level Design's
System Compiler. Our interest was ignited largely because we are *not*
hardware designers. We wanted to find a way to take advanced signal
processing algorithms written in C and run them in an FPGA. Our
environment here is a research one, so the main measure is how much
time is needed to make this implementation step. Our chip does not
need to be cheap, or even maximally fast.
We recently synthesized our first chip with their System Compiler and
now have a working FPGA. I suspect that if we had chosen to learn
Verilog or VHDL instead, we would be at a comparable point. However,
I also think that our next design will be more quickly implemented
using System Compiler than if we had gone the VHDL way.
One last point -- when using C/C++ for hardware design (i.e. CycleC),
we were able to simulate 100k gates of logic and 1.0 MB of memory in
about 3 minutes on a Pentium 2 (750MHz).
The same design in VHDL took 3 hours."
- Rob Lynch, Seagate Advanced Concepts Division
"C-Level caught our attention because of several factors:
- It provides a mean for us to implement our design in C++
and benefit from the speed-up in simulation (obviously).
- It still allows us to have control over the RTL codes produced.
Guidelines can be set for synthesizable & error-free codes.
- It is cycle-accurate (very important!)
- Its method to achieve cycle-accuracy is in line with our own
coding style.
- Its style-checker tool provides an excellent coding-style reviewer.
- No library to build and maintain.
- Cheap since its simulator is a C++ compiler.
We first started to evaluate C-Level during DAC'2000. We purchased
our first license in 1Q 2001 and since then have implemented a 750
Kgate design in C++. Our RTL had been synthesized without error to
0.25 um -- except for some minor inconveniences in translation. We
did not encounter any major bugs in the process."
- Vincent Nguyen, TRW Space & Electronics Group
"We've been using the Synopsys SystemC RTL Compiler extensively for FPGA
prototyping. Using the same SystemC source for algorithm verification
and simulation in C environments and for synthesis is extremely
convenient. The design flow is as smooth as the conventional
Verilog-based one."
- Boris Bobrov, Motorola Semiconductor
"I don't think a lot has changed since last year w.r.t. C/C++ entry.
I see no fundamental differences in 2001 vs. 2000 -- except for the
fact that some vendors were "attempting" to synthesize for low power
from the architectural level. This is new and exciting but I'm not
sure that the companies doing this work really get it."
- [ An Anon Engineer ]
"We're using SystemC for behavioral modeling, plus Wilson Snyder's
SystemPerl extensions. No commercial tools. Looked at
Wiliamette HDL's SystemC linter. It was missing a lot. Not
ready for prime time."
- [ An Anon Engineer ]
"My only experience with Synopsys SystemC proved that you need to write
the tool oriented C description (meaning a limited subset of C.) My
attempt to directly synthesize from the C description generated from
Simulink failed miserably."
- Vladimir Sindalovsky of Agere
"I have experience with SystemC -- just using one part of it in the
Verilog/C++ combined simulation. I can't imagine using it for system
level simulation. Way too slow and overly complex."
- [ An Anon Engineer ]
"SystemC (Synopsys)
The idea here is to do C-based synthesis. Synopsys proposes that a
company write its architectural model in SystemC (a superset of C/C++,
which includes concurrency controls, clock, HW data types). Then, the
company would verify the chip in C/C++ because the Csims run so much
faster than RTL, and then move right into synthesis using scripts that
are almost completely identical to the normal Verilog ones we all know
and love. (You add one new line in place of the normal read from
Verilog line.) There are a number of problems with this:
- Their whole "verify it fast" claim appears to be a big lie, er,
"Synopsys marketing claim". If you verify it as normal C-code,
the sims will run very fast, but that is not the code you can
synthesize. You have to go back and add a bunch of wait()
statements, to infer sequential elements in your code. When you
add those, it appears that the simulation time slows to something
comparable to a VCS RTL sim. And, since you have to think about
the timing and add all the sequential elements to get to
synthesizable code, I don't know how much of a time savings this
really provides over writing RTL.
- Since we don't start fresh on a new chip, but rather have a large
portion of code inherited from previous versions, the simulation
speed up would only apply for the new part of the system. As we
test a larger portion of the chip, we would have to generate
behavioral RTL from the C-code and simulate it with our existing
code. This could raise issues about whether the generated
behavioral RTL will match the synthesized code. For the same
reason, a backend equivalence check of ECO'd gates to ECO'd RTL
would no longer work for the mixed code base.
- Their "synthesize your architectural simulator" paradigm assumes a
pretty different verification methodology. We use the verified
architectural simulator as a gold model, and diff our hardware
results against it to find bugs in the RTL. When the architectural
simulator becomes the hardware, we'd need a different strategy
because the verification problem would be different.
Plus all gate-level sims have to be done using a co-sim, which would
be dog-slow."
- [ An Anon Engineer ]
"We went through a "C" phase, but are over it for the moment. We
extensively use our own homebrew PLI-based C/Verilog co-simulation
methodology for our SOCs. I write as much C as I do Verilog. But,
Verilog is our HW language. One senior person had so much trouble
getting the SystemC package to compile about 9 months ago, that it
was a real turn-off. We had some interest in CoWare and tested the
waters with our Software group. Their limited time resources (and
ours) kept us from bying into a new C-based HW/SW coupling. Everyone
agrees that HW/SW integration is hard. Anyway, we are also a little
old-fashioned and we *like* Verilog and we don't mind doing mixed
C/Verilog co-simulations."
- Tom Coonan, Scientific Atlanta
"CoWare
Another SystemC advocate, with good toys, a content-free demonstration,
and all the normal SystemC problems with their tool. We can't remember
anything about the tool, even the name (N2C comes to mind), but they
seemed to have paid a hefty licensing fee for the rights to all
Dilbert paraphernalia."
- [ An Anon Engineer ]
"For what it's worth, we're doing a SystemC based behavoral modeling,
Verilog RTL code, with a public domain simulator and VCS. That drives
Synplicity synthesis for FPGAs, and will eventually drive Design
Compiler for ASICs."
- [ An Anon Engineer ]
"I've looked at Forte, C-Level and SystemC. None of them are useful for
getting working large ASICs out the door. SystemC can compile, but is
not tuned for anything but exploring possible solutions."
- Jeff Deutch, Avici Systems
"We looked at Vera and Specman. Specman seems a lot better then Vera.
As neither nicely supports SystemC, and a lot of the benefit of both is
for "free" with classes etc in SystemC, we bailed. Not to mention
$80K/copy would be ridiculous for the 40+ SystemC executables we can
run at once."
- [ An Anon Engineer ]
"I've spent a fair amount of time looking at these. Without exception,
every C++ library based approach is total crap. Pasting together
netlists manually is lower level, not higher. Simulation times are
longer, as a result. (Higher level HDLs should simulate *faster*.)
Hardware designers know Basic, and often C, but counting on C++
experience is a folly. SystemC is totally the wrong direction to go.
That said, I think there is much promise in the C-synthesis idea. The
C-Level Design aproach isn't bad, but they wont ever generate good HW
from the full ANSI C definition. The SpecC group at Irvine University
is on the right track. Start with a C subset, and adding primitives to
the language to make it a good hardware definition language. Give the
user an environment where you can move code from hardware to software
and back, and have cycle level control. The advantage over SuperLog
(which is a nice language that has my support) is that your embedded
C programmers will be able to get involved up-front."
- Bill Cox of VI ASIC
"Forte
Forte was created by a merge of Chronology and CynApps. As near as
I can tell, they make a particularly useless SystemC verification
tool which translates C code to behavioral RTL for use in simulation.
Their booth guy was the most laughably clueless one we met at the
show, which is why I am not sure exactly what their product does."
- [ An Anon Engineer ]
"I like CynApps better than SystemC. Didn't see too much new with
the tools."
- [ An Anon Engineer ]
"Forte Design / Cynapps also looked interesting, since they are
supporting C++, as well as Rave, if we wanted to migrate to an entirely
new environment. Unfortunately, this would make it difficult to
provide our simulation environment to our customers, due to licensing
issues."
- [ An Anon Engineer ]
"Y Explorations Inc. (yxi.com)
They have a tool that allows designers to code a mix of behavioral
code, RTL code and IP blocks, and this year it takes C as well,
which it synthesizes into RTL. The designers get a list of functions
or procedures for which cores are available, and can add their own
behavioral functions. The really interesting thing is that they
automatically build a shell around your core to put it in its
environment. They will vary buffer sizing, add registers, and even
modify state machines to allow a core to be inserted. They also
generate the Synopsys constraints for the IP.
The tool also understands that arrays in your code represent
memories, so it automatically creates the state machine to control
the memory when you put an array in your code. They say their tool
is superior to creating Synopsys DesignWare because it's easier to
describe a part, it accepts hard cores (cores where you are buying
a layout) and multi-cycle cores, and it does all the glue logic and
modification of state machines for you. They say it is superior to
instantiating an RTL model of your core because it does the glue
logic on it's own, modifies state machines as needed and generates
Synopsys constraints automatically.
My perception two years ago was that their success would be dependent
on getting lots of IP vendors to describe their cores with YXI's tool.
So far, they have been unsuccessful in that. The bulk of their
customers are in Japan and most of them are using it to describe
their own design blocks for internal reuse, so they are in some way
competing against Synchronicity and EDAptive computing, although
their tool is quite different."
- John Weiland, Intrinsix
"To make this kind of switch a full set of tools will be needed. We
evaluated and rejected SystemC Compiler for the time being. We
really like what Synopsys is planning, but we will wait until they
deliver. We looked at Forte and thought they had a better design and
implementation than SystemC, but we view SystemC as the most likely
defacto standard. We're planning to move to SystemC. If Synopsys
delivers on SystemC Compiler, SystemC will become the defacto.
We have looked at CoCentric, but again, it does not yet meet our
needs because it is not yet well integrated with SystemC. Once it
is integrated, we will eventually take a good look at it.
We looked at a Y Explorations presentation and had some of the best
minds in our company there. The general consensus was "wow, that's
a really innovative approach. I wonder if it will work. Let's look
at it after they have 5 or 10 tape outs". It's too risky for us to
look at until some of the big guys show it can work."
- [ An Anon Engineer ]
"Frontier's AR|T Libraries are definitely good for fixed point
manipulations -- but they are one of the myriad of companies trying
to go down to the gate level with no solid underlying logic synthesis
or timing engine. I just don't like it."
- [ An Anon Engineer ]
|
|
