Program blocks

[amitk3553]

What is the meaning of following

 

"module (design) can not call task/function inside a program block. But a program can call task/function inside module (design)"

 

Please explain it!!
Thanks

 

[David Black]

A module is intended to represent the design under development/test and may be synthesized (subject to appropriate coding guidelines). A program block is intended for verification only. Thus the code in a program is never intended to be synthesized.

 

If a module were allowed to call a task or function in a program, that would imply that the code could be synthesized. The tools that synthesize would then have to be more complex and consider program blocks. This restriction removes that burden.

 

Also, program blocks were intended to remove race conditions between verification code and design implementation. If a module could call tasks in a program, then race conditions might occur in as the rules for where things are executed would create problems. [NOTE: This is the strongest reason, but more difficult to follow.]

[dave_59]

This was an attempt to try to keep the DUT from accessing anything in the testbench. The identifiers of anything you declare in a program are not visible to be referenced in a module. This includes task, function, variables, wires, typedefs. However since most testbenches are declared in classes that are defined inside packages, and there is nothing preventing you accessing something passed by reference to a module from a program, this rule does not prevent much. Also, there a many times during the development of a design that you need to have incomplete models access portions of the testbench.

For these and many other reasons, I do not recommend the use of program blocks. See http://go.mentor.com/programblocks

[amitk3553]

A module is intended to represent the design under development/test and may be synthesized (subject to appropriate coding guidelines). A program block is intended for verification only. Thus the code in a program is never intended to be synthesized.

 

If a module were allowed to call a task or function in a program, that would imply that the code could be synthesized. The tools that synthesize would then have to be more complex and consider program blocks. This restriction removes that burden.

 

Also, program blocks were intended to remove race conditions between verification code and design implementation. If a module could call tasks in a program, then race conditions might occur in as the rules for where things are executed would create problems. [NOTE: This is the strongest reason, but more difficult to follow.]

Thanks,

 

One more doubt about "module (design) can not call task/function inside a program block. But a program can call task/function inside module (design)"

 

It means we cannot make instance of module in program block and can make instance of Program block in Module?

[dave_59]

Modules are used for both design and verification. Modules are instantiated to create hierarchy of other modules, interfaces and programs. Programs cannot contain any hierarchy. Just forget about programs.

[cliffc]

Death to Programs!

 

It took me years to arrive at this conclusion, but I now believe that programs were a bad idea and should be avoided completely.

 

After some convincing by other committee members, I voted for inclusion of programs into the SV Standard and I now regret that vote (please forgive me!     )

 

The idea behind the program was that if an engineer applied stimulus on the active clock edge, the RTL design would completely respond to the clock, then the testbench would calculate new stimulus values on the same clock edge and send them into the RTL design, and any combinational inputs to the RTL design would then update before moving to the next clock edge. The idea was to avoid co-dependent, 0-time race conditions between the RTL and testbench execution.

 

The point of the matter is, although it is a semi-common practice, you should never send stimulus on the active clock edge. In real hardware, this is known as a setup or hold-time violation and is never done. In 0-delay RTL simulations, if done properly, it works (but can be subject to a variety of race conditions). In gate-level simulations (GLS), this will violate setup and/or hold times, which means you have to modify the testbench to run with different timing values to perform GLS.

 

I currently send stimulus using a time-budgeting scheme with my clocking blocks so that stimulus is sent 10%-20% of the clock cycle after the active clock edge (allowing for hold times and to meet long-combinational-input gate-delays). This allows me to use the same testbench for 0-delay RTL and GLS, and closely mimics the behavior of real hardware. If you don't send stimulus on the active clock edge (which you should never do), you don't need a program block.

 

As has already been discussed in this thread, if you use programs, you have confusion, limitations and rules to follow, including the fact that a program cannot instantiate a module, and a module cannot call tasks/functions from a program. Removing programs greatly simplifies testbench development. Programs were a semi-good idea gone bad.

 

As long as you do not have stimulus driven on the active clock edge (which is a bad idea - have I repeated that enough?), you can replace all program-endprogram keywords with module-endmodule. Chris Spear's very good SV Verification book uses programs. I have already informed my good friend and respected colleague that he should change all occurrences of program-endprogram to module-endmodule.

 

I have never needed to use programs and standard UVM verification techniques do not use programs. Program usage is highly discouraged in my training classes.

 

Regards - Cliff Cummings

Verilog & SystemVerilog Guru