超标量处理器后端设计：执行端口、旁路网络与访存子系统

超标量处理器的核心优势，说通俗点就是同一拍里让多条指令同时“在路上跑”，谁也别空等。这个系列写到第七篇，前面几篇已经覆盖了取指、译码、重命名、分发调度这些前端和窗口机制，剩下的硬骨头基本都在后端。这一篇我想把指令离开调度器之后的事情一次讲透，也就是执行单元怎么布局、旁路网络怎么做、Load/Store访存流水线为什么是超标量里最费心的一块，以及ROB提交和精确异常如何收尾。很多刚接触处理器内部设计的人，会把目光放在前端乱序窗口做多大、调度器多聪明，但我见过不少项目最后性能上不去，死因恰恰是后端执行资源和访存端口不匹配，理论IPC和实际跑分差了很远。这篇文章适合理清整体后端数据流的同学，也适合那些已经搭过简单五级流水、想往乱序超标量方向深入的工程师。读完后你对整个执行到提交路径会有一条清晰的量化设计主线，而不是只记住“ROB管排序”这类概念。

1. 发射之后的执行部件划分：先想清楚要几个执行端口

指令从调度器被选中并发射出去之后，首先面对的问题不是“进哪个执行单元”，而是“这个周期同时发射出来的多条指令，到底有没有足够多的执行端口能接收它们”。如果端口数量不够，调度器再怎么积极也是白搭，因为每个周期能真正离开发射队列、进入后端执行的指令数会被端口数目直接卡死。

1.1 执行端口数量：用带宽公式反推

设计执行端口时，不要凭感觉拍脑袋。先定几个关键输入：发射宽度W，平均访存指令占比r，整数算术逻辑指令占比a。那么访存指令每周期平均需求量是W×r，算术指令是W×a。对于异常处理器设计，我一般起步就会做一个简单带宽表，保证执行端口数量不大于发射宽度，但也不低于指令比例需求。

以一个很典型的4发射超标量处理器为例，假设负载里访存指令占30%到40%，那每周期平均有1.2到1.6条访存指令，如果只安排一组访存端口，访存指令立刻成为瓶颈。即使ALU有4个，访存指令在关键路径上等着排队，平均IPC也很难超过3.0。所以访存上下文至少要准备两个独立端口，对应Load Queue和Store Queue每周期要能接收2条新指令。

注意，这只是指令混合比例的粗算。真实的流水线还要考虑Cache Miss导致的阻塞、Store无法直接写Cache而占用队列、Load执行完成时间变动等问题，所以端口数最好留一点余量。我自己的习惯是把访存端口安排在“发射宽度的一半再加一”这个水平，比如4发射环境下至少要保证2个专用访存端口，遇到优化比较充足的工艺可以再加一个做带宽冗余。

1.2 通用端口还是专用端口：一个拓扑取舍问题

执行端口布局通常有三种常见方案。

全对称方案在RTL实现上最省心，因为每个端口能力一致，调度器只需要根据源寄存器状态选指令，不用做“这端口不支持某种操作”的二次过滤。但代价是每个ALU端口都必须集成地址加法器、比较器、移位桶，面积和功耗不低。专用的AGU端口可以把地址计算逻辑做得更快，还可以更早地把访存地址送进队列做依赖消歧。

实际商用处理器里，ALU和AGU经常是共享一部分端口的，原因是很多访存指令的地址计算就是一个简单的“基地址加立即数”，这条路径和普通ALU加法非常像。如果ALU硬件里有额外宽度的加法器，就顺手把AGU能力合并进去，既能提高端口利用率，又不用给每一个访存单元都复制一套完整算数部件。不过共享后会引入另一个问题：地址计算需要的结果可能比普通算术早一个周期送到LSU，这会让调试访存相关误用依赖时更难分析。所以做合并端口时，一定要确保LSU接收操作数的时机和发射周期匹配得上，不要出现逻辑上“对了但时序永远收敛不了”的情况。

2. 执行单元与旁路网络的工程细节

执行端口定下来了，接下来是更折磨人的旁路网络。超标量处理器里几乎每条指令的结果都可能马上被下一条指令使用，如果每条结果都老老实实写回寄存器堆、再让后续指令读出来，功耗和延迟都会爆炸。旁路网络的本质就是把产生结果的那一拍，直接接到需要该结果的年轻指令输入端口上，省掉写入到读出的往返。

