Control and Status Registers

Concept

Control and Status Registers (CSRs) are RISC-V architectural registers that control and hold processor state. CSRs are part of the architectural state and play a central role in modern RISC-V processor verification: ProcessorFuzz uses CSR transitions as HDL-agnostic coverage feedback; UVM-based verification environments verify CSRs alongside other core blocks; retirement-level lockstep co-simulation adds CSRs to the state-mask progression to exercise privilege and exception handling; and research systems such as SNAP use new CSRs as hardware/OS configuration interfaces for fuzzing instrumentation.

First seen 5/28/2026

Last seen 7/20/2026

Evidence 50 chunks

Wiki v12

WIKI

Control and Status Registers

Control and Status Registers (CSRs) are RISC-V architectural registers that "contain additional information about the results of instructions in the CPU," and which are "in charge of controlling and holding the state of the processor." As a core component of the Architectural State, CSRs are visible at the ISA level alongside the program counter (PC), general-purpose registers (GPRs), and memory contents relevant to execution.

In RISC-V, CSR access and the execution of privileged instructions are gated by the current privilege level: User (U) for unprivileged applications, Supervisor (S) for operating systems, and Machine (M) for full hardware control and low-level operations. Only M is required to be implemented, but most non-embedded RISC-V CPUs implement all three.

READ FULL ARTICLE →

NEIGHBORHOOD

11 nodes · 12 edges

graph · Control and Status Registers · depth=1

RELATIONSHIPS

29 connections

ProcessorFuzz ← uses 100% 11e

ProcessorFuzz monitors CSR transitions to guide fuzzing.

CSR-transition coverage ← uses 100% 6e

CSR-transition coverage monitors transitions in Control and Status Registers.

mstatus CSR ← part of 100% 6e

mstatus is a specific CSR monitored by ProcessorFuzz for privilege and state tracking.

fflags CSR ← part of 100% 5e

fflags is a specific CSR monitored by ProcessorFuzz for floating-point exception tracking.

medeleg CSR ← part of 100% 4e

medeleg is a specific CSR used to delegate traps to lower privilege levels.

mcause CSR ← part of 100% 3e

mcause is a specific CSR that records the cause of exceptions.

Instruction Set Simulator part of → 90% 2e

An ISS models Control and Status Registers as part of the processor state.

CSR-transition coverage ← uses 99% 2e

CSR-transition coverage monitors transitions in CSRs to track processor state

RISCover ← uses 85% 2e

RISCover excludes CSR-based instructions during fuzzing to avoid false positives, but permits frcsr and fscsr.

privilege mode ← part of 85% 2e

Privilege mode status is tracked through CSR fields like mstatus.xPP.

Cascade ← uses 100% 2e

Cascade generates programs that operate under randomized CSRs.

SNAP ← uses 100% 2e

SNAP introduces new CSRs as configuration interfaces between hardware and OS for fuzzing control.

RISC-V part of → 97% 2e

RISC-V processors include Control and Status Registers as architectural components.

Triple Module Redundancy uses → 90% 1e

For safety-critical applications, CSRs may use TMR as a safety mechanism.

IDesignSpec Suite ← uses 95% 1e

IDesignSpec Suite automates the design of CSRs from executable golden specifications.

RISC-V BOOM part of → 100% 1e

SNAP adds new CSRs to the RISC-V BOOM core for hardware-software interface.

CSRFormal: Formal Verification of Control and Status Registers in RISC-V ← evaluates 98% 1e

The paper addresses verification of Control and Status Registers in RISC-V.

IP Core part of → 90% 1e

IP cores of any significant complexity contain CSRs as part of their design specification.

Architectural State part of → 97% 1e

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

System On Chip part of → 95% 1e

CSRs form the hardware side of the HSI and are defined as part of the SoC design specification.

Hardware-Software Interface part of → 95% 1e

CSRs constitute the hardware side of the hardware-software interface.

Bus Interface uses → 90% 1e

CSRs usually interface to a processor bus, requiring a bus interface design.

clock domain crossing uses → 90% 1e

CSR bus interfaces may require CDC logic between the bus clock domain and the interface clock domain.

RISC-V ISA part of → 100% 1e

CSRs are part of the RISC-V ISA specification.

Parity uses → 90% 1e

For safety-critical applications, CSRs may use parity as a safety mechanism.

ProcessorFuzz Tool ← uses 1e

The ProcessorFuzz Tool monitors Control and Status Registers to guide fuzzing.

Error-Correcting Code uses → 90% 1e

For safety-critical applications, CSRs may use ECC as a safety mechanism.

instret CSR ← part of 100% 1e

instret is a CSR that counts committed instructions and is explicitly excluded from ProcessorFuzz's monitoring.

Cyclic Redundancy Check uses → 90% 1e

For safety-critical applications, CSRs may use CRC as a safety mechanism.

LINKED ENTITIES

1 links

Architectural State PART_OF Extracted graph relationship

CITATIONS

10 sources

10 citations — click to expand

[1] CSRs are in charge of controlling and holding the state of the processor, and transitions in CSRs indicate a new processor state. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers

[2] Architectural state visible at the ISA level includes the 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

[3] Lockstep co-simulation captures architectural state at each instruction retirement and reports mismatches immediately at the point of failure. RISC-V Lockstep Co-Simulation: Retirement-Level Step-and-Compare for Faster Verification & Debug

[4] The lockstep state mask typically progresses from PC-only checks, to PC plus GPRs, to adding CSRs to exercise privilege and exception handling, and finally to selected memory regions or the complete architectural state. RISC-V Lockstep Co-Simulation: Retirement-Level Step-and-Compare for Faster Verification & Debug

[5] Lockstep comparison surfaces CSR side effects, privilege transitions, and subtle ordering errors that traces or self-checks may miss. RISC-V Lockstep Co-Simulation: Retirement-Level Step-and-Compare for Faster Verification & Debug

[6] RVVI is an open standard interface for exchanging retire, state, and event information between the RTL, testbench, and reference models. RISC-V Lockstep Co-Simulation: Retirement-Level Step-and-Compare for Faster Verification & Debug

[7] A 2025 IJEDR project verifies the CSR block of a RISC-V core alongside the IFU, IDU, Execute Unit, LSU, Register File, Pipeline, and Exception/Interrupt Unit using a UVM-based testbench with constrained-random stimulus, assertions, an architectural reference model, and a scoreboard. Verification Of Risc-V Core Blocks Using Uvm

[8] The IJEDR project's toolchain comprises SystemVerilog with the UVM 1.2 / 1.1d (IEEE 1800.2) library, ModelSim / QuestaSim as the simulator, Visual Studio Code as the editor, and QuestaSim's built-in waveform viewer. Verification Of Risc-V Core Blocks Using Uvm

[9] ProcessorFuzz uses CSR-transition coverage as its coverage metric, on the rationale that transitions in CSRs indicate a new processor state, and is HDL-agnostic without requiring processor instrumentation. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers

[10] SNAP introduces new 8-byte CSRs as hardware/OS configuration interfaces for fuzzing instrumentation, including BitmapBase, BitmapSize, TraceEn, TraceStartAddr, TraceEndAddr, and the LbqAddr[0-31] / LbqStatus registers wired to LBQ entries. Hardware Support to Improve Fuzzing Performance and Precision