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]

Role in retirement-level lockstep co-simulation

In retirement-level lockstep co-simulation, the RTL design and a validated reference model run the same program under a co-simulation harness. At each retire event, architectural state is captured and compared immediately. If the states diverge, the flow reports the retire index and expected-versus-actual values, allowing debug at the point of failure. [C3]

Because comparison is performed at retirement rather than against transient pipeline states, the debug process focuses on architecturally visible behavior and reduces false positives caused by intermediate implementation states. [C4]

This methodology is referred to as Step-and-Compare: at each retire step, RTL and reference-model states are captured and compared, with mismatches reported immediately. Asynchronous events such as interrupts, debug requests, or exceptions are injected at arbitrary retire points to stress the design while keeping runs reproducible for debug. [C23]

Some lockstep flows make the compared subset configurable through a state mask. The cited flow describes starting with PC-only checks, expanding to PC plus GPRs, adding CSRs for privilege and exception behavior, and finally comparing selected memory regions or the complete architectural state for sign-off confidence. This scalability makes the approach applicable from early RTL bring-up to final verification sign-off. [C5]

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. This immediate flagging accelerates debugging and uncovers issues such as CSR side effects, privilege transitions, or subtle ordering errors that traces or self-checks may miss. [C24]

The wider functional-faithfulness literature generalizes this as batch comparison of state tuples (program counter, registers, memory, CSRs) per commit event, combined with immediate halting on any bit-wise discrepancy to guarantee functional correctness at every observable boundary. Coverage models for instructions, pipeline events, hazard conditions, and assertion-based monitoring further ensure that architectural features are exercised. [C6]

Role in XiangShan difftest and co-simulation

XiangShan's difftest framework implements a co-simulation approach in which the XiangShan design (the design under test, DUT) runs in lockstep with a golden reference model, comparing architectural state at commit points to detect discrepancies. [C7]

Two golden reference models are supported:

• NEMU (NJU Emulator): a fast functional RISC-V simulator used as the primary golden model, supporting all privilege modes (M/H/S/U) and virtual memory, with native checkpoint/restore via .zstd or .gz files. [C8]
• Spike: the official RISC-V ISA simulator maintained by RISC-V International, selected via the --spike flag. [C9]

The difftest interface exports several categories of signals for verification:

1. Architectural State: PC, GPRs, floating-point registers (FPRs), and vector registers. [C10]
2. CSRs: machine, supervisor, and hypervisor mode registers. [C10]
3. Memory Operations: load/store addresses and data for memory consistency checks. [C10]
4. Exceptions: exception cause and PC to verify trap handling logic. [C10]

The interface is checked during CI using difftest/scripts/st_tools/interface.py to ensure SimTop.sv matches the expected difftest-interface.sv. [C11]

By verifying at instruction-commit boundaries against a golden model, difftest provides cycle-accurate validation of architectural state, detection of implementation bugs, and automated regression testing across workloads. The infrastructure supports Verilator and VCS simulation backends and integrates with NEMU and Spike as functional reference simulators. [C12]

Role in EPEX

EPEX treats architectural state as the equivalence boundary for processor verification at the ISA level. The EPEX paper defines processing an instruction as transforming an architectural state s, described as the state visible to the programmer, into a new architectural state s'. [C13]

EPEX uses this abstraction to synthesize equivalent programs. For an instruction from a test program that starts in s and leads to s', EPEX uses a formal ISA model and SMT-based automated reasoning to find a different instruction that, when executed from the same s, reaches the same s'. Repeating this for each instruction transforms the original program P into a program P̂ whose behavior is equivalent on architectural states, while potentially exercising different data and control paths. [C14]

Role in DiffTest-H hardware-accelerated co-simulation

DiffTest-H is a semantic-aware hardware-accelerated co-simulation framework that builds on the DiffTest approach and optimizes the software–hardware communication used to transmit architectural-state updates from the DUT to the reference model (REF) for comparison. [C15]

In this style of co-simulation, the framework extracts architectural verification events from the DUT for each instruction (for example, instruction submission and register updates), drives the REF accordingly, and performs comparisons of architectural state. External interrupts and other non-deterministic events unique to the DUT are completely synchronized from the DUT to the REF so that their architectural states remain aligned. [C16]

