Co-Simulation
ConceptCo-simulation is the coordinated simulation of two or more instances of a design (or related designs) so that their observable states can be compared against a shared specification. In hardware verification, it is used to check an RTL implementation against a golden reference model (often an Instruction Set Simulator), with mismatches indicating non-compliance with the specification. The cited evidence shows co-simulation applied in RISC-V processor verification (ZP Cosim with Dromajo against BlackParrot), in symbolic-execution RTL/ISS checking (MicroRV32 vs. RISC-V VP ISS via KLEE, with 10 RTL bugs and 2 ISS errors discovered), and in cyber-security co-simulation testbeds for the smart grid.
First seen 5/25/2026
Last seen 7/18/2026
Evidence 70 chunks
Wiki v15
WIKI
Co-Simulation
Overview
Co-simulation is the coordinated use of multiple simulation components or models so that their behaviors can be combined or compared. In the cited ZP Cosim thesis it is defined as the process of simulating two (or more) instances of the same design with, generally, the same inputs: the expectation is that, if both instances are compliant with a formalized specification, the observable states at architecturally visible event boundaries (e.g., instruction retirements, CSR updates) will match within reason, and deviations will indicate one or both instances are not specification-compliant.
NEIGHBORHOOD
No graph connections found for this entity yet. It may appear in future ingestion runs.
explore full graph →RELATIONSHIPS
46 connections Cross-level processor verification via endless randomized instruction stream generation with coverage-guided aging ← uses 100% 11e
The paper leverages ISS and RTL in a tight co-simulation setting.
The co-simulation integrates an ISS as a reference model alongside the RTL processor.
Cross-level processor verification uses co-simulation between ISS and RTL.
Dromajo provides APIs for cosimulation
The paper integrates the ISS and RTL processor in a co-simulation setting.
The paper uses co-simulation as a central verification technique.
RISCV-DV supports co-simulation with multiple ISS
RISC-V DV leverages co-simulation with an ISS as reference model.
ZP Cosim implements cosimulation between a golden reference model and the processor under test
DiffTest is a co-simulation framework for processor verification.
The paper employs co-simulation methodology using Spike as a reference model.
MorFuzz implements a synchronizable co-simulation framework.
The verification approach employs co-simulation with the Spike ISS to check design correctness.
Synchronizable co-simulation is a specific implementation of co-simulation that handles implementation differences.
Co-simulation combines ISS with the RTL processor core for comparison.
The co-simulation contains symbolic memory as part of its structure.
The co-simulation contains an instruction stream component.
The co-simulation contains a symbolic execution interface.
The co-simulation integrates RTL processor implementations for verification.
The UVM environment performs step-by-step co-simulation of all vector instructions.
The UVM environment performs step-by-step co-simulation of all vector instructions with Spike.
Cosimulation uses a golden reference model to compare execution traces
DiffTest-H is a hardware-accelerated co-simulation framework.
The Comparator works within a co-simulation setting to compare ISS and RTL core register values.
The UVM testbench performs co-simulation of vector instructions against Spike.
Co-simulation relies on a reference model to compare DUT outputs.
Google DV framework employs co-simulation with an ISS.
The Comparator compares register values between the ISS and RTL-Core in the co-simulation setup.
Co-simulation compares the DUT against the golden model.
Co-simulation runs the design-under-test in parallel with a reference model.
Co-simulation compares the architectural state of the DUT and the model.
Co-simulation in RISCV-DV uses spike as one of the supported ISS tools.
Co-simulation in RISCV-DV uses riscv-ovpsim as one of the supported ISS tools.
Co-simulation in RISCV-DV uses whisper as one of the supported ISS tools.
Co-simulation in RISCV-DV uses sail-riscv as one of the supported ISS tools.
Whisper is an ISS developed by Western Digital that can be used for co-simulation.
Ibex verification employs a co-simulation methodology.
The Comparator is used to find functional differences between RTL-Core and ISS.
The Core-Adapter is used in the co-simulation to handle micro-architectural differences.
Simulation-based verification leverages co-simulation with ISS as a reference model.
The verification environment performs co-simulation of vector instructions.
vpu-dv performs co-simulation between ISS and DUT.
The Core-UVM environment uses co-simulation with Spike to check design correctness.
The co-simulation includes a voter to detect mismatches.
The co-simulation contains an execution controller for runtime limitations.
ExactStep is designed for use as a library for cosimulation.
CITATIONS
20 sources20 citations — click to expand
[1] Co-simulation is defined in the ZP Cosim thesis as the process of simulating two or more instances of the same design with the same inputs, comparing observable states at architecturally visible event boundaries such as instruction retirements and CSR updates. Co-Simulation (previous wiki, version 14)
[2] ZP Cosim treats Dromajo as the golden reference model and pairs it with BlackParrot instantiated under Verilator, Synopsys VCS, or FPGA emulation, with a control program feeding the executable program binary and parameters to both instances. Co-Simulation (previous wiki, version 14)
[3] Dromajo's trace comparison in ZP Cosim compares the retired instruction word, written registers/important CSRs, and the program counter; asynchronous events are manually overridden in Dromajo and comparison is done in 'almost' real time. Co-Simulation (previous wiki, version 14)
[4] ZP Cosim reduces cross-product coverage state-space to ⌈N/G⌉ · 2^G by grouping coverpoints and crossing only within groups. Co-Simulation (previous wiki, version 14)
[5] Dromajo is a formally proven RISC-V RV64GC functional reference model / multi-CPU simulator in C++ with memory/IO mapping, bootrom, custom-extension support, and checkpoint snapshot APIs used by ZP Cosim for co-simulation. Co-Simulation (previous wiki, version 14)
[6] The symbolic-execution RISC-V case study uses MicroRV32 as the DUT and the RISC-V VP ISS as the reference implementation, with instruction set RV32I+CSR, on a Linux server with an Intel Xeon Gold 6240 CPU. Processor Verification using Symbolic Execution - AGRA | Uni Bremen
[7] MicroRV32 had previously been extensively tested using constrained random techniques and also verified with the RISC-V formal tool using a Bounded Model Checking approach; the broader symbolic-execution co-simulation evaluation required more than 30 days of runtime. Processor Verification using Symbolic Execution - AGRA | Uni Bremen
[8] The symbolic-verification methodology revealed 10 bugs in the well-tested RTL core MicroRV32 and found 2 errors in the reference ISS, demonstrating the applicability of symbolic execution in full-scale processor co-simulation. Processor Verification using Symbolic Execution - AGRA | Uni Bremen
[9] An error-injection methodology defined 10 errors E0–E9 covering a broad range of RTL functionality; experiments used a 24-hour per-run limit, the co-simulation was configured for RV32I, and assumptions were added to block CSR instructions to filter known implementation mismatches. Processor Verification using Symbolic Execution - AGRA | Uni Bremen
[10] All injected errors E0–E9 were found very quickly regardless of instruction limit (1 or 2); with instruction limit 1, runs executed between 2,239,208 and 12,367,140 instructions and needed between 54 s and 3,237 s. Processor Verification using Symbolic Execution - AGRA | Uni Bremen
[11] Aggregated error-injection totals across all 10 injected errors were 53,283,172 / 88,712,782 instructions executed, 9,685 / 37,201 partial KLEE paths, 758 / 7,618 completed paths, and 166 / 57 seconds median-find times for instruction limits 1 / 2 respectively (medians 4,237,517 instructions and 543 partial paths vs. 4,560,215 instructions and 790 partial paths). Processor Verification using Symbolic Execution - AGRA | Uni Bremen
[12] Injected fault E9 causes the LW instruction to load only the lower 16 bits from memory instead of a 32-bit value, and was detected by the co-simulation. Processor Verification using Symbolic Execution - AGRA | Uni Bremen
[13] RV32I misaligned load/store instructions (LW, LH, LHU, SW, SH, SHU) produce an implementation mismatch (M) because the MicroRV32 RTL core fully supports misaligned accesses while the ISS does not, despite both being valid per the RISC-V ISA. Processor Verification using Symbolic Execution - AGRA | Uni Bremen
[14] The ISS and RTL cycle/instruction counters (mcycle, minstret, mcycleh, minstreth) differ only as a mismatch (M) because the ISS is non-cycle-accurate; the ISS additionally implements cycle, cycleh, instret, instreth, time, timeh, mhpmcounter3-31, mhpmcounter3-31h, while the RTL does not implement mhpmevent3-31, mscratch, or mcounteren — all reported as implementation mismatches (M). Processor Verification using Symbolic Execution - AGRA | Uni Bremen
[15] A voter compares RTL and ISS execution results (PC, old PC, target-register value) and aborts on mismatch; if no mismatch is found, the simulation terminates when an instruction limit or clock-cycle limit is reached and the model is cleaned up. Processor Verification using Symbolic Execution - AGRA | Uni Bremen
[16] Future work plans hybrid symbolic-execution + fuzzing techniques for scalable, comprehensive verification, plus induction-based symbolic constraints to enable complete (non-BMC-bounded) processor verification. Processor Verification using Symbolic Execution - AGRA | Uni Bremen
[17] The symbolic-execution MicroRV32 co-simulation work was supported by BMBF projects Scale4Edge (16ME0127), VerSys (01IW1900), and ECXL (01IW22002). Processor Verification using Symbolic Execution - AGRA | Uni Bremen
[18] ExactStep is an instruction-accurate multi-target ISS (RISC-V RV32IMAC/RV64IMAC, MIPS mips-i, ARM-v6m) designed to be used as a library for co-simulation, peripherals, and System-C bus interfacing, executing one instruction per cpu::step() call. Co-Simulation (previous wiki, version 14)
[19] Distributed FMI-based co-simulation enables collaborative modeling by different stakeholders while implicitly protecting intellectual property; the cited UniFMU-based approach adds cybersecurity/IP-protection mechanisms (client-initiated connections, trusted platforms) and trades off IP-protected distribution against performance across four network settings. FMI-Based Distributed Co-Simulation with Enhanced Security and Intellectual Property Safeguards
[20] A co-simulation platform couples DIgSILENT PowerFactory, OMNeT++, and Matlab EMS applications to simulate data attacks against an energy-management system and assess its vulnerability to data attacks. Co-simulation for Cyber Security Analysis: Data Attacks against Energy Management System