Arm Neoverse 系列微架构参数

  • N 系列面向 scale-out cloud、网络、电信和 infrastructure edge，优先优化 performance-per-watt、单位面积吞吐、核心密度和 SoC 配置弹性。
  • V 系列面向数据库、HPC、AI/ML 和高性能云计算，愿意用更大的前端、更深的乱序窗口、更多执行管线和更大的私有缓存换取单线程性能。

整体演进可以概括为：

  1. 前端稳步增长
    • N2/N3 稳定在 5 MOP/10 µOP dispatch
    • V1/V2 为 8/16，V3 增至 10/20
  2. 后端 V 系列稳步增长，N系列保持稳定不变
    • V 系列持续增加标量和控制流吞吐
      • Issue pipelines 从 V1 的 15 条增至 V2 的 17 条、V3 的 21 条
      • 整数/分支 pipelines 从 4+2 增至 6+2、8+3
    • N 系列后端宽度基本不变
      • N2/N3 都是 13 条 issue pipelines、4 条整数管线、2 条分支管线和 2 条 FP/ASIMD 管线，后续收益更多来自预测、预取、缓存/TLB、ISA 和实现效率
  3. MOP Cache 变化
    • V1 引入，N2/V2 减少 MOP Cache 容量，N3/V3 未说明
  4. Cache: L1 保持不变, L2 V 系列容量稳步增长, N 系列保持不变
  5. TLB 容量增加
    • 前两代 TLB 容量基本不变
    • V3 开始 L1 TLB 增大至 128/96 entries**
    • N3 开始 L2 TLB 按页大小做分段 TLB
  6. 向量演进
    • V1 使用 2×256b SVE
    • V2/V3 改为 4×128b SVE2，总峰值仍约为 512b/cycle，但能以更细粒度处理通用云、加密、压缩和 ML 操作

两条产品线的关系

阶段 N 系列 V 系列 主要设计方向
第一阶段 N1 V1 N1 建立高能效服务器基线；V1 大幅增加宽度、窗口和 SVE 能力
第二阶段 N2 V2 进入 Armv9/SVE2；N2 强调 PPA 回报，V2 强化大型代码与标量后端
第三阶段 N3 V3 N3 提供更宽配置空间；V3 进一步提高单线程前后端和翻译容量

N 系列追求效率

Arm 官方描述：

  • N2 相比 V1 使用更适度的 speculation、vector bandwidth 和 load/store bandwidth，新增结构必须具有较高的 power/area ROI
  • N2 相比 N1 获得约 40% IPC 提升，却维持接近 N1 的面积与功耗效率
    • ，而不是结构规模最大化

V 系列追求性能

  • V1 相比 N1 获得约 50% IPC 提升，但同工艺核心面积增加约 70%, 增加的面积用于更宽的前端、两倍以上的乱序窗口、15 条 issue pipelines 和 2×256b SVE

分支预测与取指前端

BTB、方向预测与代码覆盖范围

  • N1 公开了约 6K-entry BTB、5K+8K 方向预测器和高容量混合间接分支预测器, 同时采用 predict-directed fetch、4-wide frontend 和 11-stage accordion pipeline
  • V1 没有公开 BTB 绝对容量，但 Arm 表示它扩大了 BTB、提高了条件分支预测精度，将预测带宽扩展至每周期 2×32B blocks，并把可同时跟踪的代码区域数翻倍
  • N2 则保留 V1 的分支预测算法，但减少对深度 speculation 的依赖。这体现了 N 系列的基本方法：尽可能复用高收益的预测算法，但控制用于保存推测状态、checkpoint 和恢复信息的面积与动态功耗。
  • V2 又把 BTB 扩大到 V1 的 10 倍、TAGE 表扩大到两倍，同时将 instruction TLB/cache bandwidth 和 fetch queue size 都扩大到两倍
  • N3/V3 没有公开 BTB、TAGE 或 RAS 的可比绝对容量

这些变化的主要目的是同时处理以下问题：

  • 更大的 BTB 减少大型代码中的 target capacity/conflict miss；
  • 更大的 TAGE 表覆盖更长、更复杂的分支历史；
  • 更大的 fetch queue 吸收预测、I-cache、ITLB 与 Decode/Dispatch 之间的短时速率差异。

其背后的工作负载逻辑是：服务器程序常包含大型二进制、共享库、JIT code cache、虚函数和间接调用。活跃代码超出 BTB、ITLB 或 I-cache 覆盖范围后，即使条件分支方向本身容易预测，前端仍可能无法及时得到下一取指地址。

