( BSNUG 00 Item 3 ) ------------------------------------------- [ 10/13/00 ]
Subject: SystemC C++, Superlog, Verilog, VHDL, C-Level, Vera, Verisity
THE SUPERLOG EVOLUTION: Instead of hardware design languages converging on
one standard, they're splintering into at least 7 different flavors with
each splinter having its own special constituency. Out of this chaos, it
appears (oddly enough) that Superlog is gaining in popularity with many of
the very experienced (and influential) veteran chip designers. Also, it
was surprising not to find a single paper on Vera at the Boston SNUG.
"I don't have the time to write a trip report but I did notice a few
things you might want to include in your report. The most interesting
part of Aart de Geus' keynote address what was he did not talk about.
He did not mention SystemC at all. Most of the focus was on timing
closure and how Physical Compiler is going to help you with both
timing closure and crosstalk. When asked, he mentioned SystemC for
verification, but said that it is important not to get into a
language war such as the one with Verilog and VHDL and therefore you
should use C. Strange when there is SystemC, C-level, and SpecC to
mention a few. Now we have five, instead of two languages, if you do
not count Vera and E. My vote for verification language still goes
to Superlog since it is an evolutionary path from what we do today
coding Verilog. Ideally, I want all Superlog features in Verilog so
I can truely have one language for design and verification."
- Anders Nordstrom of Nortel
"The bar gathering was a good opportunity to discuss technical topics
in a round-table setting. Among attendees were Kurt Baty (consultant),
Anders Nordstrom (Nortel Networks), and John Cooley (the ESNUG guy).
Kurt and Anders are members of the 1364 Verilog Behavioral task force
and know Steve Wadsworth. One of the interesting things that we talked
about was SystemC. I asked Kurt and Anders what they thought. Kurt
said, as a consultant, there were definitely things that he would use
it for but implied that Verilog or VHDL are still more suitable for
other aspects of design problems that he works on. Anders said he
prefered Superlog over C. I agree. Superlog looks like the better way
to go. It's geared toward SoC as a one-language solution and
simplifies aspects of software/hardware co-design because design teams
use a common language. Being a superset of Verilog, it incorporates
some of the more powerful constructs of C while allowing use of older
proven design blocks or IP written in Verilog. It's hard to be very
enthusiastic about SystemC. I came away with a "wait and see"
impression of SystemC."
- Steve Start of American Microsystems, Inc.
"Specman v. Vera v. Rave? Please. We're a startup. We're doing lots
of good verification, finding a high degree of correlation with the
lab and best of all, finding lots of bugs using good old Verilog.
Vera/specman/Rave have a place, I guess. Just not here."
- Mark Garber of Equipe Corp.
"Didn't hear anything about SystemC (C++ used for hardware modeling and
eventually direct to synthesis), there were zero papers on the subject,
still hear about it alot in the press, but the users aren't using it
yet."
- Brian Fall of Microchip Technology, Inc.
"SystemC/C++ Modeling:
This is cool stuff. It allows the use of C++ to write cycle based
behavioral models and RTL. The RTL is a small restrictive subset
compared with the simulation. However, it seems extremely powerful
because it gives you the full use of C++ to write simulation models at
a very high-level. This seems perfect for architecture development.
Also, it's free and synthesis companies are supporting it.
Drawback:
It is a cycle based simulation language so it can not mingle with
Verilog's event based engine. This means no structural simulations.
Hence, the dependence on Formal methods and static timing checks for
Post-Syn verification.
Verilog and C without PLI
Co-Design Automation Inc. (www.co-design.com) has a language call
"Superlog". The marketing says that this language allows C/C++ and
Verilog to mingle in the same modules. This would be a big help in
writing simulation models. It sounds very interesting, but they may
use the PLI as a interface under the covers. Benchmarks may need to
be done to determine performance."
- an anon engineer
"On the subject of SystemC, I attended the tutorial and was absolutely
unimpressed. The presenter explained that he was an instructor of the
language and not the inventor and then made several apologies for its
Byzantine methods and structures. SystemC and all of the other C and
C++ based efforts keep confusing their goals based on what they think
the customer may be wanting today. Is it portability and simulation
speed? It shouldn't be. What we need is the next quantum leap in
level of abstraction from RTL so we can describe SOC. When that is
coupled with a tool suite and methodology that allows automated or at
least procedural refinement to hardware and software implementation,
then they will have something to sell. From the tutorial, SystemC does
not raise the level of abstraction from RTL and is actually more
difficult to code. Actually the real hold up for SOC is not capturing
the design but verifying it. Here is a question I have asked several
SOC designers:
If you had to reuse some big block of IP on your next chip and
you were given the choice of:
1) a really good implementation in fully synthesizable Verilog
with constraints and scripts and everything you need to
implement it
- OR -
2) a 100% thorough testbench of the functionality of the IP that
was guaranteed to verify your use of the IP in your system and
application
Which would you choose given that you might have to create the
other?
The answer is usually number 2. So do we need better tools, languages
and methods for capturing designs or testbenches? As you have noted
before, John, where was Vera at this Boston SNUG?"
- Martin Gravenstein of TDK Semiconductor Corp.
"SystemC C++ is starting to remind me of Gateway selling Verilog before
Synopsys came along... you know you can use it for something really
good. So does the guy selling it to you. The trouble is you just
aren't sure what you'll wind up with or how you'll put its "results"
to good use yet.
Put it in the rocket-science-for-big-companies column, for now anyway."
- Mark Garber of Equipe Corp.
|
|
