Jump to content

Effect of zero delays in uvm_phase::execute_phase running in a program vs a module

Recommended Posts

There are many zero delays in uvm_phase::execute_phase() to "let any waiters wake up", but the effect seems to be different depending on whether uvm runs inside a module or a program. In the former case, the effect of the #0 is task switching between phase threads (and other threads). For example, during the run phase termination sequence the simulator will jump back and forth between the run phase and the uvm_end terminal phase until one of them schedules the extract phase, after which the extract phase starts after both predecessor phases have run to completion. When uvm is inside a program, then the zero delays seems to have no effect for some reason, i.e the run phase or the uvm_end phase will run uninterrupted and start the extract phase before the other predecessor phase has run to completion. The first thing done in the extract phase, however, is to wait for all predecessor phases to complete, thus the overlap in phase execution seems to do no harm. However, one should think the series of zero delays are there for a reason, and that something else may break if uvm is inside a program. Is there reason to worry about this?

A somewhat related question: execute_phase() calls uvm_wait_for_nba_region(). Will this work as intended with uvm inside a program? Should the UVM_NO_WAIT_FOR_NBA macro be defined or not?



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