Designing a reset-aware OVM testbench

The driver
Driver
The driver is a component of any active agent that takes in transactions from the sequencer and translates them to pin level activity and wiggles the interface pins. It may optionally wait for the response or read data to appear on the interface and send it back to the sequencer. All this activity takes place in the run phase of the driver.

A driver that doesn’t handle resets will look like this:

 
The above code shows a driver that continuously gets a sequence item from the sequencer and drives the bus, regardless which state the bus is in.

To make the driver more reset-aware, two cases need to be considered. The first is that the driver should not drive the bus before the bus comes out of the reset state at the beginning of simulation. This can be easily achieved by monitoring the reset signal and not calling get_next_item unless reset is de-asserted.

The second case is the driver needs to keep monitoring the reset signal throughout the simulation time, and once reset is asserted, the driver needs to make its first decision based on what has been described in the testbench architecture. The driver can either abort the ongoing transaction if one is being driven on the bus, then when reset is de-asserted it can ask the sequencer for anew transaction by calling get_next_item again, or it can stall while saving the current transaction waiting for reset to be de-asserted, this is when it can re-start driving this transaction on the bus from the beginning.

The following code shows an example of a driver that will model a reset-aware bus driver that waits for reset deassertion at the beginning of simulation. It then continuously drives the bus with traffic from incoming transactions while monitoring the reset condition. When the reset is asserted, it stops driving the bus, drops the current transaction, and drives the bus default values. Finally, it goes back waiting for reset deassertion, to go through this process again.
It is very important to note that the driver needs to call item_done() when reset is asserted in the middle of simulation if a transaction was already being driven on the bus. This will prevent the driver from hanging producing the error that get_next_item() was called twice in a row without item_done() being called.