Architectural Registers
Overview
Architectural registers denote the set of processor registers defined by the instruction set architecture (ISA) that are explicitly observable by software. They are distinct from transient micro-architectural structures (e.g., pipeline registers, reorder buffers, branch predictors, load/store queues), which are implementation-specific and hidden from the programmer. In the context of FPGA-based processor debugging, particularly as described in the Prelude framework, architectural registers together with accessed memory footprint are identified as the minimal software-visible snapshot required for deterministic replay of an erroneous segment.
Components
The architectural register set encompasses:
- General Purpose Registers (GPRs): Registers used for integer, address, and general computational operands as defined by the target ISA.
- Floating Point Registers (FPRs): Registers dedicated to floating-point data operands.
- Control and Status Registers (CSRs): Registers that expose privileged or configuration state such as privilege level, exception handling, and processor control.
- Program Counter (PC): The register that holds the address of the next instruction to be fetched and executed.
Properties and Role in Execution
From the perspective of software execution, architectural registers constitute the principal interface through which a program observes and operates on the processor. Because instruction behavior within a segment is fully determined by the architectural registers (and the initial memory contents referenced), these registers:
- Remain stable across implementations of the same ISA.
- Completely determine the deterministic execution of instructions within a defined segment.
- Enable reconstruction of transient micro-architectural state, since structures such as pipeline buffers and instruction queues evolve predictably from the architectural state after a short warm-up execution.
Architectural vs. Micro-Architectural State
The Prelude framework distinguishes between two categories of processor state:
| State Category | Examples | Captured in Prelude Snapshot? |
|---|---|---|
| Architectural | PC, GPRs, FPRs, CSRs | ✓ Required |
| Micro-architectural | Pipeline registers, instruction queues, reorder buffers, load/store queues, branch predictors, other internal buffers | ✗ Reconstructed via warm-up |
| Memory | L1/L2/L3 caches, full main memory | ✗ Only accessed memory captured |
The micro-architectural components are termed transient—they evolve quickly to converge on values determined by the architectural inputs—so capturing them explicitly is unnecessary for replay and error reproduction.
Use in Replay-Oriented Debugging
In replay-oriented debugging (as exemplified by Prelude), snapshots constrained to architectural registers plus accessed memory footprint deliver:
- Functional correctness: ensuring replay begins from accurate architectural state.
- Error trigger capability: reproductions of the bug retain sufficient representational fidelity to re-trigger the failure during replay.
- Dramatic size reduction: Prelude's snapshot footprint is approximately 0.001% of a full-state snapshot, allowing practical on-FPGA capture and transfer to host without sacrificing replay determinism.
Through the Architectural Register Management Unit (AMU), captured register values are written to their assigned physical registers using the processor's map table after the pipeline is reset and flushed, redirecting the Instruction Fetch Unit (IFU) to the segment's starting PC. This reset-and-restore procedure establishes a clean, fully consistent architectural configuration free of speculative or in-flight state—forming the launching point for replay and subsequent micro-architectural state reconstruction.
Summary
Architectural registers are the ISA-defined, software-visible state (PC, GPRs, FPRs, CSRs) that wholly determine instruction behavior within a segment. Their stable, deterministic nature makes them sufficient for reconstructing transient micro-architectural state and for supporting replay-based debugging, eliminating the prohibitive cost of capturing full processor state.