Reputation: 21
task mabu_scoreboard::main_phase(uvm_phase phase);
forever begin
# 1ns;
if(extip_rd_req_cnt - extip_rd_rsp_cnt >= `MABU_READ_OST_NUM) begin
hit_rd_max_outstanding = 1;
`uvm_info(get_type_name(),"reach read outstanding threshold!",UVM_NONE);
end else begin
hit_rd_max_outstanding = 0;
end
if(extip_wr_req_cnt - extip_wr_rsp_cnt >= `MABU_WRITE_OST_NUM) begin
hit_wr_max_outstanding = 1;
`uvm_info(get_type_name(),"reach write outstanding threshold!",UVM_NONE);
end else begin
hit_wr_max_outstanding = 0;
end
end endtask
The forever
loop is executed in a time-consuming phase (main_phase
). The test can get terminated correctly because the main_phase
does not raise an objection?
Upvotes: 0
Views: 747
Reputation: 42698
One starting a time-consuming UVM phase, there must be at least one objection raised to prevent that phase from being terminated. Terminating a phase means the process of all uvm_component
s executing that phase will be killed.
In your scoreboard example, we would have to assume some other component raises an objection to the main_phase
, otherwise the forever
loop would never complete its first iteration. It's better to use the run_phase
for a process that needs to execute for the entire test.
Having any kind of delay in your UVM testbench except for generation of the clock is a bad practice. A UVM testbench is supposed to be transaction based and the only delays should be in generating your clocks. A forever
loop with a 1ns polling delay is especially bad for performance. A much better approach is to blocking waiting for an event.
Upvotes: 1
Reputation: 62082
Yes, that is correct. Since the main_phase
in your scoreboard does not call raise_objection
, the scoreboard will not prevent the test from ending.
Most of your testbench components will not raise objections. It is common for your test (the class extended from uvm_test
) to raise objections in its time-consuming phase.
Upvotes: 0