Architectural State

Concept

Architectural state is the processor state visible at the instruction-set architecture (ISA) or programmer level. Across RISC-V verification evidence it includes the program counter, general-purpose registers, control and status registers, and relevant memory contents. It serves as the comparison boundary in retirement-level lockstep co-simulation, including XiangShan's difftest framework that checks state against golden reference models (NEMU, Spike) at commit boundaries, and as the equivalence criterion in EPEX, where instructions and programs are equivalent when they transform the same starting architectural state into the same successor architectural state.

First seen 5/26/2026

Last seen 7/11/2026

Evidence 19 chunks

Wiki v7

WIKI

Definition

Architectural state is the processor state visible at the instruction-set architecture (ISA) or programmer level. In the RISC-V verification evidence, this state includes the program counter (PC), general-purpose registers (GPRs), control and status registers (CSRs), and memory contents relevant to execution. [C1]

At instruction retirement, an instruction has completed execution and its results have been committed to architectural state. Retirement is therefore a natural observation point for checking architecturally visible behavior rather than transient implementation behavior. [C2]

READ FULL ARTICLE →

NEIGHBORHOOD

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

explore full graph →

RELATIONSHIPS

17 connections

Difftest ← uses 97% 2e

Difftest compares architectural state at commit points to detect discrepancies.

Mapping Function uses → 100% 2e

Mapping functions link the implementation state to the architectural state of the processor.

EPEX ← uses 100% 2e

EPEX compares architectural states of two processor instances executing equivalent programs.

Instruction Set Architecture part of → 95% 2e

The architectural state is a key component of the ISA description.

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.

program counter ← part of 100% 2e

The program counter (PC) is part of the architectural state visible at the ISA level.

Architectural Style Properties part of → 100% 2e

Architectural style properties require explicit modeling 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.

Control and Status Registers ← part of 97% 1e

Control and status registers (CSRs) are part of the architectural state visible at the ISA level.

Design Under Verification ← uses 100% 1e

The state of the DUV is described using the architectural state abstraction.

Equivalent Program Execution ← uses 100% 1e

Equivalent Program Execution compares architectural states after executing equivalent programs.

Operation Property ← uses 100% 1e

Operation properties describe changes to the architectural state when instructions execute.

Lockstep Co-Simulation Methodology ← uses 97% 1e

Architectural state is captured and compared at each retire event in the lockstep methodology.

general purpose registers ← part of 97% 1e

General-purpose registers (GPRs) are part of the architectural state visible at the ISA level.

LINKED ENTITIES

1 links

Difftest USES Extracted graph relationship

CITATIONS

13 sources

13 citations — click to expand

[1] Architectural state is the processor state visible at the ISA level, including program counter (PC), general-purpose registers (GPRs), control and status registers (CSRs), and memory contents relevant to execution. RISC-V Lockstep Co-Simulation: Retirement-Level Step-and-Compare for Faster Verification & Debug

[2] An instruction is considered retired once its results are committed to architectural state. RISC-V Lockstep Co-Simulation: Retirement-Level Step-and-Compare for Faster Verification & Debug

[3] In retirement-level lockstep co-simulation, the RTL and reference model run the same program in parallel and architectural state is captured and compared at each retire, with mismatch reporting including the retire index and expected versus actual values. RISC-V Lockstep Co-Simulation: Retirement-Level Step-and-Compare for Faster Verification & Debug

[4] Because comparison is performed at retirement rather than against transient pipeline states, debug focuses on architecturally visible behavior and avoids false positives. RISC-V Lockstep Co-Simulation: Retirement-Level Step-and-Compare for Faster Verification & Debug

[5] The compared architectural state subset is configurable: flows typically start with PC-only checks, then PC plus GPRs, then add CSRs for privilege and exception behavior, and finally compare selected memory regions or the complete architectural state. RISC-V Lockstep Co-Simulation: Retirement-Level Step-and-Compare for Faster Verification & Debug

[6] XiangShan's difftest framework runs the design under test in lockstep with a golden reference model, comparing architectural state at commit points to detect discrepancies. Difftest and Co-Simulation | OpenXiangShan/XiangShan | DeepWiki

[7] NEMU is the primary golden reference model in XiangShan verification, supporting all privilege modes (M/H/S/U) and virtual memory with native checkpoint/restore via .zstd or .gz files. Difftest and Co-Simulation | OpenXiangShan/XiangShan | DeepWiki

[8] Spike is the alternative golden reference model maintained by RISC-V International and can be selected via the --spike flag. Difftest and Co-Simulation | OpenXiangShan/XiangShan | DeepWiki

[9] The difftest interface exports architectural state (PC, GPRs, FPRs, vector registers), CSRs (machine, supervisor, hypervisor), memory operations, and exceptions for comprehensive verification. Difftest and Co-Simulation | OpenXiangShan/XiangShan | DeepWiki

[10] The difftest interface is checked during CI using difftest/scripts/st_tools/interface.py to ensure SimTop.sv matches the expected difftest-interface.sv. Difftest and Co-Simulation | OpenXiangShan/XiangShan | DeepWiki

[11] Difftest provides cycle-accurate validation of architectural state, detection of implementation bugs, and automated regression testing across workloads, supporting Verilator and VCS simulation backends and integrating with NEMU and Spike. Difftest and Co-Simulation | OpenXiangShan/XiangShan | DeepWiki

[12] EPEX defines processing an instruction as transforming an architectural state s (the state visible to the programmer) into a new architectural state s'. EPEX: Processor Verification by Equivalent Program Execution

[13] EPEX uses a formal ISA model and SMT-based automated reasoning to synthesize programs equivalent on architectural states, transforming P into P̂ by finding different instructions that produce the same successor architectural state from the same starting state. EPEX: Processor Verification by Equivalent Program Execution