BRU与其他功能单元

2018年1月3日，Google Project Zero联合学术界公开了Spectre v2（Branch Target Injection，CVE-2017-5715）漏洞的完整技术细节。攻击者发现，通过精心构造间接分支序列来"毒化"其他进程的分支目标缓冲区（BTB），可以将BRU——这个本应只负责计算跳转地址和验证预测结果的简单功能单元——变成一个跨安全域的信息泄露通道。这一发现迫使Intel、AMD和ARM在几周内紧急发布微码补丁（IBRS、STIBP）和编译器缓解方案（Retpoline），其性能代价在数据中心工作负载上高达5%$\sim$15%。BRU从此不再只是一个"跳转地址计算器"，而是一个安全敏感的核心组件——它的每一个设计决策都同时影响性能和安全性两个维度。

这一事件深刻揭示了本书的核心论点：处理器设计的本质是在有限的晶体管预算和功耗约束下，通过投机（speculation）和并行（parallelism）的层层叠加来逼近指令吞吐率的理论上限。BRU正是投机执行机制的关键验证节点——没有它的快速验证和恢复能力，前端的分支预测就无法安全地驱动深流水线的投机取指。而Spectre漏洞则表明，当投机执行的"验证延迟"被恶意利用时，处理器的微架构状态（如缓存行的存在与否）会成为跨安全域的信息泄露通道。BRU的设计因此必须在三个维度上同时优化：性能（最小化redirect延迟）、面积（保持硬件精简）和安全性（限制投机窗口的可观测副作用）。

在前面几章中，我们详细讨论了整数ALU（第 30.0 章）、浮点FPU和SIMD/向量功能单元的微架构设计。这些单元执行的是"计算密集型"操作——加法、乘法、移位等数据变换运算，构成了处理器执行引擎的"算力核心"。然而，乱序执行引擎中还存在几类功能单元，它们虽然不以算力见长，却在整个处理器流水线中扮演着不可替代的角色。

其中最重要的是分支执行单元（Branch Resolution Unit，BRU）。分支指令在典型工作负载中占比约15%$\sim$25%，BRU负责在执行阶段对分支预测（第 17.0 章详细讨论了前端预测器的设计）进行验证——计算真实的分支条件和目标地址，与前端预测器给出的预测结果进行比较，并在预测失败时产生重定向信号以清空并恢复流水线。BRU的设计直接影响分支预测失败恢复的延迟，进而深刻影响处理器的整体性能。

本章还将讨论两类日益重要的"非传统"功能单元：密码加速单元和硬件随机数生成器。随着安全需求的普遍化（第 50.0 章和第 51.0 章将分别讨论安全攻击和防御的系统性视角），现代处理器普遍将AES、SHA等密码学原语以专用硬件的形式集成到执行引擎中，以数量级的性能提升替代纯软件实现。硬件随机数生成器则利用物理噪声源产生真正的不可预测随机数，为密码学密钥生成和安全协议提供基础支撑。

表表 33.1概览了本章讨论的功能单元及其典型性能参数。

功能单元	延迟	吞吐量	流水线	典型端口
分支执行单元 (BRU)	1周期	1/周期	单级	专用/共享INT
AES轮函数 (AESENC)	4周期	1/周期	全流水线	SIMD端口
SHA压缩 (SHA256RNDS2)	4$\sim$6周期	1/周期	全流水线	SIMD端口
RISC-V AES32 (aes32esi)	1$\sim$2周期	1/周期	全流水线	INT/Crypto端口
硬件随机数 (RDRAND)	$\sim$400+周期	变化	N/A	专用

本章讨论的功能单元概览

分支执行单元（BRU）

分支执行单元是乱序执行引擎中最"特殊"的功能单元。它与其他功能单元最根本的区别在于：BRU的执行结果不仅仅影响一条指令的目标寄存器，更可能导致整个处理器前端的重定向（redirect）——数十甚至上百条已经在流水线中的指令可能因为一次分支预测失败而被全部清空。BRU是前端投机执行（speculative execution）与后端确认（resolution）之间的关键桥梁。

在现代超标量处理器中，BRU通常具有以下特征：（1）延迟为1个周期，因为分支的"计算"本质上只是一次比较和一次加法；（2）通常独占一个执行端口或与简单整数运算共享端口；（3）需要与前端分支预测器、重排序缓冲区（ROB）、流水线清空（flush）机制有紧密的控制接口。

BRU的执行端口配置

BRU在处理器执行引擎中的端口配置因微架构而异，直接影响分支指令的吞吐量和与其他指令的交互。

微架构	BRU端口数	端口类型	共享关系
Intel Golden Cove	1	专用+共享	与INT ALU共享端口0
AMD Zen 4	1	专用	BRU独占1个端口
AMD Zen 5	2	专用	2个BRU端口
ARM Cortex-X4	2	共享	与INT ALU共享
Apple M4 (推测)	3$\sim$4	混合	2专用 + ALU上的零测试分支
SiFive P870	1	共享	与INT ALU共享

主流微架构中BRU的端口配置

BRU端口的数量选择反映了设计者对分支吞吐量需求的判断。在大多数通用工作负载中，分支指令约占动态指令的20%，且分支之间通常有3$\sim$5条非分支指令间隔——单个BRU端口已经足够。但在极端的分支密集代码中（如解释器的字节码分派、虚函数密集的C++代码），分支间隔可能降到1$\sim$2条，此时多个BRU端口可以显著提升IPC。

从发射队列的角度看，分支指令在乱序引擎中具有高调度优先级：由于分支预测失败的代价极高（10$\sim$25个周期），尽早执行分支指令可以尽早发现预测错误并启动恢复，减少在错误路径上浪费的执行资源。因此，许多微架构在调度策略中给予分支指令"优先发射"的待遇——当分支指令和普通整数指令同时就绪时，调度器优先选择分支指令发射到执行端口。这种"最老分支优先"（oldest branch first）策略虽然可能稍微延迟某些整数操作的执行，但从全局性能来看是有益的。

分支条件判断

分支指令的核心语义是"根据某个条件决定是否跳转"。不同的指令集架构（ISA）采用了截然不同的机制来表达和计算分支条件，这直接影响了BRU中条件判断逻辑的硬件设计。

基于标志位的分支（Flags-based Branching）

x86架构使用标志寄存器（EFLAGS/RFLAGS）中的条件码来驱动分支判断。前一条算术或逻辑指令的执行会设置标志位——包括ZF（零标志）、CF（进位标志）、SF（符号标志）、OF（溢出标志）等——后续的条件分支指令（如JE、JL、JBE等）读取这些标志位并根据预定义的组合逻辑决定是否跳转。

这种设计的硬件含义是：BRU内部的条件判断逻辑是一个纯组合逻辑函数，输入为标志位值，输出为"taken/not-taken"的布尔信号。表表 33.3列出了x86常用分支条件与标志位的对应关系。

分支指令	条件描述	标志位表达式	语义
JE/JZ	等于/为零	$\texttt{ZF} = 1$	$a = b$
JNE/JNZ	不等/非零	$\texttt{ZF} = 0$	$a \neq b$
JL/JNGE	小于（有符号）	$\texttt{SF} \neq \texttt{OF}$	$a <_s b$
JGE/JNL	大于等于（有符号）	$\texttt{SF} = \texttt{OF}$	$a \geq_s b$
JB/JNAE	低于（无符号）	$\texttt{CF} = 1$	$a <_u b$
JAE/JNB	高于等于（无符号）	$\texttt{CF} = 0$	$a \geq_u b$
JLE/JNG	小于等于（有符号）	$\texttt{ZF} = 1 \lor \texttt{SF} \neq \texttt{OF}$	$a \leq_s b$
JA/JNBE	高于（无符号）	$\texttt{CF} = 0 \land \texttt{ZF} = 0$	$a >_u b$

x86常用条件分支指令的标志位判断逻辑

从微架构角度看，x86的flags-based分支机制引入了一个重要的数据依赖问题：分支指令必须等待产生标志位的指令执行完毕后才能执行。这意味着在乱序引擎中，分支指令对标志位的依赖需要通过寄存器重命名来追踪。现代x86微架构（如Intel Golden Cove、AMD Zen 4）将标志寄存器拆分为多个微架构子寄存器分别重命名——例如将CF与ZF/SF/OF分开重命名，以减少不必要的依赖。

标志位重命名的物理实现

标志位的重命名与通用寄存器的重命名在原理上相同，但在实现细节上有重要差异。通用寄存器的重命名将一个逻辑寄存器编号映射到一个物理寄存器编号；标志位的重命名则将一个"标志位组"映射到一个"物理标志位寄存器"。

Intel的Golden Cove微架构将x86的EFLAGS拆分为以下几个独立的重命名组：

1. CF组：只包含CF（进位标志）。ADD、SUB、CMP等指令写入此组；INC、DEC不修改此组。

2. ZAPS组：包含ZF（零标志）、AF（辅助进位标志）、PF（奇偶标志）和SF（符号标志）。大多数算术/逻辑指令同时写入此组。

3. OF组：只包含OF（溢出标志）。有符号运算指令写入此组。

这种拆分的核心动机是消除INC/DEC指令带来的部分标志位写入问题。INC指令修改ZF、SF、OF但不修改CF——如果所有标志位作为一个整体重命名，INC后面需要CF的指令（如ADC）就会对INC产生虚假依赖，必须等待INC完成后才能读取CF。将CF单独重命名后，ADC可以直接读取更早指令写入的CF，不受INC的影响。

物理标志位寄存器文件通常比通用寄存器文件小得多——每个物理标志位寄存器只需存储几位标志值（CF为1位、ZAPS组为4位、OF为1位），总计约6位。如果分配128个物理标志位寄存器，总存储量仅为$128 \times 6 = 768$位$\approx$96字节——面积微不足道。

标志位合并的微码辅助

当某条指令需要同时读取来自不同重命名组的标志位时（例如，LAHF指令将SF、ZF、AF、PF、CF全部读入AH寄存器），处理器可能需要执行一条标志位合并（flags merging）微操作——将来自不同物理标志位寄存器的值合并为一个完整的标志位集合。这条合并$\mu$op通常是自动插入的，延迟为1个周期，但它增加了$\mu$op数量和执行端口压力。

在性能敏感的代码中，编译器应尽量避免产生需要标志位合并的指令序列。例如，使用ADD代替INC可以消除部分标志位写入的问题（ADD reg, 1与INC reg语义等价，但ADD同时写入所有标志位组），从而避免后续的标志位合并开销。

设计提示

x86的标志位寄存器重命名是一个精巧的微架构优化。例如，ADD指令同时设置CF、ZF、SF、OF四个标志，而INC指令只设置ZF、SF、OF，不修改CF。如果将所有标志位作为一个整体重命名，INC后面的JC（测试CF）指令就会对INC产生虚假依赖。将CF单独重命名后，JC可以直接读取更早的ADD设置的CF，消除了虚假依赖。部分重命名的代价是增加了重命名表和依赖追踪的复杂度。

基于寄存器比较的分支（Register-compare Branching）

RISC-V和ARM（AArch64的CBZ/CBNZ系列）采用了一种更直接的方式：分支指令自身包含两个源寄存器操作数，在BRU内部直接对这两个寄存器值进行比较。以RISC-V为例，BEQ、BNE、BLT、BGE、BLTU、BGEU六条指令分别比较rs1与rs2的相等、不等、有符号小于、有符号大于等于、无符号小于、无符号大于等于关系。

这种设计对BRU硬件的影响是：条件判断逻辑需要包含一个完整的比较器——通常是一个减法器（$\texttt{rs1} - \texttt{rs2}$），然后根据差值的符号位、零检测、以及操作数的最高位（用于区分有符号/无符号比较的溢出情况）来产生比较结果。RISC-V BRU内部的条件判断逻辑如下：

• 等于/不等于（BEQ/BNE）：计算$\texttt{rs1} \oplus \texttt{rs2}$，然后做OR归约检测是否为零。这个操作只需要异或门阵列和一个宽OR门，延迟很低。

• 有符号小于（BLT）：计算$\texttt{rs1} - \texttt{rs2}$，判断条件为差值的符号位与溢出标志不相等（$\text{sign} \neq \text{overflow}$），逻辑上与x86的JL完全一致。

• 无符号小于（BLTU）：计算$\texttt{rs1} - \texttt{rs2}$，判断条件为产生了借位（即无符号减法的进位输出为0）。

设计权衡 1 — 标志位分支 vs. 寄存器比较分支

两种分支机制各有利弊。标志位方案的优势是：一次比较或算术操作可以设置标志位，后面多条分支指令（或条件移动指令）都可以使用同一套标志位，节省了重复比较的开销。其劣势是引入了隐式的标志位依赖，增加了乱序引擎中依赖追踪的复杂度，尤其是部分标志位更新带来的"标志位合并"（flags merging）问题。

寄存器比较方案的优势是：分支指令的所有输入都是显式的通用寄存器，与乱序引擎的通用寄存器重命名机制完美契合，无需额外的标志位重命名逻辑。其劣势是：每条分支指令都需要独立的比较操作，且需要读取两个源寄存器，增加了BRU对寄存器文件读端口的需求。

现代ARM AArch64架构采用了"混合"策略——既支持传统的NZCV标志位分支（B.cond），也支持寄存器直接比较分支（CBZ/CBNZ/TBZ/TBNZ），让编译器根据上下文选择最优方案。

AArch64的条件码与条件选择

ARM AArch64保留了传统的NZCV条件码寄存器，但通过引入CSEL（Conditional Select）、CSINC、CSINV等条件选择指令，将许多原本需要分支的模式转化为无分支的数据流操作。例如，三元运算符 c = (a > b) ? x : y 可以编译为CMP + CSEL的组合，完全避免了分支预测的不确定性。从BRU的角度看，这意味着条件选择指令分流了一部分"简单分支"的工作量，留给BRU的主要是真正的控制流分支——这些分支往往更加难以预测。

BRU内部的条件判断逻辑通常只占整个单元面积的很小比例——对于RISC-V风格的比较器，主要是一个64位减法器和几个门级逻辑；对于x86风格的标志位检查，则更加简单，只需要几个门电路。条件判断的关键路径延迟在现代工艺下通常可以在半个时钟周期内完成，BRU的另半个时钟周期留给目标地址计算和预测验证逻辑。

条件判断与比较器的微架构共享

寄存器比较分支的BRU硬件

RISC-V的寄存器比较分支需要BRU包含一个完整的64位比较器。这个比较器的硬件实现有多种策略，每种策略在延迟、面积和支持的比较类型上有不同的权衡。

方案一：减法器方案。使用一个64位减法器（$A - B$），然后检查差值的符号位和溢出标志来判断大小关系。这是最通用的方案，因为同一个减法器可以同时支持所有6种比较类型（EQ、NE、LT、GE、LTU、GEU）。减法器的延迟约为$\log_2 64 \approx 6$级并行前缀运算，在先进工艺中约80$\sim$100 ps。

方案二：双通道方案。将64位操作数拆分为高32位和低32位。两个32位比较器并行工作：高32位比较器判断$A_H$与$B_H$的关系，低32位比较器判断$A_L$与$B_L$的关系。最终结果由一个2级MUX组合：如果$A_H \neq B_H$，使用高32位的比较结果；否则使用低32位的比较结果。这种方案的关键路径是32位比较器的延迟（约5级）加上2级MUX，总延迟约为7级——与64位减法器相当，但面积略大。优势在于75%的情况下（高32位不等），结果可以在5级后就确定，允许提前终止优化。

方案三：异或+归约方案。仅用于EQ/NE比较。计算$A \oplus B$（64个并行XOR），然后用一个64:1 OR归约检测是否全零。延迟约为$1 + \lceil \log_2 64 \rceil = 7$级门，但这些门非常简单（XOR和OR），实际延迟比减法器更短（约50$\sim$70 ps）。对于EQ/NE分支（在实际代码中占比约40%$\sim$50%的所有分支），这种方案提供了最快的条件判断路径。

高性能BRU通常同时实现方案一和方案三，使用双路径设计：EQ/NE分支使用快速的XOR+归约路径，LT/GE/LTU/GEU分支使用减法器路径。调度器在发射分支指令时根据分支类型选择激活哪条路径。

BRU的双路径条件判断设计：EQ/NE使用快速的XOR+OR归约路径，其他比较使用通用的减法器路径

在很多微架构中，BRU的条件比较器与整数ALU中的减法器存在硬件共享关系。例如，RISC-V的BEQ rs1, rs2, offset需要计算$\texttt{rs1} - \texttt{rs2}$来判断是否相等，而SLT rd, rs1, rs2（Set Less Than）也需要计算同样的减法。如果BRU与简单整数ALU共享执行端口（如BOOM处理器的设计），两者可以共用同一个64位加法/减法器，只是对结果的解释方式不同——BRU提取差值的零标志和符号/溢出标志来决定分支方向，SLT则将比较结果写入目标寄存器。

这种共享策略的优点是节省面积和端口数量，缺点是分支指令与整数运算竞争同一个端口的执行带宽。为了量化这种竞争的影响，考虑以下分析：

性能分析 1 — BRU端口共享对分支延迟的影响

在一个BRU与整数ALU共享端口的设计中，假设：

• 分支指令占动态指令的20%。

• 共享端口上的整数ALU指令占25%。

• 端口利用率约为45%（两者之和）。

当分支指令与整数ALU指令在同一周期同时就绪时，如果调度器采用"分支优先"策略，整数ALU指令被延迟1个周期的概率约为$0.20 \times 0.25 = 5\%$。反之，如果不给分支优先，分支指令的平均调度延迟增加约$0.25$个周期。

设分支预测失败率为5%，每次失败的代价为15个周期。不给分支优先时，分支的平均调度延迟增加0.25周期，但这0.25周期的延迟只在预测失败时才有实际损害。性能影响约为$0.05 \times 0.25 \times 15 / \text{平均CPI} \approx 0.12\%$（假设平均CPI=1.5）。虽然绝对值很小，但在性能每百分之一都很宝贵的场景下（如数据中心服务器），这一优化仍然值得。

在分支密集的代码段中（如链表遍历、树搜索），这可能成为性能瓶颈。一些高性能设计因此为BRU配备专用的执行端口——例如Intel的Golden Cove在6个整数端口中有1个专用于分支执行（Port 0），且该端口同时也能执行简单整数运算，但分支指令拥有更高的调度优先级。

条件移动与条件选择的BRU分流效应

值得注意的是，现代ISA中的条件移动/选择指令（x86 CMOV、ARM CSEL、RISC-V Zicond扩展的czero.eqz/czero.nez）可以将部分简单的"if-else"模式转化为无分支的数据流操作。编译器在优化时会将预测困难的短分支转换为条件选择指令，从而减少BRU的工作负载和分支预测失败的风险。这些条件选择指令在整数ALU上执行，不经过BRU。从系统层面看，条件选择指令的普及有效地"过滤"了容易预测的分支，留给BRU的主要是那些真正需要控制流跳转的分支指令——这些分支的预测难度可能更高，对BRU和预测器的设计提出了更高的要求。

目标地址计算

BRU的第二个核心功能是计算分支的目标地址（target address）——即如果分支被采取（taken），程序应该跳转到哪个地址继续执行。不同类型的分支指令使用不同的地址计算方式。

PC相对偏移（PC-relative Offset）

条件分支指令和直接跳转指令通常使用PC相对寻址：目标地址 = 当前指令的PC + 符号扩展的立即数偏移量。以RISC-V的B类指令为例，偏移量是一个12位有符号立即数（左移1位后为13位，表示$\pm 4$ KB的范围），目标地址计算为：

$$\text{target} = \text{PC}_{\text{branch}} + \text{sign\_extend}(\text{imm}[12:1] \ll 1)$$

x86的条件分支指令也使用PC相对偏移，但偏移量的位宽更灵活——8位短跳转（Jcc rel8，$\pm 127$字节）和32位近跳转（Jcc rel32，$\pm 2$ GB）。在微架构层面，偏移量的位宽差异只影响符号扩展逻辑的宽度，目标地址加法器始终是64位的。

PC相对分支的目标地址计算在硬件上非常简单——只需要一个64位加法器。更重要的是，由于偏移量是指令编码中的立即数，目标地址在解码阶段就可以计算出来。因此，对于条件分支指令，前端预测器通常只需要预测方向（taken/not-taken），而目标地址在解码时就已确定。这意味着BRU在验证PC相对分支时，目标地址的匹配通常不会失败——预测失败主要体现在方向错误上。

寄存器间接跳转（Register Indirect Jump）

间接跳转指令的目标地址来自通用寄存器，而非立即数偏移。例如RISC-V的JALR指令计算目标地址为$\texttt{rs1} + \text{imm}[11:0]$，x86的JMP r/m64和CALL r/m64从寄存器或内存中读取目标地址。

间接跳转对微架构的挑战远大于PC相对分支：

• 目标地址依赖于寄存器值，只有在执行阶段才能确定。前端必须通过间接分支预测器（Indirect Branch Predictor）来预测目标地址。

• 预测失败不仅可能是方向错误（对于有条件的间接跳转），还可能是目标地址错误——前端预测的跳转目标与BRU计算的实际目标不一致。

• 间接跳转的目标地址可能随运行时上下文变化（如虚函数调用、switch-case跳转表、函数指针），预测难度高于直接分支。

返回地址（Return Address）

函数返回指令（RISC-V的JALR跳转到ra、x86的RET）是间接跳转的一个重要特例。由于返回地址与调用地址具有天然的配对关系（LIFO），前端使用返回地址栈（Return Address Stack，RAS）来预测返回地址，准确率通常超过99%。BRU在执行返回指令时，需要验证RAS预测的返回地址是否与实际的ra（或栈中弹出的地址）一致。

在BRU内部，目标地址计算逻辑的硬件实现通常复用整数ALU中的加法器——实际上很多微架构将BRU安排在某个整数执行端口上，共享该端口的加法器来进行$\text{PC} + \text{offset}$或$\texttt{rs1} + \text{imm}$的计算。

硬件描述 1 — BRU的目标地址计算通路

BRU的目标地址计算通路需要支持以下几种模式：

1. PC + 立即数偏移：用于条件分支和直接跳转。输入为分支指令的PC和符号扩展后的偏移量，经过64位加法器得到目标地址。

2. 寄存器 + 立即数偏移：用于间接跳转（如RISC-V JALR）。输入为源寄存器rs1的值和12位符号扩展的立即数。RISC-V规范要求结果的最低位清零（$\text{result}[0] = 0$）。

3. 栈/内存读取：用于x86 RET，目标地址从RSP指向的栈内存中弹出。这种情况下，目标地址的获取实际上涉及一次内存加载，延迟更高。在微架构实现中，RET通常被拆分为一个内存加载微操作和一个间接跳转微操作。

