Hi,
Can someone tell me the corresponding phases of UVM with SV regions.
For instance, can we say that build phase and connect phase are equivalent to Elaboration phase in Verilog/System Verilog, and the Run phase is equivalent to “Preponed to Postponed” region of SV.
In reply to mukul1996:
In some respects you can say that the UVM phases are similar to the simulation stages of elaboration, run-time execution, and termination. However, all UVM phases execute in the active SystemVerilog event region.
Some of the UVM phase names come straight from SystemC, like
end_of_elaboration and
start_of_simulation also mimicking the stages of simulation. The major difference between the elaboration stages of simulation, and the similar stages in UVM and SystemC is they are all executing at run time. We can randomize and dynamically modify the testbench architecture. That is something that cannot be done with the elaboration of an RTL DUT.
In reply to mukul1996:
You are interpreting UVM phase wrong way. It’s not related to SV regions.
Systemverilog regions is related to event. Like on which event what type of code eveluate.
Active Region :- booking assignment, RHS of nonblocking etc.
Preponed Region :- Concurrent Assertion will sample value.
In below link Ben explained, what kind of code eveluate in which SV region.
https://verificationacademy.com/forums/systemverilog/sampling-point-assertions
In, UVM phase are structure way to simulate Design under test.
Like, build_phase. :- creating component.
connect_phase. :- makeing connection between component
run_phase. :- driving actual stimulas to degign.
Please, see below link to know about phases.
https://verificationacademy.com/verification-methodology-reference/uvm/docs_1.1c/html/files/base/uvm_common_phases-svh.html
Thanks!
Hi Dave,
You mentioned :
However, all UVM phases execute in the active SystemVerilog event region.
But this should happen if the top of the UVM Testbench is declared as “module” correct?
If the UVM Testbench top is declared as “program” then the execution of UVM phases will happen at the REACTIVE region of SystemVerilog, right?
Can you please confirm?
Thank you.
In reply to chavhector:
The process that calls uvm_pkg::run_test() determines which region the phases execute in. If that happens to be from an initial block declared in a program, then yes, the UVM phases execute in the reactive region. But don’t forget there could be other testbench code executing in an interface or other modules that complicates which region your testbench code is running in. For that reason and many others, we strongly advise against the use program blocks.
One more thing I would like to add in @chavhector 's question. If UVM Phases runs in active region, but we sometimes use clocking blocks events and waits in uvm_driver, clocking block runs in observed region, how is that managed then?
In reply to mukul1996:
Before answering that, let me reiterate that by using clocking blocks to communicate with the DUT, program block are unnecessary and yet another reason not to use them. Clocking block inputs are sampled in the preponed region and clocking block outputs are driven in the reactive region regardless of whether using modules or programs with clocking blocks. But even worse, clocking block events are intended to be triggered by events in the active region. If you try generating a clock in the reactive region by creating a UVM clock driving agent, that can lead to races with input sampling. (See section 14.13 Input sampling in the IEEE 1800-2017 SystemVerilog LRM.
To answer your question, once a process starts in a particular region, it remains executing in that region. If an process is waiting on event that gets triggered in a different region, it will wait until the scheduler gets back to the original region to resume the process.
Hello Dave,
I’m currently struggling with a testbench with several agents that I need to run in Strato. My main concern is that the testbench is written as a program and changing in to module generates a load of errors (I suspect these errors come from the UVM queues and checkers being misaligned because of how events are executed from Program vs Module.
Is there a strategy you may recommend to follow to fix the testbench to match the “program” behavior? I don’t care if we have to use non-synthesizable code now (that I can fix later).
Appreciate any suggestions you may have.
– Hector.
In reply to chavhector:
It’s hard to provide general advice without seeing more of the structure of your testbench. I doubt you can do that adequately here on this forum. It could be as simple as adding a #1 after every @(posedge clk) in your monitor code, but I do know that is a problem for emulation.
I suggest working with your tool vendor so you can share more of your code and make sure you are on a compatible methodology path.