Arm 对大型 Java code cache 的分析也表明，BTB、ITLB 和 cache 压力会共同造成前端瓶颈。Arm 大型 Java code cache 优化说明

取指带宽与前端解耦

  • N1 取指带宽是 4 instructions/cycle；V1 预测带宽是每周期 2×32B blocks
  • V1 将 branch predictor 与 instruction fetch pipeline 解耦，使预测器可以提前把代码预取到 L1 I-cache
  • V2 在扩大预测结构的同时扩大 fetch queue，说明设计目标是提高持续供给率，而不只是某一级的峰值吞吐
    • 后端短时阻塞时，fetch queue 避免立即反压预测器；
    • I-cache/ITLB 短时停顿时，队列中已有指令仍可继续供应 Decode；
    • 分支预测可以在执行后端消耗指令之前更早建立未来代码流。

MOP Cache

MOP cache 避免反复译码热点循环，同时提高供给宽度。

Arm 特别指出，小型 kernel 在基础设施软件中很常见，因此 N2 即使强调 PPA，仍保留了 MOP Cache。

  • V1 的关键变化是引入了 MOP Cache 提供两条前端路径：
    • 常规 I-cache/Decode 路径每周期最多提供 5 MOP；
    • 热点代码命中 MOP cache 后，每周期最多提供 8 MOP，并少经过一级流水线
  • N2/V2 将容量从 V1 的 3K 缩至 1536 MOP
    • 可能是在热点覆盖率、访问能耗和面积之间选择了更高的边际回报点
  • N3/V3 的官方优化指南不再描述 MOP-cache path，而是直接描述 Fetch→Decode→Rename→Dispatch
    • 一种可能解释是新前端通过更高效的直接 Decode、融合和队列组织满足供给需求，从而省去维护 I-cache 与 decoded-MOP cache 两份表示的面积和动态功耗
    • 但 Arm 没有直接公开是否“取消 MOP cache”

Decode

核心 常规 Decode MOP cache Dispatch 上限
N1 4 instructions/cycle 无 4 MOP / 8 µOP
V1 5 instructions/cycle 3K MOP，4-way skewed 8 MOP / 16 µOP
N2 未公开 1536 MOP，4-way skewed 5 MOP / 10 µOP
V2 6 instructions/cycle（次级来源） 1536 MOP，4-way skewed 8 MOP / 16 µOP
N3 未公开 官方优化指南未描述 5 MOP / 10 µOP
V3 未公开 官方优化指南未描述 10 MOP / 20 µOP

Dispatch

产品线 第一代 第二代 第三代
N 系列 N1：4 MOP / 8 µOP N2：5 / 10 N3：5 / 10
V 系列 V1：8 MOP / 16 µOP V2：8 / 16 V3：10 / 20
  • N2 相比 N1 将 dispatch 提高 25%，N3 保持不变
  • V1 的起点就是 N1 的两倍，V3 又在 V2 基础上提高 25%
  • N 系列把 5 MOP/10 µOP 视为较合理的 PPA 平衡点；
  • V 系列持续提高峰值供给，以匹配更宽的执行后端。

峰值 dispatch 不等于任意指令流都能达到相同吞吐:

  • N3/V3 优化指南列出了按 µOP 类型划分的 dispatch constraints
    • 分支、简单整数、多周期整数、向量和 load/store 各自仍有数量限制
    • 更宽 dispatch 的价值在于减少混合指令流的结构冲突，并为“一条 MOP 拆为两个 µOP”和融合指令留出带宽

乱序窗口与执行后端

ROB

  • N1 128、V1 256、V2 320；N2/N3/V3 未公开

更大的 ROB 能跨越更长的依赖链、cache miss 和分支之后寻找独立指令，使更多执行管线保持忙碌，并提高 Memory-Level Parallelism（MLP）。其代价也不只是 ROB SRAM：还需要更多物理寄存器、rename 状态、分支 checkpoint、调度项和恢复带宽；错误推测时还会消耗更多无效能量。

因此，V 系列的更大窗口与单线程性能目标一致，而 N 系列没有理由无条件复制这种规模。对高核数 SoC 而言，每核节省的窗口和调度面积可以转化为更多核心、更低功耗或更多系统级资源。

Issue pipelines

参数 N1 V1 N2 V2 N3 V3
Issue pipelines 8 15 13 17 13 21
整数管线 3 4 4 6 4 8
分支管线 1 2 2 2 2 3
FP/ASIMD pipes 2 4 2 4 2 4

