The UVM standard clearly states in the description of phase_ready_to_end() that “To prevent endless iterations due to coding error, after 20 iterations, phase_ended() is called regardless of whether previous iteration had any objections raised.” Examination of the UVM implementation indicates this limit does exist.
If a transactor used this mechanism to extend a phase, then only 20 transactions would be allowed.
The whole point of phase_ready_to_end() is to allow the “last transaction” to be processed before exiting the phase. It is not unreasonable to expect that users have enough knowledge of the system to be able to ensure that this be done with less than 20 calls. Objections should only be raised when necessary. Raise an objection in the test before starting your sequence(s) and drop from the test when the sequence(s) is(/are) complete. Usually the sequence(s) won’t complete until the driver has completely processed the last transaction (including sending back a response via put_response() or item_done()), so the driver doesn’t usually need phase_ready_to_end(). The monitor recognizes the same transaction and calls write(), which is a function, so it doesn’t usually need phase_ready_to_end() either. The most common application has the scoreboard doing some kind of analysis to the last transaction that may include some time-consuming behavior, so it’s usually the scoreboard that implements phase_ready_to_end().
Perhaps you could provide more of an explanation to justify why you think you need more than 20 calls to phase_ready_to_end(). If you really need that many, you could modify your copy of UVM and increase the number.
In reply to tfitz:
I agree with your approach.
My concern is that a number of folks I have talked with considered the use model for phase_ready_to_end() differently. Instead, they considered it as a way to avoid objections. In other words, just extend on-the-fly. I don’t think this approach is viable.
Perhaps documentation should be more explicit about the use case for this feature.
Other things to consider:
Any time you fork join-none a sequence, it needs to decide if it cares about extending the phase.
What about drivers waiting on multiple outstanding responses (e.g. ethernet packets)?
I’m not saying that the limit of 20 is wrong. I am simply saying that using phase_read_to_end() needs to be qualified with that understanding.
When using this method only to get the last in flight transaction, we need just 1 call per scoreboard. But what if you have more than 20 scoreboards? When doing vertical reuse, we would easily get to more than 20.
Is this so uncommon?