Overview

In the cited RISC-V verification evidence, DPI is the mechanism used for calls between Verilog/RTL simulation and external software-side verification components. The DPI functions are described as the integration boundary that links RTL logic to a reference model and to fuzzer-backed structures. ^{[1] [2]}

The cited Imperas step-and-compare presentation identifies DPI as the technique that connects the testbench control block to the reference model so that the RISC-V RTL and reference model can be advanced and compared in lock-step. ^[2]

Role in step-and-compare co-simulation

The step-and-compare flow presented by Imperas consists of a test program (possibly generated by an Instruction Stream Generator), a processor reference model, the RTL DUT and tracer, the RTL simulator, and step-and-compare logic. In this flow, the reference model is encapsulated in a SystemVerilog testbench; a control block steps both the DUT and the reference model, extracts data from each, compares results, and reports differences immediately. The cited slides show DPI as the named connection between the testbench and the reference model that makes this lock-step stepping possible. ^[2]

The reference model requirements described alongside this flow — configurability for RISC-V ISA extensions, support for custom instructions and CSRs, ability to run in lock-step with the RTL simulator (co-simulation), ability to step the reference model at significant events such as retire or trap, and functions to query the model state for comparison — correspond to what DPI exposes to the SystemVerilog testbench. ^[2]

A step-and-compare flow extended for asynchronous events adds asynchronous event drivers (for example, debug and interrupt drivers) on top of the same step-and-compare logic; DPI remains the boundary through which the testbench reaches the reference model and through which asynchronous events are coordinated with synchronous stepping. ^[2]

Role in Logic Fuzzer table mutation

For the Logic Fuzzer integrations described in the MICRO paper, the implementation-side logic accesses fuzzer-managed tables through DPI rather than directly accessing the RTL memory model. The fuzzer object in Dromajo is configured to allocate a table with the same size as the corresponding RTL structure (for example, a branch predictor table), and on the implementation side, the design accesses that table from the fuzzer through the DPI; during simulation the tables are fuzzed randomly or with specific patterns. ^[1]

The same passage describes replacing instruction-cache tag and data arrays with table mutators: the tables are written and read by the instruction-cache logic through the DPI. This redirection enables the fuzzer to inject alternate instruction streams when a specific tag is observed, supporting coverage of mispredicted paths and other microarchitectural corner cases. ^[1]

Position in the verification flow

Within the cited flows, DPI serves as a narrow integration boundary between SystemVerilog testbench or RTL logic on one side and external software components (reference model, fuzzer objects) on the other:

1. A testbench control block uses DPI to invoke reference-model functions for stepping, querying state, and reporting mismatches in lock-step with the RTL DUT. ^[2]
2. The same kind of DPI calls connect asynchronous event drivers (debug and interrupt) to the step-and-compare logic in the asynchronous step-and-compare variant. ^[2]
3. In the Logic Fuzzer flow, DPI redirects selected RTL table accesses to fuzzer-managed tables in Dromajo, allowing random or pattern-driven fuzzing of branch-predictor and instruction-cache structures. ^[1]

This makes DPI important both for step-and-compare co-simulation with a reference model and for Logic Fuzzer table mutation in the provided evidence.