Issue-pipeline 数量表示不同类型 µOP 的总接收槽，不等于任意 21 条指令都能在 V3 同时执行，也不能直接写成“21 IPC”。实际吞吐仍受端口功能、依赖、dispatch constraints、寄存器端口、cache bandwidth 和具体指令吞吐限制。

  • N2/N3 都保持 13 条 issue pipelines、4 条整数、2 条分支和 2 条 FP/ASIMD，说明 N 系列的主要策略不是持续堆宽后端

  • V1→V2→V3 的 15→17→21 则主要来自标量和控制流资源增长：

  • V1/N2/N3 为 4 integer + 2 branch；

  • V2 增至 6 integer + 2 branch；

  • V3 增至 8 integer + 3 branch。

  • 增加简单整数 pipelines 可以减少加减、逻辑、比较和地址相关运算之间的端口争用，这些操作正是数据库、编译器、解释器、Web 服务和控制密集代码的主体

  • 多周期整数 pipelines 没有同比复制，是因为乘除、CRC 等操作频率较低且单元成本更高。

  • 分支执行 pipelines 从 N1 的 1 条增至 2 条，使高分支密度代码或展开循环不容易受 branch-execute 端口限制；V3 增至 3 条则与 10 MOP/20 µOP dispatch 和更宽整数后端配套。不过更多 branch pipes 只有在预测正确、前端持续供给时才有意义，不能替代预测准确率。

Load/Store pipelines 趋于稳定

  • N1 使用两条 combined load/store pipelines
  • 从 V1 开始，各代都达到 3 条 load-capable 和 2 条 store-address 能力，典型组织是两条 Load/Store 加一条 Load-only；V3 对管线做了进一步拆分，但峰值功能数量仍是 3 load + 2 store address。

新增 load-only 路径符合服务器程序通常读多写少的特点：它用小于复制一条完整 L/S 管线的成本提高 load 并行度，同时保留两条 store-address 能力。此后数量不再增长，可能说明三个 load 地址与两个 store 地址已经覆盖常见循环，继续扩张会受到 L1 端口、DTLB、load/store queue 和内存依赖预测的限制。

V3 虽然没有增加表面数量，却把第二条 store-address 从共享路径中进一步拆出。这种变化更可能用于减少 load 与 store-address 对同一 issue pipe 的争用，提高调度自由度，而不是简单增加内存带宽。

Store Data Pipes 不能和 issue-pipeline 数机械相加。部分 FP/ASIMD 管线同时承担 vector store-data µOP，反映的是端口共享和指令分类，不等于物理上存在同样数量的独立 cache 写口。

FP、ASIMD、SVE 与 SVE2

从 ASIMD 到 SVE/SVE2

核心 ISA 实现向量长度 峰值向量数据通路
N1 ASIMD 128b 2×128b
V1 SVE 256b 2×256b SVE 或 4×128b ASIMD
N2 SVE2 128b 2×128b
V2 SVE2 128b 4×128b
N3 SVE2 128b 2×128b
V3 SVE2 128b 4×128b

V1 首次引入 SVE，两个 256b pipelines 把 N1 的向量计算带宽翻倍，面向 HPC、科学计算和 ML。SVE 的 vector-length-agnostic 编程模型允许软件按实现向量长度执行，并通过 predication 减少循环尾部处理。

N2 起采用 SVE2。SVE2 将适用范围从 HPC/ML 扩展到 DSP、multimedia、computer vision、通信、加密和更广泛的通用软件。N2/N3 使用 2×128b，V2/V3 使用 4×128b，表明 ISA 是否存在不是 N/V 的主要差别，总向量吞吐和执行端口数量才是。

N2/N3 的 2×128b 是性能、面积、功耗和核心密度的折中。Arm 对 N2 的官方描述也明确指出，其 vector bandwidth 比 V1 更适度，以维持 balanced core 和高 power/area ROI。

V1 的 2×256b 到 V2/V3 的 4×128b 不代表峰值 vector bits/cycle 倒退：二者名义上都是 512b/cycle。四条较窄管线能同时接收更多独立的 128b ASIMD/SVE2 操作，更适合云、crypto、压缩和 ML 中细粒度且混合的 SIMD。它还可能减轻 256b 数据通路的布线、旁路和时序压力，但 Arm 没有公开把 PPA 作为更改 vector length 的直接原因，因此后一点属于推断。

相同的 512b/cycle 也不意味着所有程序性能相同。V1 一条 SVE 指令处理 256b；V2/V3 一条处理 128b，要填满四条管线必须有足够的独立 µOP、寄存器和数据供给。SVE 的可伸缩编程模型保证功能可移植性，不保证不同实现向量长度具有相同吞吐。

Cache 与访存子系统

L1：长期维持 64KB/4-way 和 4-cycle

N1、V1、N2、V2、V3 的 L1 I-cache/D-cache 都是 64KB、4-way；N3 提供 32KB 或 64KB 选项。所有核心均使用 64B cache line，L1 D-cache load-to-use 均为 4 cycles。

L1 没有随执行宽度同比扩大，说明访问延迟、多端口复杂度和能耗比容量更关键。L1 位于 load-to-use 关键路径，扩大容量或相联度会增加 tag comparison、布线和端口成本。Arm 把主要容量增长放在 L2，可以在扩大工作集覆盖的同时守住 4-cycle L1 hit。

N3 提供 32KB/64KB L1 选项，体现 N 系列的配置弹性：

  • 小 L1 降低每核面积和漏电，适合高核心密度、网络或 edge SoC；
  • 64KB 适合工作集更大的服务器实现；
  • V3 固定 64KB，更符合高单线程性能目标。

64B cache line 长期不变则属于系统级兼容性选择。Cache line 同时影响一致性粒度、false sharing、内存 burst、预取和软件调优；改变它会牵动 DSU/CMN、内存控制器和软件生态。

私有 L2：V 系列增容，N 系列扩大配置范围

核心 私有 L2 Load-to-use latency
N1 256KB / 512KB / 1MB 未公开
V1 512KB / 1MB 10 cycles
N2 512KB / 1MB 未公开
V2 1MB / 2MB 10 cycles
N3 128KB / 256KB / 512KB / 1MB / 2MB 9 / 10 / 11 cycles
V3 2MB / 3MB 10 / 12 cycles

V1→V2→V3 的最小 L2 容量从 512KB→1MB→2MB，是以面积换单线程命中率的明确方向。更宽的 dispatch、更多执行管线和更大的乱序窗口会更快地产生并发访存；如果私有 L2 太小，后端扩宽会因频繁访问更远层级而失去收益。

V3 的 3MB L2 使用 12-way，并把 load-to-use 从 2MB 配置的 10 cycles 增至 12 cycles。这是容量、冲突 miss 和延迟之间的显式交换：

  • 2MB/10-cycle 追求更低命中延迟；
  • 3MB/12-cycle 覆盖更大的数据库、HPC 或 AI 工作集。

N3 则提供从 128KB 到 2MB 的五档 L2。较小配置可追求密度和 9-cycle 延迟，1MB/2MB 配置可提高服务器工作集命中率。其重点是覆盖更宽的 PPA 空间，而非只提供最高单线程性能点。

所有这些 L2 都是每核私有。私有 L2 与不使用 SMT 的组合，让一个软件线程独占核心侧缓存资源，有助于减少同核资源竞争、提高性能隔离并降低云环境中的 tail-latency 波动。共享 L3/SLC 则属于 DSU、CMN 或客户 SoC，不是 CPU core 的固定参数。

L1 D-cache 数据通路

核心 整数侧读路径 向量侧读路径
N1 2×128b（未按整数/向量拆分） 2×128b
V1 未按整数/向量拆分 1×128b + 2×256b
N2/N3 3×64b 3×128b
V2/V3 4×64b 3×128b

V1 的两条 256b read paths 是 2×256b SVE 的直接配套，否则宽向量执行单元会长期等待 L1 数据。

从 N2/V2 开始，Arm 分别公开整数和向量接口。V2/V3 比同代 N2/N3 多一条 64b integer read path，正好对应更宽的整数后端。第四条读路径也意味着更多 SRAM port、布线、DTLB bandwidth 和旁路资源，因此更容易在追求单线程性能的 V 系列证明其面积/功耗合理性。

N2、V2、N3、V3 的向量侧接口都为 3×128b read + 2×128b write，但 V 系列有四条 FP/ASIMD pipes，N 系列只有两条。这说明 V 系列更适合具有数据复用和较高算术强度的向量代码；对于单纯流式、低复用 workload，L1 接口可能先于四条向量执行管线成为约束。

TLB：V3 扩大最近级，N3 按页大小分工

