RTL Fuzzing

Overview

RTL Fuzzing is a hardware verification technique in which a fuzzer generates and mutates inputs to a Register-Transfer Level (RTL) hardware design in order to expose bugs, unexpected behaviors, or security vulnerabilities. It is part of the broader field of Hardware Fuzzing, adapting software-style automated testing methods—originally devised for software bug finding—to digital designs expressed in HDLs such as Verilog or SystemVerilog.

Because hardware bugs must typically be detected before deployment (unlike many software bugs), RTL Fuzzing targets RTL simulation or synthesized-on-FPGA implementations as the design under test (DUT), aiming to maximize functional coverage and detect semantic mismatches.

Motivation

Modern hardware systems—from compact edge devices to heterogeneous multi-component platforms—integrate billions of transistors. Traditional verification techniques, including functional simulation and formal methods, struggle to scale to the complexity of these designs and may fail to expose subtle or potential vulnerabilities. Fuzzing has emerged as a complementary verification approach capable of uncovering deeper, hard-to-find bugs by repeatedly exercising the DUT with diverse inputs.

Core Methodologies

Coverage-Guided Graybox Fuzzing (CGF)

Coverage-Guided Graybox Fuzzing has become a foundational technique in RTL Fuzzing. In CGF, input generation is directed by feedback from real-time code coverage, allowing the fuzzer to prioritize input mutations that reveal unexplored paths in the design, thereby improving functional coverage of RTL designs. Multiple RTL-level Fuzzing frameworks have demonstrated effectiveness in achieving broad coverage, particularly across designs with complex datapaths, using CGF principles.

Directed Graybox Fuzzing (DGF)

Hardware is typically developed incrementally, with new modules added or existing ones modified across design iterations. In such flows, verification efforts must focus on specific changes rather than re-testing the entire system. Directed Graybox Fuzzing (DGF) enables targeted fuzzing by steering test generation toward specific regions of interest. DGF is particularly useful in scenarios such as:

• Patch validation
• Bug localization
• Module-specific testing

DirectFuzz is identified as a DGF-based implementation that aimed to bring directionality into the fuzzing process to improve targeted coverage. DirectFuzz implements directed fuzzing that allows focusing the fuzzing on certain submodules in a larger system—for example, newly added components rather than unchanged older parts—saving verification time.

Differential Fuzzing Against an ISA Reference

Coverage-driven fuzzing is limited in detecting semantic bugs. To address this, differential fuzzing at the RTL level executes the same input on two simulations and compares the results:

1. An RTL simulation of the DUT.
2. An ISA simulation acting as the golden reference model—a deterministic software model of the expected or intended behavior.

If the final state (or trace) differs between the two simulations, a potential bug is flagged. This approach is especially relevant for CPU designs, where a small sequence of instructions can cause divergent behavior.

Representative Tools and Frameworks

RFuzz

RFuzz pioneered the application of AFL-style mutation feedback to RTL designs. Because traditional code coverage is hard to extract from hardware, RFuzz uses mux-coverage as a replacement for code coverage, fed back to AFL. RFuzz supports two execution backends:

• A synthesized design executed on an FPGA (FPGA-accelerated fuzzing).
• A software simulation via Verilator (an open-source tool that compiles Verilog/SystemVerilog into optimized C++/SystemC models).

In the Verilator setup, the fuzzer, DUT, input buffer, and coverage buffer share memory; in the FPGA setup, the fuzzer communicates with the synthesized DUT via a high-bandwidth direct memory access channel, requiring a System on Chip (SoC) with FPGA and CPU on the same board.

DirectFuzz

DirectFuzz builds upon RFuzz, adding directed (DGF-style) fuzzing while still using Verilator to simulate the hardware design. DirectFuzz allows the fuzzer to focus on newly added or modified submodules rather than re-testing unchanged components.

Profuzz

Saravanan et al. note that Verilator introduces an inherent mismatch between key intrinsic hardware characteristics and a software-level abstraction that cannot fully capture these characteristics, such as concurrency and signal interactions. To address this, Profuzz simulates directly at the RTL level rather than relying on Verilator-based software abstraction.

DiFuzzRTL

DiFuzzRTL applies differential fuzzing to CPU RTL designs:

