FPGA Central

I am not yet able to explain myself a plausible reason behind a
construct like program in SV.

On Fri, 4 Jul 2008 00:25:38 -0700 (PDT),
<[email protected]> wrote:

> I am not yet able to explain myself a plausible
> reason behind a construct like program in SV.

It probably helps if you know some of the background.

SV testbench constructs (classes, constrained randomization,
coverage, etc) are at least partly inspired by specialised
testbench automation languages such as 'e' and Vera. Such
languages run in a separate tool, coupled to your Verilog
simulator through the PLI. Although this split is sometimes
inconvenient, it has an interesting effect: While the
testbench code is executing you can be 100% sure that the
state of the Verilog simulation is constant, because
the Verilog simulator is not executing.

Switch over to SystemVerilog testbench and you have a
potential problem. If the testbench is written in modules,
then there is a risk that execution of your Verilog design
will interleave with execution of the testbench. Consequently,
the testbench - executing because of a clock tick or some
other interesting event in the design - is not guaranteed to
see a stable view of the design.

Program blocks provide a way to write testbench code that
will execute at a time when the design is known to be
NOT executing, so testbench code running in a program
is sure to see a consistent and stable view of the design.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~

Fast-forward to the real world of SystemVerilog, and things
are not quite so simple. Testbench activity will, of course,
update signals in the design (stimulus generation). This
gives rise to further activity in the design, potentially
triggering the testbench to do further work. We still have
some degree of tangling of testbench and design activity
at a given moment of simulation time (Verilog time slot).
This problem is very elegantly solved by clocking blocks,
which allow you to specify the timing of how a testbench
samples and drives signals in the design, independently
of the execution of the testbench. Correct use of
clocking blocks provides an alternative way to guarantee
that the testbench has a consistent, stable view of
the design's signals even when execution of design and
testbench are interleaved.

For various historical reasons, it was always intended
that clocking blocks should allow testbench code, running
in a program, to sample and drive signals in the design
running in modules/interfaces. However, in the 2005 LRM
the definition of clocking blocks and programs was not
sufficiently precise and a lot of work was required to
put it straight. One consequence of that work (which
should appear in the 2009??? LRM) is that you can write
your testbench in modules - NOT in programs - and still
make effective use of the clocking block mechanism.
The result is that several writers and experts have begun
to recommend that everything should be done in modules
and interfaces, and that programs are unnecessary.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~

As you can see, the story is not simple and it has given
rise to much argument. From a user's point of view,
if you are starting to use SV-testbench today, I suspect
it's easiest to avoid programs completely - but it then
becomes *very* important to use clocking blocks correctly
to get well-behaved, race-free interaction between your
testbench and DUT. Historically, some tool-specific
limitations have forced people into using program blocks
for SystemVerilog testbenches; those limitations no longer
exist in any tool I know of.

Programs offer a few other minor features that can be
appropriate and convenient for testbenches. However,
those features are probably not sufficiently important
to swing the argument back in favour of programs.

I hope this at least gives you some indication of the
depth and complexity of the situation!
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
[email protected]
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Hi, I just wanted a list of Testbench guidelines that are normally
follwed to write a verilog Testbench, and then would like to know that
whether those guidelies are still applicable to program block in
System Verilog.
On Jul 4, 1:15*pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Fri, 4 Jul 2008 00:25:38 -0700 (PDT),
>
> <parag_p...@hotmail.com> wrote:
> > I am not yet able to explain myself a plausible
> > reason behind a construct like program in SV.
>
> It probably helps if you know some of the background.
>
> SV testbench constructs (classes, constrained randomization,
> coverage, etc) are at least partly inspired by specialised
> testbench automation languages such as 'e' and Vera. *Such
> languages run in a separate tool, coupled to your Verilog
> simulator through the PLI. *Although this split is sometimes
> inconvenient, it has an interesting effect: *While the
> testbench code is executing you can be 100% sure that the
> state of the Verilog simulation is constant, because
> the Verilog simulator is not executing.
>
> Switch over to SystemVerilog testbench and you have a
> potential problem. *If the testbench is written in modules,
> then there is a risk that execution of your Verilog design
> will interleave with execution of the testbench. *Consequently,
> the testbench - executing because of a clock tick or some
> other interesting event in the design - is not guaranteed to
> see a stable view of the design.
>
> Program blocks provide a way to write testbench code that
> will execute at a time when the design is known to be
> NOT executing, so testbench code running in a program
> is sure to see a consistent and stable view of the design.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
>
> Fast-forward to the real world of SystemVerilog, and things
> are not quite so simple. *Testbench activity will, of course,
> update signals in the design (stimulus generation). *This
> gives rise to further activity in the design, potentially
> triggering the testbench to do further work. *We still have
> some degree of tangling of testbench and design activity
> at a given moment of simulation time (Verilog time slot).
> This problem is very elegantly solved by clocking blocks,
> which allow you to specify the timing of how a testbench
> samples and drives signals in the design, independently
> of the execution of the testbench. *Correct use of
> clocking blocks provides an alternative way to guarantee
> that the testbench has a consistent, stable view of
> the design's signals even when execution of design and
> testbench are interleaved.
>
> For various historical reasons, it was always intended
> that clocking blocks should allow testbench code, running
> in a program, to sample and drive signals in the design
> running in modules/interfaces. *However, in the 2005 LRM
> the definition of clocking blocks and programs was not
> sufficiently precise and a lot of work was required to
> put it straight. *One consequence of that work (which
> should appear in the 2009??? LRM) is that you can write
> your testbench in modules - NOT in programs - and still
> make effective use of the clocking block mechanism.
> The result is that several writers and experts have begun
> to recommend that everything should be done in modules
> and interfaces, and that programs are unnecessary.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~
>
> As you can see, the story is not simple and it has given
> rise to much argument. *From a user's point of view,
> if you are starting to use SV-testbench today, I suspect
> it's easiest to avoid programs completely - but it then
> becomes *very* important to use clocking blocks correctly
> to get well-behaved, race-free interaction between your
> testbench and DUT. *Historically, some tool-specific
> limitations have forced people into using program blocks
> for SystemVerilog testbenches; those limitations no longer
> exist in any tool I know of.
>
> Programs offer a few other minor features that can be
> appropriate and convenient for testbenches. *However,
> those features are probably not sufficiently important
> to swing the argument back in favour of programs.
>
> I hope this at least gives you some indication of the
> depth and complexity of the situation!
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.