Definition
Architectural state is the programmer-visible view of a machine used by instruction-set simulators and other functional models. In the cited description of ISS-based modeling, this view is expressed in terms of the contents of registers and memories, and instruction execution is modeled as a transition from one stable architectural state to another stable architectural state. This abstraction intentionally omits microarchitectural details such as pipeline structure, branch prediction, parallel execution, and multi-cycle internal behavior.
Architectural state in functional verification
Because functional models represent architectural state rather than microarchitectural mechanisms, they are suitable reference models for checking whether an HDL implementation exhibits the same externally visible behavior on instruction sequences. The cited verification discussion describes comparing the HDL model against a functional simulator on generated assembler tests, with the simulator providing the architectural reference behavior.
Architectural state in Dromajo checkpoints
In the cited RISC-V co-simulation flow, Dromajo checkpoints include processor architectural state, specifically registers and CSRs. The same checkpoint also includes memory, interrupt-related state (PLIC/CLINT), and performance counters such as cycle count and executed-instruction count. Dromajo defines a checkpoint as a snapshot taken after executing some number of instructions, and it can later resume execution from that snapshot for hardware/software co-simulation.
The paper further states that Dromajo checkpoints consist of two parts: a memory image and a bootrom image. During checkpoint generation, Dromajo runs stand-alone for some amount of time and then dumps the model's whole architectural state to a checkpoint.
Role in checkpoint-based co-simulation
In the described step-and-compare flow, the checkpoint is loaded into both the Dromajo model and the RTL system memory before simulation. After the boot code completes, both cores have identical architectural states. In that sense, architectural state is the comparison boundary that allows the reference model and the RTL design to begin co-simulation from the same architecturally visible point.
The cited workflow also notes a limitation: checkpoint-based co-simulation does not preserve branch predictor tables, which are microarchitectural rather than architectural state.
Determinism in the cited RISC-V flow
The cited evaluation reports that using the Debug Transport Module (DTM) to load binaries and generate artificial system calls could bring the core into a nondeterministic architectural state, causing false-positive co-simulation mismatches. The authors state that Dromajo's memory and bootrom checkpoints make DTM unnecessary in that setup, and that using the checkpointed infrastructure produced a fully deterministic architectural state in the evaluated cores.
Practical significance
Treating architectural state as a checkpointable, portable execution boundary improves verification productivity in the cited flow. Dromajo can run long workloads quickly in software simulation, emit multiple checkpoints, and then use those checkpoints to start parallel co-simulations. The paper gives Linux boot and SPEC-style benchmark phases as examples where this is useful.