• Uses an ISA simulation as the golden reference model and compares the final state with the RTL simulation; a mismatch indicates a potential bug.
• Uses register coverage (better capturing Finite State Machine state transitions due to clock sensitivity and scaling better) instead of mux coverage.
• Adds new interesting test cases based on coverage from the RTL simulation.

ProcessorFuzz

ProcessorFuzz follows the same differential-fuzzing recipe as DiFuzzRTL but improves coverage by using Control and Status Registers (CSRs) as coverage instead of DiFuzzRTL's register coverage, which can be a misleading coverage metric. To optimize runtime, ProcessorFuzz executes the test case in the (faster) ISA simulation first, marks inputs as interesting based on coverage from that simulation, and only then runs the RTL simulation on inputs deemed interesting.

INSTILLER

INSTILLER is an RTL fuzzer that targets two disadvantages of prior CPU-focused RTL fuzzers:

1. The length of RTL input instructions keeps growing, and longer inputs are ineffective for fuzzing.
2. Related work cannot simulate realistic interruptions well in fuzzing.

INSTILLER addresses these issues through:

• VACO (Variant of Ant Colony Optimization) to distill input instructions, keeping the input length short and efficient for fuzzing.
• Explicit handling for inserting interruptions and exceptions during input generation.
• Hardware-based seed selection and mutation strategies to improve fuzzing performance.

Reported empirical results against state-of-the-art fuzzers on real-world CPU cores:

• 29.4% more coverage than DiFuzzRTL.
• 17.0% more mismatches detected than DiFuzzRTL.
• 79.3% shorter input instructions than DiFuzzRTL (thanks to VACO distillation).
• 6.7% average increase in execution speed from input distillation.

FPGA-Accelerated RTL Fuzzing

Beyond RTL simulation, RTL fuzzing can be accelerated by running the fuzzer and DUT on an FPGA:

• RFuzz synthesizes the DUT on an FPGA and uses high-bandwidth DMA for communication with the fuzzer running on an SoC CPU.
• TurboFuzz runs the entire fuzzer on the FPGA, including the DUT, and offers random and mutation modes for test-case generation. The generated test case is executed on the DUT and compared against an ISA software emulator running on the SoC board's CPU. TurboFuzz also exploits the SoC's hardware snapshot feature to capture the entire FPGA state for debugging mismatches found through differential testing.

Coverage Metrics Used in RTL Fuzzing

Different RTL fuzzers adopt different coverage signals as feedback:

• Mux coverage (RFuzz) — a hardware-native proxy for code coverage suitable when traditional code coverage is unavailable.
• Register coverage (DiFuzzRTL) — better captures FSM state transitions and scales better than mux coverage.
• Control and Status Register (CSR) coverage (ProcessorFuzz) — addresses limitations of register coverage.
• Submodule/structural coverage — used by more recent works to focus on specific hardware structures or modules.

Known Limitations of CGF-Based RTL Fuzzers

CGF-based techniques mark a significant advancement but fall short in addressing the practical realities of hardware design workflows, particularly when verification must focus on incremental changes rather than re-testing the entire system. Additionally, certain DGF implementations such as DirectFuzz exhibit limitations including:

• Inability to capture hardware-specific semantics and structure.
• Misaligned coverage metrics that do not fully reflect design intent.

Relationship to Other Entities

RTL Fuzzing is a sub-technique of Hardware Fuzzing; it specifically targets designs at the Register-Transfer Level, whereas hardware fuzzing as a whole may also operate at higher abstraction levels (e.g., gate level) or on fully synthesized hardware.

Evidence Status

• Entity kind: Technique
• Entity name: RTL Fuzzing
• Supporting evidence:
  • Chunk b682155b-3a68-4f10-a10e-db864d739241 (Intelligent Graybox Fuzzing via ATPG-Guided Seed Generation and Submodule Analysis)
  • Chunk 8ecedf78-330b-4e6b-aa11-c9a9983d09fd (Fuzzing IPv4 modules on FPGAs, sections on RFuzz, DirectFuzz, Profuzz, DiFuzzRTL, ProcessorFuzz, TurboFuzz)
  • Chunk fbff30ca-78e0-4680-8809-fe58437bc6e9 (Fuzzing IPv4 modules on FPGAs, background sections on RTL fuzzing)
  • Public context: arxiv 2401.15967v1 (INSTILLER)