Overview
A branch predictor is a dynamic prediction mechanism in a processor's Instruction Fetch (IF) unit. In cited RISC-V superscalar processor design, the IF unit fetches instructions from the instruction cache and predicts the next Program Counter (PC), i.e., the address of the next instruction to fetch. The dynamic predictor is described as an instrumental part of the IF unit. [citation: IF-unit-next-PC]
Main structures
The cited IF-unit organization describes the dynamic predictor as comprising three key structures:
- Branch History Table (BHT): maintains the history of previous outcomes for each branch and predicts the current branch direction (taken or not-taken). The cited design uses a GShare indexing scheme for this direction predictor. [citation: predictor-components]
- Branch Target Buffer (BTB): records the target PC address of each branch instruction to expedite determination of branch-taken addresses. [citation: predictor-components]
- Return Address Stack (RAS): stores return addresses of decoded function calls; when a function return instruction is encountered, the popped RAS entry is used as the next predicted PC address. [citation: predictor-components]
Updates and recovery
The predictor-update interface informs the branch predictor whether a branch was taken or not. In verification of the IF unit, the cited work says the sequences driving this interface should resemble real code patterns such as for loops, while loops, nested loops, and if blocks rather than providing a purely random prediction for each branch. [citation: predictor-update-interface]
The cited processor also includes a flush controller in the Instruction Decode stage. It checks whether a branch prediction made during IF was correct by comparing the resolved branch result with the stored prediction. The branch result comes from a predictor-update signal created in the Execute stage by the branch resolve unit; the initial predictions are stored in a FIFO so the oldest prediction can be compared when an update arrives. If the prediction was wrong, the pipeline is flushed and redirected. [citation: flush-controller]
Parameterization in RTL design
Cited RISC-V RTL design evidence states that a robust RTL codebase must be hyper-parameterizable, and explicitly lists branch-predictor structures among the microarchitectural knobs that must be configurable: "Microarchitectural Knobs: Configurable pipeline depth, branch predictor structures (BHT vs. BTB sizes), cache associativity, and bus interfaces (AXI, AHB, TL-UL)." [citation: rtl-parameterization-knobs] The cited parameterization approach is part of broader hyper-parameterization that also covers XLEN (32/64/128), selectable ISA extensions, and bus-protocol selection. [citation: rtl-parameterization-king]
Reconstructability as a micro-architectural structure
Cited FPGA debugging work (Prelude) treats the branch predictor as part of the class of dynamic micro-architectural structures that pose unique challenges for state reconstruction. Table 1 in that work compares a full-snapshot approach against Prelude's lighter method, and lists branch predictors explicitly among the micro-architectural state categories not collected by Prelude (✗), in contrast to architectural registers (PC, GPRs, CSRs, FPRs) which are required (✓). [citation: prelude-table-comparison] The full-snapshot baseline is reported at 23.4 MB of micro-architectural state versus Prelude's 1 KB (0.004%); the total snapshot sizes are 4.023 GB (full) versus 18.6 KB (0.00046%). [citation: prelude-snapshot-sizes]
The cited Prelude evaluation reports that the Fetch module has a lower reproduction rate due to dynamic structures like the branch predictor requiring long execution history, while Decode and Rename achieve higher rates because their states depend mainly on current instructions and can be reconstructed from short segments. Overall, the geomean signal reproduction rate rises from 86.7% at 10² instructions to 91.5% at 10⁶ instructions, indicating that longer workloads provide more complete context for reconstructing micro-architectural state. [citation: prelude-front-end-repro] Other dynamic modules are characterized similarly: the LSU module maintains relatively stable reproduction rates as its state reflects memory access patterns that are partially dynamic but largely deterministic over short segments, while the ROB reaches very high reproduction rates because most of its signals store instruction information, with only a small portion representing dynamic control signals. [citation: prelude-module-repro]
The Prelude warm-up phase after snapshot replay is reported to allow internal queues, buffers, and predictors to settle, ensuring that replay proceeds under a consistent and reproducible micro-architectural context. [citation: prelude-warm-up]
Verification and fuzzing relevance
The Logic Fuzzer evidence identifies the branch predictor as a significant part of the design with a major effect on modern processor performance. It also notes that branch-prediction accuracy can exceed 95%, which creates a verification risk: the mispredicted path may be overlooked. [citation: high-accuracy-verification-risk]
The cited work argues that instructions on the mispredicted path should be tested because some may have side effects. In a CVA6 experiment, after more than 200 tests without fuzzing, unique RISC-V instruction coverage on the mispredicted path did not reach 60%. With fuzzing, the work reports that any instruction can be inserted into the mispredicted path regardless of the binary, reaching 100% instruction coverage earlier. [citation: mispredicted-path-coverage]
BTB behavior is also used as a fuzzing target. Without fuzzing, BTB PC predictions in the cited experiment stayed within a narrow range because the BTB predicts from the history of resolved branch target addresses and is therefore constrained to the address range encoded in the ELF .text section. With fuzzing enabled, BTB entries can be fuzzed to produce falsely predicted addresses over a broader range or even random addresses at runtime, exercising non-typical speculative instruction-address generation. [citation: btb-fuzzing-address-range]
In the Dromajo-based Logic Fuzzer implementation, the fuzzer infrastructure is exposed to RTL through DPI calls and configured through Dromajo's JSON configuration file. The cited interaction flow shows the RTL accessing the table mutator of the processor's branch predictor; the Dromajo fuzzer object allocates a table with the same size as the branch predictor. [citation: dromajo-branch-predictor-table-mutator]
Reset behavior for graybox fuzzing (CVA5)
Cited TaPaFuzz evidence notes that software graybox fuzzing frameworks typically implement control-flow (CF) monitoring by patching additional function calls into the target program, which causes interrupts and runtime overheads. As an alternative, CF monitoring can be implemented in hardware running in parallel to actual software execution, ideally with no additional runtime overhead. [citation: tapafuzz-monitoring]
The cited TaPaFuzz contributions explicitly include microarchitecture fixes to the CVA5 RISC-V core, allowing it to fully reset its caches and branch predictors between fuzzer runs; without such resets, state left in the predictor and caches from prior jobs could pollute subsequent runs in a hardware-accelerated fuzzing workflow. [citation: tapafuzz-cva5-reset] An AXI wrapper was also contributed to legalize aborted AXI transfers that would otherwise hang due to random partial design resets occurring between fuzzer job runs; the wrapper operates solely on the AXI and reset interfaces and is portable across RISC-V core microarchitectures and different AXI components. [citation: tapafuzz-axi-wrapper]
Cited TaPaFuzz resource-utilization evidence reports that the BRAM variant uses 54%–66% additional LUTs and registers compared to a plain CVA5 RISC-V core processing element at a 10 MHz lower frequency, while the DRAM/DDR4 variant requires 2%–5% more registers and LUTs over the BRAM variant and reduces the device BRAM footprint by 80 KiB, reflecting a tradeoff with additional cache and branch prediction logic enabled in the RISC-V processor. [citation: tapafuzz-resource-tradeoff]
Active research directions (public context)
Public-context sources describe ongoing branch-predictor research beyond the classic BHT/BTB/RAS structures:
- Load Driven Branch Predictor (LDBP) targets branches whose outcome depends on hard-to-predict load data. The cited work reports that branches dependent on hard-to-predict load data are the leading branch misprediction contributors and that scaling a 256-KBit history-based predictor to 1 MBit reduces mispredictions by only ~10%. LDBP exploits the observation that although random load data determines outcomes, the load address for most of these cases follows a predictable pattern (e.g., arrays, maps). It pre-triggers predictable loads, buffers precomputed branch outcomes, and uses them to predict. Reported results: augmenting a 150-Kbit IMLI with LDBP reduces average branch mispredictions by 20% and improves average IPC by 13.1% on SPEC CINT2006 and GAP benchmarks compared with a standalone 256-Kbit IMLI. [citation: ldbp-summary]
- Branch prediction for graph applications observes that real-world graph applications generally exceed cache size, that branch mispredictions occur frequently in graph processing, and that further optimization of branch predictors is still possible to handle branches that cause mispredictions, beyond improvements targeting the memory hierarchy. [citation: graph-bp-summary]