Skip to content
STIMSMITH

Co-simulation State Verification

Concept WIKI v1 · 5/27/2026

Co-simulation state verification is a processor-verification approach in which a device under test and an ISA simulator execute the same inputs in parallel and their architectural states are compared after instruction execution. In MorFuzz, the method is made synchronizable to handle microarchitectural differences such as delayed write-back and to avoid premature false positives by synchronizing legally mismatched state.

Overview

Co-simulation state verification checks a processor device under test (DUT) against a reference ISA simulator. In MorFuzz, the ISA simulator runs in parallel with the DUT, both execute the same inputs, and correctness is checked by comparing their states after each instruction is executed. [C1]

Role in MorFuzz

MorFuzz applies this verification method as an online co-simulation approach. The ISA simulator serves as the reference model for the DUT, allowing runtime detection of divergent architectural behavior during fuzzing. [C1]

MorFuzz’s implementation extracts the core logic of Spike, the official RISC-V ISA simulator, as the reference model used to check the DUT’s behavior. [C5]

Handling delayed write-back

A direct state comparison at instruction commit can be unreliable across different processor microarchitectures. The MorFuzz paper notes that prior work assumed write-back data is always ready when the DUT commits instructions, but this assumption does not always hold. Rocket is given as an example of a processor that supports delayed write-back, where long-latency instructions such as multiply, divide, and floating-point operations may not have write-back data ready at the commit stage. [C2]

To accommodate such differences, MorFuzz abstracts state comparison into two stages: a commitment stage and a judgment stage. This separation allows the co-simulation framework to tolerate cases where committed instructions do not immediately expose final write-back data. [C3]

State synchronization

MorFuzz can synchronize legally mismatched hardware state to the simulator. The paper describes checking legality by analyzing the accessed physical address on the simulator; if the access is legal, MorFuzz synchronizes the hardware state to the simulator, and otherwise reports the mismatch as a potential bug. [C4]

The same mechanism can also synchronize external events, including interrupts, to the simulator. By automatically synchronizing mismatched states, MorFuzz allows simulations to continue deeper instead of stopping early because of false positives. [C4]

Synchronization prerequisites

MorFuzz defines strict rules for approving state synchronization. A difference must satisfy prerequisites before it is treated as legal. First, only instructions involving operations beyond the verification scope may proceed to synchronization, limiting synchronization-triggering instruction types to CSR instructions and memory-operation instructions. Second, the DUT’s control-flow information must pass the commitment-stage check. If the DUT incorrectly approves access to privileged registers or reserved address space, the simulator side throws an exception. [C6]

Interaction with instruction morphing

When instruction morphing is used, MorFuzz maintains a morphing map keyed by the instruction before morphing and its address, with the morphed instruction as the value. This lets the reference model perform the same morphing as the DUT, so both models execute deterministic and identical morphed instructions and morphing does not introduce false positives. [C7]

LINKED ENTITIES

2 links
MorFuzz IMPLEMENTS
Synchronizable Co-simulation USES

CITATIONS

7 sources
7 citations
[1] Co-simulation state verification in MorFuzz runs an ISA simulator in parallel with the DUT, executes the same inputs, and compares their states after each instruction. MorFuzz: Fuzzing Processor via Runtime Instruction Morphing enhanced Synchronizable Co-simulation
[2] Prior co-simulation work assumed write-back data is ready at commit, but MorFuzz notes this is not always true because some processors support delayed write-back for long-latency instructions. MorFuzz: Fuzzing Processor via Runtime Instruction Morphing enhanced Synchronizable Co-simulation
[3] MorFuzz abstracts state comparison into a commitment stage and a judgment stage to accommodate different microarchitectures. MorFuzz: Fuzzing Processor via Runtime Instruction Morphing enhanced Synchronizable Co-simulation
[4] MorFuzz synchronizes legal hardware-state mismatches to the simulator, reports illegal mismatches as potential bugs, can synchronize interrupts, and uses synchronization to avoid premature false positives. MorFuzz: Fuzzing Processor via Runtime Instruction Morphing enhanced Synchronizable Co-simulation
[5] MorFuzz uses Spike, the official RISC-V ISA simulator, as the reference model for checking DUT behavior. MorFuzz: Fuzzing Processor via Runtime Instruction Morphing enhanced Synchronizable Co-simulation
[6] MorFuzz restricts approved state synchronization to legal differences, including limiting triggering instructions to CSR and memory-operation instructions and requiring DUT control flow to pass the commitment-stage check. MorFuzz: Fuzzing Processor via Runtime Instruction Morphing enhanced Synchronizable Co-simulation
[7] MorFuzz maintains a morphing map so the reference model can perform the same morphing as the DUT and execute deterministic, identical morphed instructions. MorFuzz: Fuzzing Processor via Runtime Instruction Morphing enhanced Synchronizable Co-simulation