Overview

In the cited Logic Fuzzer work, a TLB appears as one of the processor memory/table structures whose entries can be affected by verification-time fuzzing. The paper describes table mutators as Logic Fuzzer mechanisms that mutate RTL memories, and it lists TLB-entry mutation alongside cache-entry mutation as an example use case.

The provided evidence does not define the internal organization of a TLB or explain address-translation semantics. It supports only the role of TLBs and TLB entries as microarchitectural state that can be targeted or perturbed in the Logic Fuzzer verification context.

Use with table mutators

Logic Fuzzer table mutators allow RTL memories to be mutated. In the paper's examples, branch-predictor tables can be fuzzed because they should not affect the architectural correctness of the running program, while other examples include:

• random invalidation of cache or TLB entries;
• value fuzzing of entries that are already invalid.

The purpose of these mutations is to expose different microarchitectural behaviors during verification without relying solely on the generated program to reach those states.

Reset-state and state-coverage motivation

The paper notes that, in a verification flow, caches, TLBs, and other memory elements may start execution from reset state. This is described as problematic because potentially bug-revealing microarchitectural states may be lost. The authors state that Logic Fuzzer table mutators can partially close this gap by pre-populating or randomizing tables.

Fault-related effects in fuzzed execution

The evidence also mentions TLBs in the context of fuzzed control-flow prediction. The paper states that fuzzing BTB entries can provide false or random predicted addresses at runtime, and that such scenarios can potentially create iTLB page faults on the mispredicted path. This evidence concerns effects of branch-prediction fuzzing on instruction-side TLB fault behavior, not a standalone definition of TLB operation.