Hi All,
I came across the following issue while using ovm_report_fatal to display message.
ovm_report_fatal didn’t end the simulation when the class having fatal messages were instantiated using program block.It gave me following error
" ** Error: (vsim-8385) …/…/src//base/ovm_component.sv(1385): fork…join_none statements in function ‘do_exit_action’ only allowed if the calling process originates in an initial block.".
It then proceeded with the simulation unless the class was instantiated in ovm_env.
I tried the following code
import ovm_pkg::*;
class my_env extends ovm_threaded_component;
function new(string name = “”, ovm_component parent = null);
super.new(name, parent);
endfunction
task run();
$display(“In run of env”);
ovm_report_fatal(“FATAL”, “STARTED SIM”); #10;
ovm_report_info(“FATAL”, “oops: ovm_report_fatal does not work”);
endtask
endclass
program test;
my_env env;
initial begin
env = new(“ENV”, null);
run_test();
end
endprogram
Every thing worked fine on replacing the program block with a module.
Is this a bug or expected behaviour since ovm implements ovm_test for writting testcases and not a program block?
Does this mean that program blocks used with system verilog env should not be used in OVM to implement test cases?
This was a bug in Questa 6.3c. The OVM 1.0 kit has been tested and requires Questa 6.3d or later.
Bugs aside, the choice to use program blocks to implement testcases is independent of using the OVM class libraries; they support either way. The OVM examples do not use program blocks. My experience with AVM users support the claim that program blocks add nothing but unnecessary complexity to SystemVerilog.
Well, I’m not a guru with SV or OVM, but I’ve been reading alot (check out Chris Spears SystemVerilog for Verification). I guess the main thing seems to be separating the testbench code temporally from the design. Separating the driving and sampling (postpone region) signals. It seemed like a good idea. I tried to set something up like this with the OVM, but there were some issues getting it to compile.
Are you saying the timing issues are resolved with the OVM setup?
In my opinion, program blocks are really just legacy code structures from Vera. They are discussed in Chris Spears’ book because their use is mandated by VMM.
In OVM, test code is separated from the design because it consists of a hierarchy of classes that are defined in packages.
Handling the timing issues associated with the driving and sampling of signals can be achieved through the proper use of clocking blocks in interfaces. This approach is supported by current versions of IUS and QuestaSim and we have successfully used it in our OVM environments.
If you want to use programs, I cannot think of any reason why this should not still work with OVM, although I believe there were some issues with earlier versions of the tools.
Well said, especially since I’ve said the exact same thing myself. :)
The issues with program and clocking blocks were not with the tools, but with the LRM in 1800-2005. There is considerable change to those sections in P1800-2008. See the latest draft available from the IEEE, or look at the individual proposal Mantis 890 (guest/guest).