Standardized and interpretable RTL coverage reporting

Establish how many finite-state-machine, expression, statement, block, branch, or toggle coverage points contribute to reported coverage percentages for large RTL designs such as Rocket Core, thereby enabling meaningful interpretation and comparison of hardware-fuzzer results.

Background

The paper explains that RTL fuzzers report heterogeneous coverage measures and often omit the composition of their aggregate percentages. This lack of contextual information prevents researchers from determining whether reported improvements represent genuine exploration of new design state space or merely differences in measurement.

Rocket Core is given as a concrete example, with approximately 600,000 coverage points. The authors explicitly identify the unresolved breakdown of these points across coverage categories as an obstacle to standardization, reproducibility, and cross-tool comparison.

References

Automatic property generation could eventually provide a common set of properties and violations, but it remains an open problem.

— SoK: You Find What You Seek: Rethinking Oracles, Guidance, and Input Generation in Hardware Fuzzing  (2609.27300 - Abarajithan et al., 23 Sep 2026) in Section 6.3, “Proposed Evaluation Practices”

For instance, in designs like Rocket Core with $\sim$600K coverage points, it remains unclear how many FSM, expression, statement, block, branch or toggle coverage points contribute to reported percentages.

— SoK: ARCUS: On the Efficiency and Efficacy of Hardware Fuzzing  (2608.23933 - Murali et al., 25 Aug 2026) in Section 5.3, “Coverage Metrics,” subsection “Discussion”