Control and Status Register (CSR)

Concept

Control and Status Registers (CSRs) are software-visible processor registers that control and hold processor state, mediate privileged behavior, exception handling, capability reporting, and participate in the operand data path. In RISC-V designs, transitions in CSRs indicate new processor states, a property exploited by the ProcessorFuzz hardware fuzzer as a coverage signal. Cross-level and grammar-based testing campaigns have identified multiple CSR-related correctness bugs involving privileged-ISA semantics, trap-handling CSRs, counter CSRs, and dynamic-configuration effects, and CSR values are tracked alongside other architectural state (integer, floating-point, vector registers, PC, trap counter) inside a Machine State data structure used to extract, modify, compare, and re-establish RISC-V machine state.

First seen 5/26/2026

Last seen 7/19/2026

Evidence 10 chunks

Wiki v4

WIKI

Overview

Control and Status Registers (CSRs) are software-visible processor registers that, in RISC-V designs, are "in charge of controlling and holding the state of the processor." They are queried by software to determine implementation capabilities, and the allowed values of CSR fields determine what software may assume about the underlying implementation. Because RISC-V is modular and extensible, allowing unsupported or reserved CSR values can mislead software about what the implementation supports. [csr-overview] [csr-capability-query]

In addition to holding processor state, CSRs participate in the operand data path. In the formal microarchitectural control-flow-integrity (μCFI) model, an in-order load-store CPU is defined to load data from memory or from a CSR into a General-Purpose Register (GPR) before an instruction operates on the GPR. [csr-as-data-source]

READ FULL ARTICLE →

NEIGHBORHOOD

2 nodes · 1 edges

graph · Control and Status Register (CSR) · depth=1

RELATIONSHIPS

3 connections

Efficient Cross-Level Testing for Processor Verification: A RISC-V Case-Study ← uses 100% 2e

The paper tests and discusses CSR behavior extensively.

Machine mode (RISC-V privileged architecture) part of → 100% 1e

CSRs form the backbone of the Machine mode privileged architecture description.

Machine State ← uses 95% 1e

Machine State holds values of all CSR registers.

LINKED ENTITIES

1 links

Machine State USES Extracted graph relationship

CITATIONS

11 sources

11 citations — click to expand

[1] CSRs are software-visible processor registers that, in RISC-V designs, are in charge of controlling and holding the state of the processor, and are queried by software to determine implementation capabilities. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers

[2] In the formal microarchitectural control-flow-integrity (μCFI) model, an in-order load-store CPU is defined to load data from memory or from a CSR into a General-Purpose Register (GPR) before an instruction operates on the GPR. μCFI: Formal Verification of Microarchitectural Control-flow Integrity

[3] ProcessorFuzz uses a novel CSR-transition coverage metric that rewards inputs producing previously unseen CSR transitions, is HDL-agnostic and does not require instrumentation, was evaluated on Rocket, BOOM, and BlackParrot, triggered ground-truth bugs 1.23× faster on average than DIFUZZRTL, and exposed 8 new bugs in the three RISC-V cores plus 1 new bug in a reference model (all confirmed by developers). ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers

[4] The Machine State data structure in RVVTS holds values of all involved registers (integer, floating-point, vector, and CSR), a trap counter, the last executed PC address, and hashes for memory areas, and supports extraction from a RISC-V machine, modification, comparison, and generation of code that brings a RISC-V machine to that state. Single Instruction Isolation for RISC-V Vector Test Failures

[5] RVV adds 32 vector registers, 7 CSRs, and 624 instructions to the RISC-V programming model, with VLEN chosen by the designer; RVVTS's grammar-based ISG supports RV32/RV64, the base integer extension, RVV, and partially floating-point. Single Instruction Isolation for RISC-V Vector Test Failures

[6] Floating-point instructions can be temporarily invalid because floating-point is disabled via the mstatus CSR, and RVV instructions can be invalid due to dynamic configuration (e.g., 8-bit elements with an RVV floating-point operation). Single Instruction Isolation for RISC-V Vector Test Failures

[7] Cross-level testing reported CSR-related correctness bugs including read-only CSR writes not trapping, MEPC lower two-bit corruption, MISA initialization and unsupported-value bugs, MTVAL set to ECALL encoding, MTVEC MODE reserved-value writes, EBREAK setting MCAUSE to illegal instruction, MINSTRET/MCYCLE write traps, MINSTRET not avoiding increment on write access, MRET continuing at the wrong instruction for special MRET-plus-illegal-instruction sequences, and an ISS bug where MTVAL was set incorrectly for compressed instructions treated as illegal. Efficient Cross-Level Testing for RISC-V Processor Verification

[8] Cross-level testing found the cited bugs in less than five minutes each; in a one-hour run it generated and co-simulated 226 million instructions (12 million illegal, 214 million legal, of which 156 million completed normally and 58 million trapped). Efficient Cross-Level Testing for RISC-V Processor Verification

[9] The cross-level testing approach generates an endless on-the-fly instruction stream fed to both an RTL core and a reference ISS in tightly coupled co-simulation, avoiding restrictions on generated instructions and is generic across RISC-V ISA configurations. Efficient Cross-Level Testing for RISC-V Processor Verification

[10] Related prior work includes Bayesian-network coverage-directed test generation, feedback-based coverage-directed testing, constraint-solving-based test generation separating architecture from test generation, constraint-solution sharing across instructions, execution-path-based coverage models, machine-learning and fuzzing approaches, the Scala-based Torture Test framework, and RISC-V International's architectural tests. Efficient Cross-Level Testing for RISC-V Processor Verification

[11] Symbolic Quick Error Detection (SQED) extends QED with bounded model checking for pre-silicon verification and has been applied to RISC-V processors and hardware accelerators; EPEX uses SMT to generate equivalent test programs and compares architectural states across two instances of the same processor; the formal Sail specification of the RISC-V ISA exists (RVV part under development). Single Instruction Isolation for RISC-V Vector Test Failures