CSR-transition coverage

Concept

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.

First seen 5/28/2026

Last seen 6/6/2026

Evidence 13 chunks

Wiki v2

WIKI

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.

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

6 connections

CSR-transition coverage is compared with register coverage as alternative feedback metrics.

Finite State Machine uses → 95% 2e

CSR-transition coverage tracks processor FSM state transitions through CSR changes.

ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers ← introduces 100% 2e

The paper introduces the CSR-transition coverage metric as a new coverage feedback mechanism.

ProcessorFuzz ← implements 100% 2e

ProcessorFuzz implements the CSR-transition coverage metric as its core feedback mechanism.

ProcessorFuzz ← uses 99% 2e

ProcessorFuzz uses CSR-transition coverage as its feedback metric

Control and Status Registers uses → 99% 2e

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

LINKED ENTITIES

3 links

ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers INTRODUCES Extracted graph relationship

ProcessorFuzz IMPLEMENTS Extracted graph relationship

CITATIONS

12 sources

12 citations — click to expand

[1] A processor is effectively a complex Finite State Machine (FSM), and hardware-specific coverage metrics aim to guide the fuzzer towards different uncovered processor-FSM states by taking hardware intrinsics (e.g., wire connections) into account rather than merely the code structure of the hardware. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers

[2] DIFUZZRTL's register coverage monitors value changes in registers that control multiplexer selection signals, but ProcessorFuzz argues that many of those registers are datapath registers with minimal control over the current FSM state, making the metric misleading. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers

[3] ProcessorFuzz proposes a novel CSR-transition coverage (CTC) metric to guide processor fuzzing towards interesting processor states, and on average triggers bugs 1.23× faster than DIFUZZRTL for the bugs DIFUZZRTL also finds, while additionally revealing 8 new bugs in open-source processors and 1 new bug in a reference model. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers

[4] A value change in a CSR often signifies an architectural state change (e.g. a change in a CSR that stores exception code or privilege level), and CSRs expose information such as the state of the floating-point unit about the current architectural state of the processor. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers

[5] ProcessorFuzz monitors new transitions in CSRs rather than just identifying unique CSR values, with a rationale similar to widely-used software fuzzers that monitor edges in a program instead of basic blocks, in order to improve the sensitivity of the feedback metric. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers

[6] 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, it uses the transition to determine if the input is interesting. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers

[7] Monitoring all CSRs can mislead the fuzzer; the instret CSR, which counts retired instructions, would cause a CSR transition after every committed instruction, causing every input to be classified as interesting without providing a useful signal of processor state. ProcessorFuzz introduces two CSR-selection criteria to avoid such cases. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers

[8] CSR transitions can be extracted from either the ISA simulation or the RTL simulation, but ProcessorFuzz uses the ISA simulator; the RISC-V Spike ISA simulator is, on average, 79× faster than the RTL simulation of the RISC-V BOOM processor in the observed setup. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers

[9] After executing sret at PC 0x045c, the mstatus CSR transitions from 0x8000000a00006000 to 0x8000000a00006020, which ProcessorFuzz records as a CSR transition between the two consecutive trace-log entries. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers

[10] In the ProcessorFuzz design, the mutation engine produces inputs executed by the ISA simulator into an extended ISA trace log; the transition unit extracts CSR transitions, checks them against a transition map, and only inputs flagged as interesting are then executed under RTL simulation for bug detection by trace-log comparison. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers

[11] ProcessorFuzz is HDL-agnostic because the CSR-transition coverage metric operates on ISA-level CSRs, so the same instrumented ISA simulator can be reused across processor designs expressed in different HDLs (Chisel, SystemVerilog, VHDL, etc.) without HDL-specific hardware instrumentation. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers

[12] ProcessorFuzz was evaluated on three open-source RISC-V processors — Rocket Core (Chisel), BOOM (Chisel), and BlackParrot (SystemVerilog) — which vary in microarchitectural implementation such as pipeline depth and in-order vs. out-of-order execution. ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers