SystemVerilog for verification

[Rob Gaddi]

Oh good, a topic to start a flame war with...

So I consider myself pretty comfortable with VHDL. I use it for my
synthesizable designs. I use it for my testbenches. Occasionally I'll
write a VHDL behavioral model and run it through my simulator just to
generate timing diagram waveforms for people.

I can, given sufficient time and energy, muddle through reading Verilog.
Never written a line of it. But I'm getting a vague sense, possibly
out of frustration, that a whole lot of verification benches, especially
as you're trying to get up into transaction level bus models, get easier
in SystemVerilog than they are doing it in VHDL, even with the 2008
improvements.

I'm pretty used to doing OOP in languages like Python, C++, and Perl,
and the idea of calling bus_master.write(address, data); seems like a
pretty natural way of stringing a bench together. The options for doing
similar in VHDL (procedures with a billion signal parameters or entities
with abstract req/ack ports and 'transaction signaling) seem,
comparatively, pretty crude. I've made them work time and again, but I
can't say I've ever sat back and read it back over and said "You know,
that's pretty elegant."

I have no intention of giving up VHDL for my synthesizables; I cling to
strong typing like Linus to his blanket. But am I doing myself a
disservice by not learning SV?

 

[NeedCleverHandle]

Oh good, a topic to start a flame war with...

So I consider myself pretty comfortable with VHDL.  I use it for my
synthesizable designs.  I use it for my testbenches.  Occasionally I'll
write a VHDL behavioral model and run it through my simulator just to
generate timing diagram waveforms for people.

I can, given sufficient time and energy, muddle through reading Verilog.
  Never written a line of it.  But I'm getting a vague sense, possibly
out of frustration, that a whole lot of verification benches, especially
as you're trying to get up into transaction level bus models, get easier
in SystemVerilog than they are doing it in VHDL, even with the 2008
improvements.

I'm pretty used to doing OOP in languages like Python, C++, and Perl,
and the idea of calling bus_master.write(address, data); seems like a
pretty natural way of stringing a bench together.  The options for doing
similar in VHDL (procedures with a billion signal parameters or entities
with abstract req/ack ports and 'transaction signaling) seem,
comparatively, pretty crude.  I've made them work time and again, but I
can't say I've ever sat back and read it back over and said "You know,
that's pretty elegant."

I have no intention of giving up VHDL for my synthesizables; I cling to
strong typing like Linus to his blanket.  But am I doing myself a
disservice by not learning SV?

I use VHDL and Verilog in equal amounts. When asked which I prefer, I
always say "the other one" - there's always something the other
language does better.

SystemVerilog has a lot of the features of VHDL that I miss when
coding in Verilog - IMnsHO, enough that I think you should look at it.

If only I could trust Brand-X to synthesize it properly - right now I
use it for verification only.

RK

 

[Christopher Felton]

Oh good, a topic to start a flame war with...

So I consider myself pretty comfortable with VHDL. I use it for my
synthesizable designs. I use it for my testbenches. Occasionally I'll
write a VHDL behavioral model and run it through my simulator just to
generate timing diagram waveforms for people.

I can, given sufficient time and energy, muddle through reading Verilog.
Never written a line of it. But I'm getting a vague sense, possibly out
of frustration, that a whole lot of verification benches, especially as
you're trying to get up into transaction level bus models, get easier in
SystemVerilog than they are doing it in VHDL, even with the 2008
improvements.

I'm pretty used to doing OOP in languages like Python, C++, and Perl,
and the idea of calling bus_master.write(address, data); seems like a
pretty natural way of stringing a bench together. The options for doing
similar in VHDL (procedures with a billion signal parameters or entities
with abstract req/ack ports and 'transaction signaling) seem,
comparatively, pretty crude. I've made them work time and again, but I
can't say I've ever sat back and read it back over and said "You know,
that's pretty elegant."

I have no intention of giving up VHDL for my synthesizables; I cling to
strong typing like Linus to his blanket. But am I doing myself a
disservice by not learning SV?

I use Python via MyHDL for all my verification unless dictated
otherwise. As you point out, you can easily build up transaction
interfaces to the DUT. With MyHDL bridging the HLL to the cycles and
bits is a breeze. I have used it successfully on our last mixed-sginal
ASIC design (small'sh design but all verification via Python/MyHDL).

I do keep up with SystemVerilog but that is mainly out of curiosity and
for job prospects if I ever need it. Not all places are open to
alternative solutions. Also, integrating my signal-processing system
design/simulations and leveraging it for HDL verification is
straight-forward.

Regards,
Chris

 

[HT-Lab]

Oh good, a topic to start a flame war with...

So I consider myself pretty comfortable with VHDL. I use it for my
synthesizable designs. I use it for my testbenches. Occasionally I'll
write a VHDL behavioral model and run it through my simulator just to
generate timing diagram waveforms for people.

I can, given sufficient time and energy, muddle through reading Verilog.
Never written a line of it. But I'm getting a vague sense, possibly out
of frustration, that a whole lot of verification benches, especially as
you're trying to get up into transaction level bus models, get easier in
SystemVerilog than they are doing it in VHDL, even with the 2008
improvements.

I'm pretty used to doing OOP in languages like Python, C++, and Perl,
and the idea of calling bus_master.write(address, data); seems like a
pretty natural way of stringing a bench together. The options for doing
similar in VHDL (procedures with a billion signal parameters or entities
with abstract req/ack ports and 'transaction signaling) seem,
comparatively, pretty crude. I've made them work time and again, but I
can't say I've ever sat back and read it back over and said "You know,
that's pretty elegant."

I have no intention of giving up VHDL for my synthesizables; I cling to
strong typing like Linus to his blanket. But am I doing myself a
disservice by not learning SV?

It can never hurt to learn a new language and to have something else to
mention on your CV, but make sure it is actually useful to you. If you
are planning to use a verification framework like OVM/UVM/VMM etc then I
would say go for it and learn SV (or SC). Make sure however that your
employer has the budget to buy a simulator capable of handling SV for
verification and not just for design (huge price difference).

If you need more verification power like constraint random, functional
coverage etc then you can perfectly stay with VHDL. Just check out some
of the packages available on the web like Jim Lewis' excellent
Constraint Random and Coverage packages.

http://www.synthworks.com/downloads/index.htm

Throw in some PSL goodness and you have a very powerful/capable
functional verification environment.

Given you like OOP you might also want to check out SystemC, if you are
a Modelsim user then it is the cheapest way to get access to an OOP
language, TLM2.0, AMS(?) and CR. The interface between VHDL and SystemC
is pretty good. You might even be able to use OVM via the free OVM-ML
package from Cadence although I haven't played with it myself.

Good luck,
Hans
www.ht-lab.com

 

[Christopher Felton]

I'm pretty used to doing OOP in languages like Python, C++, and Perl,
and the idea of calling bus_master.write(address, data); seems like a
pretty natural way of stringing a bench together. The options for doing
similar in VHDL (procedures with a billion signal parameters or entities
with abstract req/ack ports and 'transaction signaling) seem,
comparatively, pretty crude. I've made them work time and again, but I
can't say I've ever sat back and read it back over and said "You know,
that's pretty elegant."

I have no intention of giving up VHDL for my synthesizables; I cling to
strong typing like Linus to his blanket. But am I doing myself a
disservice by not learning SV?

If you do decide to use SystemVerilog for verification, get the 3rd
edition of "SystemVerilog for Verification"
http://www.buchhandel.de/detailansicht.aspx?isbn=9781461407140

Very good resource!
Chris

 

[Christopher Felton]

Given you like OOP you might also want to check out SystemC, if you are
a Modelsim user then it is the cheapest way to get access to an OOP
language, TLM2.0, AMS(?) and CR. The interface between VHDL and SystemC
is pretty good. You might even be able to use OVM via the free OVM-ML
package from Cadence although I haven't played with it myself.

I think SystemC/C++, in this context, is a waste of time and effort.
Every verification effort that I have been involved with that uses
SystemC has had to devoted a fair number of resources to C++ development
and maintenance. In my opinion SystemC/C++ is antiquated and there are
better options available.

I believe Hans' main point is, if you want to use the advanced
verification features of SV you will need to shell out some money for an
SV simulator. And a cheaper alternative is SystemC. But my take,
SystemC is anti-productive, you are better off leveraging
SV/Python/Ruby/Matlab/Java any HLL that empowers the developer. SystemC
is for the large organizations that can devote the resources. In my
opinion you will spend more money developing C++ code than you will on
an SV enabled simulator.

Regards,
Chris

 

[Dal]

I have been using SV to implement a test bench for my current project.
I didn't get into OVM/UML but just used the language to create a
simple test environment. I find the language features very useful
(objects, randomization, queues, fork/join etc) and a very 'natural'
way to develop test code.

I can't see myself going back. SV seems suitable for simple and
complex designs and also allows the engineer to start simply which is
important as I was self taught as training is non-existant in my part
of the world.

I would always still use VHDL for synthesizable code.

My only gripe is there does seem to be a premium on the licence (at
least with Cadence). I am disappointed vendors didn't treat it as
Verilog from a licencing point of view.

Darrin

 

[HT-Lab]

I think SystemC/C++, in this context, is a waste of time and effort.
Every verification effort that I have been involved with that uses
SystemC has had to devoted a fair number of resources to C++ development
and maintenance. In my opinion SystemC/C++ is antiquated and there are
better options available.

Interesting, my experience is actually the opposite. I have seen a large
number of companies that are quite successful with SystemC. You are
right that most of these were large companies, that is those that use
virtual prototyping but I have also seen single users quite successfully
use SystemC for their development.

Regarding better languages, yes, I guess we all know that C++ has many
pitfalls and allows users to write in-comprehensible, un-portable mind
boggling complex code.

However, I still believe that SystemC (and the free reference simulator)
is one of those hidden gems of the EDA world. If you can discipline your
development and adhere to some good coding practises you will be amazed
what you can achieve with SystemC.

Hans
www.ht-lab.com

 

[Christopher Felton]

Interesting, my experience is actually the opposite. I have seen a large
number of companies that are quite successful with SystemC. You are
right that most of these were large companies, that is those that use
virtual prototyping but I have also seen single users quite successfully
use SystemC for their development.

It depends on how you measure success. I was trying to convey, IMO, the
*cost* to use SystemC/C++ (cost in time and resources). The projects I
have experience with that used SystemC, most would consider their
efforts successful. But the companies could assign half a dozen or more
programmers to the problem.

I have not seen efforts were one or two developers were able to leverage
SystemC. If someone has years of experience pumping out C++ code, they
might do very well. I do believe it is possible just not plausible for
a single developer or small team.

Regarding better languages, yes, I guess we all know that C++ has many
pitfalls and allows users to write in-comprehensible, un-portable mind
boggling complex code.

However, I still believe that SystemC (and the free reference simulator)
is one of those hidden gems of the EDA world. If you can discipline your
development and adhere to some good coding practises you will be amazed
what you can achieve with SystemC.

I believe any technology, regardless how old or new, can be successfully
utilized by someone who completely understands what the technology
provides and can make up for the short-comings with time and/or
resources. In this case I believe the OP wants to highly leverage a
technology for verification, I don't think SystemC is the best choice.

Chris

 

[JimLewis]

Hi Rob,

I can, given sufficient time and energy, muddle through reading Verilog.
Never written a line of it. But I'm getting a vague sense, possibly
out of frustration, that a whole lot of verification benches, especially
as you're trying to get up into transaction level bus models, get easier
in SystemVerilog than they are doing it in VHDL, even with the 2008
improvements.

I'm pretty used to doing OOP in languages like Python, C++, and Perl,
and the idea of calling bus_master.write(address, data); seems like a
pretty natural way of stringing a bench together.

For VHDL-2008, we looked at adding an interface construct. I wanted
an
upgrade from the record based IO I use. However at the same time,
I also worked out acceptable resolution functions for integer, time,
and
real and found I can get by without an interface construct.
From a users perspective, I create a package, define a record, and
define procedures that use the record.
Then calls to the procedures in the package are of the following
form (where bus_master is a record object whose elements are a
resolved type):
write(bus_master, address, data) ;

On the other hand with OOP, the complexity of the tasks is
about the same and the call is (where bus_master is a
class object):
bus_master.write(address, data);

From a VHDL purist perspective, it feels a little kludgey to
initialize the bus_master signal object to give the drivers
a default value, however, from a pragmatic perspective, it
works and it does not require any new language features.

Also from a pragmatic perspective, the current VHDL solution is
good enough that I think we (the VHDL language committee) needs
to focus our attention on other things. However, if someone is
interested in putting forward a proposal, please step up and
do it. If you are interested in what is happening with VHDL,
see http://www.eda.org/twiki/bin/view.cgi/P1076/WebHome
There is always room for more helpers.

With popular SV OOP methodologies, creating a transaction based
testbench requires lots of fork and join to both initialize
objects and create the concurrency. Sure with OOP, you can
and are dynamically elaborating the testbench, however, how
often are you plugging and unplugging components during a
simulation run - never had much use for guarded blocks, but
I suspect that they will handle this just fine.

The options for doing similar in VHDL (procedures with a billion
signal parameters or entities
with abstract req/ack ports and 'transaction signaling) seem,
comparatively, pretty crude. I've made them work time and again, but I
can't say I've ever sat back and read it back over and said "You know,
that's pretty elegant."

When I use a BFM to do the interface waveform generation, I always
use the req/ack ports. However, for simple interfaces that do not
warrant a BFM, I just put the interface signals in the record and
am done with it.

I generally use the BFM because there is other stuff that is
convenient to put in there, such as protocol checkers (VHDL or
PSL) and interface waveform loggers.

I have no intention of giving up VHDL for my synthesizables; I cling to
strong typing like Linus to his blanket. But am I doing myself a
disservice by not learning SV?

At the end of the day, it may end up like VHS vs Betamax and
politics and/or marketing BS may determine the winner and
not actual capability.

As Hans mentioned, check out our Functional Coverage
and Randomization packages at:
http://www.synthworks.com/downloads

The randomization packages rely on procedural randomization.
Used by itself, procedural randomization requires a little
more thought to get a balanced distribution of stimulus
values, however, when combined with the intelligent
coverage modeling supported by our functional coverage
packages, it does better than simple solver based
randomization. I am guessing that the results are similar
to the intelligent randomization testbench tools for which
you will have to purchase an additional license. See the
documentation for more details.

To help you go further, our testbench class (shameless
advertising plug) also comes with packages for creating
scoreboards, resolving integers, real, and time,
creating memory models (using a methodology that is
easier than using an array), and utilities.

If you are considering switching to SV for testbenches and
the costs are ok, make sure to take a class first (not a plug
as our focus is on VHDL) as this will give you a better idea
of what you are getting into - before you make the investment.
Also, no reason not to check out the free materials out there -
Mentor and Aldec both have SV web presentations recorded on
their websites.

Best,
Jim

P.S.
If you are a senior member of the VHDL community, you
should be participating in the VHDL standards. VHDL is
an individual based standard and while membership in
IEEE, IEEE-SA, and DASC are always greatly appreciated,
they are not required for participation. For more details
see: http://www.eda.org/twiki/bin/view.cgi/P1076/WebHome

Don't let your good ideas be overlooked. Particularly
those of you who have OOP experience.