2.1 延迟表中的多周期指令：写回时序不是均匀的

不同执行单元的延迟相差很大。简单整数加法和分支判断可能1个周期就出结果，整数乘法需要2到4拍，浮点加需要3到4拍，浮点乘往往是4到5拍，除法更麻烦，一般没法固定写回周期。这里涉及的后续设计关键是：每个执行单元完成写回的时刻是独立的，调度器不能用统一的“执行结束”信号唤醒所有等待指令。

设计时每个执行单元会声明一个“有效写回周期”或者“完成延迟”。比如一条乘法指令延迟为3，假设它在第T周期进入乘法单元，那么在第T+3周期它的结果才有效。有的处理器把乘法单元内部流水化为三级，每一级都打一拍，第T+3周期才在流水线末端输出。如果所有指令都从发射到写回经历相同阶段，调度器唤醒逻辑会非常简单，但代价是每一条逻辑简单的指令都被强制拖慢到多周期。这就是为什么主流设计并不用统一执行延迟，而是让延迟短的指令快速完成，同时用复杂唤醒逻辑追踪多种完成时间。

延迟表的设计请务必和调度器唤醒策略同步。我的经验是：在乱序执行的唤醒逻辑里，每条指令需要知道自己对应的物理寄存器何时被写回，然后提前一拍唤醒等待它结果的年轻指令。如果写回在T周期发生，年轻指令的目标应该是T+1周期进入读取阶段。一旦延迟表里的某个周期数填错，仿真时不会立刻崩，表现往往是某些指令永远等不到唤醒信号，ROB卡死，CPU整体停转一一这种问题特别难查，因为它不像数据错误那样报错，而是“不进不退”。

2.2 旁路网络：让年轻指令不吃“隔夜饭”

旁路网络把所有执行单元的输出连接到所有发射端口的数据输入端。如果每个执行单元结果都能广播给所有指令候选，这种设计叫全互连旁路。一个发送结果的总线数量等于同期写回的执行单元数量，每一条总线都要经过译码和选择逻辑进入到目标指令的源操作数端。

假设一个4发射后端，每周期最多有4条指令同时写回，那么每个源操作数端需要有4选1的旁路选择器。如果系统里还有浮点单元、Load结果写回，甚至可能看到8路甚至更多数据源，综合后选择路径会很长。很多处理器没法把后端频率提得太高，主要就是死在这组“所有结果选给所有消费者”的全互连网络上。这里常见的取舍是部分旁路，比如整数ALU结果只旁路到整数指令和访存指令的地址计算端，浮点结果只旁路到浮点指令和Store数据端，这样能缩短关键路径。

给一小段SystemVerilog风格的旁路选择逻辑示意，理解优先级就够：

systemverilog复制always_comb begin
  if (ex_mem_rd_vld && (ex_mem_rd_prd == src_prd))
    operand_a = ex_mem_result;
  else if (mem_wb_rd_vld && (mem_wb_rd_prd == src_prd))
    operand_a = mem_wb_result;
  else
    operand_a = rfile_rd_data_a;
end

这段逻辑表达的是：如果上一条指令刚在本周期产生结果，并且目的物理寄存器号和当前指令需要的源寄存器号一样，那就直接把结果透过第一级旁路送进去。否则看再往上一级流水阶段是否也满足，条件满足就选择那一级。这里选择优先级必须正确，否则会选到旧数据。实际很多Bug不是旁路存在与否的问题，而是很多级流水同时有结果写同一个寄存器，年轻数据被老数据覆盖了。

旁路网络是典型的“面积换延迟”——不加旁路会让流水线多拍停顿，加了以后每个周期都有大量动态选择。但设计时不要一上来就追求把所有结果全互连，更好的顺序是先统计哪些依赖出现频率高，比如整数指令到整数指令依赖通常最高，优先完成这部分全互连，其他跨类型依赖可以用较低优先级路径或者适当增加写回延迟来实现。

2.3 写回端口仲裁：多写口问题怎么解

多个执行单元可能在同一拍完成写回，而物理寄存器堆的写端口是有限的。如果4个执行单元同时写回，那么就要提供4个写端口，否则结果会在寄存器堆门口“打架”。

