I have a basic question about the relationship and synchronization between a sequence and a driver. I’d appreciate it if someone could clarify this topic for me.
Here’s what I understand so far:
The sequence generates items in zero simulation time.
The sequencer manages the scheduling and pushing of items to the driver.
In the examples I’ve seen, the driver typically receives items within a forever loop.
I have a few specific questions:
When we start the test, we only invoke the sequence using .start(), not the driver. However, the sequence finishes almost instantly. What prevents the testbench from ending while the driver is still processing items?
The driver usually runs within a forever loop. How does it terminate? For example, how does it print a message indicating that the transaction is complete or perform a final action like drop_objection?
Following up on question 2, is there a built-in mechanism that allows the driver to detect when it no longer needs to wait for items (i.e., when the sequencer is empty and all items have been sent to the DUT)?
Edit: maybe the scoreboard is more natural for such mechnism, since it analyses the influence of the signals, and it also uses the analysis ports.
The sequence doesn’t finish instantly. The start() task will complete when the sequence has generated the sequence_items that are specified. Additionally, each sequence_item will be processed by the driver, and the driver will get the next sequence_item when it has completed the previous sequence_item.
The UVM thread scheduler will start the agent’s run_phase() when required, and it will also kill it when the phase completes. Do not use any objections in a driver. There are other mechanisms which should be used to indicate that the driver is not ready to finish a phase.
There is no need for the driver to ever finish. It should continue waiting for sequence_items until it is terminated.
The scoreboard should only process items received from monitors. It has no control over the environment.
First of all, thank you for your detailed response! Your explanation helped clarify how UVM naturally handles synchronization between the sequence, sequencer, and driver, and how the phase scheduler controls termination. I really appreciate the insight.
I’d like to ask a follow-up question to deepen my understanding of how to track and confirm that all generated items have been processed.
Suppose I want to print a message once I am sure that all items generated by a sequence have been fully processed by the driver.
Is there a built-in way in UVM to track how many items a given sequence has generated, and how many are still sitting in the sequencer’s queue, waiting to be pulled and processed?
Does the sequencer itself expose counters or tracking methods that would allow a testbench to determine when all items have been handled?
If not, what would be a recommended way to implement this tracking within the UVM framework?
I’d also like to clarify the role of the monitor in test termination.
If the monitor observes the DUT passively and doesn’t have direct knowledge of how many changes should occur, does that mean test termination depends on it “realizing” that all expected activity has happened?
Should the monitor then pass this information to some other component (e.g., a scoreboard) to trigger test completion?
Or is this an entirely scenario-dependent decision, where different verification environments will implement different test termination conditions?
Lastly, are there any UVM mechanisms designed to synchronize test completion with monitor observations? For example, waiting until the monitor detects and reports all expected data before allowing the test to terminate?
A sequence uses the start_item() call to tell the sequencer that it is ready to generate/send a sequence item. The call is blocking until the sequencer is ready to receive the item. The sequence will then call finish_item() to pass the sequence_item to the sequencer. This call is also blocking and will return when the driver has finished processing the item. This flow ensures that all sequence_items generated by the sequence have been processed by the driver, and the start() call to the sequence will only return when the body() task completes. There is no queue in the sequence, as each sequence_item is generated between start_item() and finish_item().
This post dicusses a common mechanism used by the scoreboard to delay the end of a phase based on queues which aren’t empty.