跳到主要内容

取指契约：PC、取指块与跨界

前端各模块必须对“一个请求代表什么”达成严格契约。BPU 预测的是取指块，ICache 返回的是按 Cache/bank 组织的数据，IFU 最终输出的是有边界的指令。三者粒度不同。

四种地址不要混淆​

  • start PC：本次预测/取指块的逻辑起点；
  • next-line address：跨越当前取指范围后的顺序地址；
  • fall-through：FTB 表项覆盖范围之后的顺序目标；
  • taken target：被选择控制流指令的跳转目标。

FTB 的 fall-through 不必等于简单的固定宽度 PC + 常数，因为表项覆盖范围与块内控制流结构有关。源码中相关语义集中在 FrontendBundle.scala 的预测响应与 FTBEntry 方法。

RVC 带来的边界问题​

支持 16 位压缩指令后，指令起点以 2 字节对齐。一条 32 位指令可能跨越自然取指边界；IFU 需要保存尾部半字，与下一次返回的数据拼接，并确保异常 PC、预测槽位和后端指令位置仍一致。

ready/valid 契约​

取指请求被接受的唯一条件是 valid && ready。如果 FTQ 满或 IFU/ICache 不可接收：

  • PC 与历史不能擅自前进；
  • 请求 payload 必须保持稳定；
  • 返回数据不能写入错误 FTQ 项；
  • redirect 必须能取消或标记在途旧请求。

同拍事件的优先级​

前端设计评审必须明确以下组合：

  1. 正常 request fire 与 backend redirect 同拍；
  2. ICache response 与 flush 同拍；
  3. s2/s3 predictor override 与 FTQ full 同拍；
  4. 跨行半条指令等待期间发生 redirect；
  5. ITLB/PMP 异常与更老 redirect 同拍。

通常 redirect/flush 对错误路径拥有更高语义优先级，但实现可能需要流水延迟才能清理已发请求。因此不能只写一句“flush 优先”，而要逐状态规定。

设计练习​

定义一个最小 FetchRequest 与 FetchResponse：列出 PC、FTQ 指针、epoch、异常、跨界信息和 data mask。再解释为什么仅靠 PC 无法在多请求在途与 redirect 场景中匹配响应。