Skip to content
STIMSMITH

Asynchronous Events

Concept WIKI v3 · 8/14/2026

In RISC-V processor verification, asynchronous events are out-of-band stimuli such as interrupts, debug requests, and exceptions that a design must handle while executing instructions. Because they arise at unpredictable points relative to the instruction stream and are a frequent source of bugs, commercial verification solutions such as ImperasDV treat them as a first-class verification challenge and use open-standard interfaces (RVVI) with novel pipeline synchronization to reproduce and stress their handling in the design under test.

Definition

In RISC-V lockstep co-simulation flows, asynchronous events are stimuli such as interrupts, debug requests, and exceptions that are injected into the design at arbitrary instruction-retire points. Their purpose is to stress the design under test (DUT) while keeping the resulting simulation runs reproducible for debug.

Role in Lockstep Co-Simulation

Lockstep co-simulation runs an RTL design in parallel with a validated reference model, synchronising the two at each instruction retirement and comparing architectural state. Asynchronous events are a key ingredient of the stimulus used in this methodology because they force the DUT and the reference model to handle out-of-band control-flow changes (interrupts, exceptions, debug transitions) rather than just steady-state instruction execution. The Imperas "An introduction to RISC-V processor verification techniques" tutorial states that asynchronous events are driven into the DUT and that step-and-compare logic informs the reference model about asynchronous events [chunk f8509d83-df29-4f4c-a99d-643488aa15e3].

Why Asynchronous Events Matter for RISC-V Verification

RISC-V is an open standard ISA that allows any developer to design and extend a custom processor while remaining compatible with the broader ecosystem. Because of this configurability, processor verification must match the extendable nature of the ISA. Verifying DUT behavior in response to asynchronous events is described as a processor-specific challenge, with such events identified as "a frequent source of bugs" in RISC-V designs [chunk 729fe709-c309-4de5-9e8e-f8a5b8925e64]. This positions asynchronous events not merely as one stimulus category among many, but as a critical correctness axis that any RISC-V verification solution must explicitly address.

Async Step-and-Compare: Pros and Cons

The tutorial presents "async step and compare" as a category that builds on step-and-compare by responding to asynchronous events. It enumerates the following trade-offs [chunk f8509d83-df29-4f4c-a99d-643488aa15e3]:

  • Pros:
    • All the benefits of step-and-compare
    • Responds to asynchronous events
  • Cons:
    • Step-and-compare logic can be fragile and error prone
    • Implementation of async event handling is not reusable
    • Async events not connected to the reference — can conceal bugs
    • Significant effort to implement and maintain

These drawbacks motivate moving to standardised, interface-based approaches (RVVI) rather than custom async-event plumbing per project.

RVVI-Mediated Reproducibility

Because asynchronous events are non-deterministic by nature, reproducing them across reruns is essential for root-cause analysis. In modern lockstep flows, this reproducibility is provided through RVVI (the RISC-V Verification Interface), an open standard interface for exchanging retire, state, and event information between the RTL, testbench, and reference models [chunk f8509d83-df29-4f4c-a99d-643488aa15e3]. The tutorial notes that RVVI has two parts — RVVI-TRACE (signal-level) and RVVI-API (function-level) [chunk f8509d83-df29-4f4c-a99d-643488aa15e3] — and that RVVI-TRACE "includes functions to handle asynchronous events," citing interrupts and debug requests as examples [chunk f8509d83-df29-4f4c-a99d-643488aa15e3]. On the API side, the tutorial lists rvviRefEventStep() among the standard functions that RISC-V processor VIPs implement, alongside rvviRefGprsCompare(), rvviRefPcCompare(), and rvviRefCsrsCompare() [chunk f8509d83-df29-4f4c-a99d-643488aa15e3]. The Synopsys ImperasDV page likewise emphasises that RISC-V verification solutions should make use of open standard interfaces such as RVVI to enable efficiency and reuse [chunk 729fe709-c309-4de5-9e8e-f8a5b8925e64].

Handling in ImperasDV

ImperasDV, a front-end design verification solution for custom RISC-V processors, treats asynchronous events as an explicit verification target. It uses the ImperasFPM as a reference model, connects to the processor under test via the RVVI-TRACE interface, and provides continuous comparison and checking of architectural state [chunk 729fe709-c309-4de5-9e8e-f8a5b8925e64]. For asynchronous events specifically, the product page states that ImperasDV "handles random occurrences of asynchronous events using a novel pipeline synchronization technology" [chunk 729fe709-c309-4de5-9e8e-f8a5b8925e64]. This pipeline synchronization is the mechanism by which random asynchronous event injections are kept coherent with the reference model's retire stream, so that mismatches attributable to asynchronous-event handling can be reproduced and debugged.

Demo: Debugging an Asynchronous-Event Bug

The tutorial's demonstration uses the OpenHW Group CV32E40X RISC-V processor as the DUT and walks through three simulation runs: a passing test, a failing test, and a simulation that exposes an asynchronous-event bug [chunk 54059085-a682-4944-a77e-b2302328e606]. The asynchronous-event example shows the RISC-V core pins and an RVVI-TRACE waveform with valid, retire, trap, PC, and MEPC signals, illustrating the diagnostic question "Interrupt taken, but which one?" — highlighting that asynchronous events need to be unambiguously attributed to specific sources during root-cause analysis [chunk 54059085-a682-4944-a77e-b2302328e606].

Composition of Stimulus

