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