寄存器堆写端口的面积增长比读端口更明显。很多设计要求写端口数=执行端口数，但这在一些工艺下代价太高，于是设计者会考虑用分布式写回或分层写回：第一拍把快速单元的结果直接旁路给年轻指令，并在同一周期写寄存器堆；跳变慢的单元结果可能晚一拍再写回。只要物理寄存器堆的释放机制允许延迟写回，且唤醒逻辑对完成周期做了正确跟踪，这个折中可行。

我自己遇到的写回冲突主要出现在浮点单元。浮点乘法比如延迟5拍，浮点加法延迟3拍，若两条浮点指令在同一拍发射，它们完成回写的时间错开，基本不冲突。但如果设计里所有浮点单元延迟都是4拍，两条同时发射的指令就会在同一拍抢同一个写端口，这种情况下要么加写端口，要么强制让某一条指令延后一拍写回。后者的代价是它后面所有依赖这条指令的年轻指令都要多等一拍。所以“执行单元内部是否深度流水、延迟是否错开”要和“寄存器堆写端口数”一起做优化，而不是分开设计。

3. 访存子系统是超标量后端的重头戏

如果说普通RISC流水线里访存只是“Load算地址、访Cache、写回”的简单步骤，那么在超标量乱序执行里，访存指令是全局最复杂的部分，因为它天然涉及内存顺序、别名判断、Cache未命中、跨指令转发等一系列问题。很多设计者把访存子系统当成一个独立小处理器来做，不夸张。

3.1 Load Queue和Store Queue：乱序访存的“账本”

要让Load指令能够越过更旧的Store指令提前执行，同时不破坏内存一致性，处理器必须同时记录两条队列：Load Queue和Store Queue。更准确地说，现代设计普遍在每条访存指令重命名或者分发时分配一个Load Queue或Store Queue条目，这个条目会一直保留到指令提交或完成。

Store指令乱序执行的风险在于它不能立刻更新Cache，因为一旦更新，后面发现分支预测错误需要回滚时，内存里的数据已经改了，无法恢复。所以Store在执行阶段只负责计算地址和准备数据，把结果暂存在Store Queue中，直到前面的指令全部提交、Store处于提交点之后，再真正写入Cache或保留到更深的存储层。这个过程称为Store提交后写回。

Load则相对灵活。Load命中Cache且没有更旧Store指向相同地址，它可以直接拿数据返回；如果后面发现有更旧的Store和它地址相同，处理器必须能够检测并纠正。这就是内存消歧。Load执行时会把地址放到Load Queue，后续Store产生地址时，会扫描Load Queue里所有更年轻的Load看是否地址相等。如果某条更年轻Load已经读回了旧数据，而新Store又和它地址冲突，那么这条Load绝不能提交，必须被重新执行或直接触发清空，等待新数据重新执行。

3.2 Store-to-Load Forwarding：跨指令传数据的正确姿势

当执行完的Store还停留在Store Queue里没有写回Cache，而后面的Load又要读同一地址时，存在两种可能：如果Load能等，它可以等Store提交后从Cache读取，但这会让Load延迟高到不可接受；更好的做法是直接把Store Queue里的数据传给Load，这个过程叫Store-to-Load Forwarding，也就是无阻塞地把值从较旧Store转发给较年轻Load。

地址匹配的判断不是简单相等这么简单。两个内存访问地址相同、访问长度不同，需要确定范围是否重叠，以及转发数据如何对齐到Load期望的位置。一种典型判断逻辑可以表述为：如果Load的地址在Store的地址范围之内，并且Load需要的字节确实由这个Store写入了，那就可以形成转发。实际RTL里要比较的是段选择掩码、大小字段和偏移量。例如一个4字节Store到地址0x1000，后面来了一个2字节Load读0x1002，那Load的低半字其实就来自Store的高半字，这种字节偏移处理最容易写错。

考虑端序和偏移的对齐处理时，最稳的验证方式不是只做“同地址同大小”的happy path用例，而是写全“Store长度大于Load长度”“Load长度大于Store长度”“Load跨两个Store”的组合测试。很多转发电路里有一个经典Bug：比较器看到同一Cache行就认为满足依赖，忽略了字节掩码。如果Store只写了前半行、Load读后半行，这样的误判会把垃圾数据转发过去，测试必须覆盖。

