Patents Inc. Title
US11720365B2 alibaba Path prediction method used for instruction cache, access control unit, and instruction processing apparatus

背景问题

这篇专利针对的是: 处理器前端里必须尽快知道“下一拍该去哪里取指令”的问题

传统前端结构：

  • I-cache：按给定地址取指
  • BTB：给出跳转目标
  • 分支方向预测器：判断 taken / not taken
  • 预解码信息：帮助快速识别指令边界、控制流类型

但这些结构之间往往是串行的：先拿到当前块，再预解码，再识别 taken，再查 BTB，再决定下一块地址

这样会带来两个问题：

  1. 前端控制流决策链条太长, 会拉长关键路径
    • 特别是当一个 cache line 里有多条指令，甚至包含多个 target
  2. 为了加快取指，容易引入额外访存和额外动态功耗
    • 如果每次都去访问更宽、更深的预测结构，或者反复读 cache/BTB，性能可能提升有限，但功耗会增加很多

这篇专利的出发点更偏向于：

  • 把“下一条取指路径”的信息尽量前置
  • 在 cache 访问控制层面就做路径选择
  • 把跳转路径预测和顺序路径预测结合起来
  • 在不显著增加硬件复杂度的情况下改善前端吞吐/功耗

总体思想：Path Prediction（路径预测）

处理器前端真正需要的，不只是某一条 branch 的方向，而是“接下来要取哪一条 instruction path / cache line / sub-line”

专利把预测问题抽象成：

  • 当前 PC 所在的取指单元中，有若干可能的“后续路径”
  • 前端需要尽快决定“应该把哪一路作为下一条要送给解码器的候选”

基本处理流程

保留了经典前端工作方式：

  1. 根据程序 PC 获得物理地址；
  2. 取得一个 instruction packet
  3. 进行 pre-decode
  4. 判断里面是否有 jump instruction
  5. 若有，则从 BTB 获取 target address
  6. 基于 target address 再获取 instruction packet
  7. 暂存后送给解码单元

但不同点在于，这篇专利进一步引入了“路径预测信息”，并试图让访问控制逻辑在更靠前的位置就利用这些信息，从而减少单纯依赖“取到后才知道”的迟滞

I-cache 组织: 多条 path 做路径选择

  • Instruction cache 的组织形式改为 Path 0 和 Path 1 (其实和组相联类似)
  • Access control unit 内包含：
    • path maintenance unit
    • path prediction unit
  • 每个 cache line 或路径项不只存指令字节，还存 path boundary / block boundary / 跳转相关信息

然后由 access control unit 做的事情是：

  1. 根据当前 instruction address、tag、路径命中关系
  2. 对不同 path 的候选项进行比较；
  3. 通过 mux 选出应该进入前端后续阶段的那一路
  4. 同时维护 path 状态，并更新预测信息

jump path prediction + sequential path prediction

Jump path prediction

当当前 instruction packet 经过预解码后发现存在 jump instruction 时：

  • 需要知道应该跳去哪里
  • 需要知道应该选择哪条 cache line / path
  • BTB 提供目标相关信息
  • path prediction unit 配合访问控制来选路

Sequential path prediction

顺序取指本身也需要路径预测

即便当前没有 jump，顺序执行也存在困难，原因在于：

  • 一条指令包可能跨越 cache line 边界
  • 一个 cache line 中可能有多条候选 continuation
  • 路径组织可能是多路的，不是简单“PC+line size”

sequential path predictor，里面有多个 path（Path 0, Path 1, …），通过 MUX 选出输出的 ws。

传统设计认为：“顺序 next line”视为不需要专门预测；
而该专利认为，考虑到 instruction cache 的路径组织方式、压缩/变长指令、边界跨越、预解码等因素，顺序前进仍然可能有多种候选路径，需要一个顺序路径预测器来加速选择

BTB 不只是给 target，还能承载 path 预测信息

BTB 不是只存一个 branch PC → target PC 的映射，而是还关联了 jump path predictor，并输出 ws

这意味着：

  • BTB 项中不只是地址信息, 可能编码了与“路径命中/路径选择”相关的元信息
  • BTB 被扩展成更靠近“前端路径索引器”的结构

于是整个前端就形成了两套互补机制：

  • BTB / jump path predictor：面向控制转移
  • sequential path predictor：面向顺序续接

二者共同为 access control unit 提供“下一路应该选谁”的依据

10. 图 7 的流程：先查 BTB 得到路径预测信息，命中则直接辅助选线；不命中则回退到 cache 并反向更新 BTB

图 7 很重要，因为它把“命中路径”和“未命中路径”都交代了。

