Overview

In the supplied evidence, co-simulation is a processor-verification technique in which an RTL processor core and a reference instruction-set simulator (ISS) are run together on the same generated program so that their behavior can be checked during execution. The same general idea — coupling two simulators and comparing their state — is also used outside the processor domain to study cyber-physical systems, for example coupling a power-system simulator with a communication-network simulator. [C1][C2]

In the processor-verification setting, two concrete instances of this technique are documented in the evidence:

1. A fuzzing-based case study on the open-source RISC-V VexRiscv core, which uses a SystemC testbench to compare the RTL core against a reference ISS extracted from the RISC-V VP virtual prototype.
2. The RISCV-DV instruction-generator framework, which is used in the verification flows of multiple RISC-V cores and compares register writebacks of the core under test against a reference ISS such as Spike.

Coverage-guided fuzzing case study (VexRiscv)

The main evidenced use is from Efficient Cross-Level Processor Verification using Coverage-guided Fuzzing. The case study uses the open-source RISC-V VexRiscv processor as the device under test (DUT). VexRiscv is described as a configurable, four-stage pipelined RTL core written in SpinalHDL; the evaluated configuration is RV32IM. [C1]

For the reference side of the co-simulation, the authors extracted an ISS from the open-source RISC-V VP, a SystemC TLM virtual prototype supporting many RISC-V instruction sets. To enable co-simulation, they translated the RTL core to C++ using Verilator and embedded it with the ISS into a common SystemC testbench. [C1]

The same work is cited in a Springer survey of RISC-V processor verification, where the figure caption explicitly notes "Used Cross-Level testing of both RTL core and reference ISS in co-simulation setting." [C3]

CSR-focused checking support

The fuzzing flow includes CSR instruction insertion and replacement to improve testing of RISC-V privileged-architecture behavior. Each CSR mutation adds two CSR instructions: the first writes a CSR, and the second reads the same CSR. The paper states that this propagates possible CSR misbehavior directly into a register, making it detectable by the Execution Controller. [C4]

Post-processing and bug triage

After fuzzing, the evidence describes a post-processing step for clustering failing test vectors. This step uses a custom version of the co-simulation that logs all executed instructions with their corresponding addresses. The logged co-simulation is not used for fuzzing because hard-disk writes make it slower, and it does not need the coverage instrumentation required during fuzzing. The post-processing then extracts the instruction that leads to the bug. [C5]

RISCV-DV: instruction-generator co-simulation

RISCV-DV is a SV/UVM-based open-source instruction generator for RISC-V processor verification. Generated instructions are executed by the core under test and simultaneously by a reference RISC-V ISS — for example Spike or Renode — and upon completion the core states of both are compared after each executed instruction in terms of register writebacks. The RISCV-DV overview explicitly lists "Co-simulation with multiple ISS: spike, riscv-ovpsim, whisper, sail-riscv" as a supported feature. [C6][C7]

Such a co-simulation setup has been employed in the verification workflow of many cores in the RISC-V ecosystem, including the CHIPS Alliance VeeR EL2 core as well as lowRISC's Ibex. [C6]

Related uses outside processor verification

The supplied evidence also describes co-simulation in adjacent domains. In FMI-based distributed co-simulation, multiple Functional Mock-up Units are coupled to enable collaborative modeling while protecting intellectual property, with the connection initiated by the client and the models and binaries residing on trusted platforms. [C8] In cyber-security analysis of energy management systems, a co-simulation platform couples the power-system simulator DIgSILENT PowerFactory with the communication-network simulator OMNeT++, together with Matlab-based EMS applications such as state estimation and optimal power flow, in order to assess vulnerability to data attacks. [C9]

Practical implications from the evidence

• Shared execution environment: the RTL core and ISS are embedded into a common SystemC testbench for co-simulation. [C1]
• RTL integration path: Verilator is used to translate the RTL core into C++ before embedding it in the SystemC testbench. [C1]
• Reference-model choice: the reference ISS can be extracted from RISC-V VP, or in RISCV-DV-based flows it can be Spike, riscv-ovpsim, whisper, sail-riscv, or Renode. [C1][C6][C7]
• Comparison granularity: RISCV-DV compares register writebacks of the core under test against the reference ISS after each executed instruction. [C6]
• Debug-oriented variants: a slower, logging-enabled co-simulation can be useful after fuzzing for clustering failing inputs and identifying the instruction associated with a bug. [C5]
• Adoption in open-source cores: the RISCV-DV co-simulation setup has been used in the verification of the VeeR EL2 and Ibex cores. [C6]
• Configuration effort: the Springer survey notes that the original cross-level testing setup required significant manual effort to create an appropriate co-simulation for different processor configurations. [C1]
• Cross-domain applicability: co-simulation is also used to couple heterogeneous simulators (e.g. power-system + network simulators) for cybersecurity or FMI-based distributed co-simulation scenarios. [C8][C9]