3.3 非阻塞Cache与MSHR：Miss之后流水线不能干等

超标量处理器很少采用“Cache一次Miss就暂停整条流水线”的设计，否则所有后续指令都会被一次主存访问拖住。要做到即使Load Cache未命中也不阻塞其他指令，核心是让访存流水线记住这个未完成的Load，然后继续处理后面的指令。这个能力叫非阻塞Cache，而记录未完成访问的硬件结构是MSHR（Miss Status Holding Register）。

MSHR的基本行为可以这样理解：一条Load访问Cache，未命中，MSHR分配一个空条目，记录地址、需要的目标物理寄存器和Load Queue标识。数据从下级存储返回时，MSHR识别出这个请求并触发唤醒逻辑，让等待该Load结果的年轻指令继续执行。如果在等待期间又来了一条访问同一Cache块的访问，MSHR可以把两个请求合并到同一个条目上，大大减少对下级存储的请求数量。

MSHR条目数量对性能影响非常明显。假设主存访问延迟约100个周期，若MSHR只有4条，那么在极端情况下只能跟踪4个不同Cache行的未命中，第5个不同行的未命中发生时仍然要阻塞流水线。如果增加到16条，就能保持更多并行未完成的访问。我用一个简化CPI估算来说明条目数的影响：当MPI（每指令平均Miss数）是0.01、Miss延迟100周期时，理论上需要约1个未完成请求才能覆盖带宽需求，但如果访存局部性差、多个请求扎堆到达，4条MSHR可能在短时间内耗尽。做设计时至少要统计目标负载下同时访问的独立行数量，再留50%余量。

值得提一句：Load执行完成的标准并不是“从Cache返回了数据”，对乱序处理器来说，访存指令直到Load命中Cache或MSHR返回且数据被旁路到等待指令的周期，才算真正完成。如果指令被预测执行且最终分支错误，则Load Queue里的这些未提交Load都会被清空，MSHR中的相关请求也不允许触发年轻指令写回。复杂部分的处理，往往要和ROB提交逻辑一起联调。

4. ROB提交、精确异常与退休带宽

前文说过指令可以乱序执行，但真正改变架构状态时必须按原程序顺序进行，这个顺序控制由重排序缓冲完成。ROB是后端管理的最后一道关，也是“乱序执行、顺序提交”模型的物理载体。

4.1 ROB参数：窗口大小和提交宽度怎么定

ROB中的每个条目通常在重命名阶段分配，记录PC、目的物理寄存器、异常信息和完成状态。指令在调度器发射并执行完后，对应ROB条目标记为完成。提交逻辑从ROB头部开始扫描，只要头部条目完成且无异常，就能按顺序退休，并将它持有的物理寄存器正式写成架构寄存器状态。

提交宽度决定了每个周期最多能退休多少条指令。如果一个处理器设计成4发射，提交宽度一般不宜低于4，否则即使每周期能执行4条指令，提交阶段还是容易发生堵塞。ROB深度决定了乱序窗口能容纳多少条动态指令。窗口越大，越能在长延迟Cache Miss发生时继续找到足够的独立指令填充流水线。延迟-带宽公式可以写成一个粗略经验：ROB条目数至少要接近“Load Miss延迟 × 每周期退休带宽”。例如平均Miss延迟200周期、提交带宽4，那200×4=800条目才能保证每周期都有足量指令退休。当然不是所有处理器都会追求这个值，因为ROB太大，面积、功耗以及分支预测错误后的清空代价都会显著上升。

ROB本身还承担了物理寄存器回收的责任。物理寄存器堆配合ROB使用时，其实可以不立即释放物理寄存器，只要提交单元每周期把被覆盖的旧物理寄存器归还到空闲列表就行。如果ROB头部有连续的已提交指令，提交单元每周期最多要向Free List写回与提交宽度相同的条目，这个过程不能省。

4.2 精确异常：如何做到“看起来顺序执行”

精确异常要求发生异常时，处理器的架构状态必须和“每条指令严格按程序顺序执行到异常指令为止”的效果一致。换句话说，异常指令之前的所有指令已经提交，异常指令本身以及它后面的所有指令都像从未执行过一样。