Communication is decomposed into three stages: communication initiation (data preparation and software/hardware synchronization), data transmission (movement through the bandwidth-limited pathway), and software processing (running the reference model and performing checks). For DiffTest, the cited analysis counts 32 types of verification events with roughly 15 communications and ~1.2 KB of data per cycle; with hardware-acceleration platforms such as Palladium and FPGA, up to 99% of simulation time is consumed by this software–hardware communication, making it the primary bottleneck. [C17]

DiffTest-H preserves architectural-state comparison while attacking the communication bottleneck through three design points:

• Batch: uses structural semantics to compactly package verification events of different structures into a single communication, eliminating padding and reducing communication frequency. [C18]
• Squash: uses sequential semantics to decouple the check order of compressed events from the communication order, so non-deterministic events can be sent first with a sequence identifier while other events continue to be compressed; the software side then restores the correct check order. This reduces the interruptions that compression would otherwise suffer on non-deterministic events. [C19]
• Replay: uses behavioral semantics so that, on a mismatch, only the verification events near the error location are re-checked rather than re-simulating the entire DUT from a hardware snapshot, preserving instruction-level architectural-behavior details and the ability to debug at instruction granularity. [C20]

Non-deterministic verification events such as external interrupts have a specific check-order requirement: when such an event updates the REF's architectural state, all previous instructions must have been checked and no subsequent instruction may have been checked yet. Existing compression methods couple check order with communication order, which forces compression to terminate on every non-deterministic event. Sequential semantics decouple these two orders, allowing the framework to transmit the non-deterministic event first while compression continues, lowering the data volume sent over the software/hardware pathway. [C21]

Role in ImperasDV RISC-V verification

ImperasDV is a front-end design verification solution for custom RISC-V processors that performs continuous comparison and checking of architectural state between the design under test and a configurable reference model. [C22]

The flow is built on the following elements:

• ImperasFPM reference model: a configurable and extensible fast processor model that can be tailored to match the DUT, including custom ISA extensions. [C22]
• RVVI-TRACE interface: an open-standard trace interface that connects the reference model to the DUT and feeds architectural-state updates for continuous checking. [C22]
• Asynchronous event handling: a pipeline synchronization technology that manages the random occurrence of asynchronous events, which are a frequent source of bugs in processor designs. [C22]
• Functional coverage: a machine-generated coverage model for each RISC-V ISA extension supported by the verification environment. [C22]

ImperasDV can be integrated into SystemVerilog/UVM testbenches or used from any language with a C interface, supporting constrained-random stimulus and reuse across projects via the open RVVI standard. The ImperasFPM reference model is also used in lockstep comparisons for RISC-V cores; the ImperasDV partnership with Synopsys integrates the reference model and methodology into SV/UVM flows alongside RVVI. [C22] [C25]

The broader Synopsys toolchain supports this lockstep work through Synopsys VCS® as the industry-standard RTL simulator executing the DUT in co-simulation, and the Verdi® debug platform, in which mismatches, retire indices, and architectural-state differences can be inspected with waveform correlation. [C25]

Practical interpretation

Across the provided evidence, architectural state functions as the externally meaningful state of the processor:

• it is the state committed at instruction retirement;
• it includes PC, GPRs, FPRs, vector registers, CSRs, and relevant memory contents;
• it is the state compared between RTL and reference models in lockstep verification (e.g., NEMU or Spike in XiangShan difftest, or ImperasFPM via ImperasDV on RVVI-TRACE) under the Step-and-Compare methodology, with debugging supported via Verdi;
• it is the state over which EPEX defines instruction and program equivalence;
• it is the boundary preserved by DiffTest-H's Batch/Squash/Replay optimizations while compressing and batching the verification events that carry it from DUT to REF;
• it is the bit-wise comparison target at each commit event in functional-faithfulness co-simulation frameworks such as SupeRFIVe and UVM-TLM, where state tuples (PC, registers, memory, CSRs) are batched and any discrepancy halts the run.

This makes architectural state a key boundary between ISA-level correctness and implementation-level behavior.