In general, reset will be applied at different times within
at the beginning of a test
In a typical UVM test you might
start out by applying a reset, and then
go on to configure your device, and subsequently, start traffic. The associated
UVM environment, in particular its components, do not have to do anything
special to support this type of test - Life is Good!
in the middle of a test
Now, let's change things and apply
reset again, later on in the test, in order to determine that the device can transition
in and out of the reset condition properly. In this case, your verification environment
needs to contain additional infrastructure to support this type of test.
Otherwise, for example, your test might produce invalid errors.
UVM components such as scoreboards, sequencers, drivers, monitors,
and collectors need to handle an arbitrary occurrence of reset in a robust
matter. This means that you need to
implement ways to gracefully terminate ongoing activity once reset is asserted,
and restart activity properly after reset drops. In other words, you need to
have a reset-aware UVM component implementation.
Cadence provides an approach for this that works with the
standard UVM library and leverages the UVM run_phase.
In the testbench you add a reset monitor that notifies a reset handler, which
in turn calls the reset-aware component so that they terminate and restart
activity when needed (as show below). The key part of the packages is the utility
library used to implement the reset handler.
The UVM reset package includes examples and documentation
that show how this works in detail and how to use it. Cadence has contributed the
reset package to Accellera's UVM world
community so you can go ahead and check it out, and
Courtney Schmitt of Analog Devices has adopted this package
and will present her experience at DVCon 2014 in San Jose at the poster session
(and the associated paper) on Tuesday, March 4, 2014.
1P.7 Resetting Anytime with the Cadence UVM Reset