Overview

In the provided verification evidence, DPI is the mechanism used for calls between Verilog/RTL simulation and external software-side verification components. Dromajo is compiled into a shared library, linked to the simulator, and accessed from Verilog through DPI calls. The DPI functions are described as lightweight wrappers around Dromajo API functions. ^[1]

DPI is also used by Logic Fuzzer integrations that replace or redirect RTL table accesses. In the described branch-predictor and cache/table experiments, implementation-side logic accesses fuzzer-managed tables through DPI rather than directly accessing the RTL memory model. ^[2]

Use in Dromajo co-simulation

The Dromajo integration links the Dromajo shared library into the simulator and interacts with it through DPI calls from Verilog. The described flow uses three DPI wrapper functions:

• cosim_init(): invoked from an initial Verilog block; it calls Dromajo initialization, passes the path to a configuration file, and initializes the reference model. ^[1]
• step(): called when a valid instruction is committed; it communicates the program counter, instruction, and store data to Dromajo. Dromajo commits one instruction on its side, compares the communicated data, and returns a non-zero code on mismatch. ^[3]
• raise_interrupt(): used because co-simulation is synchronous while interrupts are not; it communicates the interrupt cause and sets the trap vector in Dromajo so interrupt trap handlers can be co-simulated. ^[3]

In the checkpoint-based flow, Dromajo is instantiated and encapsulated in the RTL as a submodule. After both the RTL model and Dromajo are initialized from the same checkpoint state, the RTL side calls into Dromajo during commit-time co-simulation. ^[4]

Use in Logic Fuzzer table mutation

For Logic Fuzzer table mutators, the evidence describes replacing instruction-cache tag and data arrays with table mutators. The instruction-cache logic writes and reads those tables through DPI. The same passage describes forcing branch-prediction structures to steer execution so that fuzzer tables can provide a random instruction stream when a specific tag is observed. ^[4]

The paper also describes configuring a fuzzer object in Dromajo to allocate a table with the same size as the branch predictor. On the implementation side, instead of accessing the RTL memory model, the design accesses the fuzzer table through DPI. During simulation, the tables can be fuzzed randomly or with specific patterns. ^[2]

Role in verification

Within the cited flow, DPI serves as a narrow integration boundary:

1. RTL or Verilog-side code calls software-side verification functions.
2. Wrapper functions translate simulator events such as initialization, instruction commit, and asynchronous interrupt handling into Dromajo API calls.
3. Fuzzer-backed table structures can replace selected RTL memory/table structures while remaining accessible to RTL logic through DPI.

This makes DPI important for both Dromajo co-simulation and Logic Fuzzer table mutation in the provided evidence.