Overview
Logic Fuzzer (LF) is a processor verification technique introduced for simulation-phase bug finding in RISC-V cores. Its purpose is to push a processor outside normal execution flow or operating conditions so that co-simulation can expose difficult, simulation-resistant functional bugs. The paper positions LF as an enhancement to Dromajo-based co-simulation, where Dromajo acts as the comparison framework and LF perturbs internal RTL behavior during the same tests. [C1][C2]
Unlike input-stimuli fuzzing, which stresses the design-under-test from the outside, Logic Fuzzer uses an “inside-out” approach: it fuzzes actual RTL logic wherever possible. The authors explicitly distinguish LF from external stimulus fuzzers such as RFUZZ-like flows and property-based input generation. [C3]
Goals and scope
Logic Fuzzer is not primarily intended to maximize coverage metrics. The stated purpose is to create irregular execution flow, much of which may not be captured by toggle coverage or similar code-coverage proxies. The authors note that toggle coverage is useful as a confidence metric, but not a full indicator that a system is verified. [C4]
The technique can create microarchitectural states that no program could reach naturally. The paper treats failures exposed from those states as red flags that engineers must confirm or disprove; the reported LF-exposed bugs were confirmed by designers. [C5]
Mechanisms
Table mutators
Logic Fuzzer can replace or wrap internal hardware tables so that RTL accesses are redirected to fuzzer-managed tables through DPI calls. In the paper’s branch-predictor example, the fuzzer allocates a table with the same size as the branch predictor table; instead of reading the RTL memory model directly, the implementation accesses the fuzzer table through DPI. During simulation, those tables can be fuzzed randomly or with configured patterns. [C6]
The paper also describes using table mutators for cache and memory-structure experiments. For example, mutating tag arrays and valid bits can steer cache accesses toward a target bank with relatively small RTL changes: five RTL-side lines to replace tag arrays with wrappers plus a short Table Mutator method. [C7]
Congestors
Logic Fuzzer uses congestors to perturb flow-control or backpressure-like signals. A verification engineer identifies congestible points in the design, configures one congestor object per signal, and sets each congestor’s period and random seed in a JSON configuration file. [C8]
In BOOM, the authors inserted a congestor on the ready signal of the reorder buffer and randomly pulled the ready signal low even when the ROB was ready. This caused additional toggles in the frontend, core, and load-store unit, demonstrating that a single congestor could activate logic not touched by over 200 tests. [C9]
Mispredicted-path fuzzing
Logic Fuzzer can stress speculative execution paths that normal tests may under-exercise. The paper observes that high branch-prediction accuracy can cause the mispredicted path to be overlooked from a verification standpoint. In CVA6, after more than 200 tests without fuzzing, the unique RISC-V instruction coverage in the mispredicted path did not reach 60%; with fuzzing, the authors report that they could insert any instruction into the mispredicted path and reach 100% instruction coverage earlier. [C10]
The technique can also fuzz Branch Target Buffer entries to provide false or random predicted addresses at runtime, potentially causing iTLB page faults on the mispredicted path. The same approach is described as applicable to the Return Address Stack. [C11]
Implementation with Dromajo
For a systematic and configurable implementation, the authors embedded Logic Fuzzer into the Dromajo infrastructure. They extended the base APIs so RTL can access fuzzers through DPI calls, and they configured fuzzers through Dromajo’s JSON configuration file. [C6]
The paper also reports a proof-of-concept automatic insertion flow for BOOM congestors using Chiffre. In that experiment, annotated Chisel RTL signals were automatically broken and instrumented with congestor logic. Because Chiffre works with Chisel hardware descriptions, the experiment was limited to BOOM. [C12]
Evaluation results
The reported evaluation used three RISC-V cores: CVA6, BlackParrot, and BOOM. Dromajo alone found nine bugs, while Dromajo enhanced with Logic Fuzzer exposed thirteen bugs using the same test set, without creating additional tests. [C13]
One LF-exposed example involved CVA6 iTLB mutation: a fuzzed instruction TLB entry was made valid while its translation pointed to a nonexistent memory region, leading to an exception-handling mismatch between Dromajo and CVA6. [C14]
Another example involved BlackParrot’s Branch Target Buffer. Fuzzing generated an address that mapped to off-chip memory, which froze the system when the decoded address routed to no matching tile device. [C15]
Relationship to coverage
The authors caution that LF-discovered bugs generally did not correlate with toggle coverage. Of the bugs found by Logic Fuzzer, only one, B12, was directly correlated with toggle coverage; the remaining three were attributed to randomized LF-created events and combinations of signals and states that could remain undetected even with 100% toggle coverage. [C4]