Skip to content
STIMSMITH

Architectural state

Concept

Architectural state is the programmer-visible machine state used by instruction-set-level models: the contents of registers and memories, with each instruction viewed as transforming one stable architectural state into another. In the cited RISC-V verification flow, Dromajo checkpoints capture processor architectural state such as registers and CSRs and use it as the alignment point for checkpoint-based co-simulation.

First seen 5/26/2026
Last seen 5/31/2026
Evidence 10 chunks
Wiki v4

WIKI

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

READ FULL ARTICLE →

NEIGHBORHOOD

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

explore full graph →

RELATIONSHIPS

11 connections
Architectural Style Properties part of → 100% 2e
Architectural style properties require explicit modeling of the architectural state.
Mapping Function uses → 100% 2e
Mapping functions link the implementation state to the architectural state of the processor.
Instruction Set Architecture part of → 95% 2e
The architectural state is a key component of the ISA description.
Register File ← part of 100% 2e
The register file is a component of the architectural state.
Dromajo ← uses 100% 2e
Dromajo checkpoints include the processor architectural state including registers and CSRs.
Architectural Style Properties ← uses 100% 2e
Architectural style properties are defined in terms of the architectural state.
checkpoint ← uses 100% 2e
Checkpoints capture the processor's architectural state for later restoration.
Co-simulation ← uses 100% 1e
Co-simulation compares the architectural state of the DUT and the model.
program counter ← part of 100% 1e
The program counter is a component of the architectural state.
Design Under Verification ← uses 100% 1e
The state of the DUV is described using the architectural state abstraction.
Operation Property ← uses 100% 1e
Operation properties describe changes to the architectural state when instructions execute.

CITATIONS

12 sources
12 citations — click to expand
[1] Architectural state in ISS-style functional models is the programmer-visible machine state, described as contents of registers and memories; an instruction changes one stable architectural state into another, without modeling parallel execution or multi-cycle microarchitectural behavior. Fabrice.Baray,Henri.Michel
[2] Functional verification compares an HDL model against a functional simulator on generated assembler sequences, using the simulator as the reference for behavior. Fabrice.Baray,Henri.Michel
[3] Dromajo is an emulator for co-simulation with RTL processors implementing RISC-V RV64GC; it can execute applications, generate checkpoints, and resume them for hardware/software co-simulation. Effective Processor Verification with Logic Fuzzer Enhanced Co-simulation
[4] Dromajo defines a checkpoint as a snapshot of the processor's architectural state taken after executing a certain amount of instructions. Effective Processor Verification with Logic Fuzzer Enhanced Co-simulation
[5] Dromajo checkpoints include processor architectural state such as registers and CSRs, as well as memory, PLIC/CLINT interrupt state, and performance counters including cycle and executed-instruction counts. Effective Processor Verification with Logic Fuzzer Enhanced Co-simulation
[6] Dromajo checkpoints consist of two parts: a memory image and a bootrom image. Effective Processor Verification with Logic Fuzzer Enhanced Co-simulation
[7] In checkpoint generation, Dromajo runs stand-alone for some amount of time and then dumps the model's whole architectural state to a checkpoint. Effective Processor Verification with Logic Fuzzer Enhanced Co-simulation
[8] In the step-and-compare flow, the checkpoint is loaded into both models' main memories and, once boot code completes, both cores have identical architectural states. Effective Processor Verification with Logic Fuzzer Enhanced Co-simulation
[9] Checkpoint-based co-simulation does not preserve branch predictor tables, indicating those are outside the architectural state captured by the checkpoint. Effective Processor Verification with Logic Fuzzer Enhanced Co-simulation
[10] Using DTM to load binaries and generate artificial system calls could bring the core into a nondeterministic architectural state and cause false-positive co-simulation mismatches. Effective Processor Verification with Logic Fuzzer Enhanced Co-simulation
[11] Dromajo's memory and bootrom checkpoints make DTM unnecessary in that setup, and the checkpointed infrastructure provided a fully deterministic architectural state in the evaluated cores. Effective Processor Verification with Logic Fuzzer Enhanced Co-simulation
[12] Checkpointing improves verification productivity by allowing long-running programs to be checkpointed and run in parallel; the cited paper mentions Linux boot splitting and SPEC benchmark phases as examples. Effective Processor Verification with Logic Fuzzer Enhanced Co-simulation