The sequencer and tests
sequencer is the third component in an agent, and is responsible for
managing and arbitrating between sequences running on it. The sequencer
then forwards a single transaction to the driver when it asks. The
sequencer has an internal queue that holds all pending transactions that
are ready to go.
In the simple case, the sequencer may need to
do nothing when reset is asserted, since the driver will not require any
transactions during the reset period. In this case, the sequencer will
preserve its internal state during reset, and will continue from where
it stopped when reset is deasserted.
On the other hand, in the
more complex cases, the sequencer may need to take the appropriate
action when a reset is asserted. Several actions are reasonable
depending on the testbench architecture and the answers given to the
questions asked earlier in the process. All these actions are
implemented in the run phase of the agent’s sequencer, and will make use
of the event that was declared in the agent’s event pool and triggered
by the monitor when reset was asserted.
Possible actions can be:
Sequences and tests
- Flush queues:
This step will help clear/empty the internal sequencer arbitration
queue which holds the outstanding requests. The queue name is
arb_sequence_q and it is a SV queue type, and hence emptying it is
accomplished using the delete() method.
- Stop sequences:
Another possible action is to stop all the sequences running on the
sequencer. This can be helpful if the testbench needs to go through some
configuration steps that bring up the DUT after reset before it can run
actual stimulus. This can be accomplished using the stop_sequences()
method which is already implemented in the OVM sequencer base class.
on how you architect your sequences and virtual sequences that are
started from the test, you can decide what changes are needed for those
to react to reset assertion. It is recommended that all the sequences
that are run in a test are contained in one virtual sequence and start
this virtual sequence on the environment’s virtual sequencer in the run
phase of the test. Depending on the DUT and what it needs to get out of
reset, you may need to either restart the virtual sequence if the
agents’ sequencers stopped all the sequences on reset assertion. In this
case, the virtual sequence is restarted in the test, and will go
through the same steps that it went through the first time it ran, like
configuring the DUT, setting up some registers…etc. However, if the
agents’ sequencers only emptied their queues, the virtual sequence and
test don’t need to take any further action, the sequences are expected
to continue running when the DUT comes out of reset.