Overview
A branch predictor is a dynamic prediction mechanism in a processor Instruction Fetch (IF) unit. In the 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 that 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]
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]