实现这项功能的时候，异常现场会被记录在该指令的ROB条目中。当这条指令到达ROB头部时，提交逻辑检查到异常标志，就会把异常原因、发生PC等现场信息保存到异常寄存器，然后清空ROB和所有乱序状态，同时跳转到异常服务程序入口。这个过程中，唯一不能被清空的是已经提交指令留下的架构寄存器状态，因为它们已经是合法状态了。

分支预测错误的处理和精确异常有一点类似但不等同：分支预测错误不回退寄存器堆中已经提交的指令，但要撤销所有年轻指令对物理寄存器的写操作。现代高效做法是分支预测发生之后立刻做分支重定向，处理器从正确路径重新取指，但旧指令还留在流水线里继续跑。它们可能会写回物理寄存器，只要这些物理寄存器还没被Free List回收、对应的ROB条目又尚未提交，撤销时直接清空ROB条目，那些物理寄存器会被完整归还到Free List。更激进的处理器会使用Checkpoint快照来加速恢复，但如果架构频率优先，最简单可靠的方案是全部冲刷，等前端的正确地址指令重新走完重命名一整套流程，时间代价高一点但恢复逻辑很直观。

4.3 Store提交和Cache写入的配合

Store Queue中的数据不能在执行完成时立刻写Cache，原因已经说过：分支预测错误、异常、中断都可能让它在最后关头被撤销。一旦Store到达ROB头部，该条Store指令被提交，处理器就可以“名正言顺”把Store Queue中的数据和地址送到Cache写入端口。

这道设计有一个容易踩的坑：Store执行完成后，数据可能已经不在原来执行单元口的路径上了，它一直在Store Queue保存着。提交时Cache接口需要重新读取Store Queue的数据和地址，并找到Store Queue里哪一条是ROB头部对应的最老Store。如果Store Queue支持按年龄指针读取，提交逻辑会相对简单；如果只能按分配序号无序搜索，就得额外做匹配逻辑。性能上要注意提交后Store可以分批写Cache，不一定每个周期只写一条，但Cache写端口数量有限，如果和Load访问Cache的读端口冲突，通常Load优先，Store写回会被缓冲进一步延迟。

5. 从仿真看后端：定向验证场景与常见坑

到了具体验证阶段，建议不要一上来就随机跑几百万条指令，而是先准备一批能够精准戳中后端机制的定向场景。下面是几个性价比极高的Case，几乎每个超标量处理器验证都会用到。

5.1 必测的六类后端定向Case

第一类最基础的是Store-to-Load Forwarding的组合矩阵。把地址偏移和访存长度做成排列组合，比如用四次Store分别写0x1000、0x1004、0x1008、0x100C，然后让不同年轻Load从0x1001、0x1003这种非对齐位置去读，确认每一次数据源都来自正确的Store而不是Cache或错误转发。

第二类是“已被Load读到旧值，随后又出现相同地址更旧Store”的场景。程序顺序上，一条Load先执行并拿到了Cache里的旧值，更旧的Store在它之后完成地址解析，然后发现和Load地址相同。此时必须触发纠正机制，否则Load提交后内存值就错了。验证时要有意让更旧Store的地址计算被某种依赖拖慢，确保Load先读取旧数据。

第三类是Load Miss后同一条指令的等待唤醒。先制造一次L1 Cache Miss，紧接着插入多条依赖于该Load结果的算术指令，验证它们不会提前发射，而是在MSHR返回数据之后才被唤醒。可以在Cache模型里手动延迟响应，然后观察调度器队列。

第四类是ROB头部堵塞。让最老的指令不完成，比如设计一个永不返回的Load模型，看年轻指令是否把执行单元跑满但没有一条能提交，同时Free List和ROB最终耗尽后前端停止取指。这个Case能验证停顿上报路径，避免出现前端无限派发却没有资源可用的死锁。

第五类是Store提交顺序。在同一Cache行连续多个Store，提交必须按程序顺序进行，否则最终Cache里数据是乱序后的错误结果。可以插入两条相同地址不同值的Store，再让中间其它Store提交各自延迟不同，验证Cache最终值是最后一条Store的值。

