AMD Zen 系列微架构参数
AMD Zen 系列微架构参数
- 前端
- BTB, RAS, ITA, Mop Cache 容量逐代上升
- 访存
- 访存宽度稳步上升: L1DCache 带宽，LSU
- L2/L3 Cache 容量逐代增加
- 大幅提升 L1D/L2D TLB 和 L2 ITLB 容量
- 大幅提升 MSHR 容量
- 后端指令窗口稳步加深，PRF、in-flight macro-ops、store/load tracking 持续增加，Zen5 的 8-wide dispatch 和 448 in-flight macro-ops 是明显跃迁。
分支预测与前端
BTB
| Arch | L0 BTB | L0 Bubble | L1 BTB | L1 Bubble | L2 BTB | L2 Bubble | RAS | ITA |
|---|---|---|---|---|---|---|---|---|
| Zen1 | 4 forward + 4 backward | 0 bubbles | 256 | 1 bubbles | 4096 | 4 bubbles | 32/15(SMT) | 512 |
| Zen2 | 8 forward + 8 backward | 0 bubbles | 512 | 1 bubbles | 7168 | 4 bubbles | 32/15(SMT) | 1024 |
| Zen3 | N/A | N/A | 1024 | 直接分支 0 bubbles, call/ret/indirect 1 bubble | 6656 | 3 bubbles | 64/32(SMT) | 1536 |
| Zen4 | N/A | N/A | 1536 | 直接分支 0 bubbles, call/ret/indirect 1 bubble | 7680 | 3 bubbles | 64/32(SMT) | 3072 |
| Zen5 | N/A | N/A | 16K | direct calls、same-target indirect、条件和非条件直接分支: 0 bubbles，ret 和多目标 indirect: 2 bubbles | 8K | 8 bubbles | 104/52(SMT) | 3072 |
可能考量是前端越来越依赖更大的近端预测结构来支撑更宽、更深的后端。
- Zen1/Zen2 的小 L0 适合低延迟捕获热点短分支
- Zen3 之后将容量集中到更大的 L1/L2，降低复杂控制流和大代码 footprint 下的 BTB miss
- Zen5 的 L1 BTB 跳到 16K，说明 AMD 更重视把大量活跃分支直接留在低气泡预测路径中，以喂饱更宽的 8 dispatch 后端
BTB 预测气泡反映出不同代在“容量”和“低延迟”之间的取舍:
- Zen3/Zen4 取消小 L0 后，用较大的 L1 提供零气泡直接分支预测，同时降低 L2 校正代价
- Zen5 的 L1 容量极大，但复杂间接/返回分支气泡增加，L2 代价也更高
RAS 加深主要服务于更深调用链、C++/Rust/大型框架等现代软件形态，减少 return mispredict。Zen5 继续增加 RAS，与其更大的 BTB、fetch window 一起，表明前端目标是减少控制流恢复和重定向造成的后端饥饿。
ITA 间接分支目标数增加，通常对应虚函数、解释器、JIT、switch jump table、动态语言 runtime 等代码模式。容量翻倍说明 AMD 在减少多目标 indirect branch 的误预测上持续投入，尤其 Zen4/Zen5 面向服务器和客户端混合负载时，这类控制流更常见。
L1 I-cache
- Zen1 的 L1 I-cache 是 64KB/4-way
- Zen2 起变为 32KB/8-way，并一直保持到 Zen5
- Zen5 的 L1 I-cache fetch width 从此前 32B/cycle 提高到 64B/cycle。
Zen1 到 Zen2 的变化是容量减半但相联度翻倍，可能是通过更高相联度缓解冲突，同时降低访问能耗和面积，把更多前端容量交给 Op Cache。Zen5 提高取指带宽，是为了喂两个 decode pipeline，并减少从传统 I-cache 路径取指时的瓶颈。
Decode Width
Zen1 到 Zen4 均为 4 instructions/cycle。Zen5 仍是 4 instructions/cycle per thread，但配合 64B/cycle 取指和两个 decode pipelines。
表面宽度没有变成 8-wide decode，但 Zen5 通过 per-thread 描述和双 decode pipeline 改善 SMT 或前端供给弹性。可能考量是直接扩大通用 decode 宽度成本很高，AMD 更倾向于用 Op Cache、更宽取指和更大预测结构提升有效前端吞吐。
MOp Cache
| Arch | Size | Assoc | Entry | Throughput |
|---|---|---|---|---|
| Zen1 | 2K insts | 32 sets x 8 ways | 8 insts | 8 insts/cycles |
| Zen2 | 4K ops | 64 sets x 8 ways | - | 8 insts/cycles |
| Zen3 | 4K ops | 64 sets x 8 ways | 8 macro-ops | 8 ops/cycles |
| Zen4 | 6.75K ops | 64 sets x 12 ways | 9 macro-ops | 9 ops/cycles |
| Zen5 | 6K (fused) insts | 64 sets x 16 ways | 6 (fused) insts | 12 insts/cycles |
Op Cache 是 Zen 前端演进的核心。Zen2 将容量翻倍，降低重复解码压力；Zen4 进一步提高容量和每 entry 容纳能力，以支持 AVX-512、更多融合和更大热代码区。Zen5 虽标称从 6.75K ops 变成 6K instructions/fused instructions，但计数单位改变，强调 fused instruction 密度，可能是用更贴近前端真实消耗的格式提升有效容量和取出效率。
Zen1 到 Zen4 的 Op Cache Throught 基本上和每个 Entry 的容量一致，即每周期最多取一个 entry；Zen5 提高到每 entry 的两倍，这意味着 Zen5 的 MOp Cache 可能也支持了双端口设计以满足 2-fetch pipeline
Cache
L1 D-cache
| Arch | Size | Assoc | BandWidth |
|---|---|---|---|
| Zen1 | 32KB | 8 ways | 2x128b load + 1x128b store/cycle |
| Zen2 | 32KB | 8 ways | 2x256b load + 1x256b store/cycle |
| Zen3 | 32KB | 8 ways | 3 memory ops/cycle (最多 2x256b load / 1x256b store) |
| Zen4 | 32KB | 8 ways | 3 memory ops/cycle (最多 2x256b load / 1x256b store) |
| Zen5 | 48KB | 12 ways | 4 memory ops/cycle (最多 2x256b load / 1x256b store) |
Zen1 到 Zen5 load-to-use 延迟保持不变：整数 4-5 cycles，FP 7-8 cycles。
访存带宽的提升和 SIMD 宽度演进一致：Zen2 原生支持 256-bit load/store，Zen4 引入 512-bit 操作但通过 256-bit 数据路径分两拍完成，Zen5 则提供更完整的 512-bit load path。设计考量是让向量计算、内存拷贝、数据库扫描、AI/媒体等带宽敏感代码不被 L1D 端口限制。
L2
| Arch | Size | Assoc | Load-to-use Latency | L2-to-L1 data path |
|---|---|---|---|---|
| Zen1 | 512KB | 8 ways | 12 cycles | 32B |
| Zen2 | 512KB | 8 ways | 12 cycles | 32B |
| Zen3 | 512KB | 8 ways | 12 cycles | 32B |
| Zen4 | 512KB/1MB | 8 ways | 14 cycles | 32B |
| Zen5 | 1MB | 16 ways | 14 cycles | 64B |
L2 从 512KB 到 1MB 是典型的容量换延迟：Zen4/Zen5 接受至少 2 cycles 的 L2 延迟增加，以换取更低 L2 miss 和更好的大工作集表现。Zen5 把相联度和 L2-to-L1 带宽翻倍，说明它不只是增大容量，还要降低冲突和提高 refill 速度，匹配更大的 L1D 和更高访存并行度。
L3
| Arch | Size | Assoc | Load-to-use Latency | cores per CCX |
|---|---|---|---|---|
| Zen1 | 4MB/8MB | 16 ways | 35 cycles | 4 |
| Zen2 | 4MB/16MB | 16 ways | 39 cycles | 4 |
| Zen3 | 32MB | 16 ways | 46 cycles | 8 |
| Zen4 | 96MB | 16 ways | 50 cycles | 8 |
| Zen5 | 96MB | 16 ways | 46 cycles | 8 |
L3 容量扩大和共享核心数增加，是面向多核、大工作集和服务器负载的明显选择。代价是 L3 平均延迟上升，尤其 Zen3/Zen4。Zen5 将平均 L3 延迟从 Zen4 的 50 降到 46，可能是缓存层级路径、物理实现或互连访问优化后的结果。
TLB 与地址翻译
| Arch | L1I | L1D | L2I | L2D | PTW Walkers |
|---|---|---|---|---|---|
| Zen1 | 64 | 64 | 512 | 1536/12-way | 2 |
| Zen2 | 64 | 64 | 512 | 2048/16-way | 2 |
| Zen3 | 64 | 64 | 512 | 2048/16-way | 2 |
| Zen4 | 64 | 72 | 512 | 3072/24-way | 6 |
| Zen5 | 64 | 96 | 2048 | 4096/16-way + 1G page 1024/4-way | 6 |
- L1 DTLB 增大直接减少数据访问地址翻译 miss。随着 L1D、load queue、miss tracking 和内存并行度扩大，DTLB 容量必须同步增加，否则更宽的访存 pipelines 会被页表翻译限制; （之前测试 AMD Zen5 并不支持跨页预取, 所以此处增加 TLB 容量可能不是基于跨页预取的考虑 ）
- Zen5 大幅增加 L2 ITLB，和更大的 BTB、Op Cache、fetch window 一起指向更强的前端大代码 footprint 支持。大型服务端程序、浏览器、JIT 和虚拟化环境都会受益于更大的二级指令翻译缓存。
- L2 DTLB 持续增大，说明 AMD 在缓解大内存工作集、随机访问和服务器负载中的页表翻译瓶颈。Zen4 的 24-way 偏向降低冲突，Zen5 则进一步增大总容量，并为 1G page 增设专门结构，有利于数据库、虚拟化和大页内存应用。
- PTW Walker 从 2 到 6 是 Zen3 的重要变化。它允许更多 TLB miss 并行处理，减少多个 load miss 或 instruction miss 同时发生时的串行化。这与 Zen3 起增强的 load tracking、L3 容量和服务器定位相吻合
流水线后端
乱序宽度
| Arch | Int PRF | Flag PRF | Dispatch Width | Retire Width | Inflight Mops |
|---|---|---|---|---|---|
| Zen1 | 168 | - | 6 macro-ops/cycle | 8 macro-ops/cycle | 192 |
| Zen2 | 180 | - | 6 macro-ops/cycle | 8 macro-ops/cycle | 224 |
| Zen3 | 192 | - | 6 macro-ops/cycle | 8 macro-ops/cycle | 256/128 (SMT) |
| Zen4 | 224 | 108 | 6 macro-ops/cycle | 8 entries/cycle | 320/160 (SMT) |
| Zen5 | 240 | 192 | 8 macro-ops/cycle | 8 entries/cycle | 448/224 (SMT) |
- 更大的物理寄存器文件支持更多重命名和更深乱序窗口，减少因寄存器资源耗尽导致的前端/rename stall。Zen4 起单独记录 Flag PRF，Zen5 大幅增加 flag rename 资源，可能是为了降低条件码密集整数代码、分支融合和更宽后端下的 flag 依赖压力。
- Zen5 扩宽 dispatch 是后端吞吐升级的核心。单纯扩大执行单元不够，如果 dispatch 仍是 6-wide，就无法持续填满 6 ALU、4 AGU 和更宽 FP/LS 资源
- Retire Width: Zen1 到 Zen3 为 8 macro-ops/cycle，从 Zen4/Zen5 开始描述为 8 retire queue entries/cycle，说明一个 ROB entry 可能存多个 macro-op (ROB 压缩)
- 乱序窗口持续加深，是 Zen 系列后端性能提升的主线之一。更大的在途窗口能覆盖更长 cache miss、分支恢复、执行延迟和内存乱序，提升内存级并行和指令级并行
Int 执行流水线
| Arch | Int ALU | AGU | Int IQ/Scheduler |
|---|---|---|---|
| Zen1 | 4 | 2 | 4x14-entry ALU + 2x14-entry AGU |
| Zen2 | 4 | 3 | 4x16-entry ALU + 2x28-entry AGU |
| Zen3 | 4 | 3 | 4x2 macro-ops / cycle |
| Zen4 | 4 | 3 | 4x2 macro-ops / cycle |
| Zen5 | 6 | 4 | 6 uops ALU + 4 uops AGU / cycle |
- Zen5 的 6 ALU 是整数后端宽度的明显跃迁。它可以提高通用整数、分支、移位、PDEP/PEXT、multiply 等操作的并行吞吐，尤其适合编译器生成的混合整数代码和服务器逻辑负载。
- AGU 增加反映访存地址生成需求持续上升。Zen2 从 2 到 3 支撑 2 load + 1 store 的常见模式；Zen5 增到 4，配合 4 memory pipelines 和 4 memory ops/cycle，目标是减少 load/store 地址生成对更宽 LS 的限制。
- 调度器从分散的小队列逐步演进到更高 issue 能力的组织。Zen2 增大 ALU scheduler 并统一 AGU scheduler，可能是为了提高 3 AGU 后的资源利用率。Zen5 直接以 6 ALU issue 和 4 AGU issue 描述，说明调度能力随执行宽度一起扩展。
- Integer Multiply Latency: Zen1 到 Zen5 均为 3 cycles，没有变化。
FPU 流水线
| Arch | Dispatch/Rename Width | IQ/Scheduler Capacity | Load Store Width | Non-Scheduling Queue |
|---|---|---|---|---|
| Zen1 | 4 uops/cycle | 36 uops | 128b | N/A |
| Zen2 | 4 uops/cycle | 36 uops | 256b | N/A |
| Zen3 | 6 mops/cycle | 2x32 mops | 256b | N/A |
| Zen4 | 6 mops/cycle | 2x32 mops | 256b | 64 |
| Zen5 | dispatch 8, rename 6 mops/cycle | 3x38 mops | 512b | 96 |
- FPU 前端供给能力逐步提高。Zen5 允许 dispatch 8 但 rename 6，并通过 NSQ 接住溢出，说明它希望整体核心保持 8-wide dispatch，同时承认 FP rename/调度仍有实际资源边界。
- FPU scheduler 容量扩大是为了支撑更长向量、更大窗口和更多并行 FP 操作。Zen5 的 3x38 明显增强，有助于 AVX-512 和混合 FP/访存代码维持更多在途操作。
- SIMD 数据路径宽度每隔几代翻倍
- Zen4 支持 AVX-512 但 FPU load/store path 仍是 256b，更多通过分拍完成
- Zen5 则把路径扩到 512b，使 512-bit 代码不再主要受半宽数据路径限制。
- FPU execution pipes 数量保持 4。执行 pipe 数不变，说明 AMD 更重视每条 pipe 的数据宽度和调度供给，而不是增加 FP pipe 数
- NSQ 用来在 FP scheduler 满时继续接收 macro-op，尤其帮助 load/store address calculation 先行。Zen5 扩大 NSQ，匹配 8-wide dispatch 和更大的 FP/LS 压力，减少 FP scheduler 满导致的全局阻塞。
Load-Store Unit
| Arch | Load Queue | Store Queue | Outstanding Cache Misses/MSHR | LS Pipelines |
|---|---|---|---|---|
| Zen1 | 44 | 44 | 22 | 2 load + 1 store |
| Zen2 | 44 | 48 | 22 | 2 load + 1 store |
| Zen3 | 72 | 64 | 24 | 3 memory |
| Zen4 | 48 uncompleted + 88 completed | 64 | 24 | 3 memory |
| Zen5 | 64 uncompleted loads，completed loads 无特定限制 | 104 | 124 | 4 memory |
load tracking 变得更细化、更大
- Zen3 的 72 OOO loads 增强内存级并行
- Zen4 区分 completed/uncompleted loads，说明实现上更精细地管理已完成 load 的顺序和依赖
- Zen5 取消 completed loads 的特定限制并增加 uncompleted loads，有利于深窗口下保留更多 load 状态，同时说明 completed loads 可能不再保存到 LDQ 中
store queue 增大能支持更多在途 store、store-to-load forwarding 和乱序执行，避免写密集代码中过早阻塞 rename/dispatch。Zen5 增到 104，与 4 memory pipelines、2 store/cycle 和 512-bit store handling 相匹配。
Zen5 的 outstanding miss tracking 是最大幅变化之一
- 显著提高 memory-level parallelism，能更好覆盖 L2/L3/DRAM 延迟
- 代价是 MAB/MSHR 等结构面积和功耗增加，但对服务器、多线程、随机访问和大工作集非常关键
- 相比于 AGU/LSU 而言，提升也过于巨大，所以可能是对预取的考量
LS pipeline 的演进和 AGU、L1D 带宽一致。Zen3/Zen4 将 pipeline 抽象为 3 memory ops/cycle，提升调度弹性；Zen5 增到 4，匹配 4 AGU、4 memory ops/cycle 和更高 MLP