此外，BRU还需要计算链接地址（link address）——对于JAL/JALR（RISC-V）或CALL（x86），需要将返回地址（通常为$\text{PC} + 4$或$\text{PC} + \text{指令长度}$）写入目标寄存器或栈中。链接地址的计算可以与目标地址计算并行进行。

早期目标地址计算的优化

对于PC相对分支，目标地址计算仅依赖于PC和立即数偏移——这两个值在解码阶段（decode stage）就已完全确定。因此，许多微架构选择在解码级或解码后的预分派级就完成目标地址的计算，而不是等到执行阶段由BRU计算。这种早期目标地址计算（Early Target Calculation）有两个重要好处：

1. 如果前端预测器预测了该分支为taken但给出了错误的目标地址（可能因为BTB容量不足导致的别名冲突），解码级可以立即检测到目标地址不匹配并产生一个早期redirect，而无需等到BRU执行。这种早期纠正可以节省数个周期的流水线延迟。

2. 对于解码级才第一次遇到的分支指令（BTB中尚无记录），解码级可以将计算出的目标地址直接填入BTB，避免等到BRU执行后再更新BTB。

然而，对于间接跳转（目标地址依赖寄存器值），解码级无法提前计算目标地址，只能依赖BRU在执行阶段完成验证。

分支类型的BRU处理差异

不同类型的分支指令在BRU中的处理方式和验证重点有所不同：

分支类型	方向验证	目标验证	主要失败来源
条件分支（直接）	是	通常不需要	方向预测错误
无条件直接跳转	不需要	通常不需要	BTB别名冲突
间接跳转	不需要	是	目标预测错误
条件间接跳转	是	是	方向或目标错误
函数返回	不需要	是	RAS溢出/损坏

不同分支类型在BRU中的验证重点

对于条件直接分支（如RISC-V的BEQ），前端在解码时就已经计算出目标地址（PC + offset），因此BRU只需要验证方向是否正确——目标地址通常不会错误（除非BTB容量不足导致了别名冲突）。

对于间接跳转（如RISC-V的JALR），方向总是taken（无条件跳转），BRU只需要验证目标地址——将计算出的$\texttt{rs1} + \text{imm}$与预测的目标地址比较。间接分支的预测失败率通常高于直接分支，因为间接分支的目标地址可能随运行时上下文变化。

对于函数返回（RET或JALR rd, 0(ra)），目标地址来自RAS的预测。RAS的预测准确率通常非常高（$>$99%），但在以下情况下可能失败：

• 调用深度超过RAS容量（通常16$\sim$64层），导致最早的返回地址被覆盖。

• 异常或信号处理打断了正常的CALL/RET配对。

• 使用JALR跳转到非标准返回地址（如longjmp、尾调用优化）。

BRU与前端预测器的交互协议

BRU与前端分支预测器之间的通信是一个异步的"请求-响应"模式：

1. 预测阶段（前端）：预测器在取指时为每条分支产生预测结果（方向 + 目标地址），并将预测元数据附加到分支指令上。

2. 验证阶段（BRU）：BRU在执行阶段将预测结果与实际结果比较，产生验证信号。

3. 更新阶段（退休时或执行时）：BRU将分支的实际行为反馈给预测器，用于训练和更新预测表。

这三个阶段在时间上相隔可能超过20个周期（取指到执行的流水线深度），在此期间同一分支地址可能被预测器多次查询（由于循环迭代）。为了确保预测器在多次查询之间使用一致的状态，高性能处理器通常维护两份预测器状态：

• 投机状态（Speculative State）：在每次预测后立即更新，反映最新的预测方向。投机状态用于后续取指的预测。

• 确认状态（Committed State）：只在分支指令退休时更新，保证不包含被清空的投机结果。确认状态用于在预测失败后恢复预测器。

BRU在检测到预测失败时，通过redirect_bhr信号将确认的分支历史传递给前端，前端用此值重置投机状态到确认检查点。

JALR的地址计算细节

RISC-V的JALR指令计算目标地址为$(\texttt{rs1} + \text{sign\_ext}(\text{imm}[11:0])) \mathbin{\&} \sim 1$——即将rs1加上符号扩展的12位偏移后，将最低位清零（强制对齐到2字节边界）。这个清零操作在硬件上只需要将加法器输出的最低位设置为0（一个AND门），几乎没有额外的延迟。然而，最低位的清零意味着BRU计算的实际目标地址与简单的"寄存器+偏移"之和可能差一个最低位——软件和验证工程师需要特别注意这个细节。

图图 33.2展示了BRU的内部结构框图。

BRU内部结构框图：条件判断、目标地址计算与预测验证三大功能模块

BRU流水线与Mispredict检测电路

理解了BRU的各功能模块之后，我们可以将其执行过程组织为一条精确的微流水线。图图 33.3展示了BRU在一个时钟周期内完成的四个逻辑阶段——它们在物理上是组合逻辑级联，而非独立的流水线寄存器分隔的级。

BRU的微流水线阶段分解：操作数读取$\to$条件判断/目标计算（并行）$\to$mispredict检测$\to$redirect生成。全部在一个时钟周期内完成。

::: info 硬件描述 2 — BRU Mispredict检测电路的硬件实现

BRU的mispredict检测电路是整个分支验证机制的核心。其硬件实现需要在一个时钟周期的后半部分（约100 ps以内）完成以下操作：

方向比较器：一个1位XOR门，比较pred_taken与actual_taken。如果两者不同，输出dir_mismatch = 1。延迟：1级门（$\sim$5 ps）。

目标地址比较器：一个48位$\sim$64位的相等比较器，比较pred_target与actual_target。实现为$N$位XOR阵列后接OR归约树。对于48位地址：48个XOR门并行（1级门），然后48:1 OR归约（$\lceil \log_2 48 \rceil = 6$级2:1 OR门）。总延迟约7级门（$\sim$35 ps）。输出tgt_mismatch。

Mispredict逻辑：

$$\texttt{mispredict} = \texttt{dir\_mismatch} \lor (\texttt{actual\_taken} \land \texttt{tgt\_mismatch})$$

需要1个AND门和1个OR门（2级门，$\sim$10 ps）。

Redirect目标选择MUX：根据mispredict的类型选择正确的redirect目标：

• 如果方向预测错误且实际为taken：redirect目标 = BRU计算的目标地址。

• 如果方向预测错误且实际为not-taken：redirect目标 = 分支指令的下一条顺序地址（PC + 指令长度）。

• 如果方向正确但目标错误：redirect目标 = BRU计算的目标地址。

这是一个2:1的64位MUX，由actual_taken控制。延迟约1级门。

总关键路径：目标地址比较器的7级门延迟是最长的路径，加上mispredict逻辑的2级门和MUX的1级门，总计约10级门（$\sim$50 ps）。这条路径从BRU计算出实际目标地址的时刻开始，因此是BRU时钟周期后半段的关键路径。在4 GHz（250 ps周期）设计中，目标地址计算占前$\sim$150 ps，mispredict检测和redirect生成占后$\sim$100 ps，时序可以满足。

:::

以下SystemVerilog代码展示了BRU mispredict检测逻辑的RTL实现，这是第 17.0 章中讨论的分支预测器在执行端的"镜像验证"逻辑。

