There are ocassions when some components in the testbench keep running forever and cause the simulation to hang. Another case is when performing SoC level C tests, where you could have written a while (1) code expecting an interrupt to cause the loop to break but, instead not get the interrupt at all. Not a good place to be in, especially if you tried running it in your local machine instead of an LSF farm. Let's look at what UVM has to offer to get around this.

Here's an example of what a C test might do in a UVM based verification environment.

void function trying_to_get_hung () {
  while (1) {
    // Some code ..
 
    // Wait for interrupt
 
    // Break out and do something worthwhile
  }
}
 

The idea is to automatically exit the simulation if it goes beyond a specified time, which can be done by using set_timeout() method from uvm_root. As you might already know, uvm_top is the global instance of uvm_root which can be accessed from anywhere in the testbench. The timeout value can be set via uvm_top.set_timeout() method in the base test so that all other tests derived from it will have the same timeout parameter.

class base_test extends uvm_test;
  `uvm_component_utils (base_test)
 
  ...
 
  virtual function void end_of_elaboration_phase (uvm_phase phase);
        super.end_of_elaboration_phase (phase);
        uvm_top.set_timeout (100ns);
    endfunction 
 
endclass
 

Another way to do the same is to call a global function set_global_timeout (), which might not show up in future versions of UVM.

module tb_top;
  // Instantiations
 
  initial begin
    set_global_timeout (100ns);
    run_test ("base_test");
  end
endmodule 
 

You can also override or set the timeout parameter via command line using +UVM_TIMEOUT=[value]. Here's how it would look like in a simulation log.

----------------------------------------------------------------
UVM_INFO @ 0: reporter [RNTST] Running test base_test...
UVM_INFO ./tb/my_pkg.sv(26) @ 0: uvm_test_top.m_top_env [m_top_env] Hello, I am going to hang.
UVM_INFO ./tb/my_pkg.sv(29) @ 10: uvm_test_top.m_top_env [m_top_env] oops
UVM_INFO ./tb/my_pkg.sv(29) @ 20: uvm_test_top.m_top_env [m_top_env] oops
UVM_INFO ./tb/my_pkg.sv(29) @ 30: uvm_test_top.m_top_env [m_top_env] oops
UVM_INFO ./tb/my_pkg.sv(29) @ 40: uvm_test_top.m_top_env [m_top_env] oops
UVM_INFO ./tb/my_pkg.sv(29) @ 50: uvm_test_top.m_top_env [m_top_env] oops
UVM_INFO ./tb/my_pkg.sv(29) @ 60: uvm_test_top.m_top_env [m_top_env] oops
UVM_INFO ./tb/my_pkg.sv(29) @ 70: uvm_test_top.m_top_env [m_top_env] oops
UVM_INFO ./tb/my_pkg.sv(29) @ 80: uvm_test_top.m_top_env [m_top_env] oops
UVM_INFO ./tb/my_pkg.sv(29) @ 90: uvm_test_top.m_top_env [m_top_env] oops
UVM_FATAL /pkg/cadence-incisiv-/14.22.009/i686-linux/tools/methodology/UVM/CDNS-1.1d/sv/src/base/uvm_phase.svh(1282) @ 100: reporter [PH_TIMEOUT] Explicit timeout of 100 hit, indicating a probable testbench issue

--- UVM Report catcher Summary ---