uvm-1.1c : end of simulation phases are no longer executed with new timeout

[arno]

The new uvm-1.1c changed the timeout to be fatal rather than error. But ithis change has introduced the following issue : the final phases are no longer executed at the end of the simulation.

By instance, I have a timeout, I need the check phase to run to tell what is causing it. With uvm-1.1c., it is no longer possible.

I think this is a problem that should be fixed : end of sim phases should be run in any case, timeout or not.

[kkranthikiran]

I guess its not TIMEOUT out issue directly. I think its the handling of UVM_FATAL that has issue. No matter its an UVM_ERROR or UVM_FATAL that's causing the simulation to exit they should run all the phases after run phase. Right now it seems that in case of FATAL it only running from report phase.

[mastrick]

FYI: If you use +UVM_PHASE_TRACE in 1.1c, it will show who is objecting upon a timeout.

[kkranthikiran]

The idea is to have certain clean-up/report methods to be run before the simulation exits

[arno]

Fatal have always exited abruptly without running the other phases. So that's another issue.

Going back to the timeout : a timeout can be regarded as a an error or not - it's up to the user to decide. But it shouldn't be defaulted to being a fatal in the BCL. It is unusable as it is now.

[petermonsson]

Hi arno,

A humble question: What are you looking for in the check phase?

Please note that the documentation gives you no guarantees on what happens if a timeout occurs, nor does it imply that it is up to you to decide whether a timeout is an error or not. You think that it is up to you to decide whether a timeout is an error or not, I think that a timeout is always an error, but the documentation does not prove any of us right.

Best Regards

Peter

[Justin Refice]

In UVM 1.1b (and prior), the set_timeout() and `UVM_DEFAULT_TIMEOUT method were rather vaguely documented (and in the case of set_timeout, the default mentioned was wrong):

`UVM_DEFAULT_TIMEOUT: The default timeout for all phases, if not overridden by uvm_root::set_timeout or <+UVM_TIMEOUT>

uvm_root::set_timeout(): Specifies the timeout for task-based phases. Default is 0, i.e. no timeout.

As Peter said, this doesn't state what happens when a timeout is hit, simply that the timeout exists. This lead to users trying to use the timeout to control individual phases, which was not the intent of this particular mechanism. Add to that the fact that the implementation of timeout in 1.1b was inconsistent, and did not actually do what the reference guide described, and now you've got the makings for Mantis 4295 (which changed this area of the code).

The new documentation is much clearer:

`UVM_DEFAULT_TIMEOUT: The default timeout for simulation, if not overridden by uvm_root::set_timeout or <+UVM_TIMEOUT>

uvm_root::set_timeout():Specifies the timeout for the simulation. Default is `UVM_DEFAULT_TIMEOUT

The timeout is simply the maximum absolute simulation time allowed before a FATAL occurs. If the timeout is set to 20ns, then the simulation must end before 20ns, or a FATAL timeout will occur.

This is provided so that the user can prevent the simulation from potentially consuming too many resources (Disk, Memory, CPU, etc) when the testbench is essentially hung.

The user can still create a timeout of their own, which can produce an error/warning/etc. and then end the simulation in whichever way they want, but this mechanism was intended to be "the big red button". If we hit it, then something in the phasing graph is hung, although we don't necessarily know what. We dump out immediately, showing which phase objections are active, and do not attempt to proceed any further in the phasing graph.