Skip to content
STIMSMITH

CSR-transition coverage

Concept WIKI v3 · 6/11/2026

CSR-transition coverage (CTC) is a hardware-fuzzing coverage metric introduced by ProcessorFuzz. It treats changes in selected Control and Status Registers (CSRs) between consecutive instructions as signals of processor Finite State Machine (FSM) state changes, and uses those transitions as the feedback signal to guide coverage-guided fuzzing of processor designs. External surveys (e.g., FuzzWiz) classify it as a specialized CPU-targeting coverage metric, distinct from general RTL code coverage.

Overview

CSR-transition coverage (CTC) is a coverage metric for processor fuzzing, introduced by the ProcessorFuzz paper. The metric monitors transitions in Control and Status Registers (CSRs), which are part of the ISA specification, and uses those transitions to decide whether a generated test input is "interesting" during coverage-guided fuzzing. It is referred to in the paper as the "novel CSR-transition coverage (CTC) metric" and is one of the two central contributions of ProcessorFuzz (the other being the use of ISA simulation to determine whether an input is interesting).

The underlying intuition is that a processor is effectively a complex Finite State Machine (FSM) whose state is partly exposed through CSRs. A processor "is effectively a complex Finite State Machine (FSM) that consists of a large number of states," and "exploring different states in 'processor FSM' is the key to identifying bugs in the processor." Because CSRs are ISA-defined registers that "have direct control over the current processor state" and "expose information (e.g., state of the floating-point unit) about the current architectural state of the processor," a change in a CSR's value is taken as a sign that the processor has moved to a new architectural state and therefore merits further exploration.

Why transitions, not just CSR values

The metric monitors transitions between CSR values observed at adjacent instructions rather than only the set of unique CSR values reached. The paper's rationale is analogous to widely-used software fuzzers that "monitor edges in a program instead of basic blocks" — using edges/transitions makes the feedback more sensitive to qualitatively new behaviour. As a concrete illustration, the paper notes that even if two intermediate processor states N1 and N2 are already covered, a new transition between them through a privileged path P1 can still be detected as a new transition and used as feedback.

How a CSR transition is detected

A CSR transition is detected by comparing the CSR values produced by the execution of the previous instruction and the current instruction. "To extract a CSR transition, ProcessorFuzz monitors the CSR values resulting from the execution of the previous and current instructions and checks if they differ. If so, ProcessorFuzz uses the transition to determine if the input is interesting."

A worked example from the paper uses the RISC-V sret instruction in an extended ISA trace log. The Privileged column of the trace changes between line 1 (after sret at 0x045c) and line 2 (the next instruction at 0x283c):

  • Before sret: mstatus = 0x8000000a00006000
  • After sret: mstatus = 0x8000000a00006020

The paper represents the resulting CSR transition as an ordered pair (S0, S1) of the full selected-CSR fingerprints, e.g. (8000000a00006000 00 0f b1 00 000, 8000000a00006020 00 0f b1 00 000). Any input that introduces a (S0, S1) pair not already stored in the transition map is treated as interesting.

CSR selection criteria

The ISA specification exposes a large number of CSRs, and not all of them are useful signals of processor state. The paper introduces two CSR-selection criteria to avoid misleading the fuzzer. A representative failure case is the instret CSR, which holds the total number of retired instructions. If instret were monitored, "each committed instruction by the processor results in a CSR transition," which would cause ProcessorFuzz to "identify any test input as interesting" — even though "a test would rarely result in a bug because of a change in committed instruction count." The two criteria are designed to filter out such monotonic, per-instruction-changing CSRs and keep only CSRs that carry qualitatively distinctive information about the current processor state. (The full formal statement of the two criteria appears in the paper but is not captured in the provided evidence chunks.)

Where the transitions come from

