前言
近年来，纵使摩尔定律已死的论调甚嚣尘上，处理器性能还是迎来了一波爆发式增长；适逢DSA的黄金时代，巨头们对于自研微架构的热情空前高涨。众多因素加持下，处理器新秀们如雨后春笋般层出不穷。华为作为世界舞台的顶级玩家之一自然不会错过这场盛宴。在海思麒麟的光芒下鲲鹏系列并不为多数人所知，但它的故事早在2016年就由鲲鹏916拉开了序幕。时至2019年，第一颗7nm数据中心ARM处理器鲲鹏920翩然而至，将鲲鹏系列带上了台前。然而让人意想不到的是，仅仅4个月后华为就遭受了来自大洋彼岸的制裁。正值一飞冲天之际的鲲鹏横遭折翼之祸，令人唏嘘不已；此后就只能从学术会议中窥见鲲鹏系列的车尘马迹。如今回望，鲲鹏920究竟几何，我们这次就来探究TSV110的微架构。
基准测试
在这一部分我们使用SPEC06、SPEC17、Coremark以及Verilator对处理器进行测试。注意，我们并不执着于fine-tune以获得某一微架构的最高分数；而是以合理、统一的编译参数带来可比的分值数据。SPEC06、SPEC17等的分值受系统环境、编译器版本、编译参数、BIOS调教、频率稳定性、具体SKU的Cache配置、具体平台的内存参数等因素影响巨大，且无法通过任何简单线性缩放进行分数推演。
频率
在UOS下鲲鹏920的稳定运行频率为2.6GHz，以下测试都基于2.6GHz的频率进行。
SPEC06
SPEC06是已经退役的SPEC测试集但是仍然被广泛使用；其负载特性与SPEC17并不相同，因此仍然具有相当的测试价值。
我们再次请出A76、A78这两款处理器作为参考对象。A76和TSV110可谓同期生，相互参照最为合适不过；而A78则是2年后的来人，用来一窥前两者与当今同定位处理器的差距。在绝对性能上TSV110落后于A76、A78，但是仔细观察子项分数我们很快发现一些异乎寻常的现象。TSV110的整数分数其实与A76并驾齐驱，但是一来到浮点侧便马失前蹄。TSV110在所有侧重内存带宽的子项上都表现欠佳，其单核的访存带宽应该是偏低的。TSV110在大部分侧重预取器表现的子项上都表现普通，甚至在SPEC06中唯一一个rate 1激进预取负效果子项上得分反超了A76，不禁令人怀疑TSV110的硬件预取器并未fine-tuned，抑或是被人为限制了预取激进度（因为鲲鹏920主攻服务器市场，过于激进的单核预取会导致全核负载时片上系统压力过大，最终总吞吐量不升反降）。后续的测试也会部分印证这些猜想。TSV110羸弱的浮点、向量性能不仅来自于访存子系统的掣肘，延迟过大的运算器设计、相对较小的浮点乱序队列规格也难脱其责。总体而言，TSV110的SPEC06 int表现在当时的ARM阵营堪称优秀，但是fp表现与A76等相去甚远，导致最终总分不及同期生A76。
SPEC17
SPEC17是现役的SPEC测试集，被广泛用于微结构性能评估。
SPEC17测试中三款处理器相对表现的结论没有变化，整数方面TSV110紧追A76，浮点方面则被远远甩开。TSV110在520.omnetpp中超越了其他两款处理器，让人怀疑其数据预取器是否在工作（该子项容易因为预取而失分，stream预取器尤为容易造成负效果）；再结合stream成绩、503.bwaves的成绩、549.fotonik3d的成绩，我合理怀疑TSV110根本没有配备stream预取器（L1中）。种种奇怪的现象都指向了TSV110对单核访存带宽、浮点吞吐的不重视，这究竟是出于目标负载刻意为之还是设计周期紧张没能面面俱到，我们不得而知。
Coremark是一款嵌入式基准测试程序，其受下级Cache子系统、内存等的影响极小，主要考察核内流水线以及L1 Cache的性能表现。
更为古老的A75受制于后端执行单元规格（只有2组ALU）落后于其他两款CPU；后端规格相近的TSV110与A76都在-O2编译时超过了7分。TSV110与A76的差距来自流水线前端和midcore部分，鲲鹏还需追赶（比如TSV110较为离谱的4周期延迟整数乘法器）。不过换个角度来说，自研的TSV110相较当时的上一代公版产品有了坚实的进步已经十分优秀，只是公版产品线的A76进步更为惊人而已。
Verilator
以上三款测试集对处理器的前端压力较小，仿真大规模设计的verilator则恰恰相反，海量的分支与数MB的代码足迹能够轻松压垮ICache、BTB等组件，导致巨大的性能下滑。
在这一项目中TSV110的表现出奇得差，一度让我怀疑二进制出现了问题。一开始的怀疑方向是，TSV110这样的早期微结构BTB规格不足造成了海量分支误预测，进而影响了verilator负载的性能。但是在perf考察后我们发现其分支误预测率仅2.4%，因此并不是和Zen3一样的BTB瓶颈问题。在考察ICache miss率后我们发现了问题的症结，即便在4线程verilator下TSV110仍然经历了8.52%的ICache miss率。这是典型的没有直达ICache的指令预取的表现；当然考虑到TSV110极其保守的数据预取表现，L1的指令预取也可能存在但显然没有发挥理想的效果（甚至到L2的指令预取也可能没发挥理想的效果）。
考虑到鲲鹏920的ringbus互联和4核核心簇的设计，我们还尝试了更多的线程分布。我们发现将4个线程全部置于一个核心簇时反而无法获得最佳成绩，这一点让人十分困惑。最佳成绩出现在将4个线程中的2个分别置于相邻核心簇中，是否是因为4核同时高强度取指时单个核心簇的出口带宽不够呢？总体而言TSV110似乎不能胜任verilator这样的大前端压力任务。
前端
随着现代程序体量的膨胀，处理器面临越发巨大的前端压力；为了应对庞大的程序代码段带来的海量跳转指令，大部分高性能处理器核的BTB容量、分支预测器容量不断扩展，相关算法也在不断演进。
BTB
对于采用了分离式前端（英文表述：decoupled branch prediction更为准确）的设计而言，BTB是前端的绝对核心组件；其负责在译码前识别指令流中的跳转指令并提供相应的跳转目标地址，频繁的BTB miss会造成严重的性能损失。对于没有采用分离式前端的设计而言，BTB也要负责尽快给出跳转目标地址，减少取指流水线的空泡，保证取指带宽。
TSV110的BTB图像令人困惑。首先，我们可以清晰地辨认出64项的L1 BTB，但是L1 BTB似乎不能很好得处理cache行内密集的分支，这一点与ARM A78、X1类似。我们使用更细的粒度测试图像的前段空间：
结果似乎暗示了L1 BTB的某种内部组织结构，但64项的L1 BTB完全可以用全相联CAM实现。这让人不禁怀疑L0 BTB的存在，倘若存在其容量约为8项。当然，另一种可能是TSV110的L1 BTB并非按照基本块组织，而是按照cache行组织；每个表项（1个cacheline）最多存储4条分支，因此一旦cache行内分支密度超过每四条指令一条分支就会造成L1 BTB有效容量急剧下降。一旦越过L1 BTB的容量，最密集的分支分布（全是分支和每两条指令一条分支）丢失了所有来自BTB的帮助。
其次，从verilator性能测试来看TSV110的分支误预测率偏低；倘若使用了分离式前端，仅仅1024-2048项之间的BTB容量不足以支撑如此高的准确率，因此TSV110大概率仍然采用了传统前端设计。我们使用针对传统设计的思路来解读后半段图像：
- 可能1:TSV110的取指流水级较短，则不存在L2 BTB。分支数量超过64后就需要从ICache中取指并预译码才能获得分支指令信息，获得分支指令信息后才能修正执行流；这带来了较大的延迟损失，也是传统非分离前端设计的弊端。但这样的设计也并非没有优点，借助较大的ICache，TSV110无需配备独立的巨大下级BTB，省下了宝贵的片上空间并减少了功耗。但是这似乎无法解释其糟糕的高密度分支场景表现。
- 可能2:TSV110的取指流水级特别长，则存在一个～2048项的L2 BTB。分支数量超过2048后同上。
不过无论是可能1还是可能2，TSV110的前端即便在传统前端设计中也算不上优秀，处理密集分支时的糟糕表现十分奇怪，也许是受到了过多的面积和功耗制约。
RAS
指令流中的call、return调用是较为特殊的分支指令情况，其栈形式的特征催生了专门用于预测此类场景的RAS（Return Address Stack）。简而言之，call指令压栈，return指令弹栈；而硬件栈（RAS）结构的深度就影响了处理器在复杂函数调用场景中的性能表现。
TSV110的RAS展现了一些独特的行为。
- 坏的方面：其似乎不能很好得处理对同一函数的嵌套调用，在call return指令对中夹杂条件分支后，RAS提前耗尽了容量。
- 好的方面：在该场景中，RAS容量耗尽后整个分支预测系统并没有崩溃，似乎由BTB完美接替了RAS的工作。
虽然在RAS理应管辖的范围内TSV110的表现逊于其他处理器，但当调用深度超过RAS深度很多后TSV110的表现优于其他处理器，这是我们在其他处理器核上没有观察到过的现象。
将测试改为使用不同的函数，TSV110真实的RAS容量由此显现。可见其RAS容量为32项，是时至今日也绰绰有余的容量。此时我们发现TSV110的RAS溢出后并没有做栈顶的恢复或有效的清空，导致一旦发生超过32深度的调用整个RAS就会失效（由于此处换用了不同的函数，BTB无法再有效接管所有工作了）。相对地，A76、A78在回滚后对栈顶做了恢复，icestorm则在回滚后做了其他形式的修正（诸如有效的清空）。
RAS CapacityTSV11032Icestorm32A7616A7816Gracemont2？(甚至可能没有传统意义的RAS)Zen432
BP
分支预测器是当代高性能处理器前端中的又一核心组件，负责在流水线早期给出分支指令跳转与否的猜测，引导指令流的方向。在推测执行的超标量处理器中，分支预测器的准确率会极大影响处理器的性能和能效表现。
本测试考察分支预测器在不同历史pattern长度、不同分支数量（需要预测）情况下的准确性表现。TSV110的分支预测器表现可圈可点。
- TSV110分支预测器的等效有效容量比肩A76。在分支较多时，TSV110能追踪更长的历史；在pattern长度较短时，TSV1100能够追踪更多的分支。
- TSV110似乎使用了相对较短的分支历史，即便在分支数较少时也无法追踪超长历史。当然，这也可能是主预测器内部hash冲突的结果。
IJP
IJP（Indirect Jump Predictor）作为BP（Branch Predictor）的一部分，负责预测间接跳转的地址。与预测跳转与否的BP不同的是，IJP需要在多个可能的跳转目标中选择本次的跳转目标，并引导指令流。
首先考察TSV110的IJP在不同历史pattern长度（但是可能目标均只有2个）、不同间接跳转数量（需要预测）情况下的准确性表现。我们惊讶地发现常用的测试写法下TSV110近乎完全无法做出有效预测。为了照顾部分早期处理器，我们默认使用的测试在间接跳转指令间插入了条件直接跳转，因为部分早期处理器的IJP与BP使用同一份分支历史，其中没有纳入间接跳转的地址bit，倘若不插入条件直接跳转就无法有效区分间接跳转目标的变化。TSV110的情况却反了过来，换用未插入条件直接跳转的测试得到结果如下：
TSV110的IJP表现恢复正常：
- TSV110的IJP追踪历史的能力略逊于A76。
- TSV110的IJP与BP一样，都没有明显的Cascading特征。
- 由于测试代码PC是2的幂次对齐，TSV110的IJP在某些排布下似乎出现了hash冲突，有许多细碎的性能波动。
接下来考察TSV110 IJP在不同可能跳转目标、不同间接跳转数量（需要预测）情况下的准确性表现。在这一场景中TSV110的行为与之前的测试完全相反。
- 如果使用没有插入条件直接跳转的测试，那么TSV110的表现与Icestorm相像，都很糟糕。一旦可能目标增多，IJP就无法正确预测跳转目标。结合分支数量变多后IJP立即失效的现象看，IJP自身的表项容量似乎被配置得极少，不过考虑到一般指令流中间接跳转并不多见，这样的取舍也可以理解。
- 如果使用插入了条件直接跳转的测试，那么TSV110的表现会大幅好转，但是绝对性能上仍然落后A76甚远。难道TSV110 IJP使用的历史也没有混入间接跳转目标地址？
在IJP的两项测试中TSV110表现出了相互矛盾的特性，让人费解。不过可以肯定的是，TSV110的IJP能力不强。
ITLB
TLB是现代处理器中容易被忽视的一个部件，其负责虚拟地址至物理地址的翻译。在一般情况下TLB并不会成为瓶颈，但是随着现代程序体量的膨胀TLB承受的压力也与日俱增，这一点在服务器负载中尤为明显。
TSV110的ITLB容量为～48项，取指时可以访问的L2 TLB容量为1024项。TSV110的取指侧TLB规模与A76、A78相当，大于Icestorm。不过需要注意的是，访问延迟的上涨点较为靠前，也许预示着某种特殊的替换算法或初级的TLB预取。
ITLB CapacityL2 TLB(for instruction) CapacityTSV110481024Icestorm32256A78481024A76481024
取指
处理器对程序的执行始于取指，前端的指令供给能力至关重要。一旦前端无法提供足够的指令，纵使后端的乱序执行能力再强也无力回天。对于TSV110这样的四发射处理器，我们期望其每周期能够取指至少4条指令。
TSV110没有配备mop cache。我们可以看到指令足迹在64KB以内时由ICache供指，取指带宽为4条/周期；这样的带宽在分支较少时是完全够用的，但无法与配备了mop cache的处理器比肩（例如A78的mop cache供指带宽为6条/周期）。当执行流来到L2 Cache以后取指带宽骤然下降至1.75条/周期，可能预示着ICache较小的Refill通路位宽。与A78和Icestorm不同的是，TSV110并没有限制代码段可以占据的L2 Cache容量，指令可以使用近乎全部的L2空间。当指令流进入LLC与内存段后取指带宽彻底雪崩，仅剩0.25条/周期或更低。这样的取指能力在现如今是偏低的，面对大指令足迹的程序会非常捉襟见肘（如verilator）。
A78的mop Cache对于nop指令进行了压缩优化；倘若使用nop指令测试取指，mop cache每周期能够供给超过10条指令；TSV110没有配备mop cache，自然也没有此类优化。
后端
处理器的后端负责指令的执行，当代高性能处理器普遍配备了乱序超标量机制，后端的设计也是纷繁复杂。
流水线宽度
在超标量处理器中我们着重关注前端与mid-core部分的宽度。
流水级宽度Fetch(ICache)4Fetch(mop Cache)no mop CacheDecode4Rename4
TSV110能够提供的最大取指带宽为4条指令/周期，后续的重命名级与译码级和取指宽度一致，因此TSV110是最大吞吐为4条指令/周期的典型4发射处理器核。
执行单元
执行部件数量延迟ALU31BRU2MUL14DIV119（支持提前退出）AGU(ld+st)2AGU(ld)24AGU(st)1FPU2FADD24FMUL25FDIV117FMA27
与Icestorm、A76类似，同样是4发射的TSV110也只配备了3组ALU。简单ALU并不占据过多的面积，难度来自于物理寄存器堆读写端口的设计（这在更宽的处理器上会更加棘手）。TSV110的复杂整数单元单独占据了一个发射端口，这在现如今的设计中并不多见，因此TSV110可以说是3ALU+1MDU的设计（也可以说是4ALU，只是其中一个无法执行简单运算操作）。TSV110配备了2组BRU，在密集跳转应用中能够保证吞吐量，符合现代应用程序发展的趋势；事实上，配备2组BRU已经成为当今处理器核设计的惯例。乘除法单元上方面，TSV110只配备了1组；其乘法器延迟较大，除法器算法也较为普通；除法器支持提前退出，当被除数变为0时算法可以提前结束。
TSV110拥有2个AGU（访存地址生成单元），但AGU load与AGU store并非全分离式设计；2个AGU中1个支持load/store操作，1个只支持load操作。对于一款4发射处理器而言，这样的访存单元配置较为常见，但略微落后于某些4发射处理器，它们会配备全分离的load、store AGU或是2组AGU load/store。在memory wall越发明显的趋势下，重访存也是我个人十分欣赏的设计哲学；但是我个人更喜欢Intel式的AGU load与AGU store分离的设计，不过这也会显著增加发射队列、物理寄存器堆设计的复杂度，恐怕这也是其他设计公司都未完全分离load与store AGU的原因。
TSV110配备了两组浮点执行单元。其FMADD延迟非常高，需要7个周期；FADD延迟较高需要4个周期；考虑到TSV110本身的目标频率并不算高，这样的成绩较差。虽然对于浮点性能来说吞吐量至上，但是这些堪称离谱的浮点部件延迟难免要为TSV110较低的浮点性能得分负一部分责任。浮点部件的打磨考验设计公司的综合能力，但是过高的延迟反映了TSV110在设计时没有给予浮点单元必要的尊重。
总体而言TSV110的后端执行单元配置严重偏向整数和分支指令，浮点部分非常薄弱，访存部分较为标准。
幕间
在下篇中我们将对Mid-core、访存子系统、核外系统进行逆向探究。
分析与测试：lyz、lxy
以下是文章的深度解读与分析，探讨该微架构的优缺点及其潜在的改进方向
1. 背景与定位
1.1 鲲鹏系列的起源
鲲鹏系列处理器作为华为布局高性能计算的核心产品，早在2016年由鲲鹏916首次亮相。2019年，鲲鹏920发布，成为首款采用7nm工艺的ARM架构数据中心处理器。鲲鹏920的设计目标主要集中于云计算、大数据分析和虚拟化场景。
尽管华为的自研处理器因地缘政治制裁蒙上一层阴影，但鲲鹏920及其TSV110微架构的技术价值依然不容忽视。
2. TSV110微架构评测
2.1 SPEC基准测试分析
2.1.1 SPEC06：整数表现优异，浮点略显不足
SPEC06作为传统评测工具，依然具有一定的参考价值。在测试中，TSV110表现出以下特点：
- 整数性能：与ARM Cortex-A76核心相当，表现出色。
- 浮点性能：落后于A76，主要原因在于浮点运算单元延迟较高（如FADD 4个周期，FMADD 7个周期）以及乱序队列资源较小。
- 访存性能：单核访存带宽不足，且硬件预取器表现保守，对依赖带宽的任务支持有限。
2.1.2 SPEC17：对预取优化需求明显
SPEC17测试中，TSV110在整数任务中表现紧追A76，但浮点任务仍显弱势。部分子测试（如520.omnetpp）显示出数据预取器的限制，可能缺乏流式预取机制，导致在复杂浮点计算任务中失分。
2.2 前端性能解析
2.2.1 分支预测与BTB设计
TSV110的BTB（Branch Target Buffer）设计为64项，可能存在L1 BTB条目按缓存行组织的情况，影响了高密度分支任务的处理性能。此外：
- 分支预测器容量：与A76相当，但表现出对长历史模式支持不足。
- RAS（Return Address Stack）：支持32层调用深度，但对嵌套调用的处理能力不佳。
2.2.2 指令缓存与取指能力
- ICache设计：取指带宽为4条指令/周期，在L1阶段能保证较高的吞吐量，但进入L2 Cache后取指带宽下降至1.75条/周期。
- mop Cache的缺失：TSV110未配备指令压缩缓存（mop cache），导致指令密集型任务的取指效率较低。
2.3 后端与执行单元分析
2.3.1 执行单元配置
- 整数单元：3个ALU和1个复杂整数单元，符合4发射核心的常规配置。
- 浮点单元：浮点运算单元数量与性能显著落后于同代ARM核心（如A76）。
- 访存单元：2个AGU（地址生成单元），支持负载和存储，但未完全分离，限制了高访存任务的吞吐能力。
2.3.2 性能权衡
整体来看，TSV110的后端设计更倾向于优化整数任务和分支密集型场景，而对浮点性能和访存任务支持不足。
3. 技术挑战与改进建议
3.1 硬件层面改进
-
优化预取器设计：
- 增加流式预取器支持，提升浮点密集型任务性能。
- 改善指令预取器，使大代码足迹任务（如Verilator）能够高效执行。
-
增强执行单元：
- 提升浮点单元吞吐能力，降低延迟（如将FADD延迟优化至3周期以下）。
- 增加完全分离的访存单元（load/store AGU）。
-
改进分支预测机制：
- 扩展分支预测器容量，支持更长的历史模式和复杂分支跳转。
3.2 软件生态优化
-
编译器优化：
- 提供更高效的编译器支持，针对ARM架构进行优化。
- 增强对大页（Large Pages）和NUMA架构的支持。
-
软件栈适配：
- 针对主流数据库、大数据和虚拟化平台优化，以发挥鲲鹏920的并行处理优势。
4. 鲲鹏920的市场定位与未来展望
4.1 市场定位
鲲鹏920的设计目标在于满足云计算和数据中心的需求。其核心优势包括：
- 高核心数：适合并行任务和多线程场景。
- ARM生态：推动ARM在服务器市场的扩展。
然而，其在浮点性能和访存任务中的表现限制了其在科学计算和复杂虚拟化环境中的适用性。
4.2 未来展望
随着ARM生态系统的不断成熟以及华为在微架构设计上的持续投入，未来的鲲鹏处理器有望在以下领域实现突破：
- 提升单核性能，优化浮点与访存能力。
- 加强软件生态适配，推动企业级应用迁移至ARM平台。
- 进一步优化能效比，降低空闲功耗和多核负载下的能耗。
5. 总结
鲲鹏920的TSV110微架构在整数任务和分支处理方面表现出色，但在浮点性能、访存效率和指令前端能力上仍有明显的优化空间。这既是其设计权衡的结果，也反映了华为在ARM架构服务器处理器市场中的技术积累与探索。
未来，通过硬件优化和软件生态的双向支持，鲲鹏系列处理器有望成为云计算和数据中心的重要选择，为国内自主可控的计算生态奠定坚实基础。
分析与撰写：技术探索团队
发布日期：2024年11月