( DAC 03 Item 4 ) ----------------------------------------------- [ 01/20/04 ]
Subject: SystemC, Mathworks, Mentor Seamless & PrecisionC
THE BIG BOYS BAILED: Long story short, Synopsys pushed SystemC like crazy.
It got enough attention to beat out all the other flavors of C classes, but
the mainstream chip designers showed little interest. Cadence also jumped
in and supported SystemC, but noticed it was a weak market, too. SystemC
turned out to be, at best, an architectural simulation language that still
needs to be hand translated to Verilog/VHDL before it can make chips. Real
designers didn't like that. Synopsys bails on SystemC, instead opting to
pimp Superlog under the assumed name of "System Verilog". Cadence bails on
SystemC by going general ("we support all languages") and now begrudgingly
supports System Verilog. Officially both Synopsys & Cadence are (on paper)
strong supporters of SystemC -- but everybody knows it's now left to the
start-ups to make SystemC happen. Synopsys & Cadence aren't against
SystemC; but in different ways they're putting 98% of their energies into
non-SystemC projects.
What you now see from Synopsys, Cadence, and Mentor are lip service add-ons
to existing tools that politely run SystemC primarily for the Japanese and
European architectural markets. The real SystemC action these days is with
CoWare, Forte, Summit, MathWorks.
Cadence was vehemently against System Verilog, but Synopsys couldn't be
against SystemC since they had championed it only two years ago, so the
Synopsys line was that the two languages don't really compete. Synopsys
said SystemC was for system level design and System Verilog was a
misnomer and was really for more detailed implementation.
Axis is supposedly trying to get portions of System Verilog onto their
accelerators. Synopsys thinks (hopes?) that Verilog 2005, which is
expected in 2007, will probably be based on System Verilog. There is
apparently a lot of political stuff with the committee process, though.
- John Weiland of Intrinsix
We are a kind of Switzerland when it comes to language wars.
SystemC has become a very important component of our business, and the
trend seems to be going upward. So this year, I went to DAC looking for
companies that are providing some sort of SystemC support.
I was happy to see the strong support in tools from CoWare, Cadence,
Forte, and Summit on the show floor, as well as a nice surprise seeing a
demo in another major company's suite. Complete language support varied
among these vendors. This was mostly a function of product maturity,
which is to be expected.
I was particularly impressed with CoWare - they have a proprietary
simulation front-end optimizer and kernel, so I had real doubts about
their language support, but I was able to run all of the labs from our
SystemC class (which include many things that are not "off the shelf")
without modification.
CoWare ConvergenSC
Pros:
1. Excellent compatibility with OSCI LRM, very nice source debugging
capability with SystemC-specific additions. It's the best
source-code debugger I've seen for SystemC.
2. Nice library of probes for instrumentation and data display.
3. The LisaTek acquisition gives them a big advantage to support custom
processors and/or "oddball" low volume processor cores that would be
hard for other vendors to support.
Cons:
1. Slow compile times. You can improve this somewhat by turning off
optimizations. I guess they are betting that users will gain much
more in optimized run times to make up for the slow compiles.
2. Co-simulation with VHDL and Verilog is not well integrated.
Unknown:
1. They claim really fast runtime but only benchmarking will tell.
2. CoWare has been traditionally strong in HW/SW partitioning and HW/SW
interface code generation - hopefully they will better integrate
SystemC with their N2C product.
Cadence Incisive
Pros:
1. Very good compatibility with OSCI LRM.
2. Excellent co-simulation with VHDL and Verilog in a seamless manner.
3. Great simulator for mixed SystemC and RTL/gate simulations.
4. Nice data display of higher-level transactions.
Cons:
1. Pure "OSCI" code needs some minor code additions to get it to work
in the NC environment.
2. Some minor limitations on hierarchical combinations of RTL & SystemC
Unknown:
1. Does Cadence have good ties with IP providers for hardware/software
co-simulation? It should.
2. Needs a synthesis solution for SystemC. Maybe with the GetToChip
acquisition???
Forte Cynthesizer
Pros:
1. Excellent website tutorial on SystemC.
2. Committed to improving and maintaining the open source reference
implementation.
3. Behavioral synthesis from SystemC
Unknown:
1. Quality of synthesis results. Only time and customer experience will
tell. That's the really big question. My personal hope is that they
do a good job, because I believe that behavioral synthesis is
important for SystemC adoption. SystemC can survive without
mainstream use of synthesis, but this adds a whole new dimension and
utility to the language.
Summit Design Visual Elite
Pros:
1. Helps remove the drudgery of writing interconnect and boilerplate
code.
2. Graphical design is more intuitive for some.
3. Hardware-software co-simulation.
Cons:
1. Weak OSCI LRM support (in particular, no support for hierarchical
channels).
2. They are new to the SystemC philosophy/coding guidelines & it shows.
3. I have never been a big fan of graphical tools. I recognize that
many other people do like them, and I can see their utility for
documentation and easing the "overhead" of SystemC. Personally, I'm
more productive with a good programmable editor.
Unknown:
1. Ease of hardware/software co-simulation. The demo looked nice, but
how much work went into setting it up??
Synopsys CoCentric System Studio
Pros:
1. Excellent support of OSCI LRM
2. Nice mix of editing graphical representation with text. Better than
Summit here, but they've been doing SystemC longer.
3. Behavioral synthesis and RTL synthesis of SystemC
4. Very nice library of useful IP
Cons:
1. Debugging SystemC code is not well integrated. It's done by
freezing/starting ddd in "lockstep" with their simulation kernel.
2. Co-simulation with VHDL and Verilog exists, but is not well
integrated. Cadence and Mentor have them beat hands down here.
Unknown:
1. How committed is Synopsys to SystemC?? Talk to their sales reps and
you still hear strong commitment, but then again, you are talking to
a sales rep. I'd say follow the money. Which tools are getting the
funding and staff? Will SystemC ever be integrated with VCS?
Mentor ModelTech demo
Pros:
1. Excellent OSCI LRM support
2. Seamless co-simulation with VHDL and Verilog.
3. Integrated debugging of SystemC code with VHDL and Verilog.
Cons:
1. not available yet.
Unknown:
Synthesis and hardware/software co-simulation.
This was a demo of ModelSim in Mentor's suite. I don't think they have
made an announcement yet.
OSCI SystemC users forum:
The forum was well-attended. The presentations seemed to be trying to
convince people that "Yes, you can *really* use SystemC and get *real*
benefit" I'm already convinced, so I paid more attention to the future
direction of SystemC presentation.
What I heard was fairly disturbing to me. The trend for future additions
to the OSCI standard will be to add features and additions to the
specification WITHOUT providing a reference implementation. I think OSCI
is losing sight of the power of open source. Without an open source
reference implementation, SystemC would be nowhere. Now I agree that
open source does mean that end users can and should contribute to the
reference implementation, but OSCI should remember that unlike other open
source projects, most of SystemC's end users are not professional
software developers. It is unrealistic to think that sophisticated
additions would come from the user community.
Also, while everyone is still making "happy talk" about friendly
coexistence with System Verilog, I'm not so sure. While I do believe
that System Verilog is not nearly as well suited for system-level design
and hardware-software co-simulation, I also believe that System Verilog
does have many nice (and overlapping) capabilities, and enough people
hate C++ so viscerally and irrationally that System Verilog will end up
in many situations in direct competition with SystemC for design starts
at the system level. Today, SystemC has a big advantage with its
reference implementation. If it just turns into a paper spec with uneven
implementation from vendors it would be no better than System Verilog in
that respect.
On the positive side, I did hear some commitment from John Sanguinetti of
Forte that at least some planned future additions to the OSCI standard
would be contributed to the reference implementation. Kudos to Forte!
Overall, I was very pleased with the tools I saw, and with the notable
exception of Synopsys, the problems that I saw can be attributed to
normal EDA tool immaturity and I have confidence that they will be
improved.
- [ An Anon Engineer ]
We use the OSCI SystemC simulator extensively & are generally satisfied
with it. Speed is sometimes an issue, but workarounds have always been
found (e.g. variable precision simulations, toggling between a
functional model and a cycle-based transaction model).
We are just starting serious evals of commercial SystemC simulators.
- Pierre Paulin of STMicroelectronics
I don't think much of C tools.
- Kevin Hubbard of Siemens
We don't use any commercial EDA C tools because we have our own C/C++
environment already.
Nothing beats the flexibility of your own tools and when you're coding at
the C/C++ level anyway. The overhead isn't really that big a deal.
- [ An Anon Engineer ]
We are not using these kind of tools.
- Damien Chardonnereau of Iroc Technology
Too complex and not yet easily supported by the tools. However, the
concept is interesting. The only problem is that it implies the
introduction of both Verilog 2001 (not complete yet and not fully
supported) and C (SystemC and other flavors) at the same time - too
many changes at once.
- Yuval Itkin of Metalink Ltd.
I think C EDA tools is mostly for architecture design. To do the most
accurate timing and performance analyze you need Verilog or VHDL. Maybe
later C will have formal verification.
- Ji Li of Via Technology
My take: The reason we see these tools is because C is a programming
language known by practically everybody, making the learning curve for
their tool less steep. However, the strength of the C language is that
it is standardized and consistent across platforms and vendors. These
tools lack that characteristic because they are specific to the vendor's
own product. Code is not portable, etc. etc. For this reason these
tools cannot live up to their promise. What is needed is for an IEEE
committee to sit down and define a standardized "C" EDA language that can
then be supported by vendors in their tools.
- Luke Simonson of UCLA
I use the OSCI SystemC Reference Simulator and am not familiar with the
rest of the commercial C tools.
- Henry Fung of Solustek Corp.
Some design we have to take it in C for better performance compared to
HDL. Celoxica - Handel-C is doing good in that.
- Gangadhar of DigiPro Design
I was pleased to see the interest in SystemC tools at the system level.
I spent a lot of time with Japanese partners and customers, and think
this is an area where they are leading the way. From Tenison EDA's
perspective, we have a key technology (the ability to model RTL in
C++/SystemC) which enables C/SystemC design, by providing reuse of
legacy/3rd party RTL. This made it a very good DAC for us.
- Jeremy Bennett of Tenison EDA
Accelchip sells a tool that goes from Matlab to RTL (either VHDL or
Verilog). They say most of their customers at present are FPGA
designers; they aren't sure why this hasn't caught on in ASICs. I'm
assuming ASIC people want to hand tweak the code for maximum speed and
density, but I'd think having some initial code as a starting point
wouldn't be a bad idea.
Mathworks sells Simulink, a tool that allows system level design for
communications and DSP systems using Matlab.
Elanix sells a system level design tool for communications, RF and
DSP systems. It uses predefined C based blocks (10s to 1000s of them)
which might include blocks for existing DSP chips. New for this
year - the tool outputs RTL directly. It competes with Simulink and SPW.
- John Weiland of Intrinsix
I didn't look at many of these C tools. I'm a P&R/DRC user, and we had
other people there to look at front-end and verification tools.
I did stop at a couple of the MathWorks, Elanix nor AccelChip booths. I
think these companies are a little late to the party. They're trying to
solve the problems of 5 years ago, thinking that any Verilog/VHDL they
create can be placed. NOT!!
- [ An Anon Engineer ]
C EDA tools are here to stay for long time. The only reasonable
competition is Verilog and System Verilog. The main arguments of these
is that they are C-like.
Stuff like MathWorks, Elanix and AccelChip are hard to map on hardware in
the general case. The subsets are too restrictive.
- Ahmed Jerraya
In our market (ethernet switching), there's actually a fairly limited
number of architectures available, so we don't really need architectural
exploration tools. Hence my liking for System Verilog/Superlog.
We had a presentation from the Beach Solutions guys on EASI-Capture a
while back. It sounds like an interesting idea, tying up your HDL
register map with the C your software people are generating. If I
remember correctly, you create register map in the tool, which then
writes out Verilog defines and C headers with symbolic values for the
actual register addresses. It also generates functions to access the
registers, and you can generate test code to check every register. It
also had what looked like some fairly funky document generation
abilities, so for instance it would write tables in a Word document about
your registers. We have a fairly well structured address map though, so
we didn't feel it would bring enough benefit.
We have some Matlab seats, which the hardware guys use for analysing test
results - we don't use it for ASIC design.
- Thomas Fairbairn of 3com
MathWorks is a great tool. It's quite straight forward and efficient. I
like its script style programming, everything is easy to control,
especially for upsampling and downsampling.
- LaiQing Ping of ESS Technology
I used Mentor's Seamless for co-simulation for our bsp software
development. It did help us to find several bugs before the hardware
arrived. However, the RTL simulation is so slow make even a 'bzero'
operation take forever. We did combine the Axis simulator with Seamless,
still too slow in software development point of view.
- Shumin Tony Zhang of Hughes Network Systems
You did not list 2 tools from Mentor: PrecisionC from the synthesis
group, and a newcomer from the Seamless group called ASAP for Application
Specific Assistant Processor.
PrecisionC is synthesis tool that synthesizes behavioral C into RTL. It
has good constraint driven controls, which makes for faster architectural
exploration and design reuse. Their emphasis is on DSP designs. In the
past I received training on this tool and was impressed with its
capabilities. Still looks good.
The ASAP tool is intended to help the embedded designer improve
functional performance by synthesizing a select portion of the design to
hardware. It does this by using Seamless add-on capability to help
identify and partition the portion(s) of design to accelerate. The input
code is the functional C. This tool has more limited constraint driven
options.
- John Swan of Motorola
Mentor Seamless still seems to have the market lead in hardware/software
co-verification, as I believe it has for years.
VaST Systems sells CoMET (no, I got the capitalization right). This
tool allows the system engineer to create a virtual platform with a
virtual core. They say they are cycle accurate but still very fast
(versus Seamless, they say). They support some processors from ARM,
MIPS, Intel, NEC and Motorola, but say they are market driven and will
support what customers want. They have another tool called Meteor (not
sure of capitalization) which is CoMET with fixed hardware, used for
software development only.
- John Weiland of Intrinsix
I don't think C has any place in EDA design. It's a great language as a
"generic slightly higher level assembly language" but if we can't do
better than that for a specifically targeted HDL then something is
broken.
- Kevin Jones of Rambus
I still don't think the synthesis from C concept is ready for prime time
yet (ever?). Especially considering all the development in the Verilog
and System Verilog area. However the Verilog-to-C conversion is
interesting and I am looking at a couple of tools there. What I am
doing is creating a model that is usable for software & system designers
based on my real RTL.
In an ideal world, the system design happens first and then you design
the chip. In the real world, it all goes on in parallel and
implementation choices will affect the system level.
- Anders Nordstrom of Elliptic Semiconductor
Didn't look at them. My impression is that SystemC is for guys doing
architectural experimentation. Our core design has been around for many
years and I don't think we'll be doing much architecture changes in the
foreseeable future.
- Tomoo Taguchi of Hewlett Packard
|
|
