Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > EDA/IP

Developing reset-aware OVM testbench

Posted: 10 Oct 2012 ?? ?Print Version ?Bookmark and Share

Keywords:IP? verification? monitor?

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.

As far as coverage is concerned, it is recommended to cover that the "reset in the middle of simulation" scenario occurred at least once. This way, you can ensure that the DUT is guaranteed to behave as expected if this scenario happened. This can be achieved either through the covergroups or cover directive.

Covergroups: In the coverage collector class, declare a variable of type bit with the default value of 0, and in a task set it to 1 on the triggering of the reset event. A coverpoint is then created for this variable for which 100% coverage means that the reset event was triggered. It would probably be more appropriate if a bin is created for this coverpoint to cover the value of 1 only, this way you either get a 0% or 100% coverage for this coverpoint. The code below shows an example for using covergroups to cover the scenario of reset during simulation.

Cover directive: In this case, instead of using the coverage collector class, a SVA property will be declared that describes the scenario that reset started as asserted, then it got deasserted sometime later, and at any time before the end of simulation it got asserted and deasserted again. Then the cover directive is applied to this property to ensure it was covered. An example property code is shown below. This code is usually implemented in the interface, or any other file where other SVA properties are declared and bound (using the SV bind construct) to the interface.

On the other hand, the normal transaction coverage collection is halted by default during reset since the monitor is no longer broadcasting transactions on its analysis port during reset assertion.

Scoreboard and reference model
The scoreboard usually has several internal analysis fifos that store transactions collected from the corresponding agents and consume those transactions as needed when the scoreboard needs to compare actual results with expected results. The figure shows a simple block diagram of a general scoreboard architecture. In fact, when reset is asserted, the scoreboard doesn't need to do anything with its internal fifos, since their contents are transactions that already took place and hence are complete. The incomplete transactions are being taken care of by the monitors and the monitors either will not send those incomplete transactions to the scoreboard, or send a transaction indicating it is incomplete and the scoreboard should be able to handle this case.

Figure: Scoreboard general architecture.

?First Page?Previous Page 1???2???3???4?Next Page?Last Page

Article Comments - Developing reset-aware OVM testbench
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top