Architectural State
ConceptArchitectural state is the processor state visible at the instruction-set architecture (ISA) or programmer level, comprising the program counter, general-purpose registers, floating-point and vector registers, control and status registers, and memory contents relevant to execution. It is the boundary captured and compared at instruction retirement in retirement-level lockstep co-simulation, the equivalence criterion in equivalence-synthesizing tools such as EPEX, the continuous checking target in commercial flows such as ImperasDV via the RVVI-TRACE interface, and the architectural-state comparison preserved by hardware-accelerated co-simulation frameworks such as DiffTest-H.
First seen 5/26/2026
Last seen 8/26/2026
Evidence 25 chunks
Wiki v11
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), floating-point registers (FPRs), vector registers, control and status registers (CSRs), and memory contents relevant to execution. [C1] [C10]
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]
NEIGHBORHOOD
No graph connections found for this entity yet. It may appear in future ingestion runs.
explore full graph →RELATIONSHIPS
23 connectionsThe architectural state is a key component of the ISA description.
The register file is a component of the architectural state.
Dromajo checkpoints include the processor architectural state including registers and CSRs.
Architectural style properties are defined in terms of the architectural state.
Checkpoints capture the processor's architectural state for later restoration.
EPEX compares architectural states of two processor instances executing equivalent programs.
The program counter (PC) is part of the architectural state visible at the ISA level.
Difftest compares architectural state at commit points to detect discrepancies.
Mapping functions link the implementation state to the architectural state of the processor.
Architectural style properties require explicit modeling of the architectural state.
General-purpose registers (GPRs) are part of the architectural state visible at the ISA level.
Control and status registers (CSRs) are part of the architectural state visible at the ISA level.
Retirement-Level Lockstep captures and compares architectural state at each retire event.
Step-and-Compare Methodology uses architectural state captured at each retire step for comparison.
Co-simulation compares the architectural state of the DUT and the model.
Equivalent Program Execution compares architectural states after executing equivalent programs.
The state of the DUV is described using the architectural state abstraction.
Operation properties describe changes to the architectural state when instructions execute.
Co-simulation compares architectural states of DUT and REF after each instruction.
ImperasDV provides continuous comparison and checking of architectural state via the RVVI-TRACE interface.
Lockstep simulation compares architectural state tuples (PC, registers, memory, CSRs) at every instruction commit.
Pipeline hazard conditions are architectural behaviors that are tracked as part of the architectural state verification.
Architectural state is captured and compared at each retire event in the lockstep methodology.
CITATIONS
14 sources14 citations — click to expand
[1] Architectural state at the ISA level comprises the program counter, general-purpose registers, floating-point registers, vector registers, control and status registers, and memory contents relevant to execution. RISC-V Lockstep Co-Simulation: Retirement Step-and-Compare
[2] Instruction retirement is the natural observation point at which results have been committed to architectural state. RISC-V Lockstep Co-Simulation: Retirement Step-and-Compare
[3] In retirement-level lockstep co-simulation, RTL and reference model states are captured and compared at each retire event, with mismatches reported with the retire index and expected-versus-actual values. RISC-V Lockstep Co-Simulation: Retirement Step-and-Compare
[4] Comparing architectural state at retirement avoids false positives from transient pipeline states and focuses debug on architecturally visible behavior. RISC-V Lockstep Co-Simulation: Retirement Step-and-Compare
[5] Step-and-Compare is a methodology where RTL and reference-model states are captured and compared at each retire step, with asynchronous events injected at arbitrary retire points to stress the design reproducibly. RISC-V Lockstep Co-Simulation: Retirement Step-and-Compare
[6] Lockstep flows provide a configurable state mask that can start from PC-only checks and expand to include GPRs, CSRs, selected memory regions, or the complete architectural state for sign-off confidence. RISC-V Lockstep Co-Simulation: Retirement Step-and-Compare
[7] Unlike trace-based flows or self-checking tests, lockstep comparison flags the first divergent instruction rather than surfacing problems at the end of a test run, accelerating debugging and exposing CSR side effects, privilege transitions, and ordering errors. RISC-V Lockstep Co-Simulation: Retirement Step-and-Compare
[8] Functional-faithfulness co-simulation frameworks such as SupeRFIVe and UVM-TLM perform batch comparison of state tuples (program counter, registers, memory, CSRs) per commit event and halt immediately on any bit-wise discrepancy. Functional Faithfulness Verification
[9] XiangShan difftest compares architectural state at commit points between the DUT and a golden reference model, supporting NEMU and Spike as reference models. XiangShan difftest documentation
[10] The difftest interface exports architectural state (PC, GPRs, FPRs, vector registers), CSRs, memory operations, and exceptions for verification. XiangShan difftest documentation
[11] EPEX defines an instruction as transforming architectural state s into s', and uses this abstraction to synthesize equivalent programs that match in architectural-state transitions. EPEX paper
[12] DiffTest-H preserves architectural-state comparison while compressing DUT-to-REF communication using Batch (structural semantics), Squash (sequential semantics), and Replay (behavioral semantics) optimizations. DiffTest-H paper
[13] ImperasDV uses the ImperasFPM reference model and the RVVI-TRACE interface to perform continuous comparison and checking of architectural state, with pipeline synchronization for asynchronous events and machine-generated functional coverage. ImperasDV: RISC-V Processor Verification Solution
[14] The ImperasDV flow integrates with the Synopsys verification ecosystem via Synopsys VCS as the RTL simulator, ImperasDV as the lockstep reference and methodology, and Verdi for waveform-correlated debug of architectural-state mismatches. RISC-V Lockstep Co-Simulation: Retirement Step-and-Compare