( ESNUG 414 Item 7 ) -------------------------------------------- [06/18/03]
From: Evan Lavelle <eml=user company=riverside-machines spot calm>
Subject: The News From Those Who've Done It; Evan's Pros & Cons of SystemC
Hi John,
Some comments on SystemC's pros and cons for you. First off, I don't use
SystemC for RTL synthesis. I do, however, use it for architectural design:
device definition, cycle-accurate behavioural modelling, design space
exploration, HW/SW co-simulation, and verification. SystemC does a pretty
good job in all these areas, and lets you do in *one* industry-standard
language what might otherwise require 3 languages, 3 design environments,
and 2 expensive licences. And, of course, it's free. In short, if you're
doing architectural design, it's pretty much a no-brainer. That's the
summary: the details are, of course, a bit more complicated.
The first detail is that writing synthesisable code is pretty tedious. I
don't consider this to be the end of the world, but most people don't get
beyond this point, so I've put it at the top of the list. SystemC is simply
a C++ class library, so it can't add any syntax to C++. This means that
basic HDL functionality, such as driving signals, creating processes and
modules, and so on, has to be shoe-horned into existing C++ syntax. This
works pretty well, although I'm reminded of Samuel Johnson's famous remark
about dogs walking on their hind legs: "It is not done well, but you are
surprised to find it done at all."
In practice, the most significant SystemC problems are:
1. There is no way to model continuous/concurrent assignments in SystemC.
All signal assignments must be carried out in processes.
2. Defining always blocks/processes is verbose in SystemC.
3. With SystemC, the use of signals and variables is not always symmetric.
In some cases, reading and writing signals is considerably more verbose
than reading or writing variables of the same type.
You suffer from these whether you're writing cycle-accurate behavioural code
or synthesisable RTL code, so you can't get away from them. However, they
should all be potentially solvable with suitable preprocessing. (Anyone
remember Ratfor?) You should also bear in mind that the actual time taken
to write synthesisable RTL, in the context of a complete project, is
negligible. This has always been true (even RTL coders actually have to do
some design work), and is even more so at smaller geometries. Jacques
Benkoski, Monterey Design's CEO, was recently quoted as saying "At 90nm
functional verification becomes an absolute nightmare. It takes far longer
to correct RTL than write it".
On the plus side, it is very easy to write highly-configurable RTL; even
more so than in VHDL (since you control model elaboration, and can do
whatever you want beforehand.)
That being said, my list of remaining SystemC pros and cons is as follows:
The SystemC Pros:
-----------------
1. It's C++. You can't overstate the advantages of this. The world's full
of C++ programmers, for all those bits that aren't RTL. You can even
run it on Windows. There is also a vast amount of useful software
already written in C or C++. As an example, my current code is
documented with Doxygen, and uses mpatrol for memory leak detection.
The front-end uses a parser developed in Bison and Flex, as well
as having a Gtk GUI. As a plus, all these tools are free.
2. It's got a simulation kernel built into the library; so you don't need
another HDL to run a simulation. This can make running SystemC together
with Verilog or VHDL tricky, but some tools do integrate SystemC
co-simulation (NC-Sim, for one).
3. SystemC has a (beta) verification support library (SCV), based on
Cadence's TestBuilder. This gives you introspection, transaction
recording, and constrained randomisation. There's nothing to stop you
writing your own, or course.
4. You can do everything from random stimulus generation, through
transaction-level modelling, right down to RTL-level modelling
in a single tool in SystemC.
5. The C++ STL (Standard Template Library) saves a huge amount of wheel
re-inventing.
6. If you're doing behavioural modelling, SystemC will do a better job
than Verilog. If you're doing transaction-level modelling, SystemC
will do a better job than either Verilog or VHDL.
7. You get the source code. You can look up the current bugs on the
website, and fix them yourself if you want. Synopsys does retain some
control, but Cadence's involvement should ensure that it stays around,
whatever Synopsys decides to do next week. At this stage, it looks
(politically) as if SystemC has a better future than System Verilog.
8. It's free. Did I already say that? This may seem like penny-pinching,
but consider this. If you write your behavioural code in Verilog or
VHDL, then you may need many licences when developing and exploring
complex devices. If you write your RTL in Verilog or VHDL, then you
will certainly need many licences when verifying the RTL.
9. SystemC has fixed-point arithmetic; very useful for DSP code.
10. It's easier to develop large applications in C++ than it is in Specman
or VHDL (or Verilog, if you're so inclined). Incremental compilation
and linking is easy, as is the creation and use of shared or static
libraries. VHDL has some of this functionality, but not enough.
11. SystemC is relatively fast.
The SystemC Cons:
-----------------
1. It's C++. There's no new syntax, which makes RTL tricky (see above).
C++ is complex, quirky, and difficult to learn. If you only know C,
you'll need to do some more reading before starting with SystemC,
because all those RTL bits are fitted into C++ using things like
class hierarchies, operator overloading, and templates. As for the
learning curve, my own estimates of language difficulty, rated 1 to
20, with 20 being the hardest, are:
C 10
Specman 11 (excluding generation and temporals)
Verilog 12
VHDL 14
Usable C++ 16
Specman 16 (including generation and temporals)
Expert C++ 20
2. The SystemC verification library is not nearly as sophisticated as
dedicated tools such as Specman. SystemC also does not provide any
form of temporal assertions. However, given that it's C++, you can bet
that someone will be offering PSL or Sugar 2.0 as an add-on in the near
future. You can also run Specman on top of SystemC if you require the
extra functionality.
3. The SystemC documentation is currently poor. There are a couple of
books, and a newsgroup, but the LRM won't be available for 2 or 3
months. C++ itself, of course, has a vast amount of documentation,
and a couple of very good newsgroups.
4. SystemC compiler error messages can be a problem. Some user-level
errors can only be detected by the compiler deep in the SystemC code
itself, and some debugging can be challenging. This is another
disadvantage of not having any new syntax.
5. If you just use the free simulator, then you're stuck with VCD dumps
for debug. You need the commercial tools for anything better.
I may be wrong, but I think that CoCentric is still the only synthesiser.
However, there are multiple tools for converting between SystemC and other
HDLs, as well as other simulator implementations.
- Evan Lavelle
Riverside Machines Ltd. Dereham, Norfolk, UK
|
|
