【uvm】Wait for Interface Signals in UVM

In normal scenarios the synchronization of hardware events, like clocks, resets, error signals, interrupts etc., primarily takes place inside the UVM Driver & Monitors for an UVM Testbench.

But there are certain conditions, some of them are listed below, which requires systematic handling of these interface signals because handling of these interface signals inside Driver, Monitor or Component is not sufficient to achieve the intended functionality.

Examples of certain conditions to handle interface signals outside Drivers & Monitors could be as described below:

• Providing clock based delay between transmitted Transaction items inside the Sequence (Accessing Virtual Interface signals inside Sequence)
• To ignore the coverage data collected during an error condition which are based on error signals
• To trigger another Sequence (ISR) after receiving an interrupt
• To wait for reset before sampling any valid data on the Analysis side of the UVM testbench.

Hence from the above mentioned specific conditions, its obvious that we need a systematic approach to handle interface signals to support these conditions where a dynamic object like Sequence may depend on the interface signal’s state for the next action to be taken.

Well, this requirement could be fulfilled by adding hardware synchronization methods (corresponding to the interface signals) to the Configuration Object which will also contains the Virtual Interface. These methods blocks until a hardware event occurs on the Virtual Interface. Examples of these hardware synchronization methods could be:

• wait_for_clock()
• wait_for_reset()
• wait_for_interrupt()
  i- nterrupt_cleared()
  Now, in order to use these hardware synchronization methods inside the configuration object, the Sequence or the Components must first ensure that it has a valid pointer to the configuration object.

The pointer may already have been set during construction OR it may require Sequence or Component to call get_config() static method. Once the local configuration object pointer is set & valid, the hardware synchronization methods can be accessed using the configuration object handle.

Lets see this approach by using UVM example code below:

/ Transaction Class
class transaction extends uvm_sequence_item;
 `uvm_object_utils(transaction)
 
 rand logic [31:0
1
2
3
4