RTL fuzzers have been coverage-guided since RFUZZ. Coverage-guided fuzzing finds unexplored paths, but it has no model of what the paths mean -- it cannot reason about invariants, protocol sequences, or the semantic behavior of the design under test. ChipFuzzer fixes this with a dual-stage workflow: a Coverage-Guided stage that uses control-flow similarity and discrepancy analysis to steer LLM-driven test generation, followed by a Bug-Guided stage that primes the LLM on historical bug data and concentrates new testcases on proven-risky regions. Across three open-source CPU designs, ChipFuzzer improves average condition coverage by 5.8 percentage points and bug detection rate by 21.1 points over the strongest prior baseline.
The LLM is doing real work here, not just reformatting seeds. The Coverage-Guided stage asks the LLM to reason about which control-flow branches are structurally similar to unexplored branches and to generate inputs that activate them. The Bug-Guided stage gives the LLM a map of where bugs have concentrated historically and asks it to prioritize those code regions. Both of these are tasks that require semantic understanding of RTL -- something coverage signals alone cannot provide. That is the gap that HiFuzz (RL-based) and prior mutation fuzzers could not close.
The verification bottleneck in complex RTL is not compute. It is that generating inputs that exercise corner-case behavior requires expertise the fuzzer does not have. ChipFuzzer compresses that gap: teams running it can replace a significant fraction of hand-written directed tests with LLM-steered fuzzing that adapts based on what it already found. The remaining bottleneck is corpus quality -- ChipFuzzer's bug-guided stage depends on having historical bug data. Teams that have accumulated bug databases from past tapeouts get compounding returns from this. Teams shipping their first complex SoC do not. The open-source core ecosystem (CVA6, BOOM, Ibex) starts to look like shared verification infrastructure for exactly this reason.