Overview

In the RISC-V processor verification context, asynchronous interrupts are external stimuli that may fire unpredictably 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 cause independently generated RTL and reference-model execution logs to diverge, even when the design behavior is otherwise intended. [interrupts-as-external-stimuli]

Impact on reference-model comparison

Comparing a Device Under Test (DUT) against a reference model is not as simple as running programs on both and comparing PC values; it must take into account all ISA architectural features and options, including full asynchronous operation. [rvvi-api-asynch]

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

RVVI-TRACE interface

The RVVI-TRACE interface is the SystemVerilog interface to the internals of a core's micro-architecture, exposing values, state, and events on internal signals to testbench components (a role historically fulfilled by a 'tracer'). RVVI-TRACE is designed to support a wide design space, from simple single-hart in-order cores through multi-hart, multi-issue, out-of-order cores with asynchronous interrupts, and debug modes. It also allows net changes observed by the RISC-V core to be propagated to consumers of the interface. [rvvi-trace-asynch]

RVVI-VVP virtual peripherals

The RVVI-VVP (Virtual Verification Peripherals) defines testbench components that interact with the processor — for example a virtual UART to print program output and timers to generate asynchronous interrupts. RVVI-VVP targets use from C/C++ and SystemVerilog testbenches, and in some cases from ISS-based environments, to ease test creation. The work-in-progress scope explicitly includes timers, interrupts, debug, random event generators, and printer/log/UART capabilities. [rvvi-vvp-asynch]

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 that 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 via the DPI wrapper step() is synchronous, but co-simulation is a synchronous process, 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. The 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]