I am a Verification Engineer at Cadence Design System. I started the Verification blog to store solutions to small (and big) problems I've faced in my day to day work. I want to share them with the community in the hope that they may be useful to someone else.
The uvm_event#(type T = uvm_object) class is an extension of the abstract uvm_event_base class. The optional parameter T allows the user to define a data type which can be passed during an event trigger. uvm_event class is an abstract wrapper class around SystemVerilog event construct.
It provides additional services such as over traditional SystemVerilog event like,
1) pass data when event is triggered,
A traditional Systemverilog event does not have functionality to pass data when event is triggered. While uvm_event adds this functionality. So, you can pass the transaction class handle when some event is triggered.
By calling trigger task we can trigger the event and optionally give the data which we want to pass using uvm_event.
By calling wait_trigger()/wait_ptrigger() task of uvm_event we can wait for event to be trigger and then by calling get_trigger_data() function we can get data.
or we can directly use only one task wait_trigger_data()/wait_ptrigger_data() of uvm_event to wait for event to be triggered and to get the data.
2) setting callbacks,
We can also add callbacks whenever an event is triggered. This is done by registering a callback class with particular event.
3) maintaining the number of waiters,
We can get the number of processes waiting on the event (using get_num_waiters() function).
4) maintaining the time when event was triggered,
We can get the time that this event was last triggered (using get_trigger_time() function)
Like SystemVerilog event has trigger (@event) and persistent trigger (wait(event.triggered)) mode, uvm_event also has trigger (wait_trigger task) and persistent trigger (wait_ptrigger task).
Let's go through below example and see how we can transfer data using uvm_event and how we can disable uvm_event from triggering using callbacks of uvm_event.
As shown in above code, one uvm_event named PKT_TX_CMPLT_EV is taken in driver.
In build phase of driver we get global handle of event pool using static method get_event_pool of uvm_event_pool class.
Then PKT_TX_CMPLT_EV is added into associative array of uvm_event_pool using get/add method of uvm_event_pool. Note that here PKT_TX_CMPLT_EV event is added in associative array of uvm_event_pool using key (in string format) DRV_EVENT.
In run phase of driver when stimulus is driven, trigger method of uvm_event is called and transaction class is passed in argument of trigger method.
uvm_event also provides facility of callback when event is triggered.
In code my_event_callback (callback for uvm_event) class which extended from uvm_event_callback.
uvm_event_callback provides two hookups, 1) pre_trigger, 2) post_trigger.
Called just before triggering the associated event. If this function returns 1, then the event will not trigger and the post-trigger callback is not called.
Through uvm_event we can pass data(transaction class) when event is triggered, then why do we need TLM/Analysis ports in UVM?
If event is triggered again before receiver gets the data then data will be overwritten.
Reset testing is a crucial element of functional sign-off for any chip.
The architectural components of the entire verification environment need to be
correctly synchronized to be made aware of the reset condition. Scoreboards,
drivers and monitors need to be tidied up, and the complex stimulus generation
needs to be killed gracefully.
As we know, in UVM, there are twelve phases parallel to run_phase:
pre_reset_phase(), reset_phase(), post_reset_phase(): Phases involved
in reset activity.
pre_configure_phase(), configure_phase(), post_configure_phase():
Phases involved in configuring DUT.
pre_main_phase(), main_phase(), post_main_phase(): Phases involved in
driving main stimulus to the DUT.
pre_shutdown_phase(), shutdown_phase and post_shutdown_phase(): Phases
involved in settling down the DUT after driving main stimulus.
Using these phases instead of using only run_phase, we can achieve
synchronization between all components of verification environment also easily
test reset functionality.
In reset testing, user drives random sequence to the DUT and in between
data transmission, reset is applied followed by driving restart sequence. We
will see how the reset functionality could be easily tested using phases
parallel to run_phase and phase jump feature of UVM.
Let’s go through complete example to understand how it is achieved
using UVM phases and Phase jump feature.
Driver is waiting for Reset to be asserted (in reset_phase) by raising
objection and then perform action which user want on assertion of Reset signal
and at last drop the objection and move to post_reset_phase. In post_reset_phase
driver is waiting for Reset to de-assert and then move to main_phase. In
main_phase driver drives stimulus on interface and in parallel to that wait for indication
from agent about assertion of reset.
Components such as monitors that attach to signaling interfaces should
be designed to be phase independent because they are intended to mimic other
real devices in the system. These components should watch the reset signal
associated with their interface and reset themselves accordingly.
You may find that the driver, the sequencer, and their currently
running sequences will squawk with errors if they are not synchronized
properly. UVM requires that the sequencer first stop its sequences and then the
driver must be certain to not call item_done on any outstanding sequences. However, the order that a simulator executes
threads in the various components is indeterminate. To synchronize these
operations, the containing agent has a pre_reset_phase such as the above.
It is more often that two or more components in verification environment are not in sync with each other. And there may be a case where driver/transmitter finish it's job first and call item_done. After item_done is called from driver and if there is no action pending in sequence then start method of sequence finishes and objection is also dropped.
But we want that simulation (more precisely we can say run_phase) should extend to some more time after all objection are dropped, so that other components which are late with respect to driver can finish it's job. We can achieve this by using set_drain_time in UVM.
Let's go through example and see how we can achieve this using set_drain_time in UVM.
Variable uvm_sequence_base::starting_phase is deprecated and replaced by two new methods set_starting_phase and get_starting_phase, which prevent starting_phase from being modified in the middle of a phase. This change is not backward-compatible with UVM 1.1, though variable starting_phase, although deprecated, has not yet been removed from the base class library.
New method uvm_sequence_base::set_automatic_phase_objection causes raise_objection and drop_objection to be called automatically around a sequence, avoiding the need to call raise/drop_objection manually in one common situation.
Lets understand it trough below mentioned example.