( SNUG 02 Item 7 ) --------------------------------------------- [ 5/15/02 ]
Subject: Superlog, Verilog-2001, Synopsys SystemC, CoWare
STICKING TO WHAT WORKS: On the 'to C or not to C' question, my readers
have been very adamantly anti C. This isn't a polite 'no, thank you'. It's
a deeply distrusting we-don't-want-to-relive-the-VHDL-wars-where-a-lot-
was-promised-but-nothing-changed NO, THANK YOU. This mimicks last year's
reaction (see SNUG 01 #14) with the exception that now it's a specific
dislike for SystemC design because SystemC is the only remaining survivor
out of the last 2 year's crop of failed C-based HW EDA companies. Facing
this user wrath, SystemC had to back off and become an architectural
algorithm exploration simulation. (Yawn) Superlog and the Verilog-2001
extentions are what's capturing the attention of engineers who actually
design real chips these days.
"Superlog Superlog Superlog. By the time SystemC is done, it combines
all the disadvantages of C (a contrived event model, nor an inherent
concept of time) with all the disadvantages of HDLs (runtime
"challenges" -- continental drift anyone on a 70+ million transistor
design? -- and a lack of high level abstraction mechanisms.)
Superlog addresses these in a much cleaner way.
In addition, it's high time to dispel the myth of if we can use C to
design ASICs, then C programmers can be ASIC designers. That's BS."
- Tom Heynemann of Compaq
"Having done one core in VHDL and one in Verilog and having translated
both into the other language, I have to say Superlog as superset of
both languages best features would be THE way to go. I'd love to see
this succeed."
- an anon engineer
"SystemC and Superlog are good ideas. The problem is that they have to
be generic (work with several vendors) and be deterministic (work the
same way on several vendors tools) before you can mainstream them.
Otherwise you may be left holding the bag on code you can't use again."
- David Bishop of Kodak
"The Verilog 2000 extensions are a step in the right direction but we
need more than a step. However, I'm sure we will use whatever is
supported BOTH synthesis and simulation tools. Superlog is a natural
progression it requires minimal training and can be used for both
design and verification. SystemC will most likely become an
architectural trade-off tool."
- Neel Das of Corrent Corp.
"I don't see us using SystemC now, but possibly within a year to
18 months. You ask if I would want to.
Hmmm, I don't know C/C++ but I am afraid that C-level RTL is on its way
in. I have put off learning C/C++ but I think I will have to learn it
now. So to answer the question, no I don't want to but I think
industry is headed this way.
I like what Superlog has to offer. From what I understand Superlog can
call in C (C, C++, SystemC) for simulation, synthesize the ESS portion,
read in Verilog 2001 (Verilog 95 included) all in the familiar Verilog
environment. I find this attractive because I know that the learning
curve will not be a steep since I do not know C/C++."
- Steve Elzinga of Xilinx
"Personally, I will vote Superlog. SystemC RTL modeling is really
really terrible. I can not imagine to use SystemC for RTL modeling.
One thing I like very much is the System-Verilog's encapsulation for
the interface. This is a very useful feature for SoC integration.
And we are already doing this by using PERL script on the current HDL
based design, but it will be much more convenient if this is already
built in the language and handle by the tools. Only remaining problem
is when SYNOPSYS start to support System-Verilog? I know that now the
Get2chip can take the System-Verilog (or synthesisable Superlog), but
I also would like to see SYNOPSYS move to this direction."
- Hui Fu of Infineon
"Don't see myself using SystemC. Don't want to."
- Brent Lawson of Texas Instruments
"I think that it's plain old Verilog up in front, with Superlog a length
behind, and SystemC asleep at the starting gate."
- Dave Chapman of Gold Mountain
"C-based chip design is not the answer."
- Kevin Hubbard of Siemens
"SystemC for synthesis just doesn't make sense. Of course you can't
take any C and synthesize it, you are limited to a synthesizable
sub-set just like in Verilog. Synopsys claims they can synthesize
SystemC and get the same Quality of Results as with Verilog or VHDL
if it is written at the SAME LEVEL OF ABSTRACTION. Why bother? I
don't need another language for design that is doing the same thing
as what I already have!
I don't think Superlog is a competitor for SystemC, C is. Superlog
is a design and verification language, not a architectural modeling
language. Use plain old C or C++ for that and then simulate it with
Superlog or Verilog."
- Anders Nordstrom
"I think SystemC shows some real promise and am looking forward to
seeing how it progresses. It should make a nice addition to our
current VHDL-only design and testing. But, I probably won't be
using it within the next 6 months."
- Donald Whisnant of John Deere
"SystemC holds the most promise. I like Superlog better - but it isn't
a gate simulator, and rumours are the PLI's lacking to a certain
degree. Verilog isn't enough for testing, one needs either C++
or SystemC.
The main issue with SystemC as a modelling language, is the lack of
cosimulation capability - unless you sign up to Synopsys' or CoWares
simulators. If one came out with a reasonably priced PLI between the
open source SystemC and VCS and/or Verilog-XL - we'd buy it. Until
then, we're researching building the PLI in-house. If Synopsys would
license a full blown version CoCentric System Studio for debug, and a
dumbed down version for regressions (no GUI for a lesser price) - we'd
go for that. But alas...
We do not plan to use SystemC for synthesis, but this could change if
the language catches hold."
- an anon engineer
"We use our own C++ based library for system modeling, so I have no
experience with SystemC. However having a standard tool/library is
definitely what we want to see. It is very expensive to support your
own library. Particular the debugging support is important. So we
are starting to consider SystemC.
I observed that system engineers natural choice is a C++ based
language. I believe that it is very difficult to changes this
preference within the system engineering community to a Verilog based
language. This is not so much a technical but rather human/cultural
issue but has to be taken into account as well.
On the ASIC side, a Verilog based approach is most desirable. A
Verilog language extension is overdue and most likely will result in
the least tool problems (simulation, synthesis.)
I am not even sure whether a single language for system simulations
and ASIC design will increase the productivity. Usually two different
engineers perform these duties. It's VERY difficult to find engineers
with solid knowledge in both fields."
- Karl Kaiser of Resonext
"We do behavioural modeling in plain old C -- I have no use for SystemC
or any other licenses I have to PAY for. Been doing it that way for
over 2 decades."
- Tom Moxon of Moxon Design
"We will not use any of the 'new' languages in the next 6 months. I
prefer C/C++ for verification, and plain old Verilog for HDL. If
SystemC does the job, working in a 'standard' language would be the
best of all worlds. I don't think it is there yet."
- Scott Vincelette of Flarion
"We have been using SystemC for architecture exploration and software
simulator purposes for a while. My personal view is SystemC is
excellent for algorithm level or software level analysis. Now the
question is do you want to use this language for hardware design?
I see there can be two paths to do that:
1) Define a 'synthesizable subset', which essentially is a dumbing
down of a language. A la SystemC version 1.0 or 1.2. And if you
are describing your design at a RTL level. But then if you are
choosing this apporoach then why not stick to Verilog?
2) New synthesis approach that can do synthesis at higher level of
abstration. This would definitely take time to gain acceptance,
maturity and quality as compared to today's RTL based synthesis.
Regarding Verilog 2001, I think the acceptance should be no-brainer.
Only problem is that EDA vendors should synchronize the increments they
are supporing. (HA! good luck !!) Currently I see every vendor trying
to support whatever feature is easiest or what their 'A-List' customers
want. Regarding Superlog, I am confused if it's still proprietory or
now adopted by Accellera."
- Shirish Gadre of Sony
"Never used SystemC. No plans in the next 6 months."
- an anon engineer
"Both SystemC and Superlog try to leverage object oriented programming
to boost hardware design and verification productivity. Still the
fundamental simulation throughput is not addressed. Aart's talk
points out the big problem of simulation performance relative to the
verification need. It may be the right time for designers to think
hard about the the synchronous design discipline and adopt the
cycle based simulation technique to improve simulation performance.
Besides the simulation performance improvement, a good cycle-based
compiler can pin-point lots of severe design errors at early RTL stage.
I like to say that a RTL design good for cycle-based simulation will
have better quality synthesized output and is a much cleaner design
for static timing analysis."
- Liang Chen of Sun Microsystems
"SystemC looks promising. This is a tool which has the same syntax as
C++ and thus has every advantage of C. SystemC synthesis tool can even
generate the gate level for us. Therefore, many people think that it
will replace Verilog and VHDL. I don't see that in the near future.
I think the mindset of ASIC designer is: if I'm happy with Verilog, why
bother to change to another tool? More important, even if I changed
from Verilog to SystemC, what do I do with my legacy code?
In previous years, Synopsys emphasizied the synthesis ability of
SystemC but it backfired. Many designers, sticking with Verilog,
reported the inability for SystemC compiler to synthesize large design.
This year the approach of Synopsys is to focus on the 'system
integration' advantage of SystemC since all software, firmware,
simulation file and RTL can be written in SystemC (ideally). Yet their
marketing is very careful when they introduce SystemC in verification
area because they don't want the sales of SystemC to diminish the sales
of Vera. Their R&D guy, on the other hand, was very friendly and kept
asking me whether we'd like them to come to Cisco for a demo."
- Andrew Cheng of Cisco
"I found SystemC interesting, but no, I don't see using anything but
Verilog-2000 for the next 6 months to 1 year."
- Fraya Cohen of Procket Networks
"We are sticking with plain ol' Verilog. No plans to use any of the
other languages in the near future. I'm sure there will be some
resistance if other languages are introduced."
- an anon engineer
"Don't use SystemC/Superlog and don't yet have a need. For our chip
sizes (approx. 300k gates not including RAMs), Verilog is doing just
fine. And besides, we have an internal ANSI-C simulator that a
software guy here loves to create C models for. He translates our
Verilog *after* it's been written and doubles as a good code reviewer,
too. And a lot of each new chip we turn out is built from exiting
new IP, so dropping in new C models to test various functions
becomes a pretty quick process for us."
- Jeff Waite of Netergy Microelectronics
"Don't know SystemC well. Superlog / Verilog 2000 seem very close, and
I would prefer a standard. Definitely would not initiate design on new
chips in the next 6 months with any of them. In 12 to 18 months I would
consider it depending on industry support."
- Curt Beckmann of Rhapsody Networks
"We won't be using SystemC design for the forseeable future. Seems that
there's enough juice left in Verilog (-2000, and other variants) to
satisfy us for a while.
I've been reading through some of the Verilog-2000 IEEE standard. It
improves many aspects of the language, no doubt, and I am sure that
we'll take advantage of it.
No offense intended towards the many people who worked on it, but there
were some things not included that would have made life much simpler
for me:
1. Generate statements that can generate module *ports*, not just
internal logic/instantiations, etc. Yes, we are actually writing
code doing this, crazy as it may seem. It comes in handy. We're
solving this right now using "generator pre-processing scripts".
A bit ugly. Unless I'm missing something in the standard...
2. A simple namespace directive like C++. Verilog-2001 has a pretty
complex "config" construct, and I still have to figure out how to
use it. Maybe it will solve our problem, but I don't think so.
Would be nice to change one "namespace" line & have it encapsulate
all our module names, etc. in a separate namespace.
Anyway, we'll definitely migrate to Verilog-2000 (2001?) over time, and
I hope that some good work comes out of the Accellera standards efforts
and System Verilog."
- Kris Monsen of Mobilygen Corp.
"SystemC could provide the object-oriented features VHDL lacks. It's
not a requirement for success. For now, VHDL is enough."
- an anon engineer
"Verilog 2000 seems like the least worst of the bunch. SystemC looks
like it combines all of the bad features of C with all of the bad
features of HDLs. I would rather become a goat farmer than design
with SystemC.
- Mark Gonzales of IBM
"I am interested in using SystemC for simulation program. The reason
is when doing simulations, it is unnecessary for test bench programs
to meet actual hardware requirements. VHDL is a very foolish language,
no flexibility. I don't use Verilog, either. SystemC introduces C
programming style into hardware simulation program. But I think there
are still obstacles to use SystemC, at least now I am not sure if
ModelSim software supports the SystemC."
- Weng Tianxiang of Micro Memory, Inc
"I have no use for SystemC. Superlog could be interesting, but less so
since the Verilog 2001 standard appeared. Verilog-2001 is the one I'm
interested in, because it addresses some of the Verilog weaknesses,
especially the genif statement and always @*"
- Oren Rubinstein of Nvidia
"If the language war was over, and supposedly won by Verilog, why are
all these languages/variants popping up that add all these great 'new'
features that VHDL users have enjoyed for years? Assertions in RTL?
User-defined, abstract, and/or enumerated data types and structures,
even on ports? All of these have been available since 1987 in VHDL.
My only hope with all these 'advances' is that, if and when VHDL
finally goes away, I won't have to go backwards to the next best
language. Since 1993, when VHDL added the ability to directly
instantiate entities, even the major objection to VHDL (the cumbersome
component definition and configurations) has been unnecessary. Y'all
go ahead and keep working on Verilog and it's variants; maybe some day
it will get better than VHDL, and then I'll switch!"
- Andy Jones of Lockheed Martin
"I don't know what kind of HDL most ASIC designers will use in the year
2010, but it will be called 'Verilog'."
- Steve Golson, guest speaker at SNUG'02
|
|
