Check out IEEE Std 1800-2012 & sect; 3.4 and & sect; 24. For a complete description of program blocks.
In a short, incomplete summary, the program block:
- cannot
always contain procedures, primitive instances, module instances, interface instances ( virtual interface and interface port) or other program instances. - sets planning in the active area. This prevents race conditions.
- has an additional
$exit system task that completes the program instance that calls it.- The simulation will end when all instances of the
program exit.
- basically similar to the
module block, except as indicated above.
The idea behind the program block is to create a clear separation between test and design. In earlier versions of SystemVerilog (pre IEEE 1800), instantiating a class often limited to program blocks. This emphasized the separation of tests and design. He also made program blocks vital for verification engineers who wanted to use object-oriented programming in their stream. Starting with IEEE 1800, a class can be defined and instantiated almost anywhere. As a result, program blocks became smaller.
Today, an opinion on the usefulness of the program block is shared. Of the last few conventions that I have been striving for, this trend seems to be in favor of abandoning program blocks. This is because benefits can be achieved by other methods. Jet scheduling can be accomplished using clocking blocks. A mailbox , queue ( [$] ), or an associative array ( [*] ) can be used to intelligently control the simulation that completes several tests. Personally, I still like to use program blocks and use initial forever as the equivalent of always if necessary. If you plan to use UVM, then a non- program test bench may work better for you.
In the end, it really comes down to the preference for methodology. It is best to evaluate and try it yourself.