UVM end-of-test mechanism

Question

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?

Answer 1

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_components 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.

Answer 2

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.