Menu
Are there any features of SV that a program block offers that can't be duplicated with other methods?
The less concrete version of this question is: should I bother with program blocks for verification? I'm moving from an environment where we were constrained to Verilog-95 to an environment where SV is supported, and I'm wondering if I'm creating extra work for myself by not using program blocks.
995
However, for the testbench, a lot of effort is spent getting the environment properly initialized and synchronized, avoiding races between the design and the testbench, automating the generation of input stimuli, and reusing existing models and other infrastructure. Systemverilog adds a new type of block called program block.
SystemVerilog program block was introduced for the following reasons. To provide an entry point to the execution of testbenches To create a container to hold all other testbench data such as tasks, class objects and functions Avoid race conditions with the design by getting executed during the reactive region of a simulation cycle
As far as I can tell, a program block by itself only addresses two race conditions between the testbench and DUT, both of which are covered by using a clocking block by itself. Erroneous use of blocking assignments for sequential logic. You have a race within your DUT regardless of the race between your testbench and DUT.
Therefore writing testbench with program block provides race-free interaction between the design and the testbench.
Check out IEEE Std 1800-2012 § 3.4 & § 24. For full description about program blocks.
In a short, incomplete summary, a program block:
always procedures, primitive instances, module
instances, interface instances (virtual interface and port interface is allowed), or other program instances.$exit, which terminates the program instances that calls it.
program instances have exited.module block except as stated above.The idea of a program block is to create a clear separation between test and design. In earlier versions of SystemVerilog (pre IEEE 1800), instantiation of a class was often limited to program blocks. This emphasized the division of test and design. It also made program blocks vital for verification engineers that that wanted to use object orientated programming in their flow. Since IEEE 1800, a class can be defined and instantiated almost anywhere. As a result, program blocks became less sufficient.
Today the opinion of usefulness of a program block is divided. From the last few conventions I been to, the trend seems to be in favor of abandoning program blocks. This is because the advantages can be achieved by other methods. Scheduling in the Reactive region can be done with clocking blocks. A mailbox, queue([$]), or associative array ([*]) can be used for intelligently handling simulation terminate running multiple tests. Personally, I still like using program blocks and use initial forever as an always equivalent when needed. If you are planning to use UVM, then a non-program blocks test bench might work better for you.
In the end, it really comes down to a methodology preference. It is best to evaluate and try it on your own.
80
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
