Skip to content
STIMSMITH

Return Address Stack

Concept WIKI v3 · 5/28/2026

A Return Address Stack (RAS) is a branch-prediction structure used to predict function-return targets. In the provided RISC-V superscalar processor evidence, it is part of the instruction-fetch unit’s dynamic predictor: decoded function calls provide return addresses, and return instructions pop an RAS entry to supply the next predicted program counter. The RAS is also relevant to processor-verification fuzzing because Logic Fuzzer techniques used to perturb branch-predictor targets can be applied to the RAS.

Overview

A Return Address Stack (RAS) is a component of a processor’s dynamic branch predictor. In the cited RISC-V superscalar processor description, the instruction-fetch (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 in that IF unit includes a Branch History Table (BHT), a Branch Target Buffer (BTB), and a Return Address Stack.[1]

The RAS stores return addresses of decoded function calls. When a function-return instruction is encountered, the processor pops an entry from the RAS and uses that entry as the next predicted PC address.[2]

Role in instruction fetch and prediction

Within the described IF unit, the RAS complements other predictor structures:[1]

  • BHT: maintains histories of previous branch outcomes to predict branch direction, such as taken versus not taken.
  • BTB: records target PC addresses for branch instructions to accelerate taken-target determination.
  • RAS: predicts return targets by using return addresses saved from decoded function calls.

Because return instructions often need a predicted target before execution resolves the actual target, the RAS supplies predicted next-PC values for return instructions in the instruction-fetch path.[2]

Verification and fuzzing considerations

The provided Logic Fuzzer evidence discusses fuzzing branch-predictor structures and speculative paths. For BTB fuzzing, the work reports that entries can be fuzzed to provide falsely predicted addresses over a broader range, or even random addresses at runtime. These scenarios can create instruction-TLB page faults on mispredicted paths, and the same technique can be applied to the Return Address Stack.[3]

The same work describes a table-mutator implementation in which a fuzzer object allocates a table with the same size as the branch predictor. Instead of accessing the RTL memory model, the implementation accesses the fuzzer-managed table through DPI calls, and the tables are fuzzed randomly or according to specific patterns during simulation.[4]

Logic Fuzzer may create microarchitectural states that no program could reach. The cited paper nevertheless treats co-simulation failures exposed by fuzzing as potential bugs that must be proved or disproved, and states that the bugs presented in the paper were confirmed by designers.[5]

[1]: Takakis, “UVM-based verification of RISC-V superscalar processors,” describes the IF unit as fetching instructions and predicting the next PC, with a dynamic predictor that includes BHT, BTB, and RAS. [2]: Takakis states that the RAS stores return addresses of decoded function calls and that, when a return instruction is encountered, the popped RAS entry is used as the next predicted PC address. [3]: Kabylkas et al., “Effective Processor Verification with Logic Fuzzer Enhanced Co-simulation,” state that BTB entries can be fuzzed to provide false or random predicted addresses, potentially creating iTLB page faults on mispredicted paths, and that the same technique can be applied to the Return Address Stack. [4]: Kabylkas et al. describe fuzzer-managed tables sized like the branch predictor, accessed through DPI instead of the RTL memory model, and fuzzed randomly or with specific patterns during simulation. [5]: Kabylkas et al. state that Logic Fuzzer can create unreachable microarchitectural states, but co-simulation failures exposed by fuzzing are potential bugs requiring investigation, and that the paper’s presented bugs were confirmed by designers.

LINKED ENTITIES

1 links
mispredicted path fuzzing USES

CITATIONS

5 sources
5 citations
[1] The IF unit fetches instructions and predicts the next PC, and its dynamic predictor includes BHT, BTB, and RAS. [PDF] UVM-based verification of RISC-V superscalar processors
[2] The RAS stores return addresses of decoded function calls and pops an entry for use as the next predicted PC when a function-return instruction is encountered. [PDF] UVM-based verification of RISC-V superscalar processors
[3] BTB fuzzing can provide false or random predicted addresses at runtime, potentially causing iTLB page faults on mispredicted paths, and the same technique can be applied to the RAS. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co-simulation
[4] Logic Fuzzer table mutators allocate fuzzer-managed tables matching branch-predictor size, access them through DPI instead of the RTL memory model, and fuzz them randomly or with specific patterns during simulation. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co-simulation
[5] Logic Fuzzer can create microarchitectural states no program could reach, but co-simulation failures exposed by fuzzing are treated as potential bugs requiring proof or disproof, and the paper’s presented bugs were confirmed by designers. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co-simulation

VERSION HISTORY

v3 · 5/28/2026 · gpt-5.5 (current)
v2 · 5/28/2026 · gpt-5.5
v1 · 5/27/2026 · gpt-5.5