Asynchronous Events

Concept

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.

First seen 7/10/2026

Last seen 8/26/2026

Evidence 9 chunks

Wiki v3

WIKI

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

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

5 connections

ImperasDV ← uses 98% 1e

ImperasDV addresses verification of DUT behavior in response to asynchronous events.

Lockstep Co-Simulation Methodology ← uses 93% 1e

Asynchronous events are injected at random retire points to stress the design in the lockstep methodology.

Step-and-Compare with Asynchronous Events ← uses 95% 1e

Step-and-compare with asynchronous events specifically handles asynchronous events such as interrupts

Lockstep Co-Simulation ← uses 1e

Lockstep Co-Simulation incorporates asynchronous events to stress the design while keeping runs reproducible.

Understanding the RISC-V Verification Ecosystem ← mentions 1e

The paper Understanding the RISC-V Verification Ecosystem covers handling of asynchronous events in lockstep flows.

LINKED ENTITIES

1 links

Step-and-Compare with Asynchronous Events USES Extracted graph relationship

CITATIONS

9 sources

9 citations — click to expand

[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