A comprehensive testbench in a lockstep flow typically combines constrained-random instruction streams with directed ISA tests, enhanced with asynchronous events. The tutorial recommends verifying DUT response to asynchronous events as an explicit requirement of a RISC-V processor VIP [chunk f8509d83-df29-4f4c-a99d-643488aa15e3]. Non-deterministic sources such as timers or random I/O are typically stubbed, while an RVVI-based handshake enables randomised interrupts and debug requests while keeping runs deterministic for replay [chunk f8509d83-df29-4f4c-a99d-643488aa15e3]. Industry best practices such as constrained-random stimulus and functional coverage, which are standard for asynchronous-event stressing, are also called out as requirements that a RISC-V verification solution should support [chunk 729fe709-c309-4de5-9e8e-f8a5b8925e64].

Types of Asynchronous Events

The evidence identifies the following categories of asynchronous events used in RISC-V lockstep co-simulation:

  • Interrupts — asynchronous requests that divert the hart from its current execution flow, used to exercise trap entry, save/restore, and return paths.
  • Debug requests — external debug-trigger events that force entry into debug mode, stressing debug-mode entry/exit and debug-state handling.
  • Exceptions — synchronous or asynchronous traps (e.g., from CSRs, memory, or privilege transitions) that test exception handling logic.

RVVI-TRACE explicitly groups interrupts and debug requests under "asynchronous events" with functions for handling them [chunk f8509d83-df29-4f4c-a99d-643488aa15e3]. The tutorial further lists interrupts and the debug block among the customer-specific items that need functional coverage in a RISC-V verification plan, alongside privileged CSRs, pipeline/multi-issue/multi-hart behaviour, and custom extensions [chunk 54059085-a682-4944-a77e-b2302328e606].

Connection to Step-and-Compare with Asynchronous Events

Step-and-compare with asynchronous events is the specific lockstep technique in which RTL and reference-model states are captured and compared at each retire step, while asynchronous events are injected as part of the stimulus. The tutorial positions it as one technique in a progression: post-simulation trace-file compare → self-checking tests → step-and-compare → step-and-compare with asynchronous events → RVVI-based VIP [chunk 54059085-a682-4944-a77e-b2302328e006, chunk f8509d83-df29-4f4c-a99d-643488aa15e3]. It notes that the async variant retains all the benefits of plain step-and-compare but adds response to asynchronous events, at the cost of fragile implementation and the risk of events not being connected to the reference model [chunk f8509d83-df29-4f4c-a99d-643488aa15e3].

Related Concepts

  • Step-and-Compare with Asynchronous Events — a lockstep co-simulation technique that uses asynchronous events as stimulus within the step-and-compare loop, providing immediate mismatch reporting when out-of-band events cause divergence [chunk f8509d83-df29-4f4c-a99d-643488aa15e3].
  • ImperasDV — a commercial RISC-V processor verification solution that explicitly handles asynchronous events using RVVI-TRACE and a novel pipeline synchronization technology [chunk 729fe709-c309-4de5-9e8e-f8a5b8925e64].
  • RISC-V Verification Interface (RVVI) — an open standard interface whose RVVI-TRACE and RVVI-API parts provide a standardised way for testbenches and reference models to exchange asynchronous-event information [chunk f8509d83-df29-4f4c-a99d-643488aa15e3].
  • CV32E40X — the OpenHW Group RISC-V processor used as DUT in the tutorial's demonstration of debugging an asynchronous-event bug [chunk 54059085-a682-4944-a77e-b2302328e606].

LINKED ENTITIES

1 links
Step-and-Compare with Asynchronous Events USES

CITATIONS

9 sources
9 citations
[1] Asynchronous events are out-of-band stimuli (interrupts, debug requests, exceptions) injected at arbitrary retire points to stress a DUT while keeping simulation runs reproducible. An introduction to RISC-V processor verification techniques
[2] Async step-and-compare retains the benefits of step-and-compare and responds to asynchronous events, but is fragile, error prone, hard to reuse, and risks concealing bugs because async events may not be connected to the reference model. An introduction to RISC-V processor verification techniques
[3] RVVI is an open-standard interface with two parts — RVVI-TRACE (signal-level) and RVVI-API (function-level) — that standardises communication between testbench and RISC-V VIP. An introduction to RISC-V processor verification techniques
[4] RVVI-TRACE includes functions to handle asynchronous events such as interrupts and debug requests. An introduction to RISC-V processor verification techniques
[5] RVVI-API standard functions include rvviRefEventStep() alongside rvviRefGprsCompare(), rvviRefPcCompare(), and rvviRefCsrsCompare(), supporting a step-and-compare methodology. An introduction to RISC-V processor verification techniques
[6] Asynchronous events are a frequent source of bugs in RISC-V designs and a processor-specific verification challenge that solutions such as ImperasDV must explicitly address. ImperasDV: RISC-V Processor Verification Solution | Synopsys
[7] ImperasDV uses ImperasFPM as a reference model, connects via RVVI-TRACE to the DUT, and handles random asynchronous events using a novel pipeline synchronization technology. ImperasDV: RISC-V Processor Verification Solution | Synopsys
[8] The tutorial demonstrates debugging an asynchronous-event bug on the OpenHW Group CV32E40X RISC-V processor, showing how an interrupt is taken but the specific source must be identified using signals such as valid, retire, trap, PC, and MEPC. An introduction to RISC-V processor verification techniques
[9] RISC-V functional coverage must cover customer-specific features including interrupts, the debug block, privileged CSRs, pipeline/multi-issue/multi-hart behaviour, and custom extensions. An introduction to RISC-V processor verification techniques

VERSION HISTORY

v3 · 8/14/2026 · minimax/minimax-m3 (current)
v2 · 8/8/2026 · minimax/minimax-m3
v1 · 7/10/2026 · minimax/minimax-m3