Skip to content
STIMSMITH

register coverage

Technique WIKI v3 · 6/24/2026

Register coverage is a coverage metric introduced by DifuzzRTL for processor (CPU RTL) fuzzing. It instruments three extra registers (regstate, covmap, covsum) into each RTL module, hashes control-register values into regstate every clock cycle, and marks the corresponding slot in covmap; new slots increment covsum, with module-level sums aggregated into a final coverage value. DifuzzRTL applies the metric through automatic FIRRTL-based instrumentation and uses it as feedback for coverage-guided fuzzing, cross-checking RTL outputs against an ISA simulator. The ProcessorFuzz paper analyzes register coverage alongside a `reg-cov-difuzzrtl` configuration and highlights a case (a 130-bit remainder register in a division module) where it can produce misleading coverage, motivating the alternative CSR-transition coverage metric.

Overview

Register coverage (sometimes spelled register-coverage) is a CPU RTL coverage metric introduced by DifuzzRTL for processor fuzzing. It is designed to comprehensively capture RTL design state and to guide input generation during fuzzing; DifuzzRTL applies it as automatic instrumentation inside target RTL designs and pairs it with differential checking against an ISA reference simulator.[C1][C2]

How register coverage works

DifuzzRTL injects three new registers into each RTL module: regstate, covmap, and covsum. On every clock cycle, the values of the module's control registers are hashed into regstate. The instrumentation then attempts to write a 1 into a slot of covmap selected by regstate, marking that the corresponding state has been observed. If the targeted slot was previously 0 (i.e., a new state), covsum is incremented by 1. Because regstate, covmap, and covsum are updated every cycle, the approach is clock-sensitive, and the per-module covsum values are summed across RTL modules to produce the final coverage value.[C3]

Register coverage is based on control registers rather than on mux selection signals, which the source material describes as making it more scalable than the mux-coverage approach used by RFuzz.[C3]

Use within coverage-guided fuzzing

DifuzzRTL uses register coverage as feedback for coverage-guided fuzzing: inputs that increase the coverage metric are retained and mutated to explore additional RTL states, while RTL simulation outputs are cross-checked against an ISA simulator to detect discrepancies and bugs.[C1][C2]

Limitations discussed in the literature

Mux-coverage contrast (general scalability argument)

A referenced survey of fuzzing approaches attributes two main limitations to RFuzz's mux coverage to motivate the move to register coverage:

  • Mux coverage is clock-insensitive and can merge distinct FSM states reached via different toggle orders into the same coverage bit-vector, which is problematic for large FSMs.
  • The instrumentation resources required scale quadratically with the number of muxes, limiting scalability and runtime performance.[C3]

Misleading coverage in datapath-dominated modules (ProcessorFuzz)

The ProcessorFuzz paper argues that register coverage can be misleading. It describes a scenario involving a remainder register in a division module that is 130 bits wide and controls multiple mux selection signals (so it qualifies as a control register under DifuzzRTL's definition). The paper reports that in this case most of the register-coverage increase comes from this wide datapath remainder register, which does not actually contribute to real coverage of the processor FSM. The framing is that the remainder register is mostly concerned with the data path and does not control the FSM.[C4]

This observation motivates ProcessorFuzz's CSR-transition coverage metric, which monitors Control and Status Registers (system registers in the ISA specification that directly track the processor's architectural state) and considers a test input interesting only when it produces a previously unseen transition between CSR values of the previous and current instruction in an ISA simulation.[C4]

Role in ProcessorFuzz evaluations

The ProcessorFuzz evaluation compares several configurations, including no-cov-difuzzrtl (DIFUZZRTL with no coverage guidance, i.e., a black-box fuzzer) and reg-cov-difuzzrtl (DIFUZZRTL guided by register coverage). The reg-cov-difuzzrtl setting is applicable to Rocket and BOOM cores; for the BlackParrot core it is not applicable because DIFUZZRTL's register-coverage passes do not support SystemVerilog and are tailored for FIRRTL, the intermediate representation used by Chisel HDL-based designs.[C5]

Reported geometric-mean time-to-exposure (TTE) values include:

  • no-cov-difuzzrtl: 3182.9
  • reg-cov-difuzzrtl: 3245.1
  • ProcessorFuzz (selected configuration): 2630.7