流程：

  1. Obtain an instruction
  2. Access BTB to obtain path prediction information
  3. 如果 BTB hit
    • 进行 pre-decode
    • 判断是否 jump instruction
    • 若是，则依据 jump path prediction 选择 cache line
    • 若不是，则执行 sequential path prediction
  4. 如果 BTB miss
    • 访问 instruction cache 获取 target address 或相关内容
    • 若命中，再用 path hit information 更新 BTB

这说明两个关键点：

10.1 BTB 在这里是“路径预测缓存”

BTB 命中时，前端可以少走弯路，直接借助已有的 path prediction info 来选路。

10.2 I-cache 在这里又成了“训练来源”

当 BTB 没有足够信息时，可以从 instruction cache / predecode / path hit information 中恢复或学习这些信息，然后回写更新 BTB。

也就是说，这篇专利不是把 BTB 和 I-cache 完全割裂，而是让它们形成一个闭环：

  • BTB 用于快路径
  • I-cache 用于兜底和校正
  • path hit information 作为更新依据

这是一种很典型的“预测缓存 + 主存储校验/回填”思路。

边界问题的处理

图 8 专门强调了一个问题：instruction 是否位于 cache line boundary

这在前端设计里非常重要，因为：

  • 定长 ISA 中，跨边界问题相对可控；
  • 变长 ISA 或 packed instruction 场景中，边界问题会明显变复杂；
  • 即便是定长 ISA，如果前端按 bundle / packet / fetch block 组织，也可能出现一条逻辑执行路径对应多个物理块的情况。

图 8 的流程大意是：

  1. 取得一条 instruction
  2. 判断该 instruction 是否位于 cache line boundary
  3. 如果是，则执行 sequential prediction，得到多份 path prediction information
  4. 根据 path hit information 选择单个预测结果
  5. 再判断预测是否正确
  6. 如果错误，则记录索引、计算新索引，并在后续 cache access 时获得新的 path hit information，对 sequential path predictor 进行写入更新

Access Control Unit

Access control unit 在这个设计里的职责至少包括：

  • 从 BTB 或 predictor 获取 path prediction info
  • 对多个 path 进行比较和选择
  • 根据命中信息做 mux 选择
  • 决定下一次 cache 访问应读哪一个 path
  • 维护 path 元数据
  • 在预测错误或 miss 时触发更新

14. 从工程角度看，这项技术最想优化的三件事

14.1 降低前端取指延迟

通过提前得到 path prediction info，减少：

  • 等待完整预解码后再决定路径
  • 多次回退重取
  • 控制流判断链过长的问题

14.2 提高 instruction cache 有效利用率

通过 path 组织与 path select，使真正大概率需要的 cache line/路径更快被访问，而不是盲目顺序扫取。

14.3 降低动态功耗

说明书摘要明确提到功耗收益。原因包括：

  • 减少无效 cache 访问
  • 减少错误路径上的取指
  • 利用较轻量的 path prediction info 先过滤或先选路
  • 减少前端多结构反复同时激活的次数

这也解释了为什么这项专利特别适合高性能但又强约束功耗的 CPU 前端场景。

15. 它和传统 BTB 思路相比，最本质的不同是什么

传统 BTB 更像：

  • key = branch PC
  • value = target address + 若干状态位

而这篇专利中的 BTB 更像：

  • 不仅是 target 缓存
  • 还承担 path prediction information 的快速入口
  • 与 instruction cache path 结构联动
  • 可以基于 path hit information 被更新

所以它不是单纯“BTB 更大”“BTB 多存几位”，而是把 BTB 的角色从：

跳转目标缓存

扩展为：

前端路径选择的先验信息源

这使得 BTB 的语义从“target lookup structure”朝“fetch path advisor”演化。

16. 它和传统 I-cache 思路相比，最本质的不同是什么

传统 I-cache 常见思路是：

  • 根据地址索引
  • 命中则返回 line
  • 额外由别的模块判断如何拼接、如何续取

而这篇专利把 I-cache 部分地“路径化”了。
从图 4 和图 6 看，instruction cache 内部对不同 path 做了显式组织，至少在控制逻辑层面被看作是多路径候选存储。

这意味着 I-cache 不再只是一个静态阵列，而是成为：

  • 与路径预测协同工作的前端供指资源
  • 可被 access control unit 动态 steering 的对象

这类设计思路很像把传统 cache 的“命中返回”变成“候选集返回 + 控制选择”。
本质上，这是 cache access semantics 的增强。

17. 这项专利特别适合哪些处理器场景

从说明书内容和图 9、图 10 给出的系统示意看，这个方案既可以用于通用计算系统，也可用于 SoC。其适配价值主要体现在：

