Overview

In the cited processor-verification context, asynchronous interrupts are treated as external stimuli, alongside debug requests, that may fire randomly during execution rather than at a fixed instruction boundary chosen by an offline trace-comparison flow. Because of that asynchronous behavior, a single interrupt can make independently generated RTL and reference-model execution logs diverge, even when the design behavior is otherwise intended. [interrupts-as-external-stimuli]

Impact on reference-model comparison

Trace comparison requires both models to dump execution logs, typically including program-counter flow and register or memory writeback information, and then compares those logs after execution. This works poorly for asynchronous external stimuli: if an interrupt occurs while the RTL and reference model are running standalone, the resulting logs can differ simply because the interrupt changed one execution path. [trace-comparison-limitation]

Co-simulation requirement

To support asynchronous interrupts, the verification setup must provide communication that can overwrite or redirect the emulator’s execution path. When the RTL flags an interrupt, it must inform the emulator so the emulator follows the RTL’s execution path. [cosimulation-messaging]

In co-simulation, the RTL implementation and reference model run in parallel and exchange messages. One class of message is sent at defined events such as instruction commit, causing the reference model to commit an instruction and compare relevant state. For asynchronous interrupts, an additional message is needed to notify the reference model that the RTL has taken an interrupt. [cosimulation-messaging]

Dromajo integration

In the Dromajo-based RISC-V co-simulation flow described in the evidence, instruction-by-instruction comparison is synchronous, but interrupts are not. The flow therefore logs when the core takes an interrupt and forces Dromajo’s control flow to do the same, enabling co-simulation of interrupt trap-handler routines. Dromajo’s DPI wrapper function raise_interrupt() performs this role by communicating the interrupt cause and setting the trap vector in Dromajo. [dromajo-raise-interrupt]

The same source also characterizes Dromajo as able to handle external stimuli such as interrupts and debug requests on the fly, and to integrate into existing testbench infrastructure with minimal effort. [dromajo-external-stimuli]