Jump to content

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

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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


Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...