module bru_mispredict_detect #(
    parameter ADDR_W = 48,
    parameter ROB_IDX_W = 8,
    parameter BHR_W = 64
)(
    // BRU计算结果
    input  logic              actual_taken,
    input  logic [ADDR_W-1:0] actual_target,
    input  logic [ADDR_W-1:0] branch_pc,
    input  logic [3:0]        branch_len,   // x86变长: 2-15字节

    // 前端预测元数据
    input  logic              pred_taken,
    input  logic [ADDR_W-1:0] pred_target,

    // 分支元数据
    input  logic [ROB_IDX_W-1:0] rob_idx,
    input  logic [BHR_W-1:0]     bhr_checkpoint,

    // Redirect输出
    output logic              redirect_valid,
    output logic [ADDR_W-1:0] redirect_target,
    output logic [ROB_IDX_W-1:0] redirect_rob_idx,
    output logic [BHR_W-1:0]     redirect_bhr
);

    // 方向比较: 1-bit XOR
    logic dir_mismatch;
    assign dir_mismatch = (pred_taken != actual_taken);

    // 目标地址比较: N-bit XOR + OR归约
    logic tgt_mismatch;
    assign tgt_mismatch = |(pred_target ^ actual_target);

    // Mispredict判定
    // 方向错 || (实际taken但目标错)
    assign redirect_valid = dir_mismatch |
                            (actual_taken & tgt_mismatch);

    // 正确目标地址选择
    // taken -> 使用BRU计算的目标; not-taken -> fall-through
    logic [ADDR_W-1:0] fallthrough_pc;
    assign fallthrough_pc = branch_pc + {{(ADDR_W-4){1'b0}}, branch_len};

    assign redirect_target = actual_taken ? actual_target
                                          : fallthrough_pc;

    // 传递恢复信息
    assign redirect_rob_idx = rob_idx;
    assign redirect_bhr     = bhr_checkpoint;

endmodule

设计提示

上述RTL代码中，tgt_mismatch的实现使用了Verilog的归约OR运算符|，综合工具会将其映射为一棵OR归约树。在物理实现中，这棵树的深度为$\lceil \log_2 48 \rceil = 6$级，是mispredict检测的关键路径。如果时序紧张，可以将目标地址比较拆分为高24位和低24位两组并行比较，然后用一个2输入OR合并结果——这不改变逻辑深度（仍为$\lceil \log_2 24 \rceil + 1 = 6$级），但可以通过减小每组的扇入来降低实际布线延迟。在更激进的设计中，可以将预测目标地址的高位（如高16位）在前一周期就与BRU的加法器进位链的高位输出进行预比较，从而将当前周期的比较缩短到只需低32位——这种预比较技术以面积换时序，在5 GHz以上的设计中尤为重要。

BRU端口数选择的定量分析

为什么大多数处理器只配备1$\sim$2个BRU端口，而不是更多？这个问题可以从分支指令的动态频率和时间分布来回答。

在典型的通用工作负载中，分支指令占动态指令流的约20%。对于一个4-wide分发的处理器（如AMD Zen 1$\sim$4），每周期平均分发$4 \times 0.20 = 0.8$条分支指令。这意味着单个BRU端口的利用率约为80%——已经较高，但尚未饱和。在6-wide分发的处理器中，分支分发率提升到$6 \times 0.20 = 1.2$条/周期，单BRU端口开始成为瓶颈。因此：

• 4-wide处理器（Zen 1$\sim$4、Skylake）：1个BRU端口通常足够。

• 6-wide处理器（Golden Cove、Zen 5）：1$\sim$2个BRU端口。

• 8-wide处理器（Apple M系列）：2$\sim$4个BRU端口（包括ALU上的零测试分支）。

增加BRU端口的边际收益遵循Amdahl定律：即使分支执行完全不是瓶颈，分支预测失败的代价仍然存在。第二个BRU端口的主要价值不是提高分支执行吞吐量，而是降低分支在发射队列中的等待时间——当唯一的BRU端口被一条分支占用时，另一条同时就绪的分支必须等待一个周期。这一个周期的延迟在预测失败时会被放大为一个额外周期的错误路径执行。

分支预测验证

BRU最关键的职责是分支预测验证（Branch Prediction Verification）——将前端分支预测器在取指阶段做出的预测结果与BRU在执行阶段计算出的实际结果进行比较。这个验证过程决定了流水线中所有投机执行的指令是否有效。

验证过程涉及两个独立的比较：

方向验证（Direction Verification）：比较预测方向（taken/not-taken）与实际方向。前端预测器为每条分支指令产生一个predicted_taken位，BRU执行后产生一个actual_taken位。如果两者不一致，说明方向预测失败。对于条件分支指令，方向验证是最常见的预测失败来源。

目标地址验证（Target Address Verification）：当分支实际被采取（taken）时，比较预测的目标地址predicted_target与BRU计算的实际目标地址actual_target。如果两个地址不一致，即使方向预测正确，也算预测失败。目标地址验证对于间接分支尤为重要——间接分支的目标地址可能每次执行都不同，前端的间接分支预测器（如BTB中的间接分支目标缓存）的准确率通常低于方向预测器。

预测失败的判断逻辑可以用以下伪代码表示：

$$\texttt{mispredict} = (\texttt{pred\_taken} \neq \texttt{actual\_taken}) \lor (\texttt{actual\_taken} \land (\texttt{pred\_target} \neq \texttt{actual\_target}))$$

其中，第一个析取项处理方向预测失败，第二个析取项处理目标地址预测失败（仅在分支实际被采取时才需要检查目标地址——如果分支不被采取，目标地址无关紧要）。

预测信息的传递

为了在BRU中进行验证，前端预测器的预测结果需要伴随分支指令一路经过流水线传递到执行阶段。具体来说，每条分支指令在进入后端时需要携带以下预测元数据：

• predicted_taken：预测的方向（1位）。

• predicted_target：预测的目标地址（通常为完整的虚拟地址宽度，如48位或64位）。

• branch_type：分支类型编码（条件分支、直接跳转、间接跳转、返回等），用于指导验证逻辑的行为和后续的预测器更新。

• bhr_snapshot：分支历史寄存器（BHR）的快照，用于预测失败时恢复预测器的历史状态。

• ras_pointer：RAS指针的快照，用于在预测失败时恢复RAS状态。

这些元数据存储在分支指令的ROB条目或专用的分支检查点缓冲区（Branch Checkpoint Buffer）中。由于分支指令占比约20%，且每条分支需要携带的元数据约为100$\sim$150位（目标地址48位 + 历史信息32$\sim$64位 + 其他控制位），分支检查点缓冲区的存储开销不容忽视。现代处理器通常支持32$\sim$128个未决分支（in-flight branches），对应的检查点存储总量为4$\sim$16 Kb。

性能分析 2 — 分支预测验证的延迟影响

分支预测验证延迟（从分支指令进入后端到BRU产生验证结果的周期数）直接决定了预测失败恢复的"发现延迟"（detection latency）。在典型的乱序处理器中，这个延迟包括：

• 分支指令在发射队列中等待操作数就绪：0$\sim$N周期（取决于数据依赖）

• 分支指令从发射队列调度到执行端口：1周期

• BRU执行（条件判断 + 地址计算 + 验证比较）：1周期

因此，从分支指令分派（dispatch）到验证结果可用的最小延迟约为2$\sim$3周期。在此期间，前端持续按照预测方向取指和分派新指令——如果预测最终被证明是错误的，这些指令都将被清空。这就是为什么即使BRU本身只需要1个周期，分支预测失败的代价仍然高达10$\sim$25个周期——大部分代价来自清空流水线和重新填充的延迟（即前端重填延迟，front-end refill latency）。

BRU对预测器的训练更新

BRU不仅负责验证预测结果，还需要将实际的分支行为反馈给前端的分支预测器进行训练更新（training update）。无论预测是否正确，每条分支指令执行完毕后，BRU都会向分支预测器发送一个更新包（update packet），包含以下信息：

• 分支指令的PC地址（用于索引预测器表项）

• 实际方向（taken/not-taken）

• 实际目标地址（用于更新BTB）

• 分支历史寄存器的快照（用于更新基于历史的预测器）

• 分支类型（用于更新间接分支预测器或RAS）

更新操作通常在分支指令退休（retire）时执行，以确保只有确定正确的分支结果才会被用于训练预测器——这避免了投机执行的分支结果"污染"预测器状态。然而，延迟到退休时更新意味着预测器的状态更新有较大延迟（从分支执行到退休通常有数十个周期），在此期间同一分支地址的后续出现将使用旧的预测状态。一些高性能设计采用在执行时即时更新的策略——在BRU验证完成后立即更新预测器的投机状态（speculative state），如果后续发生流水线清空，再回滚预测器状态到检查点。这种策略的优点是降低了更新延迟，缺点是增加了预测器状态管理的复杂度。

BRU更新包的带宽需求

在高频率、宽发射的处理器中，BRU每周期可能需要向前端发送1$\sim$2个分支更新包。每个更新包的位宽约为：PC地址（48$\sim$64位）+ 实际方向（1位）+ 目标地址（48$\sim$64位）+ 分支历史（16$\sim$64位）+ 分支类型（3$\sim$4位）$\approx$ 120$\sim$200位。这个更新包需要从后端传输到前端的分支预测器——与redirect信号类似，这条物理路径也可能成为时序瓶颈。

为了降低更新带宽的压力，一种常见的优化是压缩更新包：例如目标地址只发送与PC的偏移量（通常只需20$\sim$30位），分支历史只发送增量更新（1$\sim$2位），而非完整的历史快照。这种压缩可以将更新包的位宽降低40%$\sim$50%，但需要前端预测器具备增量更新的能力。

BRU验证的微架构时序详解

BRU的验证过程是一个精确的多阶段操作，必须在严格的时序约束下完成。以下是典型的BRU验证时序分解（以Intel Golden Cove为例）：

1. T-1周期（调度）：调度器选择就绪的分支指令并发射到BRU执行端口。同时，分支指令对应的预测元数据（预测方向、预测目标地址）从分支检查点缓冲区中读取。

2. T周期（执行 + 验证）：BRU在半个时钟周期内完成以下操作：

   • 前半周期：读取源寄存器操作数（通过寄存器文件或旁路网络），执行条件判断（比较器或标志位检查），计算目标地址（PC + offset 或 rs1 + imm）。

   • 后半周期：将BRU计算的实际方向和目标地址与预测元数据进行比较。如果不匹配，产生mispredict信号。同时计算链接地址（如果是CALL类指令）。

3. T+1周期（redirect传播）：如果检测到预测失败，redirect信号从BRU传播到前端取指单元。在某些微架构中，这需要通过中继寄存器，延迟增加到T+2周期。

从调度到redirect生效的总延迟约为2$\sim$3个周期。在此期间，前端持续按错误预测方向取指和分派指令——这些指令的数量约等于（前端宽度）$\times$（2$\sim$3周期）。在一个8-wide的处理器中，这意味着约16$\sim$24条错误路径指令被分派——它们最终都会被清空。

条件码计算的硬件优化

BRU内部的条件码计算可以通过多种硬件技巧来优化延迟：

1. 等于/不等判断的快速路径：BEQ/BNE（RISC-V）或JE/JNE（x86）只需要判断两个操作数是否相等。等于判断不需要完整的减法——只需要计算$A \oplus B$（按位异或），然后对所有结果位做OR归约。64位的异或+OR归约可以在2级门延迟内完成（$64 \times 1$位XOR并行，然后64:1 OR树为6级2:1 OR = 6级门延迟），远快于64位减法（约12$\sim$16级门延迟）。因此，等于/不等判断的BRU可以有一条比有符号/无符号比较更快的快速路径。

2. 高位/低位并行比较：对于大于/小于的比较，可以将64位操作数拆分为高32位和低32位。高32位的比较可以与低32位的比较并行进行。大多数情况下（约75%），高32位的比较就可以确定大小关系，不需要等待低32位的结果——只有在高32位相等时才需要参考低32位。这种提前终止（early termination）策略可以在统计上降低比较的平均延迟。

3. 标志位的直接读取：对于x86的flags-based分支，BRU不需要"计算"条件——它只需要从标志位寄存器中读取几个位并通过简单的逻辑门组合产出taken/not-taken判断。这一操作的延迟极低（2$\sim$3级门延迟），使得x86 BRU的关键路径不在条件判断上，而在目标地址计算（64位加法器）上。

硬件描述 3 — BRU条件判断的关键路径分析

对于RISC-V的BLT rs1, rs2, offset指令，BRU需要判断$\texttt{rs1} < \texttt{rs2}$（有符号）。关键路径分析如下：

1. 寄存器文件读取：$\sim$50 ps

2. 旁路MUX选择：$\sim$20 ps

3. 64位减法器（$\texttt{rs1} - \texttt{rs2}$）：$\sim$100 ps（Han-Carlson并行前缀加法器）

4. 符号位 + 溢出位检测：$\sim$10 ps

5. 与预测方向比较（1个XOR门）：$\sim$5 ps

6. redirect信号产生：$\sim$15 ps

7. 总计：$\sim$200 ps

在4 GHz（250 ps周期）的设计中，这条路径刚好可以在一个时钟周期内完成，几乎没有时序裕量。这就是为什么某些微架构选择将BRU设计为2周期延迟——在减法器和redirect信号产生之间插入一个流水线寄存器，降低时序压力但增加一个周期的预测失败恢复延迟。

预测失败时的信号

当BRU检测到分支预测失败时，需要触发一系列复杂的流水线恢复（pipeline recovery）操作。这个恢复过程是乱序处理器中最关键的控制流操作之一，涉及前端、后端和中间各级流水线寄存器的协调。

Redirect信号

BRU产生的核心输出信号是redirect——一个指示前端需要重新定向取指的控制信号。redirect信号通常包含以下字段：

• redirect_valid：指示当前周期存在有效的重定向请求（1位）。

• redirect_target：正确的目标地址，前端应从此地址开始重新取指。对于taken分支，这是BRU计算出的实际目标地址；对于not-taken分支（前端错误地预测为taken），这是分支指令的下一条顺序指令地址（$\text{PC}_{\text{branch}} + \text{指令长度}$）。

• redirect_rob_idx：产生重定向的分支指令在ROB中的索引，用于确定哪些指令需要被清空。

• redirect_bhr：恢复后的分支历史寄存器值，前端预测器需要用此值重置其历史状态。

• redirect_ras_ptr：恢复后的RAS指针，用于重置RAS状态。

分支预测失败时的redirect流程：BRU检测到失败后产生redirect信号，清空错误路径上的指令，前端从正确目标地址重新取指

流水线清空（Pipeline Flush）机制

redirect信号触发的流水线清空操作包括以下几个步骤：

1. 前端重定向：取指单元（IFU）接收redirect_target，将PC更新为正确的目标地址，从下一周期开始从正确路径取指。同时，前端的分支预测器使用redirect_bhr重置其分支历史状态。

2. 后端清空：ROB使用redirect_rob_idx确定分支指令在ROB中的位置。所有在该分支指令之后分派的指令（即ROB中位于该分支之后的所有条目）都被标记为无效并清除。这个清除操作包括：

   • 释放这些指令占用的物理寄存器（归还到空闲列表）

   • 从发射队列中移除这些指令的条目

   • 从加载/存储队列中移除相应的条目

   • 恢复寄存器重命名表到分支指令分派时的状态（通过检查点或逆向重命名）

3. 中间流水线级清空：位于解码级和分派级之间的流水线寄存器中可能还有正在处理的指令（来自错误路径），这些指令也需要被清空。通常通过在这些流水线寄存器上施加flush信号来实现——被flush的指令在下一个周期被丢弃。

案例研究 1 — Intel与AMD的分支预测失败恢复策略

Intel的Golden Cove微架构采用了即时清空+即时重取的策略：BRU在T周期产生redirect信号后，前端在T+1周期就开始从正确路径取指，总的预测失败代价约为12$\sim$14周期（从错误取指到正确指令首次到达执行阶段）。

AMD的Zen 4微架构也采用了类似的策略，但通过更快的重命名表恢复机制（基于检查点的快照恢复，而非逆向遍历ROB）来缩短后端恢复延迟。Zen 4维护了多个重命名表检查点，每个检查点对应一条未决分支指令。当预测失败时，直接将重命名表切换到对应的检查点，恢复延迟为1个周期，而基于逆向遍历的恢复方案延迟与ROB中需要回滚的指令数成正比。

Apple的M系列处理器（Firestorm微架构）采用了更激进的策略：它维护了大量的分支检查点（据推测超过100个），配合极深的流水线和极大的ROB（超过600条目），使得分支预测失败的恢复延迟虽然绝对值较大（约16$\sim$18周期），但由于ROB足够大，IPC损失的相对影响被摊薄。

重命名表恢复的两种策略

预测失败恢复中最复杂的部分之一是重命名映射表的恢复。乱序引擎在分派指令时会修改寄存器重命名表（RAT），将逻辑寄存器映射到新分配的物理寄存器。当分支预测失败需要回滚时，必须将RAT恢复到分支指令分派时的状态。有两种主要的恢复策略：

策略一：基于检查点的恢复（Checkpoint-based Recovery）。在每条分支指令分派时，保存当前RAT的完整快照（检查点）。预测失败时，直接将RAT切换到对应的检查点，恢复延迟为1个周期（一次MUX选择）。缺点是存储开销大——如果支持$N$条未决分支，需要$N$份RAT副本，每份RAT包含架构寄存器数量$\times$物理寄存器索引位宽的存储。例如，RISC-V的32个整数寄存器$\times$8位物理寄存器索引$\times$64个检查点 = 16 Kb。

策略二：基于ROB遍历的恢复（ROB Walk-based Recovery）。从ROB的尾部（最新指令）开始逆向遍历，逐条撤销每条指令对RAT的修改（将物理寄存器映射还原为指令执行前的映射）。这种方法不需要额外的检查点存储，但恢复延迟与需要回滚的指令数成正比——在极端情况下可能需要数十个周期。现代高性能处理器通常采用检查点方案或混合方案以获得最快的恢复速度。

多分支同时失败的优先级

在宽发射的超标量处理器中，同一周期内可能有多条分支指令同时在不同的BRU端口上执行，并且多条分支可能同时检测到预测失败。当这种情况发生时，需要一个优先级仲裁机制来决定哪个redirect信号生效。

当两条分支同时失败时，除了选择正确的redirect外，还需要确保物理寄存器释放的正确性——只有程序序较早的分支之后的所有指令（包括程序序较晚的那条分支本身）都应该被清空。这意味着仲裁逻辑不仅要选择正确的redirect目标地址，还要选择正确的检查点来恢复重命名表。

在硬件实现中，多BRU端口的仲裁通常使用一个优先级编码器（priority encoder），以ROB索引的环形比较结果作为优先级。当ROB是环形缓冲区时，"较早"的判断需要考虑环绕（wrap-around）——如果ROB头指针和尾指针之间的距离正确设置，简单的无符号减法比较即可确定程序序。

正确的策略是选择程序序最早（oldest in program order）的那条分支的redirect信号，因为后续分支指令本身就是在该分支的错误路径上投机执行的，它们的结果毫无意义。ROB索引的比较可以用来确定程序序——ROB索引较小（考虑环绕）的分支在程序序上更早。

$$\texttt{selected\_redirect} = \arg\min_{\text{ROB\_idx}} \{ \text{redirect}_i \mid \texttt{redirect\_valid}_i = 1 \}$$

多BRU端口的仲裁设计

在宽发射的高性能处理器中（如Apple M4的Everest核心），可能配备2个甚至更多的BRU执行端口，以支持高分支密度的工作负载。多BRU端口带来了新的设计挑战：

1. 同周期多分支验证：当两个BRU端口在同一周期各完成一条分支的验证时，如果两者都检测到预测失败，需要仲裁逻辑选择程序序较早的那条分支的redirect信号。这个仲裁可以在1级比较器延迟内完成（比较两条分支指令的ROB索引）。

2. 分支历史的投机更新：每个BRU端口的验证结果都需要更新分支历史寄存器（BHR）。如果两个BRU端口在同一周期验证了两条分支，BHR需要按照程序序正确更新——先更新程序序较早的分支，再更新较晚的。这需要BHR支持"批量更新"（batch update）——在一个周期内按正确顺序更新2位历史。

3. 检查点管理：每个未决分支都需要一个检查点。在多BRU端口的设计中，每周期可能有2条分支被分派（每条需要创建检查点），也可能有2条分支被验证通过（对应的检查点可以被释放）。检查点分配和释放逻辑需要支持每周期2次分配和2次释放，增加了管理复杂度。

案例研究 2 — Apple M系列的多BRU设计

Apple的Firestorm/Avalanche/Everest微架构据分析配备了多个分支执行端口——至少2个专用BRU端口，加上某些整数ALU端口也可以执行简单的分支判断（如CBZ/CBNZ类的零/非零测试分支）。这种"分布式分支执行"设计的优势在于：

• 在分支密集的代码中（如JavaScript解释器的字节码分派循环），多个分支可以在同一周期被验证，大幅减少了分支预测失败后的恢复延迟。

• 简单的零测试分支可以在ALU端口上以"旁路"方式执行——利用ALU已有的零检测逻辑，不需要额外的BRU硬件。

• Apple的超大ROB（$>$600项）和大量分支检查点（$>$100个）为多BRU端口提供了足够的后端资源支撑。

这种激进的多BRU设计是Apple M系列在单线程IPC上领先x86竞品的重要因素之一——在SPECint等分支密集的基准测试中，多BRU端口带来的分支吞吐量提升直接转化为IPC优势。

BRU与流水线前端的接口时序

图图 33.4展示了分支预测失败时的时序关系。一个关键的设计约束是：redirect信号必须在一个时钟周期内从BRU传播到前端取指单元——这是一条长距离的控制信号路径，在物理设计上可能成为时序瓶颈。在大型处理器核心中，BRU位于后端执行区域，取指单元位于前端区域，两者之间的物理距离可能超过1 mm。为了满足时序要求，现代处理器通常在这条路径上插入中继寄存器（relay register），将redirect信号的传播延迟从1周期增加到2周期——这意味着预测失败恢复多花费1个周期的代价，但保证了时钟频率不受影响。

BRU与投机执行安全

2018年披露的Spectre和Meltdown漏洞揭示了分支预测和投机执行对处理器安全的深远影响。BRU作为投机执行验证的核心组件，在安全防护中扮演着关键角色。

Spectre攻击的微架构本质

Spectre v1（Bounds Check Bypass）攻击利用了条件分支的投机执行窗口：当BRU尚未验证一条条件分支的方向时，处理器已经按照预测方向投机执行了后续指令。如果预测错误，这些投机执行的指令虽然最终会被清空（结果不写入体系结构状态），但它们可能已经在微架构状态（如缓存行的存在/不存在）上留下了可观测的痕迹。

攻击者利用这一窗口，诱导受害者代码在投机路径上越界访问内存——受害者的条件检查（如if (x < array_len)）被预测为"通过"，投机执行的加载指令读取了越界数据，并将数据通过缓存侧信道传递给攻击者。

从BRU的角度看，Spectre的根本原因是验证延迟——从分支指令进入后端到BRU验证完成之间存在一个时间窗口，在此窗口内的投机操作可能产生安全敏感的侧效果。

BRU侧的缓解策略

针对Spectre的BRU侧缓解策略包括：

1. 投机加载屏障（Speculative Load Barrier）：在条件分支和受其保护的加载指令之间插入一条屏障指令（如x86的LFENCE或ARM的CSDB），阻止加载在分支验证完成之前执行。这消除了投机窗口，但以性能代价为代价——每条可能被Spectre利用的分支都需要插入屏障。

2. 投机存储缓冲区隔离：在投机执行期间，不允许加载指令从投机存储的数据中获取值（即不进行投机的Store-to-Load Forwarding），防止投机存储影响后续加载的可观测行为。

3. 分支预测器隔离：在不同安全域（如不同进程、不同虚拟机、内核态/用户态）之间隔离分支预测器的状态，防止一个域的分支行为"训练"预测器以误导另一个域的分支预测。Intel的IBRS（Indirect Branch Restricted Speculation）和AMD的相关机制都是此类防护。

4. 返回地址栈防护：在RAS中增加安全检查，防止恶意代码通过操纵栈帧来毒化RAS中的返回地址预测。ARM的Pointer Authentication Code（PAC）可以对返回地址进行签名验证，在BRU验证阶段发现被篡改的返回地址。

设计权衡 2 — 安全性 vs 性能的Spectre缓解

Spectre缓解措施对处理器性能的影响因策略而异：

缓解策略	性能影响	安全覆盖
LFENCE屏障（软件）	5%$\sim$30%	仅限插入屏障处
IBRS（固件/微码）	2%$\sim$10%	间接分支预测
Retpoline（编译器）	5%$\sim$15%	间接分支（全部）
STIBP（硬件）	1%$\sim$5%	SMT间的分支预测
BHI清除（硬件）	0.5%$\sim$2%	分支历史注入

在数据中心环境中，Spectre缓解的总性能开销约为5%$\sim$15%——这是一个不可忽视的代价。新一代处理器（如Intel Golden Cove、AMD Zen 4）在硬件层面集成了更多的安全防护机制，力求在保持安全性的同时降低性能开销。

IBRS/STIBP的硬件实现细节

Intel的IBRS（Indirect Branch Restricted Speculation）和STIBP（Single Thread Indirect Branch Predictors）是在BRU和分支预测器中实现的硬件安全机制，值得深入分析其微架构含义。

IBRS的硬件实现原理是：当IBRS被启用时（通过写入IA32_SPEC_CTRL MSR），处理器在特权级切换（如从用户态到内核态）时，阻止低特权级的分支历史影响高特权级的间接分支预测。在微架构层面，这意味着：

1. 间接分支预测器（如BTB中的间接目标缓存）需要维护特权级标签——每个预测条目记录了创建该条目时的特权级。

2. 在IBRS模式下，预测器在查找时只匹配当前特权级或更高特权级创建的条目，忽略低特权级训练的条目。

3. 这有效地防止了用户态代码"毒化"内核态的间接分支预测，但代价是内核态进入后的前几次间接分支预测命中率下降（因为部分预测条目被过滤）。

STIBP的硬件实现更为激进：在SMT启用时，完全隔离两个逻辑线程的间接分支预测器状态。这意味着线程0的间接分支行为不会影响线程1的预测结果。在微架构层面，这通常通过为每个线程维护独立的间接分支目标缓存来实现——将一个共享的间接分支预测表按线程ID分区。STIBP的性能代价来自预测表的有效容量减半（每个线程只能使用一半的条目），在间接分支密集的工作负载（如C++虚函数调用、Python/JavaScript解释器）中可能导致1%$\sim$5%的IPC下降。

这些安全机制的存在深刻影响了BRU的设计——BRU不再是一个纯粹的"计算-比较"单元，它还需要感知当前的安全模式（IBRS/STIBP是否启用）并将相关信息传递给预测器的更新逻辑。这一安全维度的增加是第 50.0 章和第 51.0 章中讨论的处理器安全攻防的硬件基础。

BRU的投机执行审计

为了辅助安全分析，某些处理器在BRU中增加了投机执行审计功能——记录每条分支指令的投机窗口大小（从预测到验证的周期数）和投机路径上执行的指令数量。这些审计数据可以通过性能计数器（如Intel的BR_MISP_RETIRED.ALL_BRANCHES和BR_MISP_EXEC.ALL_BRANCHES的差值）来间接获取，帮助安全工程师评估代码对Spectre攻击的暴露程度。

设计提示

BRU到前端的redirect信号路径是处理器物理设计中的关键路径之一。在频率目标高于4 GHz的设计中，这条路径通常需要专门的时序优化，包括：（1）使用专用的信号布线通道，避免与数据总线竞争布线资源；（2）在BRU输出端使用快速锁存器减少信号建立时间；（3）将redirect目标地址的高位和低位分开传输，低位先到达以便前端提前开始I-Cache访问。

BRU的延迟优化：分支快速路径

分支预测失败代价的一个重要组成部分是BRU自身的执行延迟——从分支指令被调度到执行端口到redirect信号有效的时间。虽然BRU的"计算"很简单（一次比较和一次加法），但在实际的流水线中，BRU需要完成以下操作序列：（1）读取寄存器文件获取源操作数；（2）执行比较/加法；（3）与预测信息比较；（4）产生redirect信号。

为了最小化这条关键路径的延迟，一些微架构采用了分支快速路径（Branch Fast Path）优化：

• 旁路前递（Bypass Forwarding）：当分支指令的源操作数来自刚刚执行完毕的前一条指令时，通过旁路网络直接获取操作数，避免等待寄存器写回。

• 零周期分支（Zero-cycle Branch）：某些微架构（如SiFive的某些RISC-V核心）在特定条件下可以将分支判断合并到发射逻辑中——如果分支条件是"等于零"（BEQZ/BNEZ），只需对源寄存器做零检测（OR归约），这个检测可以在调度级完成，节省了一个周期。然而，这种优化只适用于特定的分支模式，通用性有限。

• 分支预测器与BRU的耦合：将BRU的验证结果直接反馈到前端预测器的更新端口，使用专用的物理布线通道，避免经过通用的结果总线。

分支指令在ROB中的特殊标记

分支指令在ROB中需要额外的元数据来支持BRU的验证和恢复机制。与普通算术指令相比，分支指令的ROB条目通常包含以下额外字段：

字段	位宽	说明
is_branch	1	标识此条目为分支指令
predicted_taken	1	前端预测方向
actual_taken	1	BRU验证后的实际方向（执行后填入）
mispredict	1	BRU验证后的预测失败标志
checkpoint_id	6$\sim$8	对应的重命名表检查点编号
branch_type	3	分支类型编码（条件/无条件/间接/返回）
target_address	48$\sim$64	BRU计算的实际目标地址
额外开销	约60$\sim$80位	每个分支ROB条目

分支指令ROB条目的额外字段

由于只有约20%的指令是分支指令，这些额外字段的平均存储开销为$60 \times 0.20 = 12$位/ROB条目。在一个352项的ROB中，这相当于额外$352 \times 12 = 4224$位$\approx$0.5 KB的SRAM面积。

另一种设计选择是将分支指令的元数据存储在独立的分支队列（Branch Queue）中，而非ROB条目内。分支队列只为分支指令分配条目，因此可以更紧凑——一个64项的分支队列只需要$64 \times 80 \approx 640$字节。分支队列与ROB之间通过指针链接，BRU通过分支队列索引来读取和更新分支元数据。

投机执行深度与分支预测的关系

在深度流水线和大ROB的处理器中，可能同时有数十条分支指令处于未验证的投机状态。这些未决分支的数量称为投机深度（speculative depth）。投机深度受以下因素限制：

1. 检查点数量：每条未决分支需要一个检查点。如果检查点数量为$N$，则最大投机深度为$N$。典型值为32$\sim$128。

2. BHR（分支历史寄存器）的管理：BHR记录最近$K$条分支的方向，用于索引基于历史的预测器。当投机深度$>K$时，BHR已经完全由投机分支的预测结果填充，预测器在此深度下的预测可能不够准确。

3. RAS深度：对于嵌套函数调用，RAS的深度限制了可投机的调用嵌套层数。典型的RAS深度为16$\sim$64层。

当投机深度达到上限时，处理器无法继续投机执行更多分支——在这种情况下，前端必须暂停取指，等待最旧的未决分支被BRU验证后才能继续。这种停顿称为分支检查点耗尽（branch checkpoint exhaustion），在分支极为密集的代码中（如高度嵌套的条件逻辑）可能成为性能瓶颈。

性能分析 3 — 投机深度对IPC的影响

在一个分支指令占比20%、ROB为352项、检查点为64个的处理器中：

• ROB中最多有$352 \times 0.20 = 70$条分支指令。

• 检查点数量（64个）小于ROB中的最大分支数（70），因此检查点可能成为瓶颈。

• 当检查点耗尽时，前端暂停取指，直到最旧的分支退休释放检查点。

• 假设平均分支执行延迟为10周期，每周期退休2条分支。检查点耗尽后的恢复延迟约为$1/2 = 0.5$周期/检查点——但在此期间前端完全停顿，有效IPC降为0。

增加检查点数量可以缓解这一瓶颈，但每个检查点的面积开销约为一份RAT快照的大小。对于RISC-V的32个整数寄存器$\times$8位物理索引的RAT，一个检查点约为$32 \times 8 = 256$位。64个检查点的总面积为$64 \times 256 = 16384$位$\approx$2 KB——这在现代处理器中是可接受的。Apple M系列据推测拥有超过100个检查点，正是为了支持其超大ROB和深度投机执行。

图图 33.5对比了分支预测正确与失败两种情况下的流水线时序。

分支预测正确与失败的流水线时序对比：预测失败导致错误路径指令被清空，正确路径从BRU产生redirect后的下一周期开始取指

密码加速单元

随着互联网通信、云计算和移动设备的普及，几乎所有计算设备都需要执行大量的加密和解密操作——TLS/SSL连接、磁盘加密、安全启动、数字签名验证等。在没有硬件加速的情况下，这些密码学运算完全由软件实现，性能开销极大：纯软件AES-256-CBC加密的吞吐量通常只有几百MB/s，而加入硬件AES-NI指令后可以达到数GB/s甚至更高——性能提升一到两个数量级。

从处理器设计的角度看，密码加速单元是一类"领域专用的功能单元"：它们执行的是高度规则的数学运算（有限域算术、位混淆、非线性替换等），这些运算可以高效地映射为组合逻辑电路，以很小的面积代价换取巨大的性能收益。

密码加速的历史演进

密码加速从纯软件实现到硬件加速经历了明确的演进阶段：

1. 纯软件实现（$\sim$2008年前）：AES和SHA完全由通用整数或SIMD指令实现。AES使用预计算的T-table查找表，性能约为每字节10$\sim$20个周期；SHA使用整数移位/旋转/加法指令，性能约为每字节15$\sim$25个周期。主要瓶颈是指令数量和缓存侧信道风险。

2. SIMD优化软件（2005$\sim$2010年）：使用SIMD指令（SSE/NEON）加速密码运算。例如，AES的bitslicing技术将16个128位块的AES操作转化为SIMD位级并行运算，吞吐量提升约2$\sim$4倍，同时消除了缓存侧信道（因为不使用查找表）。但bitslicing的实现极为复杂，且对单块延迟无改善。

3. 专用指令（2010年至今）：Intel AES-NI（2010年）、ARM Crypto（2011年）、RISC-V Zk（2022年）提供了专用的硬件加速指令。性能提升1$\sim$2个数量级，同时彻底消除了缓存时序侧信道。

4. 宽向量加速（2019年至今）：VAES（2019年）将AES扩展到256/512位向量寄存器，进一步提升了批量加密的吞吐量。

密码加速硬件在处理器中的集成方式有两种典型选择：（1）作为执行引擎中的功能单元，挂载在某个执行端口上，由指令调度器统一管理，与其他功能单元共享寄存器文件和旁路网络——这是Intel AES-NI、ARM Crypto和RISC-V Zk的做法；（2）作为独立的加速器引擎（crypto engine），有自己的指令队列和DMA通道，通过内存映射I/O或专用指令与CPU核心交互——这种方式常见于SoC集成的独立密码加速器（如ARM CryptoCell、Intel QAT）。本节讨论的是第一种方式——作为CPU核心内部功能单元的密码加速硬件。

AES-NI

AES（Advanced Encryption Standard）是目前最广泛使用的对称加密算法，基于Rijndael密码的128位分组、128/192/256位密钥的变体。AES的核心操作是轮函数（round function），对128位（16字节）的状态矩阵执行四个步骤的变换，重复10/12/14轮（分别对应128/192/256位密钥）。

Intel于2010年在Westmere微架构中首次引入了AES-NI（AES New Instructions）指令集扩展，提供了6条专用指令来硬件加速AES操作。AMD随后在Bulldozer微架构中也实现了AES-NI。ARM在ARMv8架构中提供了类似的AES指令。这些指令在本质上做的是同一件事——用硬件组合逻辑直接实现AES轮函数的四个步骤。

AES轮函数的四个步骤

AES将128位明文组织为$4 \times 4$的状态矩阵（State Matrix），每个元素为1字节。轮函数的四个步骤依次对状态矩阵进行变换：

1. SubBytes（字节替换）：对状态矩阵中的每个字节独立地进行非线性替换，使用一个固定的$256 \to 256$的S-box（Substitution Box）。S-box的数学定义基于$\text{GF}(2^8)$有限域上的乘法逆元运算加上一个仿射变换，这种设计提供了良好的密码学安全性（抗线性和差分攻击）。

2. ShiftRows（行移位）：对状态矩阵的四行分别进行循环左移——第0行不移位，第1行左移1字节，第2行左移2字节，第3行左移3字节。这步操作在硬件中只需要固定的字节交叉连线（cross-bar wiring），不需要任何逻辑门，延迟为零。

3. MixColumns（列混合）：对状态矩阵的每列独立地进行$\text{GF}(2^8)$上的矩阵乘法。具体来说，每列4字节与一个固定的$4 \times 4$矩阵相乘（在$\text{GF}(2^8)$上），实现字节之间的线性扩散。$\text{GF}(2^8)$上的乘法可以用xtime操作（左移一位，若溢出则异或$\texttt{0x1B}$）和异或组合来实现。

4. AddRoundKey（轮密钥加）：将状态矩阵与该轮的轮密钥（round key）进行逐字节异或。轮密钥由主密钥通过密钥扩展（key expansion/key schedule）算法导出。

AES-NI指令集

Intel AES-NI包含以下核心指令：

• AESENC xmm1, xmm2/m128：执行一轮AES加密（SubBytes + ShiftRows + MixColumns + AddRoundKey）。xmm1为输入状态，xmm2为轮密钥，结果写回xmm1。

• AESENCLAST xmm1, xmm2/m128：执行AES最后一轮加密（SubBytes + ShiftRows + AddRoundKey，无MixColumns）。

• AESDEC xmm1, xmm2/m128：执行一轮AES解密（逆SubBytes + 逆ShiftRows + 逆MixColumns + AddRoundKey）。

• AESDECLAST xmm1, xmm2/m128：执行AES最后一轮解密。

• AESKEYGENASSIST xmm1, xmm2/m128, imm8：辅助密钥扩展运算。

• AESIMC xmm1, xmm2/m128：计算等效的解密轮密钥（对轮密钥应用逆MixColumns）。

图图 33.6展示了AES轮函数的硬件实现结构。

AES轮函数的硬件实现结构与流水线划分（4级流水线）

AES-NI与侧信道安全

除了性能优势外，AES-NI的一个同等重要的贡献是消除了缓存时序侧信道。纯软件AES实现（如OpenSSL的传统实现）使用预计算的S-box查找表（T-table），这些表存储在数据缓存中。攻击者通过Flush+Reload、Prime+Probe等缓存侧信道技术，可以观测到S-box查找触发的缓存行访问模式，进而推断出密钥的部分比特。这类攻击在共享硬件的云计算环境中尤为危险——同一物理核心上的不同虚拟机可能共享L1/L2缓存。

AES-NI将S-box实现为固定的组合逻辑电路，运算过程完全不涉及数据缓存访问，因此在物理层面上不存在缓存时序泄漏。这种"恒定时间"（constant-time）执行特性是AES-NI在安全性方面相对于软件实现的本质优势。密码学库（如OpenSSL 1.1+、BoringSSL）在检测到处理器支持AES-NI时，会自动切换到硬件加速路径，不仅提升性能，也消除了侧信道风险。

SubBytes的硬件实现

SubBytes是AES中计算最复杂的步骤，有两种主要的硬件实现方式：

方法一：查找表（LUT）实现。最直观的方法是将S-box实现为一个$256 \times 8$位的ROM查找表。16个字节可以使用16个独立的S-box LUT并行处理。每个LUT的面积约为$256 \times 8 = 2048$位SRAM或等效逻辑，16个LUT的总面积约为32 Kb。LUT方法的优点是延迟低（一次ROM读取），缺点是面积较大，且ROM访问可能受到侧信道攻击（cache-timing attack）。由于S-box LUT在硬件中是固定逻辑（不通过cache访问），硬件实现的AES天然免疫缓存时序侧信道攻击——这也是AES-NI的一个重要安全优势。

方法二：组合逻辑实现。S-box的数学定义是$\text{GF}(2^8)$上的乘法逆元后接仿射变换。$\text{GF}(2^8)$逆元运算可以通过复合域分解（composite field decomposition）技术将其分解为$\text{GF}((2^4)^2)$上的运算，再进一步分解为$\text{GF}(((2^2)^2)^2)$上的运算。这种分解将一个$\text{GF}(2^8)$逆元运算简化为多个$\text{GF}(2^2)$和$\text{GF}(2^4)$上的小规模运算（乘法、平方、求逆），每个小运算只需要几个XOR和AND门。复合域实现的S-box约需要100$\sim$130个等效门（GE），面积远小于LUT方法，但组合逻辑深度（延迟）较大。

实际的AES-NI实现通常采用混合策略——对SubBytes使用优化的组合逻辑实现以节省面积，同时通过流水线化来缓解延迟问题。

S-box的复合域分解详解

S-box的数学定义可以分解为两个步骤：首先计算$\text{GF}(2^8)$上的乘法逆元（零映射到零），然后对逆元结果应用一个仿射变换（一个固定的$8 \times 8$位矩阵乘法加上一个常数向量）。

$\text{GF}(2^8)$上的逆元计算是S-box中计算最复杂的部分。直接实现需要一个$8 \to 8$位的查找表（256个8位条目），但这在面积上等效于约2 kbit的ROM。复合域分解将$\text{GF}(2^8)$视为$\text{GF}(2^4)$的二次扩张——$\text{GF}(2^8) \cong \text{GF}(2^4)[x]/(x^2 + \alpha x + \beta)$，其中$\alpha$和$\beta$是$\text{GF}(2^4)$中的常数。在此表示下，$\text{GF}(2^8)$中的一个元素$a = a_H \cdot x + a_L$（$a_H, a_L \in \text{GF}(2^4)$）的逆元可以通过以下步骤计算：

1. 计算$d = a_H^2 \cdot \beta + a_H \cdot a_L + a_L^2$（在$\text{GF}(2^4)$上）。

2. 计算$d^{-1}$（$\text{GF}(2^4)$上的逆元——这只是一个$4 \to 4$位的查找表，仅16个条目）。

3. 计算逆元的高低部分：$b_H = a_H \cdot d^{-1}$，$b_L = (a_H + a_L) \cdot d^{-1}$。

所有运算都在$\text{GF}(2^4)$上进行——$\text{GF}(2^4)$上的乘法可以用$4 \times 4$位AND-XOR阵列实现（约20$\sim$30个门），平方运算$a^2$在$\text{GF}(2^4)$上是一个线性运算（仅需XOR，无AND），$\text{GF}(2^4)$的逆元用16条目的查找表或更深层的分解（$\text{GF}(2^4) \cong \text{GF}(2^2)[x]/(x^2 + x + \phi)$）实现。

这种层层分解最终将$\text{GF}(2^8)$逆元简化为$\text{GF}(2^2)$上的基本运算（乘法、平方、逆元），每个$\text{GF}(2^2)$运算只需2$\sim$5个门。整个S-box的组合逻辑实现约需要$100 \sim 130$个等效门，组合逻辑深度约为$15 \sim 20$级——这在先进工艺中约对应$1 \sim 1.5$个时钟周期的延迟。

16个并行S-box的总面积约为$16 \times 130 = 2080$个等效门，加上仿射变换的$16 \times 30 \approx 480$个等效门（$8 \times 8$位矩阵乘法在$\text{GF}(2)$上实际只需XOR门），SubBytes的总面积约为2.5 kGE——远小于ROM查找表方案的$16 \times 256 \times 8 = 32$ kbit SRAM。

AES S-box的复合域分解实现：将$\text{GF}(2^8)$逆元分解为$\text{GF}(2^4)$上的运算链

以下SystemVerilog代码展示了AES S-Box的简化组合逻辑实现。完整的工业级实现会使用更深层的复合域分解（$\text{GF}(2^2)$级别），这里为了可读性使用$\text{GF}(2^4)$级别的分解。

module aes_sbox_composite (
    input  logic [7:0] in_byte,
    output logic [7:0] out_byte
);
    // GF(2^8) -> GF(2^4)^2 映射 (isomorphic mapping)
    logic [3:0] a_h, a_l;  // 高4位, 低4位 in GF(2^4)
    assign a_h = in_byte[7:4] ^ in_byte[3:0];  // 简化映射
    assign a_l = in_byte[3:0];

    // GF(2^4) 乘法: a_h * a_l
    logic [3:0] ah_al;
    gf4_mul u_mul1 (.a(a_h), .b(a_l), .p(ah_al));

    // GF(2^4) 平方: a_h^2 * beta (beta为不可约多项式系数)
    logic [3:0] ah2_beta;
    gf4_sq_scale u_sq (.a(a_h), .p(ah2_beta));

    // GF(2^4) 平方: a_l^2
    logic [3:0] al2;
    assign al2 = {a_l[3], a_l[2]^a_l[3], a_l[1], a_l[0]^a_l[1]};

    // d = a_h^2*beta + a_h*a_l + a_l^2 (GF(2^4)加法 = XOR)
    logic [3:0] d;
    assign d = ah2_beta ^ ah_al ^ al2;

    // GF(2^4) 逆元 (4-bit LUT, 仅16条目)
    logic [3:0] d_inv;
    gf4_inv u_inv (.a(d), .b(d_inv));

    // 最终乘法: b_h = a_h * d^{-1}, b_l = (a_h+a_l)*d^{-1}
    logic [3:0] b_h, b_l;
    gf4_mul u_mul2 (.a(a_h),        .b(d_inv), .p(b_h));
    gf4_mul u_mul3 (.a(a_h ^ a_l),  .b(d_inv), .p(b_l));

    // 逆映射 + 仿射变换
    logic [7:0] inv_out;
    assign inv_out = {b_h, b_l};
    aes_affine u_aff (.in(inv_out), .out(out_byte));
endmodule

// GF(2^4) 乘法器: ~20 AND+XOR 门
module gf4_mul (
    input  logic [3:0] a, b,
    output logic [3:0] p
);
    logic [3:0] partial [0:3];
    genvar i;
    generate
        for (i = 0; i < 4; i++) begin : gen_partial
            assign partial[i] = b[i] ? a : 4'b0;
        end
    endgenerate
    // 带约化的异或累加 (不可约多项式 x^4+x+1)
    logic [6:0] raw;
    assign raw = {3'b0, partial[0]} ^ {2'b0, partial[1], 1'b0}
               ^ {1'b0, partial[2], 2'b0} ^ {partial[3], 3'b0};
    // 约化: x^4 -> x+1, x^5 -> x^2+x, x^6 -> x^3+x^2
    assign p = raw[3:0] ^ {1'b0, raw[6:4]} ^ {2'b0, raw[6:5]};
endmodule

设计权衡 3 — S-Box实现的三种策略：查找表 vs 组合逻辑 vs 复合域

实现策略	面积 (GE/S-Box)	延迟 (级)	侧信道安全
ROM查找表	$\sim$800	1–2 (ROM读取)	硬件ROM: 安全
直接组合逻辑	$\sim$300	25–30	安全（恒定时间）
复合域分解	$\sim$130	15–20	安全（恒定时间）

现代AES-NI实现几乎全部采用复合域分解方案，因为它在面积上比ROM查找表小6倍，在延迟上虽然比ROM慢（15–20级 vs 1–2级），但通过4级流水线化后每级只需承担4–5级组合逻辑深度，在5 GHz工艺下完全可以满足时序要求。关键的"为什么不用ROM"的原因是：16个并行的ROM S-Box总面积为$16 \times 800 = 12800$ GE $\approx$ 12.8 kGE，而复合域方案只需$16 \times 130 = 2080$ GE——面积节省超过80%。在处理器die面积寸土寸金的设计中，这一差距是决定性的。

性能分析 4 — AES-NI吞吐率五步计算

以下五步计算展示了AES-128-CTR模式在配备AES-NI的4 GHz处理器上的理论加密吞吐率：

步骤1：确定单条指令的参数。AESENC指令的延迟为4个周期，吞吐量为1条/周期（全流水线化）。每条指令处理128位（16字节）数据。

步骤2：计算每块加密所需指令数。AES-128需要10轮。前9轮各1条AESENC，最后1轮1条AESENCLAST，共10条指令/块。

步骤3：分析依赖关系。CTR模式下不同块之间无数据依赖——块$k$的第$r$轮与块$k+1$的第$r-1$轮可以在流水线中重叠。但同一块的连续轮之间存在RAW依赖（上一轮的输出是下一轮的输入），延迟4周期。

步骤4：计算交织后的吞吐量。使用4路交织（同时处理4个独立块），可以完全隐藏4周期的延迟：

$$\begin{aligned} \text{4块总周期} &= 4\text{（流水线启动）} + 10 \times 1 \text{（每轮1周期$\times$10轮）} = 14\text{周期} \\ \text{每块平均} &= 14 / 4 = 3.5\text{周期/块} \end{aligned}$$

步骤5：计算最终吞吐率。

$$\text{吞吐率} = \frac{16\text{字节/块}}{3.5\text{周期/块}} \times 4 \times 10^9 \text{周期/秒} = 18.3\text{\,GB/s（4路交织）}$$

使用8路交织（需要8个空闲XMM寄存器）：$8 + 10 = 18$周期/8块 = 2.25周期/块 $\Rightarrow$ 28.4 GB/s。理论极限（完全流水线，$\infty$路交织）：$16\text{B} \times 4\text{GHz} = 64\text{\,GB/s}$。

AES密钥扩展的硬件加速

AES-NI不仅加速了AES的轮函数，还提供了密钥扩展（key schedule/key expansion）的硬件支持。AES-128的密钥扩展从128位主密钥生成11个128位轮密钥（第0轮使用主密钥本身，第1$\sim$10轮的轮密钥由递推关系计算）。

每轮密钥扩展涉及一个RotWord操作（4字节循环左移1字节）、一个SubWord操作（4字节的S-box替换）和与Rcon常数的异或。Intel的AESKEYGENASSIST指令执行SubWord和Rcon异或，但RotWord和最终的异或需要由额外的SIMD指令（PSHUFD和PXOR）完成。

密钥扩展在通常的AES操作中只需执行一次（在建立加密会话时），因此其性能对整体吞吐量的影响很小。但在频繁更换密钥的场景（如TLS 1.3的每个连接使用不同密钥）中，密钥扩展的延迟可能成为建连延迟的一部分。AES-256的密钥扩展需要更多轮次（14轮密钥），总延迟约为100$\sim$150个周期。

MixColumns的硬件实现

MixColumns对每列4字节应用以下矩阵乘法（$\text{GF}(2^8)$上）：

$$\begin{bmatrix} b_0 \\ b_1 \\ b_2 \\ b_3 \end{bmatrix} = \begin{bmatrix} 2 & 3 & 1 & 1 \\ 1 & 2 & 3 & 1 \\ 1 & 1 & 2 & 3 \\ 3 & 1 & 1 & 2 \end{bmatrix} \begin{bmatrix} a_0 \\ a_1 \\ a_2 \\ a_3 \end{bmatrix}$$

其中乘法和加法都在$\text{GF}(2^8)$上进行——加法就是异或（XOR），乘以2就是xtime操作（左移1位，若最高位为1则异或0x1B），乘以3就是xtime后再异或原值。因此，MixColumns的硬件实现主要由xtime电路（每个约8个XOR门 + 1个AND门）和XOR树组成，逻辑深度约为3$\sim$4级XOR，延迟很低。

性能分析 5 — AES-NI的性能分析

在Intel的现代微架构（如Golden Cove）中，AESENC指令的延迟为4个周期，吞吐量为每周期1条（全流水线化）。这意味着AES-128的10轮加密只需要约10$\sim$14个周期（考虑流水线启动延迟），对应的加密吞吐量为：

$$\text{吞吐量} = \frac{128\text{位}}{1\text{周期}} \times f_{\text{clk}} = \frac{16\text{字节}}{1\text{周期}} \times 4\text{\,GHz} = 64\text{\,GB/s}$$

实际的AES-128-CTR（计数器模式）吞吐量可以接近这个理论值，因为CTR模式的各个数据块可以完全并行加密（不同于CBC模式的串行依赖）。在AES-256-CTR模式下，由于需要14轮而非10轮，吞吐量约为理论值的$10/14 \approx 71\%$。

相比之下，纯软件实现的AES-128加密（使用通用整数指令和查找表）在同一处理器上的吞吐量约为1$\sim$2 GB/s——AES-NI提供了约30$\sim$60倍的加速。更重要的是，软件实现的查找表方式存在缓存时序侧信道攻击（Cache-timing Side-channel Attack）的风险：攻击者可以通过测量cache访问延迟的差异来推断S-box查找的索引值，进而恢复密钥。AES-NI的硬件实现完全消除了这一攻击面。

AES加速单元的流水线化

为了实现每周期1条的吞吐量，AES轮函数的硬件被组织为4级流水线（以Intel实现为例）：

• 第1级：SubBytes的前半部分（$\text{GF}(2^8)$到$\text{GF}(2^4)$的映射和部分逆元运算）

• 第2级：SubBytes的后半部分（$\text{GF}(2^4)$逆元完成、仿射变换）+ ShiftRows（零延迟连线）

• 第3级：MixColumns（xtime + XOR网络）

• 第4级：AddRoundKey（128位XOR）+ 结果写回

这种流水线划分使得多个独立的AES操作可以重叠执行——当第$k$轮数据在第3级执行MixColumns时，第$k+1$轮数据可以在第1级开始SubBytes。对于CTR、GCM等可以并行处理多个数据块的操作模式，这种流水线化的效果尤为显著。

AES轮函数的流水线级间交互

AES轮函数的4级流水线之间需要传递128位的完整状态矩阵。由于每轮的输出是下一轮的输入（即连续的AESENC指令之间存在RAW依赖），流水线化的主要收益来自对不同数据块的并行处理，而非对同一块的不同轮次的并行。

在CTR（计数器）模式下，不同数据块的加密完全独立——对块$k$的第$r$轮加密与块$k+1$的第$r-1$轮加密可以同时进行。如果处理器有足够的寄存器来存储多个块的中间状态，编译器可以将多个块的加密循环"交织"（interleave）在一起，使4级流水线的每一级在每个周期都有工作：

// 4路交织的AES-128加密（伪代码）
for (int round = 0; round < 10; round++) {
    state0 = AESENC(state0, roundkey[round]);  // 块0, 轮r
    state1 = AESENC(state1, roundkey[round]);  // 块1, 轮r
    state2 = AESENC(state2, roundkey[round]);  // 块2, 轮r
    state3 = AESENC(state3, roundkey[round]);  // 块3, 轮r
}

在上述交织模式下，每条AESENC的延迟为4周期，但由于4条AESENC操作不同的数据块（无数据依赖），调度器可以在每个周期发射一条。4个块的加密在$4 + 10 \times 1 = 14$个周期内完成（4周期的流水线启动 + 10轮 $\times$ 1周期/条），平均每块3.5周期。如果不交织，每块需要$10 \times 4 = 40$个周期（每轮等待4周期延迟），交织提供了约$40/3.5 \approx 11\times$的加速。

实际的加速效果取决于可用的XMM/YMM寄存器数量——每路交织需要一个寄存器保存中间状态。在x86的16个XMM寄存器中（AVX-512下为32个ZMM寄存器），除去轮密钥占用的寄存器，通常可以实现4$\sim$8路交织。

AES-GCM模式的硬件加速

在实际应用中，AES很少单独使用——它通常与某种认证加密（Authenticated Encryption with Associated Data, AEAD）模式组合。最常用的AEAD模式是AES-GCM（Galois/Counter Mode），它在AES-CTR加密的基础上增加了GHASH认证标签计算。GHASH本质上是一个$\text{GF}(2^{128})$上的多项式求值运算，其核心操作是$\text{GF}(2^{128})$上的乘法——也就是128位无进位乘法（carry-less multiplication）。

Intel提供了PCLMULQDQ（Carry-Less Multiplication Quadword）指令来加速GHASH运算。PCLMULQDQ执行两个64位操作数的无进位乘法，产生128位结果。通过将AES-NI的AESENC与PCLMULQDQ交织执行（利用它们在不同执行端口上并行运行），可以同时完成加密和认证，达到接近AES-CTR的吞吐量。ARM的ARMv8-A Crypto扩展也提供了等价的PMULL/PMULL2指令。

AES加速单元在执行端口中的位置

AES-NI指令操作的是128位XMM寄存器，因此AES加速硬件通常被安排在SIMD/向量执行端口上，与SIMD整数运算单元共享端口但使用独立的功能电路。在Intel Golden Cove中，AES-NI指令在端口0（Port 0）上执行，该端口同时也是SIMD整数乘法器和FMA单元的所在。AES硬件与这些单元共享端口但不共享数据通路——AES使用独立的128位组合逻辑电路。

VAES：AES-NI的向量扩展

Intel在Ice Lake中引入了VAES（Vectorized AES）指令集扩展，将AES-NI从128位XMM寄存器扩展到256位YMM和512位ZMM寄存器。VAES的VAESENC ymm可以同时对两个独立的128位数据块执行AES轮函数，VAESENC zmm同时处理四个数据块。

VAES的硬件实现本质上是复制AES轮函数硬件：一个256位的VAES单元包含两套完整的S-box阵列（$2 \times 16 = 32$个S-box）、两套ShiftRows连线和两套MixColumns电路。从面积角度看，VAES单元的面积约为标准AES-NI单元的2倍（256位）或4倍（512位）。从性能角度看，VAES在不增加指令数的情况下将AES吞吐量翻倍（256位）或翻四倍（512位）——这对于高带宽的网络加密（如100 Gbps网络接口的TLS加密）尤为重要。

性能分析 6 — VAES对网络加密吞吐量的影响

以一个4 GHz处理器核心为例，不同AES实现的加密吞吐量：

实现方式	吞吐量	对应网络速率
标准AES-NI (128位)	128位/周期 $\times$ 4 GHz = 64 GB/s	$\sim$500 Gbps
VAES (256位)	256位/周期 $\times$ 4 GHz = 128 GB/s	$\sim$1 Tbps
VAES (512位)	512位/周期 $\times$ 4 GHz = 256 GB/s	$\sim$2 Tbps

标准AES-NI的64 GB/s吞吐量已经远超当前任何网络接口的需求。VAES的价值主要在于降低每字节的CPU开销——在相同吞吐量下使用更少的CPU周期，释放更多的执行资源给应用逻辑。在数据中心的TLS卸载场景中，VAES可以将加密操作的CPU占用从$\sim$5%降低到$\sim$1%。

值得注意的是，Intel在Alder Lake及后续的混合架构处理器中，高性能核心（P-core）和能效核心（E-core）都支持AES-NI，但实现方式可能不同：P-core使用完全流水线化的256位通路（通过VEX/EVEX编码处理YMM/ZMM寄存器中的多个128位块），E-core则可能只支持128位通路。这种异构实现要求操作系统的线程调度器在分配密码学工作负载时考虑核心类型的差异。

SHA扩展

SHA（Secure Hash Algorithm）是一族密码学哈希函数，广泛用于数据完整性校验、数字签名、证书验证和密码存储。SHA-256是目前最常用的变体，它将任意长度的输入消息处理为256位（32字节）的哈希值。SHA-256的计算由两个主要部分组成：消息调度（message schedule）和压缩函数（compression function）。

SHA-256的算法结构

SHA-256将输入消息分为512位（64字节）的块，每个块经过64轮迭代压缩。每轮的操作包括：

1. 消息调度：将512位（16个32位字）的输入块扩展为64个32位字$W_0, W_1, \ldots, W_{63}$。前16个字直接来自输入块，后48个字通过以下递推关系计算：

   W_t = \sigma_1(W_{t-2}) + W_{t-7} + \sigma_0(W_{t-15}) + W_{t-16}, \quad t = 16, \ldots, 63$$ 其中$\sigma_0$和$\sigma_1$是两个"小$\sigma$"函数，由右旋转（ROTR）和右移（SHR）操作组成： $$\begin{aligned} \sigma_0(x) &= \text{ROTR}^7(x) \oplus \text{ROTR}^{18}(x) \oplus \text{SHR}^3(x) \\ \sigma_1(x) &= \text{ROTR}^{17}(x) \oplus \text{ROTR}^{19}(x) \oplus \text{SHR}^{10}(x) \end{aligned}

2. 压缩函数：维护8个32位工作变量$a, b, c, d, e, f, g, h$（初始值来自前一个块的哈希输出或固定初始值），每轮更新：

$$\begin{aligned} T_1 &= h + \Sigma_1(e) + \text{Ch}(e, f, g) + K_t + W_t \\ T_2 &= \Sigma_0(a) + \text{Maj}(a, b, c) \\ h &\leftarrow g, \quad g \leftarrow f, \quad f \leftarrow e, \quad e \leftarrow d + T_1 \\ d &\leftarrow c, \quad c \leftarrow b, \quad b \leftarrow a, \quad a \leftarrow T_1 + T_2 \end{aligned}$$

其中$\Sigma_0$、$\Sigma_1$是"大$\Sigma$"函数（由旋转和异或组成），$\text{Ch}$（Choose）和$\text{Maj}$（Majority）是位级选择/多数投票函数，$K_t$是64个固定的轮常数。

Intel SHA扩展指令

Intel在Goldmont微架构（2016年）中引入了SHA扩展指令，包含以下核心指令：

• SHA256RNDS2 xmm1, xmm2/m128, <xmm0>：执行SHA-256压缩函数的两轮运算。xmm1包含状态变量$c,d,g,h$，xmm2包含状态变量$a,b,e,f$，xmm0（隐式操作数）提供两个$W_t + K_t$值。

• SHA256MSG1 xmm1, xmm2/m128：执行SHA-256消息调度的部分计算（$\sigma_0$变换）。

• SHA256MSG2 xmm1, xmm2/m128：完成SHA-256消息调度（$\sigma_1$变换和累加）。

• SHA1RNDS4 xmm1, xmm2/m128, imm8：执行SHA-1压缩函数的四轮运算。

• SHA1MSG1、SHA1MSG2、SHA1NEXTE：SHA-1消息调度和状态更新指令。

SHA硬件的微架构实现

SHA压缩函数的硬件实现面临一个核心挑战：每轮的输出是下一轮的输入，存在严格的串行数据依赖。单纯地流水线化无法提高单个消息块的处理速度——只能通过并行处理多个独立消息块来提高吞吐量。

Intel的SHA256RNDS2指令一次执行2轮压缩，延迟为4个周期，吞吐量为每2个周期1条。这意味着处理一个完整的512位消息块（64轮）需要$64/2 \times 2 = 64$个周期（考虑指令间的数据依赖）。加上消息调度指令的开销，实际性能约为每100$\sim$120个周期处理一个512位块，对应的吞吐量约为每字节1.5$\sim$2个周期。

硬件描述 4 — SHA-256压缩函数的硬件结构

SHA-256单轮压缩函数的硬件核心包括：

• $\Sigma_0$单元：3个32位旋转器（分别旋转2、13、22位）和2个32位XOR门。旋转操作在硬件中只是固定的连线重排（barrel rotate = wiring），延迟为零；XOR是简单的按位逻辑。

• $\Sigma_1$单元：类似$\Sigma_0$，旋转量为6、11、25位。

• Ch单元：$\text{Ch}(e,f,g) = (e \land f) \oplus (\lnot e \land g)$，只需要AND、NOT、XOR门，单级逻辑延迟。

• Maj单元：$\text{Maj}(a,b,c) = (a \land b) \oplus (a \land c) \oplus (b \land c)$，同样是单级逻辑。

• 32位加法器：$T_1$的计算需要5个32位数相加（$h + \Sigma_1(e) + \text{Ch}(e,f,g) + K_t + W_t$），可以用CSA（进位保留加法器）树压缩为2个操作数后再用一个CPA（进位传播加法器）完成。$T_2$需要2个32位数相加。

关键路径是$T_1$的5输入加法——使用3级CSA + 1级CPA，延迟约为$3 \times O(1) + O(\log n) \approx 3 + 5 = 8$级门延迟。在先进工艺下，这约为1$\sim$2个时钟周期。

SHA消息调度的并行化

SHA-256的消息调度（式 (33.5)）存在一个有利的并行化特性：$W_t$只依赖于$W_{t-2}$、$W_{t-7}$、$W_{t-15}$和$W_{t-16}$，其中$W_{t-7}$、$W_{t-15}$和$W_{t-16}$在计算前几个字时就已确定。因此，消息调度可以提前于压缩函数进行——当压缩函数在处理第$t$轮时，消息调度可以提前计算第$t+1$、$t+2$等轮的$W$值。Intel的SHA256MSG1和SHA256MSG2指令正是利用了这种可分离性——MSG1计算$\sigma_0$部分，MSG2完成$\sigma_1$和累加，两条指令可以与SHA256RNDS2在流水线中交织执行，实现软件级别的流水线并行。

在硬件层面，SHA的消息调度单元和压缩函数单元可以设计为两个并行的数据通路：消息调度通路包含旋转器和加法器来计算$W_t$，压缩函数通路包含$\Sigma$函数、$\text{Ch}$/$\text{Maj}$逻辑和多输入加法器。两者通过一个$W_t$缓冲区连接——消息调度产生的$W_t$值被写入缓冲区，压缩函数从缓冲区读取当轮的$W_t$值。

SHA消息调度的硬件结构

SHA-256消息调度的核心是递推公式$W_t = \sigma_1(W_{t-2}) + W_{t-7} + \sigma_0(W_{t-15}) + W_{t-16}$。在硬件中，这需要：

1. $W$值缓冲区：一个包含16个32位寄存器的移位寄存器链，存储最近16个$W$值（$W_{t-16}$到$W_{t-1}$）。每轮计算完新的$W_t$后，将其推入链头，链尾的$W_{t-16}$被丢弃。

2. $\sigma_0$计算单元：从移位寄存器链中读取$W_{t-15}$，执行$\sigma_0(x) = \text{ROTR}^7(x) \oplus \text{ROTR}^{18}(x) \oplus \text{SHR}^3(x)$。三个旋转/移位操作由固定连线实现（零门延迟），两个XOR门串联（2级门延迟）。

3. $\sigma_1$计算单元：从移位寄存器链中读取$W_{t-2}$，执行$\sigma_1(x) = \text{ROTR}^{17}(x) \oplus \text{ROTR}^{19}(x) \oplus \text{SHR}^{10}(x)$。结构与$\sigma_0$完全相同。

4. 4输入加法器：将$\sigma_1(W_{t-2})$、$W_{t-7}$、$\sigma_0(W_{t-15})$和$W_{t-16}$四个32位值相加。使用2级CSA（进位保留加法器）将4个输入压缩为2个输入，再用一个CPA（进位传播加法器）完成最终加法。CSA的延迟约为2级全加器延迟，CPA的延迟约为$\log_2 32 \approx 5$级门延迟。总延迟约为7级门延迟。

SHA-256消息调度硬件结构：16个$W$值的移位寄存器链、$\sigma_0$/$\sigma_1$计算单元和4输入加法器

SHA压缩函数的关键路径

SHA-256压缩函数每轮更新8个工作变量$a \sim h$，其中最关键的计算是$T_1$：

$$T_1 = h + \Sigma_1(e) + \text{Ch}(e,f,g) + K_t + W_t$$

$T_1$涉及5个32位值的加法。使用CSA压缩树的实现方案：

1. 第1级CSA：将$h$、$\Sigma_1(e)$和$\text{Ch}(e,f,g)$三个值压缩为2个值（和与进位）。延迟：1级全加器 $\approx$ 2$\sim$3级门。

2. 第2级CSA：将第1级的2个输出与$K_t$一起（3个输入）压缩为2个值。延迟：1级全加器。

3. 第3级CSA：将第2级的2个输出与$W_t$一起（3个输入）压缩为2个值。延迟：1级全加器。

4. CPA：将最终的2个值通过32位进位传播加法器相加。延迟：$\sim$5级门（使用并行前缀加法器）。

$\Sigma_1(e)$和$\text{Ch}(e,f,g)$可以与CSA的前两级并行计算（因为它们只依赖于$e$、$f$、$g$，这些值在上一轮结束时就已确定）。因此，$T_1$的关键路径约为$3 \times 3 + 5 = 14$级门延迟——在先进工艺下约为150$\sim$200 ps，接近一个时钟周期。

$T_2 = \Sigma_0(a) + \text{Maj}(a,b,c)$的计算更简单——只有2个32位值相加，延迟约为$\sim$8级门。

新的$a$值为$T_1 + T_2$（另一次32位加法），新的$e$值为$d + T_1$。两次加法可以并行执行，因为它们共享$T_1$但不互相依赖。

Intel的SHA256RNDS2指令一次执行2轮压缩，将两轮的串行依赖压缩到4个时钟周期内。这意味着每轮的有效延迟为2个周期——通过流水线化和部分预计算（提前计算$\Sigma$和$\text{Ch}/\text{Maj}$函数）来实现。

性能分析 7 — SHA-256的全消息块处理性能

处理一个完整的512位SHA-256消息块需要64轮压缩。使用Intel的SHA256RNDS2（每条处理2轮，延迟4周期，吞吐量2周期/条），加上消息调度指令的开销，总体性能约为：

• 压缩函数：$64/2 = 32$条SHA256RNDS2，考虑流水线启动和数据依赖，约需要$32 \times 2 = 64$周期（理想情况下每2周期发射一条）。

• 消息调度：$48/4 \times 2 = 24$条SHA256MSG1/SHA256MSG2（每条处理4个$W$值中的部分步骤），可以与压缩函数指令交织执行。

• 总计：约80$\sim$100周期/块，即每字节$80/64 \approx 1.25$周期。

• 在4 GHz处理器上：$64/(100/4 \times 10^9) \approx 2.56$ GB/s的哈希吞吐量。

实际性能取决于消息调度与压缩函数的交织效率——编译器（或手写汇编）需要精心排列指令顺序，确保消息调度指令在压缩函数的数据依赖间隙中执行，不增加总体延迟。优秀的SHA-256实现（如OpenSSL的优化汇编）可以达到接近理论极限的吞吐量。

ARM的SHA扩展

ARM在ARMv8.0-A中就定义了SHA-1和SHA-256的加速指令（作为可选的Crypto扩展），包括SHA256H、SHA256H2（压缩函数）和SHA256SU0、SHA256SU1（消息调度）。ARMv8.2-A进一步增加了SHA-512和SHA-3的指令。ARM的SHA指令操作128位NEON寄存器（Q寄存器），与Intel的实现类似，每条指令处理2$\sim$4轮压缩。

SHA-1与SHA-256的硬件共享

SHA-1和SHA-256的压缩函数在结构上有相似性，但也有重要差异。SHA-1使用80轮迭代（vs SHA-256的64轮），工作变量为5个32位值（vs SHA-256的8个），每轮使用不同的逻辑函数（$f_t$在前20轮为$\text{Ch}$，中间20轮为$\text{Parity}$，后20轮为$\text{Maj}$，最后20轮再为$\text{Parity}$）。

在硬件实现中，SHA-1和SHA-256的执行单元可以共享以下组件：

• 32位加法器：两种算法都需要多输入的32位加法器来计算$T_1$/$T_2$值。SHA-256需要5输入加法（$T_1$），SHA-1需要4输入加法。共享的CSA压缩树可以同时支持两种配置。

• 旋转器：两种算法都使用32位固定旋转操作。旋转在硬件中只是连线重排（零面积），因此"共享"本质上就是各自的旋转连线在物理上共存于同一数据通路中。

• 控制逻辑：解码器根据指令操作码选择SHA-1模式还是SHA-256模式，配置逻辑函数选择（$\text{Ch}$/$\text{Parity}$/$\text{Maj}$）和轮常数来源。

不可共享的组件包括：消息调度单元（SHA-1和SHA-256的递推公式完全不同）、工作变量寄存器（SHA-1为5个，SHA-256为8个）。因此，同时支持SHA-1和SHA-256的硬件面积约为单独实现SHA-256面积的1.3$\sim$1.5倍，而非2倍。

SHA-3/Keccak的硬件实现差异

SHA-3标准基于Keccak海绵结构（sponge construction），与SHA-256的Merkle-Damgård结构有根本不同。Keccak使用一个$5 \times 5 \times 64 = 1600$位的状态阵列，通过24轮置换函数$f$进行变换。每轮置换包含5个步骤：

1. $\theta$（theta）：列奇偶校验 + 旋转 + 异或扩散。需要计算5列的64位奇偶校验，然后将结果异或回状态阵列。

2. $\rho$（rho）：25个64位字各自旋转不同的固定量。纯连线操作，零延迟。

3. $\pi$（pi）：25个字的位置置换。纯连线操作，零延迟。

4. $\chi$（chi）：行内的非线性变换——每个位由当前位、同行下一位和下下一位通过AND-XOR组合产出。

5. $\iota$（iota）：与一个轮常数异或。

SHA-3的硬件实现面积约为15$\sim$25 kGE（完整的1600位数据通路），延迟约为4$\sim$8个时钟周期/轮（取决于流水线深度）。与SHA-256相比，SHA-3的数据通路更宽（1600位 vs 256位），但逻辑深度更浅（主要由简单的XOR、AND和旋转组成，无需多输入加法器）。

Intel的SHA扩展目前不包含SHA-3加速指令。ARM在ARMv8.2-A的Crypto扩展中增加了SHA-3指令（SHA512H、SHA512H2用于SHA-512，以及EOR3、RAX1、XAR、BCAX用于Keccak的基本操作）。RISC-V的Zvksh扩展也提供了SHA-256向量加速，Zvkg提供了GHASH加速。

在Cortex-A76及后续微架构中，SHA-256指令的延迟约为3$\sim$4周期，吞吐量与Intel的实现相当。由于ARM的SHA指令设计更加正交化（每条指令功能更原子化），编译器和库开发者在软件流水线化方面有更大的灵活性。

设计权衡 4 — 密码指令粒度的选择

密码加速指令的设计面临一个粒度选择问题。粗粒度指令（如一条指令执行AES的一整轮）的优势是减少了指令数，降低了前端和调度器的压力；但劣势是灵活性较差——如果需要实现AES的变种（如AES-GCM中的GHASH运算），粗粒度指令可能无法复用。

细粒度指令（如分别提供SubBytes、ShiftRows、MixColumns的独立指令）的灵活性更好，可以支持更多密码算法的变体；但指令数增加，性能可能受限于指令分派和调度的开销。

Intel的AES-NI选择了"中等粒度"——每条指令执行一整轮AES运算。ARM的Crypto扩展也采用了类似的策略。RISC-V的Scalar Crypto扩展则选择了更细的粒度——在32位寄存器上操作单个AES列或S-box，最大化了在面积受限的嵌入式处理器上的可用性。

密码加速单元与执行引擎的集成

密码加速单元作为执行引擎中的功能单元，其与乱序引擎的集成需要处理以下微架构问题：

密码指令的调度特性

密码指令与普通SIMD指令在调度特性上有重要差异：

1. 延迟较高：AES-NI的AESENC延迟为4周期（vs 普通SIMD加法的1周期），但吞吐量为1条/周期（全流水线化）。这意味着密码指令在发射队列中的占用时间更长——每条指令的依赖链延迟为4周期，期间它的目标寄存器不可用。

2. 数据依赖模式固定：AES加密的10/12/14轮形成了一条固定长度的依赖链——每轮的输出是下一轮的输入。调度器需要能够高效地处理这种"长链"依赖模式，确保链中的每条指令在前序完成后立即被调度。

3. 与其他指令的交织：在AES-GCM模式下，AES加密指令（AESENC）和GHASH指令（PCLMULQDQ）可以在不同的执行端口上并行执行。调度器需要识别这两类指令之间的独立性，将它们分配到不同的端口以最大化吞吐量。

密码状态的安全擦除

密码指令处理的中间状态（如AES轮函数的中间矩阵、SHA的工作变量）包含密钥相关的敏感信息。当密码操作完成后，存储这些中间状态的物理寄存器需要被安全擦除（secure erasure）——不是简单地标记为"空闲"，而是主动将寄存器内容写零，防止后续指令通过微架构侧信道读取残留数据。

在实践中，大多数处理器不提供自动的安全擦除——这一责任被留给软件。密码学库（如OpenSSL）在操作完成后使用OPENSSL_cleanse函数（或等效的memset_s）来清除敏感内存，但物理寄存器文件中的残留数据更难清除。某些安全敏感的处理器（如ARM的Cortex-M55 with TrustZone）提供了寄存器清除指令（如CLRM），可以在从安全域退出时自动清零指定的寄存器。

密码指令在ROB中的提交

密码指令在ROB中的提交与普通指令相同——它们按程序序退休，结果从物理寄存器写入体系结构状态。对于AES-NI指令，每条AESENC退休后，包含中间AES状态的源物理寄存器可以被释放到空闲列表中——此时寄存器中仍然保留着AES中间状态，直到被后续指令覆盖。

在安全关键的应用中，可以在AES操作序列结束后插入VPXOR xmm0, xmm0, xmm0等零化指令来清除中间寄存器。处理器的零化习语识别机制会将这条指令标记为零操作——不占用执行端口，但将物理寄存器映射到硬连线零寄存器，确保后续任何对该寄存器的读取都返回零。

密码指令的功耗特征

AES-NI指令的功耗特征与普通SIMD指令有所不同：

• SubBytes步骤中的S-box组合逻辑具有较高的翻转率——每个S-box的输入为8位，输出为8位，输入变化时约有50%的内部节点会翻转。16个并行S-box在每个时钟周期都可能产生大量的翻转活动。

• MixColumns步骤中的xtime电路和XOR网络的翻转率也较高。

• 相比之下，AddRoundKey步骤只是128位XOR，翻转率与输入数据分布相关。

AES-NI在满负荷运行时的功耗约为0.5$\sim$1 W（在5 nm工艺下），占核心总功耗的3%$\sim$5%。当不执行密码指令时，AES硬件通过时钟门控降至接近零的功耗。

性能分析 8 — 密码加速的能效分析

以AES-256-GCM加密为例，比较硬件加速和纯软件实现的能效：

实现方式	吞吐量	功耗	能效 (GB/J)
纯软件（通用整数指令）	0.5 GB/s	5 W	0.1
软件+SIMD优化（bitslicing）	2 GB/s	6 W	0.33
AES-NI硬件加速	30 GB/s	6 W	5.0
VAES (256位) 硬件加速	60 GB/s	7 W	8.6

AES-NI的能效比纯软件实现高约50倍。这一巨大差距的根本原因是：硬件AES电路的面积仅约30$\sim$50 kGE（$<$0.01 mm$^2$），但完成了本需数百条通用指令才能完成的运算——每条通用指令都需要取指、解码、调度、执行、写回的全流水线开销，而硬件AES将所有操作压缩为4级组合逻辑。这正是领域专用硬件（DSA）的核心优势——以微小的面积代价实现数量级的性能和能效提升。

RISC-V Scalar Crypto扩展

RISC-V的密码学扩展分为两大类：向量密码扩展（Zvk系列，操作向量寄存器）和标量密码扩展（Zk系列，操作通用整数寄存器）。标量密码扩展专为面积敏感的嵌入式处理器设计，在不引入SIMD/向量寄存器文件的前提下，通过少量的专用指令和最小的硬件开销来加速常见的密码运算。

标量密码扩展的子扩展

RISC-V标量密码扩展（Zk）由以下子扩展组成：

• Zbkb（Bitmanip for Crypto）：面向密码运算优化的位操作指令，包括brev8（字节内位反转）、pack（半字拼接）、zip/unzip（位交织/解交织）、rev8（字节序反转）等。这些指令的硬件实现只需要简单的连线重排和MUX逻辑。

• Zbkc（Carry-less Multiply for Crypto）：无进位乘法指令clmul/clmulh，用于GCM模式中的GHASH计算和CRC校验。无进位乘法与普通整数乘法的区别是进位传播被替换为异或——硬件上可以用AND-XOR阵列替代AND-加法阵列来实现，面积约为普通乘法器的60%$\sim$70%。

• Zbkx（Crossbar Permutation for Crypto）：交叉存取指令xperm4/xperm8，支持基于索引的4位/8位粒度查找表操作，可用于实现任意S-box替换。

• Zkne（AES Encryption）：AES加密指令。在RV32上为aes32esi（AES-32 Encrypt SubBytes + ShiftRows单列）和aes32esmi（加MixColumns），每条指令处理状态矩阵的一列（4字节中的1字节S-box替换 + 部分轮函数）。在RV64上为aes64es/aes64esm，每条指令处理两列。

• Zknd（AES Decryption）：AES解密指令，结构与Zkne对称。

• Zknh（SHA-256 / SHA-512 Hash）：SHA哈希指令，包括sha256sig0/sha256sig1（$\sigma_0$/$\sigma_1$变换）和sha256sum0/sha256sum1（$\Sigma_0$/$\Sigma_1$变换），以及对应的SHA-512版本。

RV32上的AES实现策略

RISC-V Scalar Crypto在32位处理器上实现AES的策略极具创意：由于32位寄存器只能容纳状态矩阵的一列（4字节），不可能像AES-NI那样一条指令处理整个128位状态。因此，aes32esi指令的设计采用了"逐字节处理"的方式：

1. 从源寄存器rs2中根据bs字段（2位，指定字节0$\sim$3）提取1个字节。

2. 对该字节执行S-box替换（SubBytes）。

3. 将S-box输出放置在32位结果中的正确字节位置（实现ShiftRows的效果）。

4. 将结果与目标寄存器rs1异或（累积到状态列中）。

aes32esmi在此基础上增加了MixColumns步骤——对S-box输出执行单列的MixColumns变换后再异或到rs1中。

因此，在RV32上执行AES-128一轮加密需要16条aes32esmi指令（4列 $\times$ 4字节/列）加上4条XOR指令（AddRoundKey），总计约20条指令/轮。10轮共约200条指令。虽然指令数远多于AES-NI的10条（每轮1条），但每条指令的硬件成本极低——只需要一个8位S-box和一些XOR/移位逻辑，整个AES加速硬件约为200$\sim$400个等效门，非常适合面积预算极为紧张的IoT和嵌入式处理器。

硬件描述 5 — RV32 AES指令的硬件实现

aes32esmi指令的硬件数据通路包含以下组件：

1. 字节提取器：从32位源寄存器rs2中根据bs字段（2位）提取一个字节。硬件实现为一个4:1的8位MUX，面积约10 GE。

2. S-box：对提取的字节执行AES S-box替换。使用复合域分解实现时约130 GE（单个S-box）。这是整个指令硬件中面积最大的组件。

3. 列混合（仅aes32esmi）：对S-box输出执行单列MixColumns变换——将8位的S-box输出扩展为32位的MixColumns部分结果。实现为固定的xtime电路和XOR网络，约50 GE。

4. 字节放置：根据bs字段将结果放置在32位输出的正确字节位置（实现ShiftRows效果）。硬件为一个旋转器（barrel rotator），约20 GE。

5. 异或累加：将放置后的结果与rs1异或。一个32位XOR门阵列，约30 GE。

总面积约为$10 + 130 + 50 + 20 + 30 = 240$ GE。在典型的28 nm嵌入式工艺中，这约占0.0005 mm$^2$——几乎可以忽略不计。相比之下，Intel AES-NI的单轮硬件（16个并行S-box + 4个MixColumns + ShiftRows连线）约为30$\sim$50 kGE，面积差距超过100倍。

RV64上的AES实现

在64位RISC-V处理器上，Zkne/Zknd提供了aes64es、aes64esm、aes64ds、aes64dsm和aes64ks1/aes64ks2（密钥扩展）指令。aes64esm一次处理状态矩阵的两列（8字节），因此一轮AES加密只需要2条aes64esm指令。完整的AES-128加密（10轮）约需要20$\sim$30条指令，性能比RV32方案提升约10倍，硬件面积约为1$\sim$2 kGE。这种设计在面积和性能之间取得了更好的平衡，适用于RISC-V应用处理器（如Linux capable的核心）。

Zknh的SHA-256指令

Zknh扩展为SHA-256提供了四条专用指令：sha256sig0、sha256sig1对应$\sigma_0$和$\sigma_1$变换（用于消息调度），sha256sum0和sha256sum1对应$\Sigma_0$和$\Sigma_1$变换（用于压缩函数）。这些指令的硬件实现非常轻量——每个变换只需要3个固定宽度的旋转器（由连线实现）和2个XOR门，总面积约为每指令50$\sim$100 GE。与完整的SHA压缩函数相比，这些指令只加速了其中的旋转-异或运算部分，加法和逻辑函数（Ch、Maj）仍由通用整数指令完成。即便如此，由于$\sigma$和$\Sigma$变换需要三次不同位数的旋转再异或——这在没有专用指令时需要6条移位+3条异或=9条通用指令——专用指令将其压缩为1条，加速比约为9倍。

对于RV64的SHA-512支持，Zknh同样提供了sha512sig0、sha512sig1、sha512sum0和sha512sum1指令，操作64位寄存器。在RV32上实现SHA-512则更加复杂，需要sha512sig0h/sha512sig0l等高低位拆分指令来处理64位旋转操作。

RISC-V向量密码扩展（Zvk）

除了标量密码扩展（Zk）之外，RISC-V还定义了向量密码扩展（Zvk系列），将密码运算扩展到向量寄存器上，提供比标量扩展更高的吞吐量。

Zvk系列包含以下子扩展：

• Zvkned：向量AES加密/解密。vaesz.vs执行AddRoundKey，vaesem.vs/vaesem.vv执行AES中间轮加密（SubBytes + ShiftRows + MixColumns + AddRoundKey），vaesef.vs/vaesef.vv执行最后一轮加密。每条指令处理一个完整的128位AES状态（存储在128位向量元素中），当VLEN$>$128位时可以并行处理多个独立的AES块。

• Zvksh：向量SHA-256。vsha2ms.vv执行消息调度，vsha2ch.vv/vsha2cl.vv执行压缩函数的高/低半部分。

• Zvkg：向量GHASH（$\text{GF}(2^{128})$乘法），用于AES-GCM模式。

• Zvksed：SM4加密（中国国密算法）。

• Zvksh：SM3哈希。

向量密码扩展的设计哲学是将密码运算视为向量操作的一种特殊情况——密码运算的"元素"是128位（或256位/512位）的密码学块，向量寄存器存储多个这样的块，向量密码指令同时对所有块执行相同的密码学变换。这种设计与SIMD的"一条指令，多路数据"思想完全一致。

在微架构实现上，向量密码扩展需要在向量执行管线中集成密码功能单元。一个VLEN=256位的RVV核心的向量AES单元包含$256/128 = 2$套并行的AES轮函数硬件，每套约30$\sim$50 kGE。总面积约为60$\sim$100 kGE——与标准AES-NI相当。对于VLEN=128位的核心，只需1套AES硬件，面积与标量Zkne接近。

密码加速的ISA设计原则

不同ISA的密码扩展设计反映了不同的设计原则：

1. x86 AES-NI：将AES轮函数作为单条指令，操作固定的128位XMM寄存器。设计目标是最大化单线程AES吞吐量。优点是简单高效，缺点是与向量/SIMD扩展正交，不能直接利用更宽的数据通路。

2. ARM Crypto：与NEON/SVE向量指令集统一编码，密码指令操作NEON/SVE寄存器。设计目标是与向量编程模型统一。优点是编码紧凑、与向量操作自然集成；缺点是密码指令的操作数格式受制于向量寄存器的组织方式。

3. RISC-V Zk/Zvk：提供标量（Zk）和向量（Zvk）两套密码扩展，分别针对面积敏感和吞吐量敏感的场景。设计目标是最大化可扩展性——从200 GE的IoT芯片到100 kGE的服务器核心都有合适的实现选择。

案例研究 3 — 密码加速单元的面积对比

不同实现策略的密码加速硬件面积差异巨大。表表 33.6对比了几种典型实现的面积开销。

实现方案	AES面积 (kGE)	SHA-256面积 (kGE)	目标场景
Intel AES-NI (128位通路)	30$\sim$50	–	服务器/桌面
ARM Crypto (128位通路)	25$\sim$40	15$\sim$25	移动/服务器
RISC-V Zkne (RV32, 单S-box)	0.2$\sim$0.4	–	IoT/嵌入式
RISC-V Zkne (RV64, 双列)	1$\sim$2	–	应用处理器
RISC-V Zknh (RV32)	–	0.3$\sim$0.5	IoT/嵌入式

从表中可以清晰地看到不同设计策略的面积-性能权衡：Intel/ARM的实现面积约为30$\sim$50 kGE，提供最高吞吐量（每周期一轮AES，$\sim$64 GB/s@4 GHz）；RISC-V RV32的实现面积仅0.2$\sim$0.4 kGE，吞吐量约为100$\sim$200 MB/s——约低两个数量级。

可以看到，RISC-V标量密码扩展的面积开销比Intel/ARM的实现小两个数量级，代价是性能降低约一个数量级。这种设计取舍完美契合了嵌入式处理器"够用就好"的设计哲学——在有限的面积预算下提供硬件级别的密码运算加速和侧信道防护，而不追求极致的吞吐量。

密码加速单元在执行端口中的位置（以类Intel微架构为例）

随机数生成

密码学安全的随机数是整个安全体系的基石——密钥生成、初始化向量（IV）、nonce、密码盐值等都需要高质量的不可预测随机数。如果随机数生成器（RNG）存在偏差或可预测性，即使使用最强的加密算法也可能被攻破。因此，现代处理器普遍集成了硬件随机数生成器（Hardware Random Number Generator，HRNG）。

硬件随机数生成器

硬件随机数生成器的核心组件是真随机数生成器（True Random Number Generator，TRNG）——它利用物理过程中的不可预测性（熵源）来产生随机比特。与软件伪随机数生成器（PRNG）不同，TRNG的输出在理论上是不可预测的，即使攻击者完全了解硬件的设计也无法预测下一个随机比特。

TRNG的物理原理

集成电路中常用的熵源包括：

1. 热噪声（Thermal Noise）：电阻中电子的随机热运动产生的电压波动。热噪声的功率谱密度为$S_v = 4kTR$（$k$为玻尔兹曼常数，$T$为绝对温度，$R$为电阻），其物理根源是量子力学层面的随机过程，真正不可预测。基于热噪声的TRNG通常使用一个放大器将微弱的噪声信号放大到可检测的水平，然后用比较器将其数字化。

2. 环形振荡器抖动（Ring Oscillator Jitter）：由奇数个反相器首尾相连构成的环形振荡器（Ring Oscillator，RO），其振荡周期受到电源噪声、热噪声和闪烁噪声（$1/f$噪声）的影响，产生微小的时序抖动（jitter）。通过对比两个独立环形振荡器的相位差异，或用一个"慢速"采样时钟对"快速"环形振荡器的输出进行采样，可以提取随机比特。环形振荡器抖动是CMOS工艺中最常用的TRNG熵源，因为环形振荡器的实现极其简单——只需要几个标准单元反相器——且与数字工艺完全兼容。

3. 亚稳态（Metastability）：当触发器的输入信号恰好在其建立/保持时间窗口内变化时，触发器进入亚稳态，其输出在一段时间内不确定。利用这种亚稳态的不确定性可以生成随机比特。然而，亚稳态方法的可控性较差，且恢复时间不确定，在实际产品中使用较少。

硬件描述 6 — 基于环形振荡器的TRNG设计

一个典型的基于环形振荡器抖动的TRNG包含以下组件：

1. 多个独立的环形振荡器：每个RO由$N$个反相器组成（$N$为奇数，通常为3$\sim$11），振荡频率约为$f_{\text{RO}} = \frac{1}{2N \cdot t_{\text{inv}}}$，其中$t_{\text{inv}}$为反相器延迟。多个RO的输出通过XOR门合并，以增加熵的质量。

2. 采样触发器：用一个低频采样时钟（如$f_{\text{sample}} \approx f_{\text{RO}} / 100$）对XOR后的RO输出进行采样。采样间隔足够长，确保RO积累了足够的抖动，使得采样结果的0/1概率接近50:50。

3. 后处理/去偏（De-biasing）：原始TRNG输出可能存在轻微的偏置（0和1的概率不完全相等），需要通过后处理来消除偏差。常用方法包括von Neumann校正器（将连续两比特的00和11丢弃，01映射为0，10映射为1）和基于线性反馈移位寄存器（LFSR）的白化（whitening）。

4. 健康监测（Health Monitoring）：在线监测TRNG的输出质量，检测熵源退化或故障。典型的监测包括重复计数测试（Repetition Count Test）和自适应比例测试（Adaptive Proportion Test），符合NIST SP 800-90B标准的要求。

在先进CMOS工艺（如5 nm）中，一个完整的TRNG模块（包括RO阵列、采样逻辑、后处理和健康监测）的面积约为0.001$\sim$0.01 mm$^2$，功耗约为$0.1\sim1$ mW。

图图 33.10展示了完整的TRNG$\to$DRBG架构流水线，从物理熵源到最终的密码学安全随机数输出。

完整的TRNG$\to$DRBG硬件架构：多个环形振荡器的输出经XOR合并和相位采样提取原始熵，通过AES-CBC-MAC调节器去偏后，作为种子驱动AES-CTR DRBG产生高速随机数。\inst{RDSEED}直接读取调节器输出（高质量但低速），\inst{RDRAND}读取DRBG输出（高速但确定性）。

环形振荡器TRNG的详细电路

基于环形振荡器（RO）的TRNG是CMOS工艺中最常用的熵源设计。其工作原理可以从电路和概率两个层面理解。

在电路层面，一个由$N$个反相器组成的环形振荡器的振荡周期为$T_{\text{RO}} = 2N \cdot t_{\text{inv}}$，其中$t_{\text{inv}}$是单个反相器的传播延迟。由于热噪声和电源噪声的影响，每次振荡的周期都有微小的随机波动$\Delta T$——这就是时序抖动（jitter）。抖动的标准差$\sigma_J$取决于噪声功率和反相器的增益带宽积，在典型的5 nm CMOS工艺中约为$1 \sim 10$ ps/振荡周期。

为了从抖动中提取随机比特，最常用的方法是相位采样（phase sampling）：用一个低频的参考时钟$f_s$（如10 MHz）对RO的输出信号进行采样。在采样间隔$T_s = 1/f_s$内，RO完成了$T_s/T_{\text{RO}}$次振荡，积累的总抖动为$\sigma_{\text{total}} = \sigma_J \cdot \sqrt{T_s/T_{\text{RO}}}$（抖动按平方根累积，因为各振荡周期的抖动是独立的随机变量）。

当$\sigma_{\text{total}}$足够大（通常$> 0.5 \times T_{\text{RO}}$）时，采样时刻RO的相位完全不可预测——采样结果为0或1的概率接近50:50。此时，每次采样产生接近1比特的熵。采样频率$f_s$越低，积累的抖动越多，输出的随机性越好——但产出比特率也越低。设计者需要在比特率和熵质量之间平衡。

为了提高比特率，常见的策略是使用多个RO并行——$M$个独立的RO的输出通过XOR门合并。由于各RO的抖动是独立的，XOR合并后的信号具有更高的熵密度（每比特的min-entropy更接近1）。典型的设计使用8$\sim$32个RO，总面积约为几百到几千个等效门。

TRNG的攻击面与防护

硬件TRNG面临多种攻击威胁：

1. 频率注入攻击：攻击者通过操纵电源电压或注入电磁干扰来同步RO的振荡频率，使抖动减小甚至消失。防护措施包括：电源滤波、屏蔽层、多RO冗余（即使部分RO被攻击，其余RO仍然提供足够的熵）。

2. 温度攻击：在极端温度下，RO的振荡特性可能改变，抖动可能减小。防护措施包括：温度传感器监测、自适应采样频率调整。

3. 侧信道泄漏：RO的振荡可能通过电源或电磁辐射泄漏信息。防护措施包括：RO的物理隔离、差分设计（使用互补RO对消除共模噪声）。

4. 老化退化：长期使用后，反相器的阈值电压漂移可能改变RO的振荡特性。在线健康监测可以检测到这种退化并触发告警。

NIST SP 800-90B健康测试的硬件实现

NIST SP 800-90B标准要求TRNG实现两类在线健康测试，这些测试必须在硬件中实时执行，而非离线后处理：

重复计数测试（Repetition Count Test）：检测TRNG输出是否出现异常长的连续相同比特序列。如果TRNG输出了超过$C$个连续的0或1（$C$由min-entropy估计决定，典型值为$C \approx 1 + \lceil -\log_2(\alpha) / H_{\min} \rceil$，其中$\alpha = 2^{-20}$为误报率，$H_{\min}$为min-entropy），则判定TRNG故障。硬件实现只需要一个计数器和一个比较器：

• 1个1位寄存器存储前一个输出比特。

• 1个$\lceil \log_2 C \rceil$位计数器记录连续相同比特数。

• 每个新比特到来时：如果与前一比特相同，计数器加1；否则计数器重置为1。

• 如果计数器超过阈值$C$，输出health_fail信号。

• 总面积：约20$\sim$30个等效门。

自适应比例测试（Adaptive Proportion Test）：在一个滑动窗口（通常512或1024比特）内，统计1的出现频率。如果频率偏离50%超过阈值，则判定TRNG输出偏置过大。硬件实现需要：

• 1个$\lceil \log_2 W \rceil$位计数器（$W$为窗口大小）记录窗口内1的个数。

• 1个$\lceil \log_2 W \rceil$位计数器记录窗口内的总比特数。

• 两个比较器分别检查上界和下界。

• 一个移位寄存器或FIFO存储窗口内的历史比特，以便在比特滑出窗口时更新计数。

• 总面积：约200$\sim$500个等效门（取决于窗口大小）。

性能分析 9 — TRNG熵产出率的定量估算

以下五步计算展示了一个典型RO-based TRNG的熵产出率：

步骤1：确定RO参数。使用$N=5$个反相器，每个反相器延迟$t_{\text{inv}} = 15$ ps（5 nm工艺）。RO振荡频率$f_{\text{RO}} = 1/(2 \times 5 \times 15\text{ps}) = 6.67$ GHz。

步骤2：估算抖动。每个振荡周期的抖动标准差$\sigma_J \approx 2$ ps。

步骤3：确定采样间隔。设采样频率$f_s = 10$ MHz（$T_s = 100$ ns）。在一个采样间隔内，RO完成$100\text{ns} / 150\text{ps} = 667$次振荡。积累抖动$\sigma_{\text{total}} = 2\text{ps} \times \sqrt{667} \approx 51.6$ ps。

步骤4：评估每样本熵。$\sigma_{\text{total}} = 51.6$ ps vs $T_{\text{RO}}/2 = 75$ ps。比值$\sigma_{\text{total}} / (T_{\text{RO}}/2) = 0.69$，对应的min-entropy约为$H_{\min} \approx 0.8$比特/样本（通过正态分布的min-entropy公式估算）。

步骤5：计算总熵率。使用$M = 16$个独立RO，XOR合并后的min-entropy接近1比特/样本（独立源的XOR合并提高了熵密度）。原始比特率$= 10$ Mbps。经von Neumann去偏（效率约25%）后有效比特率$\approx 2.5$ Mbps。经AES-CBC-MAC调节器（2:1压缩）后$\approx 1.25$ Mbps的密码学安全种子。这远超RDRAND的需求——DRBG每$2^{16}$块（$= 1$ MB）重播种一次，在64 GB/s的DRBG输出下约每15 $\mu$s重播种一次，每次需要256比特种子$\Rightarrow$种子需求率仅为$256 / 15\mu\text{s} \approx 17$ Mbps——TRNG的有效输出完全满足需求。

TRNG的安全认证与测试标准

硬件TRNG必须满足严格的安全标准，以确保其输出的随机性和不可预测性。主要的认证标准包括：

• NIST SP 800-90B：美国国家标准与技术研究院发布的熵源评估标准，定义了对TRNG进行min-entropy估计的统计测试方法，以及在线健康测试的要求。

• AIS 20/31：德国联邦信息安全办公室（BSI）发布的物理随机数发生器评估标准，将TRNG分为P1（仅统计测试）和P2（包含数学模型验证）两个安全等级。

• FIPS 140-3：美国联邦信息处理标准，定义了密码模块（包括RNG）的安全等级（Level 1$\sim$4），高等级要求物理防篡改和入侵检测。

在硬件设计阶段，TRNG的验证面临独特的挑战——随机性是一个统计特性，无法通过功能仿真（functional simulation）来验证。设计验证通常包括：（1）在RTL仿真中使用物理噪声的行为模型注入抖动；（2）在硅后（post-silicon）阶段运行NIST SP 800-22统计测试套件对大量样本进行分析；（3）在不同温度、电压和老化条件下反复测试以确保熵源的鲁棒性。

TRNG的输出速率

TRNG的原始比特输出速率（raw bit rate）取决于采样频率和RO的抖动积累速度，通常在几Mbps到几百Mbps的范围。然而，经过后处理（去偏、白化）后的有效输出速率会降低——von Neumann校正器的平均输出速率约为输入速率的$1/4$，LFSR白化则取决于LFSR长度和缓冲策略。

对于密码学应用而言，TRNG的输出速率通常足够——密钥生成只需要几十到几百字节的随机数，频率很低。真正的性能瓶颈出现在需要大量随机数的场景（如蒙特卡洛模拟、随机化算法），此时需要用TRNG作为种子来驱动确定性随机数生成器（Deterministic Random Bit Generator，DRBG）。

DRBG与TRNG的组合

现代处理器中的硬件RNG子系统通常由TRNG和DRBG两部分组成：

• TRNG提供高质量的熵种子（entropy seed），速率较低但随机性有物理保证。

• DRBG（如NIST SP 800-90A定义的CTR_DRBG或HMAC_DRBG）使用TRNG提供的种子作为密钥和初始状态，通过确定性算法（如AES-CTR）快速生成大量伪随机数。DRBG的输出在密码学意义上是不可预测的（前提是种子不泄露且DRBG算法安全），且输出速率远高于TRNG。

• DRBG定期用新的TRNG种子重新播种（reseed），以保持前向安全性（forward secrecy）——即使DRBG的当前内部状态被泄露，攻击者也无法回推之前的输出。

在硬件实现中，DRBG通常使用AES-CTR模式——它将一个AES密钥和一个递增计数器作为输入，通过AES加密产生128位随机输出。每次reseed时，新的TRNG种子与旧密钥进行密码学混合（如异或后再通过AES加密）来更新DRBG密钥。AES-CTR的优势在于它可以复用处理器中已有的AES加速硬件——如果处理器已经集成了AES-NI，DRBG的AES运算可以直接在AES-NI硬件上执行，几乎不需要额外的硬件开销。

以下伪代码展示了DRBG的基本工作流程：

// DRBG初始化
void drbg_init(drbg_state *s, uint8_t *seed) {
    memcpy(s->key, seed, 16);      // 128位AES密钥
    memset(s->counter, 0, 16);      // 128位计数器初始化为0
    s->reseed_counter = 0;
}

// 生成随机数
bool drbg_generate(drbg_state *s, uint8_t *out, int len) {
    if (s->reseed_counter > RESEED_INTERVAL)
        return false;  // 需要重新播种
    while (len > 0) {
        increment(s->counter);  // 计数器加1
        aes_encrypt(s->key, s->counter, block);  // AES加密
        memcpy(out, block, min(len, 16));
        out += 16; len -= 16;
    }
    s->reseed_counter++;
    return true;
}

设计提示

硬件RNG子系统的设计需要特别关注启动延迟（startup latency）和熵耗尽（entropy depletion）问题。系统上电后，TRNG需要一段时间（通常为毫秒级）来稳定振荡并积累足够的熵；在此期间，DRBG尚未被有效播种，不应该向外界提供随机数。此外，当软件以极高速率请求随机数时，DRBG可能来不及从TRNG获取新种子——此时应该返回错误或阻塞，而非提供质量下降的随机数。Intel的RDRAND和RDSEED指令通过进位标志（CF）来指示随机数是否可用，软件必须检查此标志。

RDRAND和RDSEED（x86）

Intel从Ivy Bridge微架构（2012年）开始引入了RDRAND和RDSEED指令，提供了用户空间程序直接访问硬件随机数生成器的能力，无需操作系统调用或特权切换。

RDRAND与RDSEED的区别

• RDRAND（Read Random）：从DRBG的输出缓冲区中读取一个随机数（16/32/64位），存入目标寄存器，并设置进位标志CF指示操作是否成功（$\texttt{CF}=1$表示成功）。RDRAND提供的随机数经过DRBG处理，密码学质量高，速率较快，但不直接来自TRNG——适合大多数密码学应用。

• RDSEED（Read Seed）：直接从TRNG的后处理输出中读取一个随机数。RDSEED提供的随机数直接包含物理熵，质量最高，但速率较低——当TRNG的输出缓冲区为空时，RDSEED会返回失败（$\texttt{CF}=0$）。RDSEED主要用于需要最高质量随机数的场景，如DRBG的播种、长期密钥生成等。

微架构实现

Intel处理器中的硬件RNG子系统（Intel称之为Digital Random Number Generator，DRNG）的微架构实现包括以下层次：

1. 熵源（Entropy Source）：位于处理器核心外部（通常在片上非核心区域，uncore）的模拟电路，基于热噪声或环形振荡器抖动产生原始随机比特流。

2. 在线健康测试（Online Health Test）：实时监测熵源输出质量，检测stuck-at故障、频率偏移等异常。不合格的随机比特被丢弃。

3. 调节器（Conditioner）：使用AES-CBC-MAC或类似的密码学算法对原始随机比特进行熵提取（entropy extraction），将可能存在偏置的原始比特流转化为均匀分布的种子。调节器的输入/输出比通常大于2:1（即输入至少$2n$位原始比特来产生$n$位种子），以确保输出的最小熵（min-entropy）足够高。

4. DRBG引擎：使用AES-CTR模式的确定性随机数生成器。DRBG以调节器输出的种子作为AES密钥，以一个递增计数器作为输入，通过AES加密产生随机数。DRBG定期用新种子重新播种。

5. 输出缓冲区：DRBG产生的随机数被存储在输出FIFO缓冲区中。RDRAND指令从DRBG的输出FIFO中读取；RDSEED指令从调节器的输出FIFO中读取（绕过DRBG）。

DRBG的安全性质

DRBG（确定性随机数生成器）虽然是确定性算法，但在密码学意义上可以提供与TRNG相当的安全性，前提是：

1. 种子的保密性：TRNG提供的种子必须保密——如果攻击者获得了种子，就可以重现DRBG的所有输出。

2. DRBG算法的安全性：使用的DRBG算法必须是密码学安全的（如AES-CTR模式的CTR_DRBG）。

3. 定期重播种：DRBG必须定期从TRNG获取新种子，以限制单个种子泄露后影响的输出数量。NIST SP 800-90A规定CTR_DRBG在产生$2^{48}$个128位块后必须重播种。

4. 前向安全性（Forward Secrecy）：即使DRBG的当前状态被泄露，之前的输出仍然不可预测。这通过在每次重播种时更新DRBG密钥来实现。

5. 后向安全性（Backward Secrecy）：即使DRBG的当前状态被泄露，重播种后的输出不可预测（因为新种子来自TRNG，攻击者无法获取）。

在Intel DRNG子系统的实现中，DRBG使用AES-256-CTR模式，种子为256位。每产生$2^{16}$个128位块后自动重播种，确保了即使在极端高负载下也能维持安全性。重播种的过程是透明的——软件调用RDRAND时不知道（也不需要知道）是否发生了重播种。

RDRAND/RDSEED的性能特征

RDRAND的延迟在不同微架构上有所差异：在Skylake上约为460个周期，在Ice Lake上约为200个周期（得益于改进的DRNG子系统）。吞吐量方面，单核心约为每秒500M$\sim$1G个64位随机数，多核心共享时吞吐量可能受到DRNG子系统带宽的限制。

RDSEED的延迟和吞吐量都低于RDRAND，因为它直接从速率较低的TRNG/调节器输出中读取。在高并发请求下，RDSEED频繁返回失败（$\texttt{CF}=0$），软件需要在循环中重试。

性能分析 10 — RDRAND的性能模型

RDRAND在微架构中被实现为一条微码辅助（microcode assist）指令——它不像普通算术指令那样在单个执行端口上用1$\sim$几个周期完成，而是触发微码引擎执行一个复杂的内部序列：

1. 向片上DRNG控制器发送读取请求（通过内部总线）。

2. 等待DRNG控制器返回随机数据（涉及片上互连延迟、FIFO读取等）。

3. 将返回的随机数据写入目标寄存器。

4. 根据读取是否成功设置CF标志。

由于涉及片上互连通信和非核心逻辑的延迟，RDRAND的延迟远高于普通ALU指令。然而，RDRAND通常不在性能关键路径上——密码学密钥生成是低频操作。当确实需要大量随机数时（如初始化随机数池），软件可以通过多次调用RDRAND并将结果存入内存缓冲区，然后以DRBG方式从缓冲区扩展。

RISC-V的随机数生成

RISC-V通过Zkr（Random Number）扩展提供硬件随机数支持。Zkr扩展定义了一个CSR寄存器seed（0x015），软件通过csrrw指令读取该寄存器来获取随机数。seed寄存器的高2位（OPST字段）指示操作状态：

• BIST（00）：内置自检进行中，随机数不可用。

• WAIT（01）：暂时无可用熵，软件应稍后重试。

• ES16（10）：成功，低16位包含有效的随机种子。

• DEAD（11）：熵源不可恢复故障，应触发安全警报。

RISC-V的设计将随机数访问定义为CSR读取而非专用指令，这与RISC-V"最小化指令数，最大化正交性"的设计哲学一致。每次读取只返回16位有效随机数（而非x86的64位），这降低了对TRNG输出速率的要求——嵌入式处理器中的TRNG可能只有很低的比特率。

Zkr规范还要求seed寄存器只能通过csrrw指令访问（读并写），每次读取后硬件自动将seed内容清零或更新为新的随机值——这确保了同一个随机种子不会被读取两次，防止了信息泄露。此外，seed寄存器被定义为Machine-level（M模式）CSR，用户模式（U模式）和监督者模式（S模式）不能直接访问。操作系统需要通过ecall机制或虚拟化的CSR访问来向用户空间提供随机数服务——这种权限控制确保了虚拟化环境下不同虚拟机之间随机数源的隔离。

RDRAND vs RDSEED的微架构差异深度分析

RDRAND和RDSEED虽然在用户层面看起来功能相似（都返回随机数），但它们在微架构实现上有根本差异，理解这些差异对于安全敏感的应用至关重要。

特性	RDRAND	RDSEED
数据源	DRBG输出FIFO	调节器输出FIFO
确定性	是（给定种子）	否（物理随机）
输出速率	高（$\sim$800 MB/s/核）	低（$\sim$10 MB/s全局）
失败概率	极低（$<$0.001%）	中等（高并发时$\sim$20%）
延迟	$\sim$200–460周期	$\sim$300–800周期
适用场景	密钥生成、nonce、IV	DRBG播种、长期密钥
前向安全	重播种后是	天然是

RDRAND vs RDSEED的微架构对比

关键微架构差异1：数据路径长度。RDRAND从DRBG输出FIFO读取，该FIFO位于与核心相同的Die上（在DRNG控制器中）。RDSEED从调节器输出FIFO读取，调节器直接连接到TRNG熵源——这条路径更长，需要经过额外的调节步骤（AES-CBC-MAC处理），延迟更高。

关键微架构差异2：争用模型。RDRAND的DRBG输出FIFO由AES-CTR DRBG持续填充，DRBG的吞吐量极高（接近AES-NI的吞吐量），因此FIFO很少为空。但RDSEED的调节器输出FIFO由TRNG的低速输出驱动，在多核心同时调用RDSEED时，FIFO会迅速耗尽，导致频繁的失败返回。在128核EPYC系统中，如果所有核心同时调用RDSEED，失败率可能超过50%——软件必须在循环中重试，显著增加了有效延迟。

关键微架构差异3：安全属性。RDRAND的输出是确定性的（给定DRBG的种子和内部状态，输出完全可预测），因此其安全性完全依赖于种子的保密性和DRBG算法的安全性。如果攻击者获得了DRBG的内部状态（例如通过侧信道），可以预测RDRAND的所有后续输出——直到下一次重播种。RDSEED的输出直接包含物理随机性，即使攻击者获得了TRNG的完整设计文档，也无法预测下一个输出——这种不可预测性来自物理（量子力学层面的热噪声），不依赖于任何算法假设。

案例研究 4 — Linux内核对RDRAND/RDSEED的使用策略

Linux内核的随机数子系统（/dev/random和/dev/urandom的后端）对硬件RNG采用了防御性混合策略：

1. 在早期启动阶段（boot），内核使用RDSEED（如果可用）初始化内核熵池。如果RDSEED不可用或返回失败，回退到RDRAND。如果两者都不可用，使用中断时间戳等低质量熵源——此时内核会在日志中打印警告。

2. 在正常运行期间，内核定期将RDRAND的输出混入内核熵池，但不将其作为唯一熵源——而是与中断时间戳、设备噪声、磁盘I/O延迟等多个独立熵源混合。这种策略确保即使RDRAND被完全攻破（如硬件后门），整体的随机数质量仍有保障。

3. 从Linux 5.18开始，如果系统启用了random.trust_cpu引导参数，内核会完全信任CPU的硬件RNG，将RDRAND的输出直接用于初始熵池的信用（credit）——这加速了启动阶段的熵积累，但牺牲了对硬件RNG不信任场景下的安全保障。

这一策略反映了安全工程中的纵深防御原则：不依赖任何单一安全机制，而是通过多层独立机制的叠加来提高整体安全性。即使TRNG、DRBG或操作系统熵收集中的某一环出现问题，其他环的独立性仍能保证整体随机数质量不会灾难性地下降。

案例研究 5 — RDRAND争议与透明性

Intel的RDRAND指令曾引发安全社区的广泛讨论。核心争议在于透明性：DRNG子系统的具体实现细节（尤其是熵源的质量和DRBG的参数选择）对外部用户不可见，用户必须信任Intel没有在硬件中植入后门或削弱随机性。2013年Edward Snowden的泄密文件显示NSA曾试图在商用加密标准中植入后门，这进一步加剧了对硬件RNG信任度的担忧。

作为应对，安全敏感的应用通常不会单独依赖RDRAND，而是将其作为多个熵源之一——例如Linux内核的/dev/urandom将RDRAND的输出与操作系统收集的其他熵源（中断时间戳、设备噪声等）混合后使用。这种"熵混合"策略确保即使某一个熵源被攻破，整体的随机数质量仍有保障。

RISC-V的Zkr扩展规范明确建议实现者提供熵源的文档和可审计性，反映了开放标准对透明性的更高重视。

ARM的随机数生成指令

ARM在ARMv8.5-A中引入了RNDR和RNDRRS指令，提供了与x86 RDRAND/RDSEED类似的功能：

• RNDR（Random Number）：从DRBG读取一个64位随机数到通用寄存器。成功时设置NZCV标志的Z位为0，失败时Z=1。

• RNDRRS（Random Number, Reseeded）：从TRNG/调节器直接读取，确保输出包含完整的物理熵。类似于x86的RDSEED。

ARM的随机数指令设计与x86有一个重要差异：ARM不使用进位标志（CF）来指示成功/失败，而是使用条件标志（NZCV）——这使得随机数读取可以与ARM的条件执行机制（CSEL等）无缝配合。例如，一个读取随机数并在失败时重试的循环可以编写为：

retry:
    MRS     x0, RNDR           // 读取随机数到 x0
    CBNZ    wzr, retry          // 如果失败 (Z=1)，重试
    // x0 现在包含有效的随机数

ARM的设计还规定RNDR可以在EL0（用户模式）直接访问——不需要特权切换。操作系统通过设置SCEEN寄存器的位来控制是否允许用户态访问随机数指令。在虚拟化环境中，Hypervisor可以通过HCR_EL2寄存器中的位来控制Guest OS是否可以使用RNDR——如果禁用，Guest中的RNDR会陷入EL2，由Hypervisor提供模拟的随机数。

密码学指令的性能与安全性权衡

密码加速指令在提供性能的同时，也引入了新的安全考量：

1. 功耗侧信道：虽然AES-NI消除了缓存时序侧信道，但硬件AES电路的功耗仍然与数据相关——不同的明文/密文输入导致不同的翻转活动和功耗。在物理接触攻击场景（如智能卡、IoT设备），攻击者可以通过差分功耗分析（DPA）从AES硬件的功耗波形中提取密钥。防护措施包括：掩码技术（masking，将中间值随机化）、随机延迟插入、恒功耗设计。

2. 微架构侧信道：在同步多线程（SMT）环境中，不同硬件线程共享执行端口。攻击者线程可以通过观察密码指令对共享端口的占用模式来推断受害者线程的密码操作特征。缓解策略包括：在执行密码指令时禁用SMT（极端但有效）、使用恒定时间的密码操作模式。

3. 指令级时序泄漏：某些密码指令的延迟可能取决于输入数据。例如，如果AES的SubBytes使用的是ROM查找表（而非组合逻辑），ROM的读取延迟可能随地址位模式而微妙变化。现代AES-NI的组合逻辑实现消除了这种风险，但在面积受限的嵌入式设计中（如RISC-V Zkne的单S-box实现），可能需要额外注意时序恒定性。

设计提示

密码学硬件的设计原则是：安全性优先于性能。一个在功能上正确但存在侧信道泄漏的密码加速器可能比纯软件实现更不安全——因为软件实现可以使用恒定时间编程技术（如bitslicing）来消除时序泄漏，而硬件泄漏对软件不可见、不可控。处理器设计者在实现密码加速硬件时，必须将侧信道评估作为验证流程的必要环节——不仅验证功能正确性，还要验证各类操作的时序、功耗和电磁特征是否与数据无关。

多核心共享与仲裁

在多核心处理器中，DRNG子系统通常是所有核心共享的全局资源。当多个核心同时执行RDRAND指令时，需要仲裁机制来分配DRNG的输出带宽。Intel的实现中，DRNG控制器维护一个输出FIFO，各核心的请求通过片上互连排队访问该FIFO。当FIFO为空时（所有核心的消费速率超过了DRBG的产生速率），后续的RDRAND请求将返回失败。

硬件RNG的吞吐量扩展

当多个线程或应用同时需要大量随机数时，单一的全局DRNG可能成为带宽瓶颈。扩展方案包括：

1. 层次化DRBG：全局TRNG$\to$调节器$\to$多个本地DRBG实例。每个核心或核心簇拥有自己的DRBG实例，从全局调节器获取种子后独立运行。

2. DRBG并行化：单个DRBG可以使用多个AES-CTR流并行生成随机数——例如，将DRBG密钥与不同的nonce结合，创建多个独立的AES-CTR流，然后交织输出。这种方案不需要额外的TRNG或种子分发逻辑，但需要DRBG硬件支持多流管理。

3. per-thread种子：为每个硬件线程分配独立的DRBG种子，完全消除线程间的随机数争用。代价是需要更多的TRNG带宽来为所有线程提供种子。

为了缓解多核心竞争，一些设计中每个核心或核心集群（cluster）配备一个本地的DRBG实例——全局TRNG定期向各个本地DRBG分发种子，本地DRBG独立产生随机数供本地核心使用。这种层次化的架构在保持安全性的同时提高了吞吐量的可扩展性。

多核心处理器中DRNG子系统的层次化架构：全局TRNG + 调节器产生种子，分发到各核心集群的本地DRBG

::: tip 设计提示

在多核心处理器中设计DRNG子系统时，需要特别注意隔离性：不同安全域（如不同虚拟机或TEE enclave）的随机数请求应该得到隔离处理，确保一个安全域无法通过观察DRNG的延迟或输出模式来推断另一个安全域的活动。这可能需要为不同安全域维护独立的DRBG状态和输出缓冲区——增加了硬件复杂度，但对于安全关键的应用（如机密计算、TEE）是必要的。

:::

RDRAND/RDSEED的侧信道考量

硬件RNG指令本身也存在潜在的侧信道风险。例如，RDRAND的延迟可能随DRNG输出FIFO的填充状态而变化——FIFO满时延迟较低，FIFO空时延迟较高（需要等待DRBG产生新数据）。攻击者如果能够精确测量RDRAND的延迟，可能推断出其他核心或线程对DRNG的使用模式。为了缓解这种侧信道，Intel在较新的微架构中对RDRAND的延迟进行了一定程度的恒定化处理——即使FIFO中有数据立即可用，也会人为添加延迟使总延迟保持相对恒定。这种防御措施的代价是增加了RDRAND的平均延迟，但在安全关键的应用中是必要的权衡。

AES加速单元的面积与功耗模型

AES-NI加速单元在现代处理器核心中的面积和功耗占比虽然不大，但其设计涉及的工程权衡值得深入分析。以下是基于公开文献和工艺参数的定量模型。

AES-NI模块的面积分解

一个完整的AES-NI执行单元（支持AESENC/AESDEC/AESENCLAST/AESDECLAST）的面积可以分解为以下组件：

组件	面积 (kGE)	占比	说明
SubBytes (16$\times$S-Box)	2.1	5.3%	复合域实现, 130 GE/S-Box
逆SubBytes (16$\times$inv-S-Box)	2.5	6.3%	解密用, 含逆仿射变换
ShiftRows/逆ShiftRows	$\sim$0	0%	纯连线, 零面积
MixColumns (4列)	1.2	3.0%	xtime + XOR网络
逆MixColumns (4列)	1.8	4.5%	更复杂的GF(2$^8$)运算
AddRoundKey	0.5	1.3%	128位XOR
流水线寄存器 (4级)	20.0	50.0%	$4 \times 128$位寄存器
操作数MUX + 控制	6.0	15.0%	加密/解密模式选择
旁路逻辑	6.0	15.0%	与SIMD旁路网络接口
总计	$\sim$40	100%

AES-NI硬件模块的面积分解

一个令人惊讶的发现是：流水线寄存器占了AES-NI硬件面积的50%。这是因为AES轮函数的4级流水线需要在每级之间存储完整的128位中间状态，而128位宽的流水线寄存器的面积远超组合逻辑本身。这一观察对设计者的启示是：如果能够减少流水线级数（例如将4级缩减为3级），面积节省将非常可观——但代价是每级的组合逻辑深度增加，可能限制最高频率。

AES-NI的功耗特征

AES-NI在运行时的动态功耗主要来自两个来源：

翻转活动（Switching Activity）：S-Box的组合逻辑具有高翻转率——当输入字节变化时，约50%的内部节点翻转。16个并行S-Box每周期可能产生$16 \times 130 \times 0.5 = 1040$个节点翻转。在5 nm工艺中，每个节点翻转消耗约$C_{\text{load}} \times V_{dd}^2 \times f \approx 0.5\text{fF} \times 0.75^2\text{V} \times 4\text{GHz} = 1.125\,\mu\text{W}$。总翻转功耗约$1040 \times 1.125\,\mu\text{W} \approx 1.17\,\text{mW}$（仅S-Box部分）。

时钟树功耗：4级流水线寄存器需要时钟信号驱动。$4 \times 128 = 512$个触发器的时钟树功耗约占AES-NI总功耗的60%$\sim$70%。

在满负荷运行时，AES-NI模块的总功耗约为0.5$\sim$1.0 W（5 nm工艺，4 GHz）。当不执行AES指令时，AES硬件通过时钟门控（clock gating）将时钟信号切断，动态功耗降至接近零。静态漏电功耗约为$\sim$5 mW，通过电源门控（power gating）可进一步消除。

AES-NI在核心面积中的占比

以一个典型的5 nm高性能x86核心（面积约10$\sim$15 mm$^2$）为参考，AES-NI的面积约为40 kGE $\approx$ 0.05 mm$^2$，占核心面积的约0.3%$\sim$0.5%。如果加上VAES（256位版本，面积翻倍）和SHA（约20 kGE），密码加速硬件的总面积约为0.1$\sim$0.15 mm$^2$，占核心面积的约1%。

设计提示

专家洞察：密码硬件是"面积杠杆率"最高的功能单元。AES-NI以核心面积的0.5%换取了加密性能30$\sim$60倍的提升和缓存侧信道的完全消除——这种面积-收益比在所有处理器功能单元中无出其右。作为对比，增加一个FMA执行端口（面积约核心的3%$\sim$5%）仅在FP密集代码中提供2倍的吞吐提升。这就是为什么即使是面积极为紧张的嵌入式处理器（如RISC-V的低端核心）也值得集成密码加速硬件——Zkne扩展以0.2 kGE（$<$核心面积的0.01%）的代价提供了硬件级的AES加速和侧信道防护。

MixColumns的GF(2$^8$)硬件电路详解

MixColumns操作在$\text{GF}(2^8)$有限域上执行矩阵乘法，是AES轮函数中第二复杂的步骤（仅次于SubBytes）。理解其硬件实现需要先理解$\text{GF}(2^8)$上的乘法运算。

xtime操作的硬件实现

$\text{GF}(2^8)$上乘以2的操作称为xtime：将8位值左移1位，如果最高位为1（即移位前的值$\geq 128$），则将结果异或不可约多项式$\texttt{0x1B}$（即$x^8 + x^4 + x^3 + x + 1$的低8位表示）。用公式表示：

$$\text{xtime}(a) = \begin{cases} a \ll 1 & \text{if } a[7] = 0 \\ (a \ll 1) \oplus \texttt{0x1B} & \text{if } a[7] = 1 \end{cases}$$

硬件实现只需要：

• 1个8位左移器（连线实现，零面积）：$\{a[6:0], 0\}$

• 1个8位与门阵列：$\{8\{a[7]\}\} \text{ AND } \texttt{0x1B}$

• 1个8位XOR门阵列：将上述两者异或

• 总面积：约8个XOR门 + 4个AND门 $\approx$ 12 GE

• 延迟：2级门（AND + XOR）

MixColumns矩阵中的乘以3操作（$3 \times a$）可以分解为$\text{xtime}(a) \oplus a$——只需一个额外的8位XOR。因此，MixColumns的一列计算（4个字节输入$\to$4个字节输出）需要：

• 4个xtime单元（乘以2）：$4 \times 12 = 48$ GE

• 4个8位XOR门（乘以3 = xtime $\oplus$ 原值）：$4 \times 8 = 32$ GE

• 12个8位XOR门（矩阵各行的加法/异或）：$12 \times 8 = 96$ GE

• 一列总面积：约176 GE

• 4列（完整128位状态）：$4 \times 176 = 704$ GE

延迟约为3$\sim$4级XOR门（$\sim$20 ps），远低于SubBytes的15$\sim$20级。这就是为什么在4级AES流水线中，MixColumns被分配到一个独立的流水线级——它的逻辑深度足够浅，一级即可完成。

逆MixColumns的复杂度增加

AES解密使用的逆MixColumns矩阵包含更大的系数（$\{0x0e, 0x0b, 0x0d, 0x09\}$），需要更多的xtime级联操作：

• $0x09 = \text{xtime}(\text{xtime}(\text{xtime}(a))) \oplus a$（3次xtime + 1次XOR）

• $0x0b = \text{xtime}(\text{xtime}(\text{xtime}(a))) \oplus \text{xtime}(a) \oplus a$

• $0x0d = \text{xtime}(\text{xtime}(\text{xtime}(a) \oplus a)) \oplus a$

• $0x0e = \text{xtime}(\text{xtime}(\text{xtime}(a) \oplus a) \oplus a)$

逆MixColumns的面积约为正向MixColumns的2.5倍（$\sim$1760 GE），延迟也增加到5$\sim$6级XOR门。这是AES解密硬件比加密硬件更复杂的主要原因之一。

AESIMC指令（Inverse Mix Columns）专门用于将加密用的轮密钥转换为解密用的等效轮密钥，其硬件实现就是一个独立的逆MixColumns电路。

BRU、密码单元和RNG的设计方法学

本节从设计方法学的角度总结本章讨论的三类功能单元的共同设计特征。

面积-性能-安全的三维权衡

传统的处理器功能单元设计主要在面积和性能之间权衡。但BRU、密码单元和RNG引入了第三个维度——安全性。

BRU的安全维度

BRU的设计不仅影响性能（分支预测失败代价），还影响安全性（Spectre类投机执行攻击的暴露窗口）。降低BRU延迟可以缩小投机窗口，减少Spectre攻击的有效载荷。但更激进的投机策略（如更深的投机深度）虽然提高了性能，也扩大了安全攻击面。

密码单元的安全维度

AES-NI的安全价值至少与其性能价值相当——即使不考虑性能，仅消除缓存时序侧信道这一点就足以证明专用密码硬件的必要性。在面积受限的嵌入式设计中，即使只能提供较低的密码运算吞吐量（如RISC-V Zkne的单S-box设计），硬件实现的恒定时间特性也使其在安全性上优于任何纯软件实现。

RNG的安全维度

硬件RNG的设计几乎完全由安全性驱动——性能（随机数产出率）是次要考量，因为密钥生成等安全操作的频率远低于处理器的计算能力。RNG设计的核心挑战是确保在各种操作条件（温度、电压、老化、攻击）下的熵质量和不可预测性。

功能单元	面积优先级	性能优先级	安全优先级
BRU	低（面积很小）	极高（影响全局IPC）	高（Spectre缓解）
AES-NI	中（30$\sim$50 kGE）	高（加密吞吐量）	极高（侧信道消除）
SHA扩展	中（15$\sim$25 kGE）	中（哈希吞吐量）	高（完整性保障）
TRNG/DRBG	低（$<$1 kGE）	低（比特率足够即可）	极高（信任根）

三类功能单元的设计权衡维度

BRU与处理器安全的深层联系

Spectre漏洞家族的每一个变体都与BRU的某个具体设计特性直接相关。理解这些关联，需要从BRU的投机窗口（speculative window）出发进行系统分析。

投机窗口的定量分析

BRU的投机窗口定义为从分支指令被分派（dispatch）到BRU完成验证（resolution）之间经过的周期数。在此窗口内，前端持续按预测方向取指和分派新指令——这些指令在投机状态下执行，可能读取敏感数据并通过缓存侧信道泄露。

投机窗口的大小取决于：

1. 分支指令在发射队列中的等待时间：如果分支的源操作数来自一条长延迟指令（如L2 cache miss load），分支可能等待10$\sim$20个周期才能执行。这直接扩大了投机窗口。

2. BRU自身的执行延迟：通常为1周期，对投机窗口的贡献很小。

3. 前端取指宽度：宽前端在投机窗口内分派更多的投机指令。8-wide处理器在10周期窗口内可能分派80条投机指令，而4-wide处理器只分派40条。

性能分析 11 — Spectre攻击的投机窗口量化

以下分析量化了典型Spectre v1攻击中的投机窗口大小：

攻击代码模式：

if (x < array_len) {         // 分支指令 (条件依赖于x)
    y = array[x];            // 投机访问 (可能越界)
    z = probe[y * 64];       // 侧信道泄露 (缓存探针)
}

时序分析：

• 周期0：分支指令被分派到发射队列

• 周期0$\sim$5：等待x和array_len的值就绪（假设来自L1命中）

• 周期6：BRU执行分支判断，假设预测为taken（通过训练使预测器偏向taken）

• 周期1$\sim$5（与上面并行）：前端投机分派array[x]加载指令

• 周期3$\sim$7：投机加载执行，读取越界数据到y

• 周期5$\sim$12：probe[y * 64]加载执行，将y的值编码到缓存状态中

• 周期6：BRU检测到预测错误（$x \geq array\_len$），发出redirect

• 周期7$\sim$8：flush信号传播，清空投机指令

关键观察：在周期6 BRU检测到错误之前，probe[y * 64]的加载已经在周期5开始执行。如果这条加载在BRU验证完成之前就访问了缓存（L1 miss但L2命中的情况），它会将y的值编码为L2缓存行的存在/不存在状态——这个微架构状态变化不会被flush清除，因为flush只恢复体系结构状态（寄存器、内存），不恢复微架构状态（缓存内容）。

攻击成功率取决于投机窗口（$\sim$6周期）是否足够长以让两条投机加载完成。在现代处理器上，L1命中延迟约4周期，因此6周期的窗口刚好足够——这就是为什么Spectre v1如此有效。缩短投机窗口（例如通过更快的BRU验证或限制投机加载的发起时机）是硬件级Spectre缓解的核心思路。

Spectre v2（Branch Target Injection）的BRU影响

Spectre v2利用了间接分支预测器（Indirect Branch Predictor）的跨安全域共享问题。攻击者通过在自己的进程中训练间接分支预测器，使其对特定分支PC产生特定的目标地址预测。当受害者进程执行同一PC上的间接分支时，预测器返回攻击者注入的目标地址，导致受害者投机执行攻击者选定的代码路径（gadget）。

从BRU的角度看，Spectre v2的根本原因是：BRU在验证间接分支的目标地址时，验证延迟允许了足够长的投机窗口。间接分支的目标地址依赖于寄存器值（如函数指针），只能在BRU执行阶段才能确定——无法像直接分支那样在解码阶段提前计算。因此间接分支的投机窗口通常比条件分支更长。

硬件缓解策略（IBRS、STIBP、Retpoline）的核心思路都是限制间接分支预测器的跨域训练。但这些策略的性能代价不容忽视——IBRS在数据中心工作负载上的性能影响约为2%$\sim$10%，Retpoline约为5%$\sim$15%。这些代价在长期来看将通过更精细的硬件隔离机制（如per-domain预测器分区）来逐步降低，但完全消除Spectre类攻击在不牺牲投机执行性能的前提下，至今仍是未解决的开放问题——这也是第 51.0 章中将深入讨论的安全防御架构的核心挑战。

BRU与旁路网络的关键交互

BRU虽然计算逻辑简单，但它与旁路网络（第 34.0 章）的交互设计至关重要——BRU需要尽快获取源操作数才能尽早完成验证。

分支操作数的旁路路径

对于RISC-V的BEQ rs1, rs2, offset指令，BRU需要rs1和rs2两个操作数。如果这两个操作数来自刚刚执行完毕的前一条ALU指令，则通过旁路网络直接获取——不需要等待ALU结果写回寄存器文件。这条旁路路径的延迟直接影响BRU能否在"操作数就绪后的下一个周期"执行分支验证。

在典型的6端口整数执行引擎中，BRU需要接收来自所有6个端口的旁路数据——这意味着BRU的操作数MUX扇入为6（加上寄存器文件读取端口，总扇入为7）。这个7:1的MUX延迟约为2$\sim$3级门（$\sim$15 ps），是BRU关键路径的一部分。

如果BRU与ALU共享端口（如BOOM处理器的设计），旁路MUX的扇入可以减少——因为BRU直接使用同一端口的ALU减法器，省去了部分旁路路径。但这种共享的代价是分支指令和整数指令竞争同一端口的执行带宽。

x86标志位的旁路特殊性

对于x86的flags-based分支（如JE），BRU的源操作数不是通用寄存器，而是标志位寄存器。标志位的旁路路径与通用寄存器的旁路路径是独立的——标志位来自ALU的标志位输出端口，通过专用的标志位旁路网络传递到BRU的条件判断逻辑。

这条独立的标志位旁路路径在物理设计上需要特别注意，因为：

1. 标志位旁路的数据宽度很窄（6$\sim$8位），但时序要求与通用寄存器旁路相同。

2. 标志位产生端口（ALU）与消费端口（BRU）可能位于核心的不同物理区域，需要长距离信号传输。

3. 如前所述，Intel将标志位拆分为CF组和ZAPS组进行独立重命名，这意味着BRU可能需要从两个不同的标志位物理寄存器获取数据，增加了旁路MUX的复杂度。

功能单元的验证策略

本章讨论的三类功能单元在验证方面各有特殊挑战：

BRU的验证

BRU的功能验证需要涵盖所有分支类型（条件/无条件/间接/返回）与所有条件码组合（EQ/NE/LT/GE/LTU/GEU或各种flags组合）的笛卡尔积。特别需要验证的边界情况包括：

1. 分支目标地址溢出/下溢（PC + 很大的正/负偏移量）。

2. 两个BRU端口同时检测到预测失败时的仲裁正确性。

3. 检查点分配和释放的正确性——确保在各种分支/清空序列下不会出现检查点泄漏或双重释放。

4. 分支历史更新的正确性——确保BHR在预测失败恢复后被正确回滚。

密码单元的验证

密码单元的验证需要使用已知测试向量（Known Answer Tests, KATs）——即标准定义的输入/输出对。AES的KATs由NIST发布（FIPS 197附录A/B/C），SHA的KATs由NIST发布（FIPS 180-4）。验证过程包括：

1. 对所有KATs进行功能仿真验证。

2. 对S-box的每个输入值（0$\sim$255）进行穷举验证。

3. 对MixColumns的每种列输入模式进行验证（由于$\text{GF}(2^8)$乘法的特殊性，需要验证xtime操作在所有256种输入下的正确性）。

4. 验证密钥扩展在所有密钥长度（128/192/256位）下的正确性。

5. 验证加密和解密的互逆性：$\text{Dec}(\text{Enc}(P, K), K) = P$对所有$P$和$K$成立。

RNG的验证

RNG的验证最具挑战性，因为"随机性"是一个统计特性，无法通过功能仿真确定性地验证。验证流程包括：

1. RTL仿真阶段：使用行为级的噪声模型注入抖动，验证采样逻辑和后处理电路的功能正确性。但仿真无法验证输出的随机性质量。

2. FPGA原型阶段：在FPGA上运行RNG设计，收集大量（$>10^6$）随机比特样本，运行NIST SP 800-22统计测试套件。

3. 硅后测试阶段：在最终的芯片上，在多种温度/电压条件下收集样本并运行统计测试。确保TRNG在所有运行条件下都产生高质量的随机输出。

4. 安全认证：提交给NIST（CMVP程序）或BSI（Common Criteria程序）进行独立安全评估。

本章小结

本章讨论了处理器执行引擎中三类"非传统"功能单元。分支执行单元（BRU）虽然计算逻辑简单，但它是前端投机执行机制的关键验证环节，其预测失败信号的传播和流水线恢复机制直接影响处理器的整体性能。密码加速单元（AES-NI、SHA扩展、RISC-V Scalar Crypto）以微小的面积代价换取了密码运算数量级的性能提升和侧信道安全性。硬件随机数生成器则为整个安全体系提供了不可预测的熵基础。

本章涵盖的功能单元在面积和功耗上的占比远小于ALU或FMA单元——BRU的面积约占核心的0.5%，AES-NI约占1%，SHA约占0.5%，TRNG约占0.01%。但它们在处理器的整体性能和安全性中的影响远超其面积占比。

这些功能单元的共同特点是：它们不以"算力"见长，而以"安全性"和"控制流正确性"为核心价值。BRU保障了投机执行的正确性——没有可靠的分支验证和快速的恢复机制，乱序执行引擎就无法安全地进行激进的推测。密码加速单元保障了数据的机密性和完整性——在数据中心和移动设备中，加密已经成为默认操作而非可选特性，软件实现的性能和安全性都无法满足需求。硬件随机数生成器则保障了密码学系统的根基——所有的密钥、nonce和挑战值的安全性都建立在随机数的不可预测性之上。

分支预测失败的全系统性能影响

分支预测失败的代价远不止BRU本身的redirect延迟。一次预测失败在整个处理器系统中引起的连锁反应包括以下维度，每个维度都对IPC产生可量化的影响。

前端重填延迟的分解

当BRU在时钟周期$T$检测到预测失败并产生redirect信号时，以下事件序列依次发生：

周期	事件	可优化？
$T$	BRU检测到mispredict，产生redirect信号	—
$T+1$	redirect信号传播到前端（可能+1周期中继）	专用布线
$T+1\sim T+2$	前端PC更新为正确目标地址	—
$T+2\sim T+3$	I-Cache查找（使用新PC）	Op Cache旁路
$T+3\sim T+4$	I-Cache返回指令字节 / Op Cache命中	—
$T+4\sim T+6$	预解码和解码（如果Op Cache miss）	Op Cache命中=跳过
$T+5\sim T+7$	$\mu$ops进入$\mu$op队列	—
$T+7\sim T+9$	重命名和分发	更宽分发
$T+9\sim T+11$	调度器等待操作数	旁路优化
$T+11\sim T+13$	执行	—
$T+13\sim T+15$	结果写回，流水线恢复正常	—

分支预测失败的恢复时序分解（典型15周期惩罚）

从表中可以看到，15周期惩罚中：

• redirect传播占约2周期（可通过专用布线缩短到1周期）。

• 前端取指+解码占约4$\sim$6周期（Op Cache命中时可节省2$\sim$3周期）。

• 后端分发+调度占约4$\sim$6周期（更宽的分发和更快的旁路可各节省1周期）。

这一分解解释了为什么Op Cache对降低分支预测失败代价如此重要——它不仅提升了前端的稳态吞吐量，还在mispredict恢复路径上节省了2$\sim$3周期，将有效惩罚从$\sim$15周期降低到$\sim$12周期。

分支预测失败对Cache层次的影响

一次分支预测失败不仅浪费了流水线中的执行资源，还可能导致Cache状态的污染：

1. I-Cache污染：前端在错误路径上取指时，将错误路径的指令加载到I-Cache中，可能驱逐正确路径的指令。在I-Cache容量紧张的工作负载中，这种污染可能导致正确路径重新取指时出现I-Cache miss。

2. D-Cache预取污染：错误路径上的加载指令可能触发硬件预取器，将无关数据加载到L1/L2 DCache中，驱逐有用数据。

3. TLB污染：错误路径上的访存可能触发TLB填充，占用TLB条目。

4. BTB训练污染：错误路径上的分支指令可能"训练"分支预测器——如果这些投机分支的预测结果被用于更新预测器状态（使用投机更新策略），则预测器可能学到错误路径上的分支模式。

为了缓解这些污染效应，现代处理器采用了多种策略：标记错误路径上的Cache填充请求为"低优先级"（less likely to be needed）、延迟错误路径上的预取请求、使用投机-确认双状态的预测器更新等。这些策略增加了微架构的复杂度，但对维持高IPC至关重要。

BRU在不同工作负载中的性能影响

BRU的性能影响因工作负载特征而异。以下数据基于公开的性能计数器测量（Intel Golden Cove平台）：

工作负载	分支占比	MPKI	惩罚	IPC损失
SPEC CPU int (gcc)	22%	12.5	13 cyc	15%
SPEC CPU int (mcf)	18%	8.2	13 cyc	9%
SPEC CPU fp (lbm)	5%	1.2	13 cyc	1%
Web浏览 (Chrome)	28%	15.3	14 cyc	20%
数据库 (MySQL)	20%	9.8	14 cyc	12%
游戏引擎	24%	7.5	13 cyc	8%
Python解释器	30%	18.7	14 cyc	24%

不同工作负载中分支预测失败对IPC的影响

关键观察：解释器类工作负载（Python、JavaScript）受分支预测失败的影响最严重——它们的分支占比高（30%）且MPKI高（$>$18），因为字节码分派循环中的间接跳转（switch-case或computed goto）对预测器构成极大挑战。这就是为什么Apple M系列处理器在这类工作负载上表现突出——它们的多BRU端口设计和超大ROB可以更好地应对高分支密度和高误预测率。

设计提示

专家洞察1：分支预测的"最后一公里"问题。现代分支预测器的整体MPKI已经降到5$\sim$8的范围，这意味着平均每125$\sim$200条指令才有一次预测失败。进一步降低MPKI变得越来越困难——剩余的失败分支往往是真正不可预测的（如依赖于外部输入的条件分支），或具有极长周期的模式（预测器的历史长度不足以捕获）。在这种"最后一公里"阶段，降低每次失败的惩罚（通过更快的BRU验证、更快的前端重填、更大的ROB吸收气泡）可能比进一步提高预测精度更有效。这是Zen 5增加第二个BRU端口和扩大ROB到448项的根本动机。

设计提示

专家洞察2：BRU是处理器设计中"杠杆效应"最大的功能单元。BRU的面积约占核心的0.5%，但它的执行结果影响了核心中100%的指令——因为每一条在分支之后分派的指令都是在BRU验证之前的投机执行。BRU验证延迟每增加1个周期，分支预测失败的代价就增加1个周期，在15%$\sim$20%的IPC来自分支相关损失的工作负载中，这可能导致0.5%$\sim$1%的全局IPC下降。没有其他功能单元能以如此微小的面积产生如此大的全局性能影响。这就是为什么高性能处理器设计中，BRU到前端的redirect路径是最优先进行物理设计优化的信号路径之一。

BRU的微架构优化总结

分支执行单元虽然是执行引擎中逻辑最简单的功能单元，但其在整个处理器性能中的影响可能超过任何一个算术功能单元。BRU的设计优化可以从以下几个维度展开：

降低分支执行延迟

BRU的执行延迟直接影响分支预测失败的发现速度。优化手段包括：

1. 专用执行端口：为BRU配备独立的执行端口，避免与其他整数运算竞争。在分支密集的代码中（如解释器主循环、链表遍历），专用BRU端口可以显著降低分支执行的等待时间。

2. 简化比较器：对于RISC-V的BEQ/BNE指令，使用XOR+OR归约替代完整的减法器，降低条件判断的组合逻辑深度。

3. 分支预测器与BRU的直连：减少redirect信号从BRU到前端预测器的物理传输延迟。在某些设计中，BRU的redirect端口与前端预测器之间有专用的物理布线通道（dedicated routing channel），避免与通用数据总线竞争金属层资源。

降低分支预测失败代价

即使BRU本身延迟为1周期，分支预测失败的总代价仍然高达10$\sim$25周期。降低这一代价的微架构策略包括：

1. 快速重命名表恢复：使用基于检查点的恢复策略（而非ROB遍历），将重命名表恢复延迟降到1个周期。代价是需要为每条未决分支维护一份RAT快照。

2. 选择性清空：不清空整个流水线，而是只清空分支指令之后的指令。在分支之前已经完成执行但尚未退休的指令可以保留在ROB中。

3. 前端快速重启：在redirect信号到达前端的同一周期就开始从正确目标地址取指（而非等到下一周期），通过推测性地使用redirect目标地址来减少一个周期的延迟。

4. 增大ROB和发射队列：更大的ROB允许处理器在分支预测失败后仍有足够的"有用工作"（分支之前的指令）可以执行，减少了实际的IPC损失。Apple M系列处理器的超大ROB（$>$600项）就是这一策略的极端体现。

提高分支指令的调度优先级

通过给分支指令更高的调度优先级，可以尽早发现预测错误，减少在错误路径上浪费的执行资源。但过于激进的优先级可能延迟关键路径上的数据运算。现代处理器通常采用动态优先级策略——当分支指令的估计"在错误路径上的损失"（基于分支预测置信度和后续指令数量）超过延迟数据运算的代价时，提升其优先级。

设计提示

分支执行单元是处理器设计中"投入产出比"最高的功能单元之一。一个精心优化的BRU（降低1周期的redirect延迟）在分支密集的代码中可以带来3%$\sim$5%的IPC提升——这一提升只需要约0.01 mm$^2$的面积投入（一个简化的比较器和快速的信号传输通道）。相比之下，增加一个FMA端口（面积约0.1 mm$^2$）通常只能提升FP密集代码的吞吐量，对其他工作负载影响有限。因此，在面积预算有限的情况下，优化BRU的延迟和恢复机制通常比增加更多的算术执行端口更具全局性能收益。

密码加速单元的演进方向

随着后量子密码学（PQC）标准的确立，处理器中的密码加速硬件面临新的演进需求。

后量子密码的硬件需求

NIST在2024年标准化的PQC算法（CRYSTALS-Kyber用于密钥封装、CRYSTALS-Dilithium用于数字签名）与传统AES/SHA在计算核心上有根本不同：

• 数论变换（Number Theoretic Transform, NTT）：PQC算法的核心操作是多项式乘法，通常通过NTT加速。NTT类似于FFT，但在模素数的有限域上进行。硬件加速NTT需要高效的模运算单元（模加法、模乘法）和蝶形运算网络。

• 模归约（Modular Reduction）：Kyber使用模$q = 3329$的运算。模归约可以通过Montgomery乘法或Barrett归约实现。专用的模归约硬件可以比通用整数除法器快1$\sim$2个数量级。

• 多项式采样（Polynomial Sampling）：从随机种子生成多项式系数需要大量的SHA-3/SHAKE哈希运算。SHA-3（Keccak）的硬件实现与SHA-256有本质不同——Keccak使用$5 \times 5 \times 64$位的三维状态阵列和海绵结构（sponge construction），置换函数包含$\theta$、$\rho$、$\pi$、$\chi$、$\iota$五个步骤。

目前，处理器厂商尚未大规模集成PQC专用硬件。短期内，PQC运算主要通过以下方式在现有硬件上加速：

1. 利用SIMD指令（如AVX-512 IFMA的52位整数乘加指令）加速NTT中的模乘运算。

2. 利用SHA扩展指令加速多项式采样中的哈希运算。

3. 利用AES-NI辅助密钥生成中的伪随机数生成。

长期来看，如果PQC成为主流加密标准（可能在2030年代逐步替代RSA/ECC），处理器中可能出现专用的NTT加速单元和SHA-3/Keccak硬件——类似于AES-NI的演进路径，从软件实现逐步过渡到专用硬件加速。

展望未来，这些"非传统"功能单元的重要性只会增加。后量子密码学（Post-Quantum Cryptography, PQC）算法（如基于格的CRYSTALS-Kyber和CRYSTALS-Dilithium）将需要新一代的硬件加速支持——这些算法的核心操作包括多项式乘法（NTT变换）、模运算和哈希函数，与当前AES/SHA硬件的运算模式有显著差异。如何在处理器中高效集成PQC加速硬件，同时保持对传统算法的向后兼容，是下一代处理器设计面临的重要挑战。

从处理器架构的角度看，BRU、密码单元和随机数生成器代表了三种不同的"非计算型"功能单元设计范式：

1. BRU代表了控制流验证范式——功能单元的输出不是数据结果，而是影响整个处理器流水线行为的控制信号。BRU的设计目标是最小化验证延迟和最大化恢复速度。

2. 密码单元代表了领域专用加速范式——将特定算法（AES、SHA）的运算映射为专用组合逻辑电路，以微小的面积代价获得数量级的性能提升和侧信道安全性。

3. 随机数生成器代表了物理信任根范式——利用物理过程的不可预测性为整个安全体系提供熵基础。TRNG的设计目标不是计算速度，而是随机性质量和抗攻击能力。

这三种范式在未来处理器中将继续扩展。BRU的控制流验证可能扩展到包含安全相关的控制流完整性（CFI）验证——如ARM的Pointer Authentication和x86的CET（Control-flow Enforcement Technology）都需要在分支验证时增加额外的安全检查。密码单元将逐步纳入PQC加速硬件。随机数生成器可能引入量子随机源（基于量子隧穿或量子噪声）以提供更高质量的熵。

前向桥接——旁路网络与功能单元的耦合。本章讨论的所有功能单元——BRU、AES-NI、SHA、TRNG——都需要通过旁路网络（bypass network）与其他功能单元交换数据。第 34.0 章将深入分析旁路网络的设计：BRU的条件操作数如何通过旁路从前一条ALU指令直接获取（避免等待寄存器写回），AES-NI的128位中间状态如何在4级流水线的各级之间前递，以及宽数据通路（256/512位）的旁路网络如何在面积和时序之间取得平衡。旁路网络的设计质量直接决定了功能单元能否达到其理论吞吐量——一个1周期延迟的BRU如果因为旁路路径缺失而必须等待2周期才能获得操作数，其实际效果等同于一个3周期延迟的BRU。