( 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