P
parag_paul@hotmail.com
Guest
I am not yet able to explain myself a plausible reason behind a
construct like program in SV.
construct like program in SV.
Navigation
Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
More options
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
What was the motivation vbehind the program construct in SV
J
Jonathan Bromley
Guest
On Fri, 4 Jul 2008 00:25:38 -0700 (PDT),
<parag_paul@hotmail.com> wrote:
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.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
<parag_paul@hotmail.com> wrote:
It probably helps if you know some of the background.I am not yet able to explain myself a plausible
reason behind a construct like program in SV.
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.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
R
RSGUPTA
Guest
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:
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.