高性能乱序核

前端供指压力大，控制流复杂，预测失误代价高。

多发射/宽取指前端

一次取很多字节/很多指令时，边界、路径选择、跳转切换会更复杂。

指令密度高或存在变长/压缩编码的体系

边界预测、预解码、路径选择的收益会更明显。

对功耗敏感的移动/嵌入式高性能核

因为该专利明确强调了通过减少无效访问来降低功耗。

18. 说明书里隐含的实现风格：它不是极端复杂的全局历史预测器，而是更偏局部、前端物理可实现

从全文观感看，这篇专利不像 TAGE 那样重视复杂历史长度组合，也不像神经分支预测那样强调高阶相关性。
它更像一种：

  • 前端物理结构导向
  • 依赖当前地址/边界/路径命中
  • 局部更新
  • 用于缩短取指控制关键路径

的实现方式。

也就是说，它的目标不是做最“聪明”的预测器，而是做一个更容易落地到 instruction fetch pipeline 里的预测-访问协同机制。
这是非常阿里/工业界风格的方案：不是单点刷指标，而是围绕系统瓶颈做平衡优化。

19. 如果把这篇专利抽象成一句话，它的技术本质是什么

可以把它概括成：

将“下一条前端取指路径”的预测，从传统的分支目标/方向层面，上升为与 instruction cache 访问控制直接耦合的路径选择机制。

更具体一点：

  • 用 BTB 和路径预测器快速给出候选路径信息；
  • 用 access control unit 在多个 cache path 中选出最可能的取指路线；
  • 用 pre-decode、边界信息、path hit information 做校正和训练；
  • 同时覆盖 jump path 与 sequential path；
  • 最终实现更快、更省电的前端取指。

20. 我对这篇专利的技术评价

优点 1：抓住了前端真实瓶颈

它没有只盯着“分支预测精度”这个单点指标，而是抓住了“预测结果如何被前端真正利用”这个更系统的问题。

优点 2：把 jump 与 sequential 两类情况统一起来

很多方案只优化分支跳转，而它把顺序路径也纳入路径预测框架，这是很有价值的。

优点 3：强调边界与路径命中，说明方案是面向工程实现的

这类细节正是前端硬件中最容易拖慢周期、增加复杂性的地方。

优点 4：BTB / I-cache / access control 三者联动很有现实意义

这比单独增强某个 predictor 更容易形成可观的整机收益。

21. 这篇专利可能的局限性

虽然专利本身没有讨论太多缺点，但从架构实现角度可以看到几类潜在挑战：

21.1 元数据维护复杂度会上升

既然要维护 path、path hit information、边界相关信息、索引更新逻辑，那么：

  • cache 项格式更复杂
  • 控制逻辑更多
  • predictor 与 cache/BTB 的一致性维护会变难

21.2 预测收益可能依赖程序控制流局部性

如果程序控制流非常随机，path 组织和 path predictor 的收益可能下降。

21.3 路径化 I-cache 可能增加设计验证难度

特别是涉及：

  • cache line 边界
  • 多路径命中优先级
  • predictor 更新时序
  • miss/hit 混合情况
    这些都容易让前端 corner case 增多。

21.4 对现有前端结构的侵入性不低

它不是简单加一个小表，而是要改造：

  • BTB 的信息内容
  • I-cache 的路径视图
  • access control unit 的选路逻辑

所以更像是中等规模的前端架构改造，而非微小 patch。

22. 最终总结

这篇 Alibaba 专利的核心，并不是发明一种传统意义上的“更准的分支预测器”，而是提出了一套面向 instruction cache 前端访问控制的路径预测体系。其关键特征包括：

  1. 把取指问题抽象成“路径选择”问题，而不只是目标地址查找问题。
  2. 将 BTB 扩展为路径预测信息的快速入口，不只是简单存 target。
  3. 在 instruction cache 访问控制层面引入 path 组织和 path 选择逻辑。
  4. 统一支持 jump path prediction 与 sequential path prediction。
  5. 显式处理 cache line boundary、path hit information、预测更新等工程细节。
  6. 目标是同时优化前端性能和功耗，减少无效取指与无效访问。

所以，从处理器前端设计角度看，这篇专利可以理解为：

一种“预测驱动的 I-cache 取指选路机制”，
它把 branch/target/path 这些原本分散在多个结构里的信息，整合进了一个更靠近取指控制的数据通路中。

如果你愿意，我下一步可以继续帮你把这篇专利再整理成两种更深入的版本之一：
一种是“按图逐页精读版”，另一种是 “和传统 BTB / uop cache / trace cache / fetch block 方案做系统对比版”。