I am working on ovm to uvm migration.
In my ovm environment run_test is called after 2us in the top module initial block.
But when i give the same delay in uvm environment it is giving an error.
“No non-zero delays are allowed before run_test()”
I could find that there is a fatal error message in uvm library as follows:-
task uvm_root::run_phase (uvm_phase phase);
if($time > 0)
`uvm_fatal(“RUNPHSTIME”, {“The run phase must start at time 0, current time is “,
$sformatf(”%0t”, $realtime), ". No non-zero delays are allowed before ",
"run_test(), and pre-run user defined phases may not consume ",
“simulation time before the start of the run phase.”})
endtask
I am using run_phase() in testcase.
And I need to have some delays before I call run_test.
Unfortunately, this is a backward incompatible change with the UVM. I think this was more a committee methodology decision than a technical requirement. If you start getting VIP from other vendors, I think they would all expect things to start a time 0.
You might try to set the id_action of RUNPHSTIME to a warning.
But you should explain way you can’t start run_test at time 0.
But you should explain way you can’t start run_test at time 0.
We have seen several users doing this in OVM - simply b’cos OVM allowed only one task - run(). Many simple designs need simple reset toggling before starting transactions, hence this was convenient (than doing a virtual sequence etc.).
Maybe same reason with Jithu-vlsi too?
BTW - the fix above rationale in UVM would be to move the reset to reset_phase.
I’ll necro this thread since it was very helpful for me brute forcing an issue I had. Sometimes it’s simply not practical to find where in a VIP to add a delay or to pass rst and/or rst_done signals so the simplest way to let the DUT bringup sequence finish is to do the reset/bringup sequence outside of the UVM test and delay the start of run_test.
Since this is in uvm_root, I couldn’t get the following to work or any of the APIs to override severity for an ID.