Patents Inc. Title
US12487830B1 Ventana Prediction unit with first predictor that provides a hashed fetch address of a current fetch block to its own input and to a second predictor that uses it to predict the fetch address of a next fetch block

整体上看，这篇 Ventana 专利包含了两个层层递进的前端预测/取指思想：

  1. 第一层，是把传统 BTB 从“只做控制流目标预测”扩展成“顺便缓存 I-cache 的 set/way 结果”，从而把原本串行的取指流程折叠成并行的 folded fetch pipeline
  2. 第二层，是在这个基础上再加入一个单周期的小预测器 SCP，让它先快速预测“当前 fetch block 会产出的下一块地址的哈希信息”，再把这些哈希信息喂给更复杂但更准确的多周期预测器 FBPU，使后者能提前启动，从而维持每拍一个 fetch block 的高吞吐前端。

问题

现代高性能处理器的取指过程很长：

  1. 用虚拟取指地址去 ITLB 做地址翻译，得到物理地址；
  2. 用物理地址的 set index 去访问 I-cache tag 阵列，判断命中哪一路；
  3. 再去 data array 读出真正的指令块

这三步既依赖存储结构访问延迟，又天然串行，所以现代前端会形成较长的 instruction fetch pipeline。

问题是：分支预测一旦错了，恢复正确路径的延迟就会被长取指流水线进一步放大，执行单元在这段时间里会空转，性能损失严重

解法：BTB 不只预测跳转，还预测 I-cache 的 set/way

Ventana 的解法是：在 BTB 的每个条目里额外存储信息—— fetch block 上次是从 I-cache 的哪个 set、哪个 way 取出来的

额外信息包括： predicted set index 和 predicted way number

下一次遇到同一个 fetch 地址时：

  • BTB 命中后，不必先等 ITLB 翻译和 tag 比较全部完成
  • 可以直接拿 BTB 预测的 set/way 去读 I-cache data RAM
  • 同时并行地做 ITLB 翻译和 tag 检查；
  • 最后再用真正算出来的 set/way 去验证 BTB 预测的正确性

专利将这个过程称为 folded pipeline：原本串行的 translation / tag / data 三个子流水段，被折叠成并行执行

前端整体架构

前端整体架构包括：

  • instruction cache
  • PRU（predict unit）
  • FBD FIFO
  • IFU
  • FBlk FIFO

这里有两个概念特别重要。

Fetch Block Descriptor（FBD）

PRU 不直接把指令交给 IFU，而是先生成 FBD: 取当前 fetch block 的请求描述符，包括信息：

  • BTB hit 标志
  • predicted set index
  • predicted way number
  • fetch block length
  • FVA（fetch virtual address）

BTB Entry

一个 BTB Entry 包含：

  • BTB tag
  • predicted set index
  • predicted way number
  • fetch block length
  • PC-relative target address
  • termination type

predicted set index / predicted way

  • 上一次真正成功取到该 fetch block 时，I-cache 实际命中的 set 和 way
  • 下次预测同地址时，BTB 直接把它们拿出来当预测值

为节省存储空间，只在 BTB 里存需要翻译后才能知道的部分 set index 位；另外那些无需翻译、可直接从虚拟地址低位得到的 set index 位，则从当前 FVA 直接取

专利提到一种实现里只需大约 5 bits set index + 2 bits way，就有机会把 6 级取指路径压成 2 级

fetch block length / termination type

这两个字段标识：这个 fetch block 本身的控制流终止特征：顺序结束? / PC-relative branch? / indirect branch? / return? /…

用于为 PRU 的 next fetch group addr logic 提供信息

folded instruction fetch pipeline 微架构

取指流水被拆成三个子路径：

  • translation 子流水：ITLB 把 FVA 翻成 FPA，并得出 correct set index
  • tag 子流水：根据 set index 查 ICTR，比较 tag，得出 correct way
  • data 子流水：根据 set/way 去 ICDR 取真正的指令块。

1. folded 模式

当 BTB hit 时：

  • data 子流水直接使用 BTB 预测的 set index + way number 去读 ICDR
  • translation 子流水同时去做 ITLB 翻译
  • tag 子流水同时做 tag 比较，算出真正的 correct way

2. unfolded 模式

