Spike
Spike is an open-source instruction-set simulator (ISS) for the RISC-V Instruction Set Architecture (ISA). It is developed and maintained under the RISC-V Foundation / RISC-V Software organization, and acts as a reference model of the RISC-V ISA. The official source repository is https://github.com/riscv-software-src/riscv-isa-sim.
Role and characteristics
Spike is described in the literature as one of the most widely used open-source ISSes for RISC-V. It supports the official RISC-V ISA extensions (including RV32/RV64 with M, A, F, D, C/G and others), as well as exceptions, interrupts, and a debugging mode for step-by-step program simulation. The simulator provides a platform for running RISC-V programs without requiring actual hardware and is commonly used for testing, simulating, and verifying the functionality of RISC-V processors.
ISSes such as Spike are not cycle-accurate; they work at the granularity of a single committed instruction. For this reason they are well suited as a reference model in functional verification of a core, where the architectural state (registers, memory) produced by the RTL design under test (DUT) must be compared against the reference ISS after each instruction.
Use as a golden reference in functional verification
Spike is used as the golden reference model in RISC-V core verification flows. Typical usage includes:
- Wrapping the ISS in a UVM or Python cocotb testbench and comparing register and memory state after every committed instruction against the DUT.
- Parsing Spike's output to extract the data-memory transactions that the predictor components then push to the scoreboard.
- Using Spike's exit signal (the monitor checks for a write to a particular address with a predetermined value, e.g. address
0x20008written with value1) to drop the UVM objection and end the simulation.
Co-simulation with RISCV-DV
The CHIPS Alliance / Google RISCV-DV framework is a SystemVerilog/UVM instruction generator for RISC-V processor verification. RISCV-DV supports co-simulation with multiple ISSes; the list explicitly enumerated in its documentation includes spike, riscv-ovpsim, whisper, and sail-riscv.
The co-simulation model used by RISCV-DV and described in the SV Tools Project article works as follows: the generated instructions are executed by the core under test and simultaneously by a reference RISC-V ISS such as Spike (or Renode). After each executed instruction, the architectural state of the core and the ISS are compared in terms of register writebacks. Such a co-simulation setup is used in the verification of RISC-V ecosystem cores such as the CHIPS Alliance VeeR EL2 core and lowRISC's Ibex.
ISS verification via coverage-guided fuzzing
Spike has also been a subject of ISS verification itself. In Verifying Instruction Set Simulators using Coverage-guided Fuzzing, Spike was one of three publicly available RISC-V ISSs included in the case study. The paper applied coverage-guided fuzzing (built on LLVM's libFuzzer) to ISS verification, complementing code coverage with a functional coverage metric tailored to instruction-set semantics.
In that study, the coverage-guided fuzzing run was reported to find a Spike issue labeled S1, while the RISC-V ISA tests and RISC-V Torture test generators were reported as finding no Spike issues in the same evaluation table. The reported coverage-guided fuzzing run took 32,492 seconds and reached 100% branch coverage along with 100% in the R1, R2, and R3 functional coverage columns shown in the table; it also triggered all seven injected/tracked ISS-under-test errors [V1..V7], the S1 Spike issue, and the Forvis issues H1,H2.
See also
- RISC-V instruction-set architecture
- Instruction-set simulation (ISS)
- Coverage-guided fuzzing
- RISCV-DV