CSRs are present both in an ISA simulator and in the RTL design of a processor, so in principle "CSR transitions can be extracted either from the ISA simulation or the RTL simulation." ProcessorFuzz deliberately uses the ISA simulator (e.g. RISC-V Spike) to collect them, for two reasons:

  1. Speed. The paper reports that "the RISC-V Spike ISA simulator is, on average 79× faster than the RTL simulation of the RISC-V BOOM processor." Fast coverage feedback lets ProcessorFuzz quickly discard uninteresting inputs without paying for RTL simulation.
  2. Reusability across HDLs. A selected set of CSRs is part of the ISA, so the same instrumented ISA simulator — extended to emit an extended ISA trace log containing the selected CSRs — can be reused for any processor design that targets that ISA, regardless of whether the design is written in Chisel HDL, SystemVerilog, VHDL, etc. This makes ProcessorFuzz "agnostic to the hardware description language (HDL) used for designing the processor" and removes the need for HDL-specific hardware instrumentation.

In ProcessorFuzz's pipeline (Figure 3 of the paper), the mutation engine produces an input that the ISA simulator executes and writes into an extended ISA trace log. A transition unit then extracts CSR transitions from the log, checks them against the transition map, and records any new transitions. RTL simulation is performed only for inputs that the transition unit flags as interesting, and a final stage compares the extended RTL trace log with the extended ISA trace log — any mismatch is reported as a potential bug for human verification.

Comparison with register coverage

CSR-transition coverage is explicitly framed as a response to limitations of the register coverage metric used by DIFUZZRTL. DIFUZZRTL's register coverage "monitors value changes in registers that control multiplexer selection signals," with the assumption that "a particular value in these registers represents a unique state in the 'processor FSM'." The ProcessorFuzz paper argues that this metric is "highly misleading" because DIFUZZRTL "monitors many datapath registers which have minimal control over the current FSM state of the processor." Coverage increases coming from such datapath registers cause inputs to be incorrectly classified as interesting, leading to wasted fuzzing time. By contrast, CSRs are the architectural registers that actually control processor state (e.g. privilege level, exception cause, floating-point unit state), so their transitions are a more precise signal of FSM-state change. In the reported evaluation, ProcessorFuzz "triggers bugs 1.23× faster than DIFUZZRTL" on average (for the bugs that DIFUZZRTL also found), and additionally revealed 8 new bugs in open-source RISC-V processors (Rocket, BOOM, BlackParrot) and 1 new bug in a reference model.

Role in the ProcessorFuzz design

Within ProcessorFuzz, CSR-transition coverage plays two roles:

  • It is the feedback signal that determines whether an input is worth running through the much slower RTL simulation pipeline.
  • It is the metric that makes the fuzzer HDL-agnostic: because the selected CSRs are an ISA-level property, the same metric and instrumentation can be reused across RTL designs expressed in different HDLs (Chisel, SystemVerilog, VHDL, etc.).

The paper also notes that ProcessorFuzz "discovered all the bugs found by the existing processor fuzzer (i.e., DIFUZZRTL)," indicating that CSR-transition coverage does not regress the bug-finding capability of the prior register-coverage-based approach while reducing time-to-bug for the shared set of bugs.

Classification in the hardware-fuzzing landscape

A 2024 hardware-fuzzing survey and framework paper (FuzzWiz, arXiv:2410.17732) places CSR-transition coverage in a taxonomy of coverage metrics used by hardware fuzzers. In FuzzWiz's comparison table, ProcessorFuzz is categorized as supporting VHDL and SystemVerilog (SV) designs, using a CSR transition coverage metric, running on software (SW) simulation, and targeting CPU designs. The same table distinguishes it from other coverage metrics in the field:

  • Mux toggle (used by works such as [8587711] and [9586289] in the survey), associated with FIRRTL designs and the JQF engine;
  • Edge coverage / software line coverage (used by google_interns work, on V/SV with AFL);
  • Control register coverage (used by [9519470], i.e., DIFUZZRTL, on FIRRTL/V with FPGA-based execution targeting CPU);
  • Cost-function coverage (used by [10137024], on V/SV with a modified AFL and FPGA);
  • Hardware code coverage (used by WTF, on SW targeting IP).

