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 

The second case is the driver needs to keep monitoring the reset signal throughout the simulation time, and once reset is asserted, the driver needs to make its first decision based on what has been described in the testbench architecture. The driver can either abort the ongoing transaction if one is being driven on the bus, then when reset is de-asserted it can ask the sequencer for anew transaction by calling get_next_item again, or it can stall while saving the current transaction waiting for reset to be de-asserted, this is when it can re-start driving this transaction on the bus from the beginning.

The following code shows an example of a driver that will model a reset-aware bus driver that waits for reset deassertion at the beginning of simulation. It then continuously drives the bus with traffic from incoming transactions while monitoring the reset condition. When the reset is asserted, it stops driving the bus, drops the current transaction, and drives the bus default values. Finally, it goes back waiting for reset deassertion, to go through this process again.

It is very important to note that the driver needs to call item_done() when reset is asserted in the middle of simulation if a transaction was already being driven on the bus. This will prevent the driver from hanging producing the error that get_next_item() was called twice in a row without item_done() being called.

The monitor is a passive component that resides in an agent, and monitors bus transactions on the pin interface to convert them to transaction level and send them out to the rest of the testbench for consumptions. That said, the monitor doesn't need to wait for reset deassertion at the beginning of simulation since it is guaranteed there will be no transactions driven on the bus during reset assertion as that was modeled in the driver.

The monitor code changes are very similar to those made to the driver, yet somehow simpler. Below is an example for a monitor that will continuously monitor the bus until reset is asserted. Once reset is asserted, the monitor will drop the transaction it was handling and go back to monitoring a new transaction.

It may be a testbench architecture requirement that the monitor observes and sends the incomplete transaction to its subscribers if needed when reset is asserted, but for the code shown above, the monitor drops the transaction. The code will have to change a little to handle this case. One solution is to make the object handle of the transaction the monitor_bus() method is building up visible outside the method. Then, before disabling the fork process when reset is asserted, clone this object and send it to the analysis port.

In addition to monitoring the reset assertion, the monitor_reset_assertion() task will also inform the agent's components of a reset using the OVM event pool. This event will be used later by other components of the agent to make decisions and take actions on the triggering of the reset event. Following is an example code for the monitor_reset_assertion() task.

Note that in order to be able to reference the agent static event pool, the agent class needs to be forward defined before the monitor uses it.

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.

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

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