当 BTB miss，或者后续发现有 set/way 预测错误时，就退回正常串行流程：

  1. 先翻译
  2. 再查 tag
  3. 再读 data

错误处理与 folded/unfolded 的动态切换

预测错误: set mismatch 和 way mismatch

在 folded 模式下，后台会并行检查 BTB 预测的 set/way 是否正确

  • 如果 predicted set != correct set，触发 set mismatch；
  • 如果 set 对但 predicted way != correct way，触发 way mismatch。
  1. set mismatch
    • 当前 fetch request 会被取消
    • 已经从 ICDR 读出来的数据不写入后续 FIFO
    • 该请求会以 unfolded 方式 replay ；
    • replay 后 BTB Entry 会被更新成正确的 set 和 way
  2. way mismatch (set match)
    • 请求同样取消
    • 可以用已知正确的 set/way 更快地再进行一次 folded 处理
    • 然后只更新 BTB 的 way 字段

流水线需要能在 folded 与 unfolded 之间动态切换:
专利举例说，在一个实现里 translation/tag/data 各自是两级，那么：

  • folded 模式有效延迟只有 2 个周期；
  • unfolded 模式有效延迟则是 6 个周期。

触发 unfolded 的条件包括：

  • BTB miss
  • ITLB miss
  • I-cache miss

大多数“常见且重复”的前端路径尽量走 folded path，异常/冷启动/失配情况再退回保守慢路

SCP + FBPU 两级预测结构

  • SCP（Single-Cycle Predictor）：很小、很快、每拍都能出结果，但结果只是 hashed next fetch group，不能直接去取指
  • FBPU（更复杂的 Fetch Block Prediction Unit）：多周期、更准确，利用 SCP 的输出去发起 BTB/分支预测器/RAP 等更完整的查找，最终给出真正可用于取指的 next FVA 和 FBD

SCP Entry

SCP entry 里主要存的是：

  • HNFAI：hashed next fetch address index
  • HNFAT：hashed next fetch address tag
  • BrDir-S：分支方向
  • IndBr-S：是否为间接分支
  • useful bit: 用于控制训练/替换策略
  • hashed pc tag

SCP 存储哈希信息，不存完整地址: 足够快，足够小，目标是驱动 FBPU

  • SCP 输出的信息很小，比如可能只要 25 bits 左右，因此可以做得足够小、足够快，从而每个时钟周期都能给出一个新预测
  • 但这些哈希信息本身不足以直接供 IFU 去 I-cache 取指，因为哈希不可逆，不能还原完整 fetch address

SCG 输出的小信息会被 FBPU 使用，用来提前发起：

  • BTB 查找
  • 条件分支预测器查找
  • 间接分支预测器查找
  • 分支历史更新
  • 可能的返回地址预测相关操作

在高性能前端里，真正复杂的预测器常常多周期、表很多、访问路径长。如果等完整 next FVA 出来后再启动这些预测器，就会拖慢吞吐。Ventana 的设计是：

  • 先用 SCP 预测一个“压缩版未来”
  • 用这份压缩版未来去给 FBPU 提前热身
  • FBPU 再生成完整可用的 next FVA 与 FBD。

PRU 五级流水

  • PR1：访问 SCP 出结果
    • SCP 的输入来自上一拍它自己输出的一部分，因此形成自反馈链。
  • PR2：FBPU 生成供更大预测器使用的索引/标签/历史
  • PR3：启动 FBPU 各预测结构访问
    • 开始访问 BTB、条件分支预测器、间接分支预测器等结构
  • PR4：拿到 FBPU 正式预测结果，形成 FBD (包括真正的 next FVA)
    • BTB hit
    • predicted set index / way
    • fetch block length
    • PC-relative target
    • termination type
    • 条件分支方向
    • 间接跳转目标
    • 返回地址预测结果
  • PR5：检查 SCP 是否预测错误(以 PR4 得到的正确预测结果为基准)
    • 把 PR4 的 next FVA 再 hash 成正确的 HNFAI/HNFAT，与 PR1 SCP 给出的 HNFAI/HNFAT 比较
    • 如果 mismatch，说明 SCP 预测错误，进行恢复：

SCP 预测错误恢复

  • PRU pipeline 被 flush
  • SCP 被训练填充
  • PRU 用“正确”的下一块信息重新启动