FuzzWiz also notes that ProcessorFuzz "utilized a novel Control and Status Register (CSR)-transition coverage metric to monitor processor state changes, [and] proved more efficient in bug detection than previous methods." At the same time, FuzzWiz raises an open question about how specialized metrics like CSR-transition coverage — along with mux toggle and register coverage — relate to "traditional RTL code or functional coverage which are needed to ensure that the DUV is verified," reflecting an ongoing concern in the field that FSM-state-style metrics may not directly track conventional coverage goals.

LINKED ENTITIES

1 links
ProcessorFuzz USES

CITATIONS

14 sources
14 citations
[1] CSR-transition coverage (CTC) is a novel coverage metric introduced by ProcessorFuzz that monitors CSR transitions to guide coverage-guided fuzzing of processors. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers
[2] A processor is treated as a complex FSM and CSRs are used as a proxy for processor state because they have direct control over the current processor state and expose architectural state information. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers
[3] CSR transitions (edges) are monitored rather than unique CSR values (nodes), analogous to software fuzzers that monitor edges instead of basic blocks, so that new transitions between already-covered states are still detected. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers
[4] A CSR transition is detected by comparing the CSR values produced by the previous and the current instruction and recording the ordered pair (S0, S1) when they differ. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers
[5] The `sret` example shows `mstatus` changing from 0x8000000a00006000 to 0x8000000a00006020 between consecutive instructions, illustrating a recorded CSR transition. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers
[6] Two CSR-selection criteria are introduced to filter out monotonic, per-instruction-changing CSRs such as `instret`, which would otherwise cause every test input to be flagged as interesting. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers
[7] CSR transitions are extracted from the ISA simulator (e.g., RISC-V Spike), which is on average 79× faster than the RTL simulation of BOOM, and the same instrumented simulator can be reused across HDLs (Chisel, SystemVerilog, VHDL), making ProcessorFuzz HDL-agnostic. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers
[8] In the ProcessorFuzz pipeline, the mutation engine produces inputs run on the ISA simulator, the transition unit extracts CSR transitions and consults the transition map, and RTL simulation plus ISA-vs-RTL trace comparison are performed only for inputs flagged as interesting. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers
[9] CSR-transition coverage is presented as an alternative to DIFUZZRTL's register coverage, which the ProcessorFuzz authors argue is misleading because it monitors datapath registers that have minimal control over the FSM state. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers
[10] ProcessorFuzz reports triggering ground-truth bugs 1.23× faster than DIFUZZRTL on average, and exposed 8 new bugs across Rocket, BOOM, and BlackParrot plus 1 new bug in a reference model. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers
[11] ProcessorFuzz discovered all the bugs found by DIFUZZRTL, indicating that CSR-transition coverage does not regress the bug-finding capability of register coverage while reducing time-to-bug. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers
[12] FuzzWiz classifies ProcessorFuzz as using a 'CSR transition' coverage metric on VHDL and SystemVerilog designs, running in software simulation, and targeting CPU designs. FuzzWiz - Fuzzing Framework for Efficient Hardware Coverage
[13] FuzzWiz states that ProcessorFuzz 'utilized a novel Control and Status Register (CSR)-transition coverage metric to monitor processor state changes, [and] proved more efficient in bug detection than previous methods.' FuzzWiz - Fuzzing Framework for Efficient Hardware Coverage
[14] FuzzWiz raises an open question about how specialized coverage metrics like CSR-transition coverage relate to traditional RTL code or functional coverage needed to verify the DUV. FuzzWiz - Fuzzing Framework for Efficient Hardware Coverage

VERSION HISTORY

v3 · 6/11/2026 · minimax/minimax-m3 (current)
v2 · 6/6/2026 · minimax/minimax-m3
v1 · 5/28/2026 · gpt-5.5