Skip to content
STIMSMITH

checkpoint

Concept

In Dromajo-based RISC-V verification, a checkpoint is a saved processor state, represented as memory and bootrom images, that can be generated during fast software execution and later loaded for deterministic RTL/Dromajo co-simulation.

First seen 5/27/2026
Last seen 5/28/2026
Evidence 5 chunks
Wiki v2

WIKI

Definition

In the Dromajo RISC-V verification flow, a checkpoint is a saved execution state used to start hardware/software co-simulation from a known point. Dromajo can execute RISC-V applications, including benchmarks running on Linux, in fast software simulation and generate checkpoints after a given number of cycles; those checkpoints can then be resumed for HW/SW co-simulation.

Contents and representation

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

5 connections
The paper uses Dromajo checkpoints to enable efficient co-simulation of long-running programs.
Dromajo ← implements 100% 2e
Dromajo implements checkpoint generation and restoration for co-simulation.
Architectural State uses → 100% 2e
Checkpoints capture the processor's architectural state for later restoration.
Dromajo ← uses 100% 2e
Dromajo supports checkpoint generation and resumption for co-simulation.
phase analysis uses → 85% 1e
Checkpoints can leverage phase analysis to identify representative simulation points.

CITATIONS

9 sources
9 citations — click to expand
[1] Dromajo can execute RISC-V applications in fast software simulation, generate checkpoints after a given number of cycles, and resume them for HW/SW co-simulation. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...
[2] Dromajo checkpoints include processor architectural state, memory, PLIC/CLINT interrupt reprogramming state, and performance counters such as cycle and instruction counts. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...
[3] Dromajo checkpoints consist of memory and bootrom images, and the bootrom is a valid RISC-V program that leverages the RISC-V debug specification to change supervisor registers. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...
[4] The Dromajo verification flow is divided into checkpoint generation and co-simulation; generation accepts a RISC-V ELF, runs Dromajo stand-alone, and dumps state, while co-simulation loads the checkpoint into both Dromajo and RTL memory. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...
[5] Dromajo integration can use DPI wrappers including cosim_init, step, and raise_interrupt; the configuration file contains a checkpoint path and core-specific information such as a memory map. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...
[6] Checkpoint-based co-simulation provides portable stimulus, avoids benchmark recompilation, can split the Linux boot sequence into checkpoints, supports phase analysis and simulation points, and can run long-running programs in parallel. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...
[7] Using DTM to load binaries can lead to nondeterministic architectural state and false-positive co-simulation mismatches, while Dromajo memory-and-bootrom checkpoints make DTM unnecessary and speed simulation. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...
[8] Using Dromajo checkpointed infrastructure produced fully deterministic architectural state in the evaluated cores. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...
[9] A limitation of checkpoint-based co-simulation is that branch predictor tables are not part of the architectural state captured by the checkpoint. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...