Skip to content
STIMSMITH

Bootrom Preloading

Concept WIKI v1 · 6/18/2026

A modification to the Spike RISC-V instruction set simulator that allows a boot ROM image to be preloaded from an .elf file, enabling Spike to be used as a flexible reference model across different verification environments and SoC designs.

Overview

Bootrom preloading is a capability added to the RISC-V Spike instruction set simulator (ISS) that allows the simulator to be initialized with a boot ROM image loaded directly from an .elf file. The feature was introduced as part of adapting Spike for use as a reference model in the UVM-based verification of a multi-core RISC-V system.

Motivation

In a subsystem-level UVM verification environment, the reference model must mirror, as closely as possible, the boot-time state and instruction sequence of the design under test (DUT). A standard upstream Spike build assumes a particular boot flow that does not always match the boot ROM contents used by a given design. To reuse Spike across multiple cores and SoC configurations without having to maintain separate simulation harnesses, the verification team needed a way to swap in the design's actual boot ROM.

Implementation in Spike

The Spike simulator was extended with a hook that:

  1. Accepts an .elf file as an additional input.
  2. Treats that .elf as the boot ROM image.
  3. Loads the contents into the simulator's memory at the addresses described by the .elf program headers before normal instruction execution begins.

According to the source material, "We also modified it to allow the preloading of a bootrom from an .elf file. This provides us the flexibility we need to use Spike with different environments and designs." This modification sits alongside other Spike adaptations used in the flow, including:

  • A core_type configuration flag (core_type=Standard tracks vanilla ISA and upstream Spike behavior).
  • SystemVerilog DPI calls invoked at every committed instruction so the UVM environment can step Spike in lock-step with the DUT.
  • DPI calls to force results into Spike (to compensate for known floating-point rounding differences and HPM counter values).
  • DPI calls to toggle the external interrupt signal and to perform silent TLB walks (used to model VIPT caches in core-uvm).

Use in Multi-Core Verification

Bootrom preloading is exercised by the same test infrastructure described in the verification paper:

  • Regression suites composed of riscv-isa-tests, riscv-arch-tests (formerly compliance), internal RVV ISA tests, and directed UVM tests for JTAG and DMA interfaces.
  • Random instruction streams (built with riscv-dv), including basic scalar tests, basic vector tests emphasizing vector instructions and memory operations, and atomic-instruction stress tests that randomize atomic operations.
  • Multi-binary runs that combine several randomly generated programs in a single simulation, where exception and interrupt behavior causes divergent dynamic instruction counts even when the static instruction counts are similar.

The bootrom preload capability allows Spike to start executing from the same initial image as the DUT in every one of these scenarios, which is essential for keeping the step-by-step DPI-driven comparison between the reference model and the RTL coherent from the very first instruction.

Related Concepts

  • Spike ISS — the upstream RISC-V instruction set simulator that was extended with the bootrom preload capability.
  • Verification of a RISC-V system with multiple cores — the paper that documents the modified Spike, the DPI-based reference-model integration, and the multi-core verification flow that relies on bootrom preloading.

CITATIONS

4 sources
4 citations
[1] Spike was modified to allow the preloading of a bootrom from an .elf file. Verification of a RISC-V system with multiple cores
[2] The bootrom preloading modification gives Spike the flexibility to be used with different environments and designs. Verification of a RISC-V system with multiple cores
[3] Bootrom preloading is part of a broader set of Spike adaptations used as a UVM reference model, including a core_type configuration flag, DPI calls to step the simulator per committed instruction, DPI calls to force values, interrupt toggling, and silent TLB walks. Verification of a RISC-V system with multiple cores
[4] The verification flow that uses bootrom preloading combines riscv-isa-tests, riscv-arch-tests, internal RVV tests, UVM directed tests for JTAG and DMA, and randomized riscv-dv-generated tests, and supports multi-binary runs. Verification of a RISC-V system with multiple cores