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

A Dromajo checkpoint includes the processor architectural state, such as registers and CSRs, along with memory, interrupt reprogramming state for PLIC/CLINT, and performance-counter state such as cycle and instruction counts.

Dromajo represents a checkpoint with two parts:

• a memory image;
• a bootrom image.

The bootrom is a valid RISC-V program. It uses the RISC-V debug specification to change supervisor registers, which lets Dromajo-created checkpoints be shared across different RV64 CPUs that support the debug specification, without changing initialization beyond loading the appropriate memory and bootrom.

Role in a Dromajo verification flow

The flow described for Dromajo is divided into two parts: checkpoint generation and co-simulation.

During checkpoint generation, Dromajo accepts a RISC-V ELF binary, runs stand-alone for a selected amount of time, and dumps the model's architectural state to a checkpoint. During co-simulation, the checkpoint is loaded into both the Dromajo model and the RTL model's main memory. Once the boot code completes, the two cores have identical architectural states.

In the DPI-based integration described in the MICRO-54 work, Dromajo is compiled as a shared library and linked to a simulator. A cosim_init() wrapper initializes Dromajo from a configuration file that includes the path to a checkpoint and core-specific information such as the memory map. A step() wrapper is called when the RTL commits a valid instruction; Dromajo then commits one instruction on its side and compares the communicated program counter, instruction, and store data. A raise_interrupt() wrapper is used to force Dromajo to follow the RTL when the core takes an asynchronous interrupt.

Uses and benefits

Checkpoint-based co-simulation provides portable stimulus and improves verification productivity by avoiding benchmark recompilation. One described use is splitting the Linux boot sequence into several checkpoints to speed verification.

Checkpoints also enable phase-oriented workflows: the cited work notes that phase analysis and simulation points can be used to capture important program phases in a portable format, allowing workloads such as SPEC benchmarks to be co-simulated by loading simulation points that represent different phases. Long-running programs can also be checkpointed and run in parallel to reduce simulation cost.

Determinism compared with DTM loading

The cited work identifies deterministic simulation infrastructure as a prerequisite for co-simulation. It reports that using a Debug Transport Module (DTM) to load binaries into RTL and generate artificial system calls brought the core into nondeterministic architectural states and caused false-positive co-simulation mismatches. Dromajo supports DTM, but its memory-and-bootrom checkpoint infrastructure avoids DTM usage, removes the time spent uploading binaries, and produced fully deterministic architectural state in the evaluated cores.

Limitation

The cited work notes one disadvantage of checkpoint-based co-simulation: branch predictor tables are not part of the architectural state captured by the checkpoint.