Global Sources
EE Times-India
EE Times-India > EDA/IP

How to design reset-aware OVM testbench

Posted: 23 Oct 2012     Print Version  Bookmark and Share

Keywords:IP  verification  monitor 

However, the scoreboard usually has the TLM or behavioral reference model representing the DUT that computes the expected behavior of the DUT. Since this model resembles the DUT, it is very important that it monitors for reset assertion and takes necessary action too. First, the model can use the reset event triggered by the agent's monitor to know when reset is asserted; the same way the coverage collector used it. Once reset is asserted, the model needs to take the same actions the DUT takes in reset state. These actions may include but are not limited to resetting registers and internal storage or memory, resetting a finite state machine to the default state, empty its queues or stop expecting more messages of a certain type.

It is very important to note that the model should not stop computing the expected behavior of a transaction if reset is asserted. In other words, if the model happens to be calculating the output for a transaction at the time reset is asserted, it needs to continue and send that expected behavior to the scoreboard before it can take those reset actions.

In today's verification environments, it is inevitable that a register package is utilized to abstract register operations to/from the DUT registers as well as shadows them for use within the testbench. The DUT registers are usually modeled to be reset to their reset/default values once reset is asserted. However, the register model might not do the same automatically. The user needs a process that monitors for the reset event explained earlier, and reset the register model on triggering this event. Although this depends heavily on the register package used, most of the register packages have an API for the register object that can be used to reset the register shadow to its reset value described in the register description provided to the register model generator.

Below is some pseudo code that takes care of resetting the register model when the reset event is triggered. Most likely this code with be implemented in the run phase of the agent.

UVM implementation
Most of what we described previously applies to both OVM and UVM. However, UVM adds some capabilities specifically to the testbench phases that allow the testbench developer have more fine grain control over the testbench behavior.

UVM introduces several new phases that didn't exist in the OVM. The one of interest to our discussion is the reset phase and its callbacks: pre_reset and post_reset. In those phases, the testbench is supposed to define the reset behavior and behave accordingly. For example, in the pre_reset phase, the driver should drive X's or Z's on the inputs of the DUT and wait for power good conditions before moving to the reset phase when the driver should drive default values of those signals.

The other thing UVM introduces is phase jumping. Jumping allows the testbench to move from one phase to another without restricting the order of the two phases, i.e. the testbench can jump back to a previous phase or jump forward to skip a phase. UVM provides two jump methods: one that jumps to a phase within the current phase schedule and another that makes all schedules jump to the specified phase.

The new UVM capabilities and phases allow us to change the implementation of a reset-aware testbench a little bit. First, the method drive_default_values() implemented in the driver is not needed anymore. This is the implementation of the reset_phase() of the driver. The code that resets the register model also is no longer in the main_phase() (note that it is no longer run, even though run_phase exists in UVM) of the agent, it is moved to the reset_phase(). The monitor will still need to monitor reset and trigger the reset event for the verification components to use.

Another major difference in the implementation is the agent behavior when the reset event is triggered. The agent needs to monitor the reset event and when triggered, it needs to jump and make all the components jump to the reset_phase() phase. It shall use the jump_all(reset_phase) so that all the sub-components (driver, monitor, sequencer...etc.) jumps to this phase and start from there again. This will ensure that the VC goes through the correct phases (reset, configure, main...etc.) and executes the corresponding code to bring the DUT out of reset and into functional mode.

Reset is an important state of an IP and the testbench needs to be designed to accommodate and handle this state. We have seen throughout the paper the necessary changes to the various testbench components in order to deal with the reset conditions. We have also discussed how those changes differ if the testbench is UVM-based versus OVM-based.

About the author
Bahaa Osman is a senior verification engineer at Intel. His main focus is testbench and verification IP architecture and development and also verification planning for various IPs. Previously, he worked at Mentor Graphics as a Verification Technologist. He received his bachelor's degree from Cairo University in Egypt in 2004.

To download the PDF version of this article, click here.

 First Page Previous Page 1 • 2 • 3 • 4

Comment on "How to design reset-aware OVM testbe..."
*  You can enter [0] more charecters.
*Verify code:


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


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top