Corresponding ProcessorFuzz geometric-mean speedups are reported as 1.21× over no-cov-difuzzrtl and 1.23× over reg-cov-difuzzrtl (with per-bug speedups up to 2.1× and 2.32× respectively).[C6][C7]

A figure labeled "Register coverage progress during fuzzing" plots no-cov-difuzzrtl, reg-cov-difuzzrtl, and ProcessorFuzz over a ~48-hour window.[C6]

Selection strategy used by ProcessorFuzz (for contrast)

ProcessorFuzz applies its own selection strategy rather than treating register coverage as its primary feedback: it classifies a generated test input as interesting only when it yields a new (previously unseen) CSR transition during fast ISA simulation. The paper reports that ProcessorFuzz classified only 33% of generated inputs as interesting, launched RTL simulation only on interesting inputs, discarded the rest, and used the fast ISA simulation to quickly filter out inputs that do not produce a new FSM state.[C6]

Coverage signal interpretation

Across the cited sources, register coverage is positioned as:

  • a control-register-based, clock-sensitive coverage signal that is more scalable than mux coverage,[C3]
  • a feedback mechanism that can nonetheless be dominated by wide datapath control registers and therefore misrepresent FSM exploration,[C4]
  • the baseline coverage-guided configuration (reg-cov-difuzzrtl) used in the ProcessorFuzz head-to-head evaluation against two alternative DIFUZZRTL settings (no-cov-difuzzrtl and the CSR-transition-guided ProcessorFuzz).[C5][C6][C7]

LINKED ENTITIES

2 links
DiFuzzRTL INTRODUCES
Coverage-Guided Fuzzing USES

CITATIONS

7 sources
7 citations
[1] DifuzzRTL introduces a novel coverage metric called register-coverage that comprehensively captures RTL design states, automatically instruments it into target RTL designs, and uses it to guide fuzzing input generation alongside differential checking against an ISA simulator. DifuzzRTL — CPU RTL Differential Fuzzer | Open Awesome
[2] Register coverage is based on control registers; it injects three registers (regstate, covmap, covsum) into each RTL module, hashes control-register values into regstate each clock cycle, writes 1 into the covmap slot determined by regstate, increments covsum on new slots, and sums covsum across modules into a final coverage value. Fuzzing IPv4 modules on FPGAs - Search for publications in DiVA
[3] Mux coverage has two main limitations: it is clock-insensitive and can merge distinct FSM states, and its instrumentation resources scale quadratically with the number of muxes, which motivated DifuzzRTL's switch to control-register-based register coverage as a more scalable alternative. Fuzzing IPv4 modules on FPGAs - Search for publications in DiVA
[4] Register coverage can be misleading: a 130-bit remainder register in a division module (which qualifies as a control register and controls multiple mux signals) can dominate coverage increase even though it belongs to the data path and does not control the FSM, motivating ProcessorFuzz's CSR-transition coverage. Fuzzing IPv4 modules on FPGAs - Search for publications in DiVA
[5] The ProcessorFuzz evaluation compares no-cov-difuzzrtl (black-box DIFUZZRTL) and reg-cov-difuzzrtl (DIFUZZRTL guided by register coverage); reg-cov-difuzzrtl applies to Rocket and BOOM cores but not BlackParrot because the register-coverage passes target FIRRTL (Chisel HDL) rather than SystemVerilog. ProcessorFuzz: Processor Fuzzing with Control and Status ...
[6] Reported geometric-mean TTE values are 3182.9 (no-cov-difuzzrtl), 3245.1 (reg-cov-difuzzrtl), and 2630.7 (ProcessorFuzz selected); ProcessorFuzz achieves 1.21x and 1.23x geometric-mean speedups over the two DIFUZZRTL settings (up to 2.1x and 2.32x respectively); a 'Register coverage progress during fuzzing' plot compares all three configurations. ProcessorFuzz: Processor Fuzzing with Control and Status ...
[7] ProcessorFuzz selected only 33% of generated test inputs as interesting, launched RTL simulation only for those inputs, and used fast ISA simulation to quickly discard inputs that do not produce a new FSM state, contrasting with using register coverage as the main feedback. ProcessorFuzz: Processor Fuzzing with Control and Status ...

VERSION HISTORY

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