核心 L1 ITLB L1 DTLB L2 TLB
N1 48 48 1280 / 5-way
V1 64 40 2048 / 8-way
N2 48 44 2048 / 8-way
V2 48 48 2048 / 8-way
N3 32 48 1536/6-way small-page + 256/4-way medium-page；另有 reduced-area 配置
V3 128 96 2048 / 8-way
  • V1/N2/V2/V3 的 L2 TLB 容量基本稳定在 2048，反映大型虚拟地址空间、虚拟化和两阶段地址翻译的重要性提高。更大的 L2 TLB 降低 page walk 频率，避免 TLB miss 触发多次页表内存访问。
  • V3 把 L1 ITLB/DTLB 大幅增至 128/96, 扩大最近级 TLB 比单纯增加 L2 容量更有利于高单线程性能，因为更宽的前端和更多 load pipes 对 translation latency 更敏感
    • ITLB 扩张幅度尤其大，可能针对大型 server binary、JIT、数据库和 AI framework 的 instruction footprint 以及跨页指令预取
    • 增大 L1DTLB 对跨页预取也有一定的帮助
  • N3 采取不同组织：
    • small-page TLB 保存 4KB/16KB/64KB terminal translations，标准版 1536 entries/6-way，reduced-area 版 1024/4-way；
    • medium-page TLB 保存 2MB/32MB/512MB block translations，共 256 entries/4-way；
    • L2 TLB 还包含 walk-cache functionality。

按页大小拆分可以避免大页条目与大量 4KB translation 完全争用同一资源，并允许 reduced-area 实现缩小常用页表结构。它与 N3 的可选 L1/L2 容量共同体现了体系化的 PPA 配置能力

Outstanding transactions：用更多状态覆盖外部延迟

N1 发布材料给出的 68 in-flight loads、72 in-flight stores 和 46 outstanding system transactions

TRM 给出的对外 outstanding read/write capability 为：

核心 Outstanding read Outstanding write 说明
N1 22 / 34 / 46 22 / 34 / 46 随 TQ 配置变化
V1 68 / 76 / 84 / 92 68 / 76 / 84 / 92 随 TQ 配置变化
N2 48 / 56 / 64 48 / 56 / 64 随 TQ 配置变化
V2 92 92 对称配置
N3 62 124 明显偏向 write
V3 92 92 对称配置

N1→V1 的显著扩张是更大 ROB、更多 load/store address pipes 和更宽 SVE 的配套：后端能产生更多 cache miss，就必须有足够 TQ 和外部 transaction state 才能避免新增执行资源在长延迟访问期间闲置。

V2 的 92/92 高于 N2 的最大 64/64，也符合 V 系列重视单线程 MLP 的定位。N 系列可以通过更多核心隐藏系统级延迟，V 系列则需要单个线程同时跨越更多独立 miss。

N3 的 62-read/124-write 是非对称设计，可能用于吸收 write burst，避免 store backpressure 阻塞流水线，并适配 networking、memory copy 等写流量较高的场景。但 Arm 没有公开将这一配置归因于某一具体 workload，因此只能视为推断。

每核单线程

表内所有 N/V 核心均为 1 thread/core。Arm 对云平台的解释是：凭借较高能效，可以用完整物理核心替代依赖 SMT 提高利用率的逻辑线程；每个线程独享核心和私有 L2，从而得到更一致的性能、更线性的扩展和更少的同核资源共享。

其根本逻辑是以核心密度换取可预测性：

  • 云租户不需要和同核 SMT sibling 竞争 ROB、scheduler、cache 和执行端口；
  • 安全隔离更简单，跨线程侧信道和资源干扰面更小；
  • tail latency 对共享资源状态不那么敏感；
  • SoC 厂商可以通过增加物理核心数获得 socket throughput。

ISA: Armv8→Armv9→Armv9.2

  • N1 以 Armv8.2-A 为基础；V1 加入更多 Armv8.3～Armv8.6 能力和 SVE。
  • N2/V2 进入 Armv9.0-A，引入 SVE2、Memory Tagging Extension（MTE）等基础设施能力。
  • N3/V3 进入 Armv9.2-A，并取消 AArch32 EL0，只保留 AArch64。
  • V3 进一步支持 Arm Confidential Compute Architecture/Realm Management Extension，服务机密虚拟机和多租户数据中心。

取消 AArch32 可以减少验证、异常处理和前端兼容逻辑的长期负担，使设计资源集中到服务器实际使用的 AArch64；代价是不能再原生运行 32-bit 用户态代码。这种取舍在成熟服务器生态中比客户端或兼容性优先的平台更容易接受。

参数变化背后的整体设计方法

持续前端供给

扩宽 dispatch 或增加 issue pipelines 只有在分支预测、I-cache、ITLB、ROB、寄存器、L1 data paths 和 outstanding transactions 同步增强时才有价值。Neoverse 的变化通常成组出现：

  • V1 同时扩大预测、MOP cache、ROB、issue、SVE 和 memory transaction capacity；
  • V2 在 dispatch 不变时，扩大 BTB/TAGE、fetch queue、TLB/cache bandwidth 和整数后端；
  • V3 同时增加 dispatch、issue、整数/分支管线、L1 TLB 和私有 L2。

参考资料

N1:

V1:

N2:

V2:

N3:

V3: