当芯片开始“堵车”，NoC面临新挑战

如果片上网络（NoC）没有针对在存储器和处理器之间传输的各种类型的数据流量进行优化，那么来自尖端人工智能加速器和多裸片（multi-die）架构的速度优势可能会丧失。

其中面临的挑战十分繁多，包括确定哪些数据流量需要保持一致性（coherent），确保在不同工作负载导致数据路径老化程度不均衡时，仍然留有足够的余量来重新规划信号传输路径，以及确保在合适的位置部署合适的互连协议。此外，工程团队还需要考虑热效应、噪声以及结构完整性将如何影响这些数据的传输。

NoC 在此发挥着关键作用。它们已经从相对简单的片上网络布局发展成为一个复杂的、分层的编排层，用于管理和维护异构系统在其预期生命周期内的数据流。

“NoC 的设计初衷是为了解决布线拥塞问题，但它面临的新挑战是如何在不考虑物理连接的情况下，实现跨裸片的连接，” Cadence公司芯片和IP解决方案高级产品营销总监Mick Posner表示，“系统的协议是什么？它看起来像一个单一的NoC吗？还是有两个，各自拥有独立的内存空间？这些都是需要解决的新问题。”

以前，NoC 并不关心芯片外部发生的事情，因为芯片外部通信通常是通过 PCIe 等标准协议进行连接的。““如今已经变成了裸片到裸片（die-to-die）互连，因此人们真正希望片上网络能够透明地扩展到多个裸片之间，这也催生了一个全新的创新领域，”Posner 说道，“例如，在英伟达 GPU 领域，Arm 希望成为与 GPU 配套的 CPU。那么，这个问题该如何解决？他们正在研究利用 AMBA CHI C2C（chiplet-to-chiplet）实现裸片间接口，而这是一种支持缓存一致性的接口，可以解决他们所面临的问题。”

验证一致性

一致性流量与非一致性流量的混合，是当前最具挑战性的课题之一。

Axiomise首席执行官 Ashish Darbari 表示：“如果一个一致性请求被重新排序到一个非一致性数据流之后，或者某个 credit 返回到了错误的虚拟通道（VC），这些问题在仿真过程中并不会表现为功能性错误。真正暴露问题的，往往是在几个月后的芯片上电调试（bring-up）阶段，以死锁（deadlock）的形式出现，而那时定位问题的代价已经极其高昂。NoC 架构师在单裸片（on-die）设计中对此已经非常熟悉。而如今真正的难点在于，随 chiplet 的出现，NoC 的边界已经移动到了封装边缘（package edge），在这里，时序、重试机制（retry semantics）以及错误处理方式都发生了根本性的变化。”

与 I/O 一致性相比，缓存一致性更难实现。“验证起来也更麻烦，因为存在更多难以发现的问题，” Synopsys 系统解决方案战略项目执行总监 Frank Schirrmeister 表示，“定义所有情况绝非易事。你必须对整个验证环境的构建方式保持极高的谨慎。”

过去几年，得益于近乎无限的计算能力，大规模多物理场仿真使得这种方案更容易实现，但也存在一些问题。Schirrmeister 解释道：“NoC 工具已经拥有所有输入信息，包括主设备（initiators）、目标设备（targets）以及它们之间的连接关系。首先从功能层面对其进行分析，再通过仿真进行验证，随后借助验证工具确定实际的时序情况。这就是所谓的物理感知部分，它由 NoC 供应商提供，也是我们面临的一大挑战——一致性相关功能验证。如果比较缓存一致性与 I/O 一致性的区别，你会发现，为了定义这些测试用例，从体系结构的角度来看，需要业内最优秀的专家共同参与。”

近年来，越来越多的相关工作已经提前到了设计流程的前端。“以前用户需要手动创建一个测试用例，而这种测试用例人工编写起来非常困难；现在，你可以让用户先向内存中写入一些数据，计算缓存中有多少数据，然后将其移动到另一侧，接着让运行在第二个核心上的软件访问同一内存区域，”Schirrmeister 说道。“然随后，再判断 NoC 内部的数据表示是否能够知道最后一个缓存项位于哪里，以及究竟是哪一个处理器持有最后一个缓存项。这是一个极其复杂而精细的过程。”

这种集成不同处理器并根据约束条件自动生成测试的方法，与 Portable Stimulus 的理念大体相似，但它并非基于 PSS（Portable Stimulus Standard）标准，而是专门针对缓存一致性问题进行了优化。

AI 迫使人们重视 I/O 问题

无论NoC 是采用 CPU 间缓存一致性连接，还是仅支持非一致性 I/O，都必须将其与 I/O 结合起来考虑。Arteris 产品管理和市场营销副总裁 Andy Nightingale 表示，“集成的 AI 越多，就越需要将 I/O 边界视为一级系统资源。带宽密度（bandwidth density）、延时确定性（latency determinism）、拥塞控制（congestion control）、服务质量（QoS）以及错误隔离（error containment）都已经成为体系结构层面的约束，而不再只是布局布线完成后才需要解决的问题。这正是可扩展片上互连架构（on-chip fabric）以及系统级互连方案发挥价值的地方。它们能够在大量终端节点之间提供可预测的连接，同时为工程师提供拓扑结构、缓冲机制、数据排序以及隔离等方面的可调节能力，使 I/O 数量的增加不会自动演变成系统混乱。”

图 1：Arm 缓存一致性验证设置示例。来源：Arteris

需要解决的问题领域非常庞大。它涉及大量的线路或物理线路，所有这些都需要在 No 和I/O的仿真中进行捕获和表征。

Synopsys产品管理高级总监Matt Commens表示：“从整体来看，互连设计本身并不算特别复杂，但规模庞大。计算机辅助设计本身并不难，因为通常采用的是较大的节点尺寸和较宽松的设计规则，但真正的问题在于信号线数量已经达到了惊人的程度。我们目前看到的关键词就是容量、容量、还是容量。客户希望对整个 chiplets 互连进行仿真，研究尽可能多的信号线，甚至全部信号线。我们已经听到不少公司的要求——每一条信号线都必须进行仿真。这当然可以做到，但仿真的规模通常会非常巨大。”

单个裸片或 NoC 可以在统一的功耗分布图（power map）以及理想边界条件下进行仿真。然而，这必须放到整个芯片乃至整个系统的运行环境中去考量。

Vinci半导体和电子业务市场战略负责人Satish Radhakrishnan表示：“由多个裸片和chiplets组成的系统具有相互叠加、空间分布式的功耗分布图，这些分布图之间存在热耦合。一个芯片的热活动会提高其相邻芯片的基准温度，全局热点未必对应任何单个芯片的局部最高温度。你不能简单地将各个独立芯片的结果相加。因此，必须捕捉串扰（crosstalk）以及相邻芯片和堆叠结构带来的影响。同时，还必须从整个系统的角度评估边界条件和散热方案，才能完整反映整个热传导路径。”

这就是传统仿真方法的局限性所在。Radhakrishnan解释道，“系统层面需要考虑的场景数量众多——包括不同功耗状态、不同堆叠结构以及不同边界条件——使得依赖专家逐个完成串行仿真的传统设计流程已经不切实际，能够在完整的芯片到系统堆栈范围内持续运行多物理场分析，并获得具有确定性且可重复的结果，将彻底改变体系结构冻结之前真正能够完成的评估工作。”

NoC 仿真是一项多物理场挑战

NoC 通常具有分布式热源，且热量具有瞬态特性，它们不仅取决于工作负载，还受到芯片及系统散热架构、是否采用各种散热方案等因素影响。同时，它们还受到封装内相邻裸片或机架内相邻芯片的影响，从而产生串扰、热噪声或衬底噪声（substrate noise）、电磁干扰，以及可能导致封装翘曲或将潜在缺陷演变为实际缺陷的机械应力。

Radhakrishnan 表示，“你不能孤立地分析某一个节点，并期望结果仍然成立。封装翘曲、低介电常数介质层开裂和分层也是由系统瞬态热负载引起的问题。更深层次的挑战在于，一个精确但速度慢的求解器可以回答一个物理问题，但 NoC 问题涉及一个庞大且充满不确定性的设计空间，其中包含大量瞬态、耦合、多尺度场景。要在体系结构最终确定之前，运行足够多的仿真案例来真正理解整个设计空间，就需要一种完全不同的计算吞吐模式。”

由于仿真同时在事务级（SystemC）和RTL级进行，因此它直接影响对真正周期精度性能瓶颈的测量能力。“SystemC或事务级模型（TLM）非常适合早期体系结构探索以及高层次性能权衡分析，”Axiomise公司的Darbari表示，“但如果要证明具有周期精度的微架构特性，例如精确的 Credit 行为、仲裁延迟（arbitration delay）、跨时钟域（CDC）安全性以及数据包传输过程，则必须依赖 RTL 层级的形式化验证（formal verification）。仿真侧的 VIP（Verification IP）主要用于性能分析以及定向测试，而形式化验证则必须承担穷举所有边界情况（corner case）的任务。这一点非常重要，因为许多真实的 NoC 缺陷都源于单周期竞争（single-cycle race）以及实现细节，而这些问题在事务级模型中根本无法观察到。一种平衡的方法应该是在体系结构研究阶段采用 TLM，而在实现签核（implementation signoff）以及瓶颈分析阶段，则结合 RTL 形式化验证与 RTL 仿真共同完成。”

形式化验证

形式化验证在发现跨协议边界情况（cross-protocol corner cases）状态空间中的缺陷方面，同样发挥着关键作用。“例如，UCIe链路状态、CHI snoop事务（snoop transactions）以及 NoC 仲裁等问题，并非仅靠模拟就能解决，”Axiomise公司的Darbari表示，“形式化验证可以证明 credit守恒（credit conservation）、无死锁性（deadlock freedom）、顺序属性以及每个接口的协议合规性（protocol compliance）。正是出于这个原因，我们一直在将形式化验证提前到仿真之前。一旦多裸片系统进入仿真阶段，再发现一致性或死锁问题，就很可能导致流片延期（tape-out slip）。”

先进的封装技术也带来了挑战。Darbari 表示：“EMIB（Intel 嵌入式多裸片互连桥）、CoWoS和混合键合技术对凸点间距、重布线层和热设计边界都提出了严格的要求。过去，团队通常把封装工作交给下游部门，但现在这种做法行不通了。2.5D和3D封装方案的选择会直接影响布局规划、供电网络，这对验证和确认有着重大影响，所以从一开始就必须考虑这个问题。”

此外，在验证 NoC 时，设计人员必须确保所选拓扑结构正确连接所有节点，并且数据包遵循预期的最短路径或自适应路径进行传输。

Darbari 表示：“形式化验证可以用于证明网格、环面或自定义拓扑中每个合法源-目标节点的结构连通性（structural connectivity）和可达性（reachability），而不是像仿真那样只抽样验证部分路由。这项工作可以通过连接性检查（connectivity checking）应用轻松完成，并且能够实现穷举验证。对于确定性最短路径路由，可以编写 SystemVerilog 断言（assertion）、属性（properties）和模型，使每一次跳转（hop）都能按照规范中定义的路由度量不断缩短路径，例如二维 Mesh 网络中的曼哈顿距离（Manhattan distance），同时始终保证数据包能够合法地向目标节点推进。对于自适应路由（adaptive routing），则可以对路由逻辑施加约束，并证明其只会在体系结构允许的最短路径或逃逸路径（escape paths）之间进行选择，从而保证所有自适应决策都不会违反路由策略，也不会产生不一致行为。利用基于对称性的状态空间约简（symmetry-based reduction）以及基于跳数（hop count）的数学归纳法，是使这些证明能够扩展到实际规模拓扑，而不仅仅局限于玩具模型（toy topologies）的关键技术。

流量控制机制，例如基于 credit 的流量控制，也必须经过验证，以确保在网络饱和状态下缓冲区不会发生溢出。Darbari 表示：“对于基于 Credit 的流量控制，可以通过证明所有正在传输（in-flight）的 Flit（流控单元）数量永远不会超过下游缓冲区对应的 Credit 配额或物理 FIFO 深度来完成验证。相关属性还必须保证 Credit 仅在存储空间真正释放时才返回，既不能提前返回，也不能丢失，更不能重复计数，因为 Credit 统计错误是许多潜伏 NoC 缺陷最常见的来源之一。这些证明可以在以网络饱和为前提的假设条件下完成，从而确保即使系统处于最大合法流量状态，也不会因为背压（backpressure）失效而导致缓冲区溢出、空读（underflow）或静默的数据包丢失（silent packet loss）。”

网络在发生故障（例如缓冲区错误或路由器节点故障）时，必须模拟和验证网络行为。“路由器故障、链路卡死或缓冲区错误等故障场景可以在指定的故障模型（fault model）中，以非确定性故障注入（non-deterministic fault injection）的方式建立形式化模型，从而使验证环境能够遍历所有可能的故障位置以及发生时机，”Darbari 指出，“形式化验证非常适合故障建模，因为它本质上就是在无约束条件下运行，而这种非确定性恰恰是故障注入、故障传播以及故障检测所必需的特性。”

NoC 的测试与仿真

如今，芯片的复杂程度不断提高，导致设计流程中原本彼此独立的各个阶段开始相互重叠。对于 AI 芯片而言，测试本身已经十分复杂，而由于整个生态系统的持续变化，实现全面覆盖变得更加困难。

Keysight Technologies AI和网络测试解决方案产品经理Razvan Arhip表示：“这包括评估和优化AI互连架构，以确保最大限度地减少GPU空闲时间。另一个重要因素，是观察当流量扩展到数百个端口之后，对 AI 互连架构以及协议部署所带来的影响。”

图 2：AI 互连架构测试面临的挑战和任务。来源：Keysight/Collective Communication Library (CCL)、ECN（Explicit Congestion Notification）、PFC（Priority-based Flow Control）、RoCEv2（RDMA over Converged Ethernet version 2）

损伤测试（Impairment Testing）也是整个流程中至关重要的一环，尤其是在数据平面方面。Arhip表示，“我们可以人为引入数据包延迟、丢失或者直接丢弃数据包。我们还可以在真实流量中叠加各种不同模式的抖动（jitter），以观察上层协议在各种异常情况下究竟会如何表现。”

AI 时代与 AI 出现之前最大的区别之一，就是 Incast（汇聚通信）网络瓶颈出现得更加频繁。

Arhip 表示：“数据中心的 AI 互连架构内部存在大量的 incast 现象，GPU 获取数据并完成计算之后，会按照各种不同模式交换数据，例如全互连（all-to-all）、Reduce Ring（环形归约）等。当这些通信开始时，会有一个统一的触发信号启动整个网络中的数据传输，因此极有可能在设备某个入口位置形成 incast，也就是出现严重拥塞。我们希望重点模拟的正是网络中的这些关键时刻。首先，我们部署 GPU 集群，然后在某一个特定时刻开始发送流量。但我们不会让所有流量实现完全同步，因为现实世界中根本不存在这种情况。我们会对端点之间的流量进行随机化处理，因此尽管它们之间的流量是同步的，但并非纳秒级同步。当然，我们也提供纳秒级同步的选项，但默认情况下，端点之间的流量并非纳秒级同步。”

NoC 可靠性：数据中心与汽车

在数据中心，NoC 必须以最佳状态运行，以支持高速数据传输并降低热量产生，而在汽车应用中，这可能关乎生命安全。

Baya Systems 的首席解决方案架构师 Kent Orthner 表示：“如果想获得汽车认证并进入汽车市场，那么设计和验证的方法论，以及对冗余机制、错误检测、数据保护等能力的支持，都必须达到远高于普通产品的要求。许多部署 AI 的大型数据中心都认为，随着时间推移，芯片最终都会逐渐老化失效，但汽车不能接受这种情况。自动驾驶汽车需要能够准确识别行人，绝不能允许任何潜在故障发生。因此，汽车领域最大的挑战之一，就是确保 NoC 的设计能够在每一条数据路径上增加额外位（extra bits），用于检测错误，并能够立即通知控制平面（control plane）。在某些情况下，还需要采用冗余逻辑（redundant logic），即多个硬件模块并行执行完全相同的计算，并持续比较它们的结果。这样，一旦出现任何问题，都可以在纳秒内恢复。随着自动驾驶和驾驶辅助功能的日益普及，我们会看到推理引擎（inference engine）部署在汽车中。”

总体而言，汽车中的许多数据流与数据中心其实非常相似。Orthner 表示：“虽然汽车的规模远不及数据中心那些像大型冰箱一样庞大的服务器机柜，但从芯片本身来看，它们依然属于性能非常强大的芯片。不同之处在于，如今安全已经成为最重要的考量因素。”

图 3：将各种 NoC 集成到统一架构中，使其在多裸片系统中像智能全局 NoC 一样运行。来源：Baya Systems

结论

AI 的训练和推理速度取决于专用处理器和内存之间数据传输网络的速度。同样，软件定义车辆的可靠性也取决于支持其区域化架构之间通信的网络的可靠性。

设计人员正在开发一系列新的解决方案，用于验证、确认、仿真和测试 NoC 设计，以确保数据流量的流动不会导致系统故障。然而，在多裸片封装以及不同类型数据持续进行路由和重新路由的情况下，如何确保数据流量畅通无阻，对于日益复杂的设备而言，尤其是在工作负载变化频繁以及任务关键型和安全关键型市场中，仍然是一个巨大的挑战。