systemC vs verilog/PLI for verification

[Dipu]

HI,

I am a design engineer. I use mostly verilog for thr RTL design. For
testbenches I have used verilog and C models embedded into verilog
using PLI. We are starting a new project. We are looking into using
systemC for the testbenches and the verification framework. The RTL
design will be in verilog. How do we compare the Verilog with PLI
based approach with the systemC testbench approach?

I looked into some of the postings in the newgroup. Most of them were
discussions on the pros and cons of using SystemC for design. I do not
want to start a discussion on that at this time

Our design has three diferent sections:
1. Datapath intensive section. We will have a c-model of the
algorithm. Previously we had created input/output vectors from the
C-model and use them with a verilog testbench.
2. protocol intensive section ( similar to a packet based system ).
Previously we have used verilog testbenches to create input sequences
and compare the output with the expected sequence. The input-output
relation is specified in the protocol specification.
3. SOC section. Previously we have used ISA model with BFM of the
processor in the overall verilog RTL simulation of the design.

I would like to hear comments from people experienced with using
system for these types of designs. I am trying to decide if we should
invest in using SystemC for our verification approach or stay with
verilog/PLI approach. We have cadence unified simulation environment
which seems to be able to handle mixed systemC/Verilog simualtion
without much problem. So the tool is not an issue.

I would also like to hear the perspective from design engineers
involved in verification as well as verification engineers.

Thanks.

-Dipu

 

[Raymond Bingham]

dipumisc@hotmail.com (Dipu) wrote in message
[snip compare sysC with Verilog]

A while ago I did an analysis on System C with Verilog using VCS
Cosimulation. I was most concerned about performance, so that's where
this comes from. Here's a readme file on what I discovered. When
discussing this issue with the VCS folks, they told us that there
really is no way to Cosimulation go any faster... (That's a very
abreviated version of what they said, after a couple hours of
discussion and possible work arounds, etc, that didn't really answer
my issues...)

Keep in mind we had our PLI in place from a number of projects, so we
weighed performance heavily, since we'd figured out the PLI interface
okay... (hence it was not necessary to factor into development time,
like most people should)

My impressions of System C, it was pretty easy to learn the basics,
though I didn't have to alter any of the classes or templates or any C
funny business. It was convenient enough. Lack of VCD+ support is a
drawback, cuz regular Virsim wave files files are huge.

----

Here's my readme file... I'm not giving out any code... but it took me
(something of a moron, trust me) about a week to do these examples...

----

The directory structure of this example is fashioned of a sort after
the
directory structure we use in our chip environment. I've have
seperated
testbench (../sim) from RTL (../rtl) and all our tests are run within
the
testbench side of the structure in seperate run directories.


In general here's an ascii block diagram of the test system.

+--------------------------------------------------------+
| Testbench (generates clk and instantiates all submods) |
| |
| clk +------------+____________ +-------+ |
| | +----\ dut | 40b vcount \|compare| |
| | | +--/ (vcounter) +------------/| & | |
| +---v-------+ | +------------+ |display| |
| |stimdata | +--^----+ |
| |(random out) | +------------+ / \ |
| +-----------+ | | "golden" L_______________| | |
| | +--\ model | 40b ccount | |
| +----/ (ccounter) +-----------------+ |
| +------------+ |
| |
| |
+--------------------------------------------------------+


The stimdata module creates random out to both the dut and golden
models: these outputs are:
rst - sync reset
load_en - force counter to be load_data (when count_en == 0)
count_en - count up or down
upordown - 1 = count up, 0 = count down (or vice versa, I forget)
load_data (40 bit) - data to load when load_en is true.

The testbench runs 1 billion up-edge clocks with timescale 1ps/1ps
with
a 20ps period.

In order to compare with our current GM PLI methodology we created a
C PLI to emulate the verilog counter, a systemc equivalent counter to
likewise serve as a gm (golden model) and also ran the cases in "pure"
sysC, and verilog to compare tradeoffs.

The following rundirs (in workdir/sim) hold the builds for each of the
given toplogies (included is how fast they ran).

rundir_ctop - System C testbench, stimdata, GM and Compare module,
with a
verilog DUT (ran for 5 hours, 38 minutes)
rundir_vtop - Verilog testbench, stimdata module, DUT module and
Compare module, with a SystemC GM. (Ran for 4 hours, 21 minutes)
rundir_top_gm - Verilog Testbench, stimdata module, compare module, C
PLI GM and verilog DUT (our current methodology) (Ran for 3 hours)
rundir_conly - Pure System C environment (Ran for 1 hour)
rundir_vonly - Pure VCS Verilog (Ran for 15 minutes)


To run an example, please set vars (in the RUN csh script) to
coorespond to
your install of systemC 2.0.1 and VCS 7.0.1 and then type RUN.

We ran these on systems running Linux RedHat 7.3 and GNU version 2.96
(we
could not get the Solaris version to work correctly).

--Ray

 

[Dipu]

rbingham@dotcast.com (Raymond Bingham) wrote in message news:<c26550fd.0409151504.19e611d8@posting.google.com>...

The following rundirs (in workdir/sim) hold the builds for each of the
given toplogies (included is how fast they ran).

