Skip to content
STIMSMITH

table mutator

Concept WIKI v1 · 5/27/2026

A table mutator is a Logic Fuzzer mechanism for processor verification that replaces or wraps RTL memory-like tables so their contents can be fuzzed, pre-populated, invalidated, or otherwise mutated during simulation. In the cited MICRO-54 work, table mutators are used on structures such as branch-predictor tables, cache tag/data arrays, valid bits, TLB entries, and other memory elements to stress under-exercised microarchitectural states without regenerating test binaries.

Overview

A table mutator is a Logic Fuzzer mechanism that allows RTL memories or table-like microarchitectural structures to be mutated during verification. The cited work describes table mutators as a way to fuzz structures such as branch-predictor tables, cache entries, TLB entries, and invalid entries, while preserving architectural correctness assumptions for structures whose contents should not affect the correctness of the running program.

What it mutates

The paper gives several examples of target structures:

  • branch-predictor tables, which can be freely fuzzed at a given moment because they must not affect architectural correctness;
  • cache and TLB entries, including random invalidation;
  • already-invalid entries, whose values can be fuzzed;
  • instruction-cache tag and data arrays, used to inject randomized instruction streams on mispredicted paths;
  • cache tag arrays and valid bits, used to steer accesses toward selected cache banks or ways.

Implementation pattern

The implementation pattern is to replace an RTL memory model or array with a wrapper that accesses a fuzzer-managed table through DPI. In the Logic Fuzzer implementation described in the paper, a fuzzer object is configured to allocate a table with the same size as the relevant RTL structure, such as a branch predictor. During simulation, the RTL-side implementation accesses the fuzzer table through DPI instead of the original RTL memory model, and the table contents are fuzzed either randomly or with specific patterns.

For cache-focused use cases, the authors describe replacing tag arrays with wrappers that access Table Mutators through DPI. In their CVA6 example, they edited five RTL lines and added a simple twelve-line method in the Table Mutator class to mutate entries and stress a cache bank of interest.

Verification uses

Stressing cache behavior

In a CVA6 L1 cache experiment, over 50 random tests generated with Google's riscv-dv showed that the regular run favored way 0 for stores under the tested memory-access pattern. Instead of regenerating binaries and constraining address generation to stress underutilized ways, the authors mutated tag arrays and valid bits to steer cache accesses to the target bank with less effort.

Stressing mispredicted paths

Table mutators are also used to insert random instructions into a mispredicted path. The described flow replaces instruction-cache tag and data arrays with table mutators, forces the Branch History Table to predict taken, forces the Branch Target Buffer to provide an address with a specific tag, and programs the fuzzer tables to return a random instruction stream when that tag is observed.

Restoring or randomizing microarchitectural state

The paper notes that checkpoint-based co-simulation can start caches, TLBs, and other memory elements from reset state, losing potentially important microarchitectural state. Logic Fuzzer's Table Mutators are proposed as a partial way to close that gap by pre-populating or randomizing such tables.

Relationship to Logic Fuzzer

Table mutators are one of the fuzzing mechanisms used by Logic Fuzzer. They complement congestors: congestors perturb control/backpressure-like signals, while table mutators perturb memory-like RTL structures and microarchitectural tables.

LINKED ENTITIES

1 links
Logic Fuzzer USES

CITATIONS

6 sources
6 citations
[1] Table mutators allow RTL memories to be mutated and can fuzz branch-predictor tables, invalidate cache or TLB entries, and fuzz values of already-invalid entries. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...
[2] A table mutator can be implemented by replacing RTL memory access with access to a fuzzer-managed table through DPI, with contents fuzzed randomly or using specific patterns. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...
[3] In the CVA6 cache example, tag arrays and valid bits were mutated to steer cache accesses to a bank of interest; the authors report replacing tag arrays with DPI wrappers and implementing a small Table Mutator method. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...
[4] The CVA6 L1 cache experiment used more than 50 random tests generated with Google's riscv-dv and observed way/bank utilization differences with and without tag-array mutation. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...
[5] To insert random instructions into a mispredicted path, the authors replaced instruction-cache tag and data arrays with table mutators, forced branch-prediction structures, and programmed fuzzer tables to provide a random instruction stream for a specific tag. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...
[6] Logic Fuzzer's Table Mutators can partially address the loss of microarchitectural state in checkpoint-based co-simulation by pre-populating or randomizing tables such as caches, TLBs, and other memory elements. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...