第六类是分支预测错误与访存撤销联动。在分支指令后有大量乱序执行的Load/Store，当分支被判定错误后，这些访存都必须从Load Queue、Store Queue和MSHR里干净地清掉，不能残留。残留的MSHR请求如果继续写回，会让年轻指令错误唤醒。

5.2 调试后端问题的速查表

后端问题非常容易表现为“系统卡住”而不是数据报错，所以排查时如果看不到具体错误，多半是某个队列或寄存器状态进入了死锁。以下是几个我调试时碰到的典型症状。

这类问题单靠波形很难抓，最好在早期就给关键队列加上统计计数器，比如“每个周期Load Queue满了几次”“ROB满了几次”。因为性能回归往往是一个比例问题，不是你盯着某一个波形就能发现的。我见过有团队花了很大力气排查所谓的算法Bug，最后只是Store Queue少了几个条目，导致一部分访存指令在分发阶段被堵，直接拖低了整体调度。

5.3 给仿真平台留“后门”：手动注入Miss和完成事件

验证访存后端时最痛苦的是不能精确控制一条Load什么时候命中、什么时候Miss。所以我在测试环境里习惯在Cache模型和Load Queue之间留一个可编程延迟接口，比如允许测试用例直接设置某地址区间为“强制Miss”，并且指定返回延迟周期数。这样你在确定性验证Load唤醒路径时，不需要依赖随机主存模型的时序。

从整体上模拟一个简化版本的写回唤醒事件，下面这段SystemVerilog只是示意，重点是要理解“后端验证需要可控延迟注入”这个思路：

systemverilog复制module miss_control_tb;
  // 地址段配置
  reg [63:0] miss_start_addr;
  reg [63:0] miss_end_addr;
  reg        force_miss_en;
  int        extra_latency;

  always @(posedge clk) begin
    if (force_miss_en && req_addr >= miss_start_addr &&
        req_addr <= miss_end_addr)
      // 强制让该请求延迟extra_latency个周期才返回
      resp_valid_dly <= #extra_latency;
  end
endmodule

这类“后门”会在回归测试里引入一点面积和逻辑复杂度，但不加的话，每次想验证一个只有几十拍窗口的时序问题，都得靠运气。控制器上建议加一个信号锁，只有仿真阶段该功能被打开，综合时引脚配置默认关闭，避免把测试逻辑带进流片。

6. 结合个人经验的后端设计小技巧

最后想分享几个我在实际后端调试过程中觉得特别重要的点。

第一，设计后端时尽量把“完成信息”和“提交信息”分开，不要因为一条指令执行完成就立刻释放它的所有资源。执行完成只代表结果已经算出来，并不代表可以提交，很多年轻指令会依赖它继续乱序执行，但架构状态必须等它走到ROB头才真正改变。这个区分理解到位后，很多关于Store能不能写Cache、物理寄存器能不能回收的问题都会迎刃而解。

第二，做后端验证时不要依赖“随机测很久然后跑分”，一定要从周期级波形里把唤醒和提交两条路径单独拿出来检查。我试过最有效的方法是把设计按“前端派发”“调度唤醒”“访存完成”“ROB提交”切成几个阶段，然后单独观察每个阶段是否有指令停留超过预期周期数。哪个阶段开始堆积，瓶颈就在哪里。不管ROB多大、MSHR多深，任何队列一旦出现周期性满占用，都会以非线性方式拖垮整体性能。

第三，多周期执行单元的延迟不要轻易“为了省事”统一成同一数值。统一延迟确实会让调度器实现简单，但会让原本1拍能出结果的简单指令被强行拖慢，性能损失在全系统CPI上非常明显。我的建议是先按延迟分类给每类单元单独建立“完成时间表”，然后集中精力把唤醒逻辑里的多延迟处理做好，把复杂度控制在可验证的范围内。这个选择虽然前期麻烦，但后期性能回报很可观。

超标量处理器内部设计做到访存和提交这一步，前面的乱序机制才能真正兑现成实际性能。如果你正在搭建自己的后端设计，不妨按照这套端口规划、旁路优先级、访存队列管理、ROB提交和定向验证的路径走一遍。过程中每个模块看起来都不算太复杂，但联调时才能体会到它们之间的耦合有多深。