rundir_ctop - System C testbench, stimdata, GM and Compare module,
with a
verilog DUT (ran for 5 hours, 38 minutes)
rundir_vtop - Verilog testbench, stimdata module, DUT module and
Compare module, with a SystemC GM. (Ran for 4 hours, 21 minutes)
rundir_top_gm - Verilog Testbench, stimdata module, compare module, C
PLI GM and verilog DUT (our current methodology) (Ran for 3 hours)
rundir_conly - Pure System C environment (Ran for 1 hour)
rundir_vonly - Pure VCS Verilog (Ran for 15 minutes)

The numbers above indicates that the more systemC components you had,
the longer it took for simulation. Is that correct? I hope I am
interpreting the numbers correctly?

-Dipu

 

[Narendran Kumaraguru Nath]

Hi Dipu,
I've written PLI in verilog and had some time to look around systemc
with the freeware simulator kernel that came with it. In my experiance
you need people having good knowledge of both c++ and VHDL/Verilog.
Also the debugging was a bit difficult with systemc.
I don't have any performance figures. Also since the tool you're
going to use may not be mature, it might cause delays down the line.
Also I heared that synopsys had taken back their commitment on systemc
(I don't know how exact the info is).
Remember - These are just my prespective of the world!
Thanks & Regards,
Naren.


dipumisc@hotmail.com (Dipu) wrote in message news:<d074680d.0409160918.d82dde1@posting.google.com>...

rbingham@dotcast.com (Raymond Bingham) wrote in message news:<c26550fd.0409151504.19e611d8@posting.google.com>...

The following rundirs (in workdir/sim) hold the builds for each of the
given toplogies (included is how fast they ran).

rundir_ctop - System C testbench, stimdata, GM and Compare module,
with a
verilog DUT (ran for 5 hours, 38 minutes)
rundir_vtop - Verilog testbench, stimdata module, DUT module and
Compare module, with a SystemC GM. (Ran for 4 hours, 21 minutes)
rundir_top_gm - Verilog Testbench, stimdata module, compare module, C
PLI GM and verilog DUT (our current methodology) (Ran for 3 hours)
rundir_conly - Pure System C environment (Ran for 1 hour)
rundir_vonly - Pure VCS Verilog (Ran for 15 minutes)



The numbers above indicates that the more systemC components you had,
the longer it took for simulation. Is that correct? I hope I am
interpreting the numbers correctly?

-Dipu

 

[Raymond Bingham]

dipumisc@hotmail.com (Dipu) wrote in message

(Ray wrote this)
rundir_ctop - System C testbench, stimdata, GM and Compare module,
with a
verilog DUT (ran for 5 hours, 38 minutes)
rundir_vtop - Verilog testbench, stimdata module, DUT module and
Compare module, with a SystemC GM. (Ran for 4 hours, 21 minutes)
rundir_top_gm - Verilog Testbench, stimdata module, compare module, C
PLI GM and verilog DUT (our current methodology) (Ran for 3 hours)
rundir_conly - Pure System C environment (Ran for 1 hour)
rundir_vonly - Pure VCS Verilog (Ran for 15 minutes)

The numbers above indicates that the more systemC components you had,
the longer it took for simulation. Is that correct? I hope I am
interpreting the numbers correctly?

Yeah that's what it appeared, though I didn't scale the project, cuz
we weren't tasked to do much other than an initial investigation. It
would be interesting to see a more comprehensive study. This is
entirely empirical.

Keep in mind the real slowdowns occur when you attempt COSIMULATION
(mixing Verilog with System C (as opposed to PLI, which also creates a
significant slow down. (I have not investigated the equivalent
functionality using VCS's Direct C, though I was "assured" by Synopsys
that if I used it, I'd see far better performance than our PLI)).

It makes sense that it'd be much slower. SystemC has a full fledged
scheduler mechanism in it for maintaining all its methods and threads.
Essentially it's like you're running two simulators.

Pure System C development with NO Verilog would yield speedups
compared with a PLI/Verilog model. Pure Verilog knocked the socks off
of all the cases, of course... but then, who does verification in pure
Verilog!? (Well, I do a lot of it, come to think of it, but (darn it!)
I'd rather not if there were alternatives that didn't cost an arm and
a leg and were reasonably well supported and fast... (am I asking for
too much here!? Sheesh)...

As per the criticism that System C requires "extensive" C++
experience. I disagree. I think if you had one person learn it really
well, and establish coding guidelines, it would be workable. I was
able to learn it, completely on my own with only the examples from the
System C docs, and the Synopsys docs, in a week. I took a lot of long
walks, reading the docs to myself so that I wouldn't slip into a coma,
but other than that, it was relatively pain free.
The templates are setup in such a fashion that you can teach a user to
be a SystemC user, and not require them too much software experience.
I would think a software person would have greater difficulty learning
"proper" SystemC (that might Synthesize) because of a lack of
understanding of HDLs and the hierarchical module/submodule structure
that SYSC (and all HDLs) support.
(Then again, I may be overly optimistic, as I've dabbled in C++ for
over a decade, and have always wanted to use it more, though haven't
had much opportunity due to the direction my career has gone...)

I also don't know what the SystemC synthesis tools (if there are any)
are like, or if there are any, for systemC for the whole hardware
cycle. I seem to recall that Synopsys wanted more money for such a
thing, and well, we'd already given them our firstborn child... (I'm
in a small company... without limitless funds. That's why we had a
vested interest in making it work with VCS, because we don't have the
funds to support too many tools or start over after having spent
tons-o-money on tools for previous projects.)


--Ray Bingham

(No, I'm not the CEO of Cadence, though, ironically, my dad and he are
cousins...)