Interrupt handling in UVM Test
April 5, 2023 2023-05-02 13:25Interrupt handling in UVM Test
Viswa K In this blog post, we will go over the implementation of interrupt handling in the UVM Test bench(TB) environment.
In a DUT, typically there will be one or more interrupt pins. Related to interrupts, TB
- Would need to check the correctness of interrupts
- May need to have routines to service the interrupts
- May have mask registers that would need to be checked for correctness.
When there are multiple functionalities in a DUT that trigger interrupt (s), it is better than in the TB, all interrupt-related checking and service routine logic are centrally handled.
When there are multiple interrupt pins in a DUT to indicate each individual interrupt, the TB can use the individual interrupt pins in interrupt checkers and trigger interrupt service routines. When there is a single interrupt pin, there will be a status register that has bits to indicate which particular interrupt status caused the interrupt to assert. In either case, the chip interface can have individual interrupt events for each of the functionality in the DUT and a centralized interrupt handler can take up triggering these individual interrupts which can be used within the Test environment by the interrupt checkers and the interrupt service routines.
The interrupt handler flow for a single interrupt pin is as shown in this block diagram.
Learn Now: SystemVerilog for Verification
In this flow, when the DUT asserts the interrupt, in the TB, first the status register is read and then the mask register value can be got from a register model or read from DUT and then based on the mask value and the status value, the interrupt bits that are set by the DUT are derived and the respective interrupt events in the chip interface are triggered. Subsequent to that, an optional mask checking can be added – that is the mask bits can be turned on to check if the interrupt gets masked/de-asserted. In the TB, there typically needs to be separate interrupt service routines for each of the interrupts. These routines will wait for the respective interrupt to be triggered and then would service the interrupt and then would trigger interrupt service done. For each of the interrupt, the chip interface would also need to have separate interrupt service done events. Separately, interrupt checkers will get triggered based on respective TB interrupts and the checkers would check to see if the respective interrupt is expected and then display pass/fail accordingly.
The main interrupt handling thread waits for all interrupt service routines done and then clears the respective interrupt status bits and asserts respective interrupt cleared event. For each of the interrupt, chip interface need to have interrupt cleared events.
While the interrupts are getting serviced, more interrupts could have happened in the DUT- to check that, again the status is read and mask is read – if there are new interrupts then the whole process of triggering the respective interrupts are started – else the thread waits for main interrupt to de-assert and then goes back to the start.
Given below is an illustration of interrupt handler for a router.
In an UVM TB, the interrupt handler can be a separate uvm component. A video illustration of interrupt handler is in the following link:
A code snippet of the interrupt handler is given below:
To get the full UVM TB code of this illustrated interrupt handler, email us at coderequest@edveon.com
