Overview
A table mutator is a Logic Fuzzer technique that allows RTL memories to be mutated during verification. The MICRO-54 Logic Fuzzer paper describes table mutators as a way to fuzz memory-like microarchitectural structures such as branch-predictor tables, cache entries, and TLB entries. Examples include random invalidation of cache or TLB entries, fuzzing values in already-invalid entries, and freely fuzzing branch-predictor tables when their contents must not affect architectural correctness.
Table mutators are intended to expose behavior that ordinary program execution may not reach. The paper notes that Logic Fuzzer can create microarchitectural states that no program could reach, so failures found by fuzzing are treated as potential bugs that must be proved or disproved by engineers.
Implementation model
In the described implementation, a fuzzer object allocates a table with the same size as the target structure, such as a branch predictor. Instead of accessing the RTL memory model directly, the implementation accesses the fuzzer-managed table through the DPI. During simulation, the table can be fuzzed randomly or according to specific patterns.
For cache-oriented uses, the RTL can replace tag arrays with wrappers that access table mutators through DPI. In the CVA6 example, the authors report replacing tag-array access with table-mutator wrappers and using a small Table Mutator method to alter entries so that cache accesses are steered toward a target bank.
Uses in processor verification
Branch predictor fuzzing
Table mutators can be applied to branch-predictor tables because their microarchitectural state can be changed without directly changing the architecturally correct result of the program. The evidence describes allocating fuzzer tables sized like the branch predictor and fuzzing them randomly or with patterns during simulation.
The same section discusses fuzzing BTB entries to provide falsely predicted addresses, or even random addresses at runtime. Such scenarios can create iTLB page faults on the mispredicted path, and the paper states that the same technique can be applied to a Return Address Stack.
Cache and TLB fuzzing
The technique also applies to cache and TLB structures. The paper gives examples including random invalidation of cache or TLB entries and value fuzzing of entries that are already invalid. In a CVA6 L1 cache example, mutating tag arrays and valid bits was used to steer cache accesses toward an underutilized bank, avoiding the need to regenerate binaries or understand cache replacement policy details.
Mispredicted-path instruction injection
To stress the mispredicted path, the described flow replaces the instruction-cache tag and data arrays with table mutators. The instruction-cache logic reads and writes those tables through DPI. The setup then forces the Branch History Table to predict taken and forces the Branch Target Buffer to return an address with a specific tag. When that tag is observed, the fuzzer tables provide a random instruction stream.
This is motivated by the observation that high branch-prediction accuracy can make the mispredicted path under-tested. The paper reports that, after more than 200 CVA6 tests, instruction coverage on the mispredicted path did not reach 60% without fuzzing, while fuzzing can insert arbitrary instructions into that path regardless of the binary.
Role in checkpoint-based verification
The paper also positions table mutators as a way to partially close a gap in checkpoint-based co-simulation: caches, TLBs, and other memory elements may otherwise start from reset state, losing microarchitectural state that could manifest bugs. The authors suggest that Logic Fuzzer table mutators can partially close this gap by pre-populating or randomizing tables.
Verification caveats
Table mutators may create microarchitectural states that are not reachable by any real program. The cited paper treats resulting co-simulation failures as red flags rather than automatic correctness failures: they are potential bugs that engineers must prove or disprove.