Design Article
Tell us What You Think
We want to know what you thought about this Design. Let us know by adding a comment.
Designing a reset-aware OVM testbench
Bahaa Osman - Intel
9/24/2012 9:42 AM EDT
The sequencer and tests
Sequencer
The 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
Depending 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.
Sequencer
The 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:
- 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.
Sequences and tests
Depending 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.
|
|
|
|
|
Navigate to related information