Developing reset-aware OVM testbench

Reset is a state that exists for almost every single IP. It is usually controlled by at least one, in some cases more, input signal. Typically, a design starts in the reset state and when the reset signal is deasserted; the IP comes out of the reset state and walks through into its functional states. The reset state may be also the state which the IP starts in when powered up after being power gated. In addition, the IP might need to be reset during run-time for various reasons, either functional reasons such as power gating/power up or recovering from incorrect behavior. An IP can be reset during operation for verification purposes as well, to check that the IP will behave gracefully if reset is asserted at any time while the IP is running. All the above makes the reset state and the signals affecting it of great concern to the verification of the IP. The verification environment designed to verify the IP is required not only to be aware of the reset state and signals causing any state transition to and out of this state, but also be able to verify the IP behaved as expected when going into and coming out of the reset state. This paper describes how to design your testbench to make it reset-aware, starting by discussing how this affects the testbench architecture, and then going into more details about each verification component and what changes are required for it to take into consideration the reset conditions.

Testbench architecture
Initially, as part of defining the testbench architecture, some questions need to be answered that will define how reset-aware the testbench needs to be. The first obvious question is does the device under test (DUT) have a reset state and if it does, what the conditions and inputs causing the DUT to go into this state are. Several questions follow; when can the DUT enter the reset state? Is it only during power up sequence? And can the DUT go into this state any time the reset signal is asserted, and can the reset be asserted any time during run time? Does the DUT have to be in a certain state before going to reset, IDLE for example? Is the reset synchronous? More interestingly, does the DUT have one reset or does it have a reset signal for each interface in addition to a functional reset?

Answers to the above questions need to be determined from the design specification and the design architects while deciding the testbench architecture. This will allow the testbench architects to account for reset functionality and design the various verification components that comprise the verification environment to be able to handle the different reset conditions and verify that the DUT behaved correctly. Moreover, the answers will define verification requirements that will be translated into test scenarios to be generated and covered as well as checkers to be developed to verify correctness of the reset state.

A typical Open Verification Methodology (OVM) verification environment is built using one or more OVM agents representing the different device models in the system, some system-level analysis components like scoreboard and coverage collectors, as well as a virtual sequencer which directs sequences to the appropriate agents to run on their sequencer. In the coming sections, we will discuss in details how each verification component can be designed to account for reset.

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

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

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