3.2 冒险检测与前递网络：流水线的自我修复

3.2 冒险检测与前递网络：流水线的自我修复

本节摘要：流水线让指令同时在场，于是三类故障随之而来——数据冒险（后条要用前条还没写回的结果）、结构冲突（两条指令抢同一个部件）、控制冒险（下一条在哪还没确定）。本节讲清判别条件的电路本质、前递网络如何用旁路把结果"抄近道"送到需要的地方、什么时候前递也救不了只能停顿，以及装载—使用这个经典停顿场景的完整分析。

一、三类故障的诊断手册

把三类冒险放一张表里，判别条件都是简单的比较逻辑：

控制冒险单独立刻 3.3 讲；本节先把数据冒险与结构冲突拆到底。

数据冒险的判别电路小得惊人：在译码站读出源寄存器号后，与执行、访存、写回三站里"即将写回的目标寄存器号"逐个比较——普通数字相等比较器而已。命中即冒险。真正有讲头的是命中之后怎么办：能抄近道的抄近道（前递），抄不了的停顿等待（互锁）。

结构冲突在现代 RISC-V 核里已被设计得很少见：寄存器堆普遍做成分离读写口，缓存与指令通路分离。它更多出现在极小面积设计里——比如译码与写回同拍访问同一个单端口寄存器堆。解法要么加端口（面积），要么错峰（时序），要么让编译器插空指令（代码密度）——又一个标准的三方谈判。

二、前递网络：抄近道的艺术

看一段典型代码。装载后紧接着使用：

lw   a0, 0(a1)      # 周期1取指 2译码 3执行 4访存 5写回
add  a2, a0, a3     # 周期2取指 3译码 4执行 ← 需要 a0，但它第5拍才写回
​

加法指令第 4 拍在执行站要用装载结果，而装载第 5 拍才写回寄存器堆。最粗暴的解法是停顿一拍等写回；但注意——装载结果在第 4 拍访存站末尾其实已经算出来了，只是还没走完写回手续。前递网络做的事就是搭一条旁路：把访存站末尾的装载结果直接接到执行站输入，跳过写回这一步。

前递网络的路径全景

前递的收益巨大——绝大多数数据冒险被它无声化解，流水线不停一拍。但天下没有免费的旁路：前递多路选择器就挂在执行站的输入端，选择器级数随旁路条数增加，直接顶住关键路径。这就是时序谈判桌上"冒险处理深度对主频"的条款：旁路越多，覆盖越全，但执行站入口的组合逻辑越深，主频越难看。小核有时故意砍掉部分旁路、用停顿补上，换取更浅的逻辑——又是那句老话，看产品要什么。

三、前递救不了的时刻：装载—使用停顿

回到本节开头那段汇编。装载结果在访存站末尾才可用，而紧跟的加法在下一拍就要用——旁路二确实存在，但注意时序：装载第 4 拍访存，加法第 4 拍执行，同一拍内结果还没从访存站输出。旁路二够不着这个场景，只能停顿一拍：加法在译码站多等一个周期，之后旁路接力送数。

这个场景叫装载—使用冒险，是五级流水线里唯一必须停顿的数据冒险（在缓存命中的前提下）。硬件上由互锁单元自动插入：检测到"装载后紧跟使用其结果"，就让后续指令整体冻结一拍。它看似小事，实则是编译器指令调度的头号目标——下一章 7.1 会讲编译器怎么把无关指令填进这一拍。

更麻烦的是缓存失速：装载遇上一级缓存未命中，访存站可能阻塞几十拍，整条流水线都顶在它后面。停顿机制必须能"整体冻结 + 精确恢复"，这为第五章的异常精确打断埋下了机制伏笔。

四、从电路到规范：RISC-V 的一个聪明决定

老一代精简指令集（如经典的教学架构）把装载—使用冒险的填空责任交给编译器，硬件不做互锁——规范允许编译器假设"装载后隔一条指令结果才可用"。这种设计在理想代码上更快，但代价沉重：二进制代码与流水线级数耦合，换一代实现就得重新编译，安全审计也平添麻烦。RISC-V 选择硬件互锁：规范只承诺"结果可用性由硬件保证"，编译器无需关心流水线细节。这就是第一章说的"合约把微架构细节隔离掉"在数据冒险上的落点——同一个决策模式，5.3 讲分支预测时还会出现一次（拒绝延迟槽），可以对照着看。

⚠️ 常见坑：把前递当成"自动的、免费的"。前递覆盖的是结果已算出但未写回的窗口；结果本身没算出来（缓存未命中的装载、多周期除法），任何旁路都无能为力，停顿不可避免。评审微架构方案时，先问停顿场景清单，再看旁路条数。

前递之外的旁路变体

前递网络的形态不止一种，工程上有两个常见变体值得知道。写回段旁路：除了"执行末到执行入口""访存末到执行入口"两条经典路径，还有一条"写回前一刻的值"兜底路径——覆盖读寄存器堆同拍赶上写回的边角时序，让读到的永远是新值。这条兜底路径在简单实现里可以用"写优先的寄存器堆"替代（写与读同拍时读出新值），两条方案的选择又是面积与时序的小谈判。部分前递：有的小核只为最紧的依赖（相邻指令）架旁路，隔一条指令的依赖靠停顿——省选择器、牺牲平均性能，是成本敏感设计的常见妥协。读一颗开源核的前递方案时，先画出它的旁路覆盖表，哪些依赖零停顿、哪些要等，一目了然。

常见问题快答

问：编译器能消除数据冒险吗？ 能减轻、不能消除。编译器可以重排无关指令填空拍（7.1 的调度），但真依赖链上的停顿是数据本身的串行性，任何调度器都无能为力——链多长，墙就有多厚。

问：怎么从性能计数器看出冒险开销？ 常见指标是停顿周期计数：装载—使用停顿、分支冲刷、缓存未命中等待分别有独立计数（7.3 的可编程计数器），三者相加对照总周期数，就能算出"理想流水线"与"真实流水线"的差距构成——8.3 的演练会把这套账算给你看。

本节要点回顾

• 三类冒险一张表：数据靠前递与停顿、结构靠资源设计、控制靠预测（下节）；
• 判别是比较器：源寄存器号对未写回目标寄存器号的逐站比较，电路极简；
• 前递抄近道有代价：选择器深度顶住执行站入口，旁路条数是主频谈判条款；
• 装载—使用是唯一必停的数据冒险（缓存命中时），互锁自动插一拍，编译器负责填空；
• 规范选择硬件互锁而非编译器填空：把流水线细节挡在合约之外，二进制寿命更长。

数据疏通了，还剩最后一个问题：下一条指令在哪？分支预测登场。