Scale-up 互连协议被讨论了很多年但我发现真正能坐下来把状态机、消息格式、路由策略全摊开聊的场合其实很少。去年一次互连方案评审我被一个问题问住了CHI 的七态到底是哪七态和 MOESI 差在哪多出来的状态解决什么问题。当时会议室里几个人给的答案都不太一样这个细节让我意识到多数人包括我自己其实对协议的理解停留在“名字很熟”的层面。这篇内容我想把六个在开源社区和高性能计算领域绕不开的互连协议放在同一张解剖台上AMBA CHI、TileLink-C、CXL、CCIX、OpenCAPI、Gen-Z。从缓存一致性状态机、数据包比特布局、请求路由策略三个层次切开看重点放在 CHI 的七态状态模型和 PBR 策略路由上。适合正在做芯片互连架构、SoC 集成、RISC-V 开源生态开发或者刚接触一致性协议的工程师看完至少能对协议对比这件事建立起自己的坐标系。1. Scale-up 互连为什么值得把状态机翻出来看1.1 Scale-up 和 Scale-out 的本质差别Scale-out 解决的是“机器不够就加机器”的问题靠以太网或 InfiniBand 把多台服务器连起来一致性由分布式软件协调。但 Scale-up 是一条相反的路把 CPU、内存、加速器塞进同一个物理系统让它们像一个整体一样工作。AI 训练、高性能计算、内存数据库这些场景对单机带宽和延迟的要求越来越高Scale-up 互连的重要性也就越来越大。这两个方向对互连协议的要求完全不同。Scale-out 网络层可以容忍几十微秒延迟数据一致性主要靠软件协议栈处理。Scale-up 互连跑的是缓存一致性流量延迟通常要求亚微秒甚至纳秒级硬件必须在状态机层面直接裁决“这个 cache line 现在在谁手里、允许谁写、数据脏没脏”。所以 Scale-up 互连协议的内部机制本质上就是一堆精心设计的状态机和路由表。把状态机翻出来看是因为很多问题的根源不在链路速度而在状态转换的并发竞争。比如两个节点同时想写同一个 cache line谁先谁后、谁被监听、目录何时更新这些都必须由协议状态机明确回答。状态机设计得好不好直接决定了死锁、活锁、性能回退这些工程里最头疼的问题会不会出现。1.2 选这六个协议的理由目前公开资料里能称为“开放/开源”的 Scale-up 互连协议不止六个但我挑出来做横向解剖的这六个每个都代表了一种有影响力的设计流派。AMBA CHIArm 生态的服务器 SoC 事实上都在用它Neoverse 系列背后的互连就是 CHI 风格。它把缓存一致性和路由策略分开治理状态机丰富、目录机制完整是理解高端互连的入口。TileLink-CRISC-V 生态里普及度最高的一致性互连协议Rocket Chip、Chipyard 这些开源 SoC 框架直接可用。它用五个物理通道把所有事务类型都覆盖了属于“简单而完备”的典型。CXL目前业界押注的对外互连统一方向承载在 PCIe 物理层之上主机和设备之间的缓存一致性、内存共享都在同一套框架里解决。CCIX上一代加速器一致性竞争的产物同样跑在 PCIe 上一致性模型源自 ARM ACE 协议现在风头被 CXL 盖过但设计思路仍有参照价值。OpenCAPIIBM 主导的加速器互连协议核心是开放规范和较简洁的目录式一致性FPGA 生态里曾有不少支持。Gen-Z纯粹的内存语义互连实验把内存、IO、加速器全部抽象成内存访问核心交换器维护目录。规范后来并入 CXL但它的思路影响了很多后续设计。把这六个放在一起对比其实是在看同一道考题的六种解法在多个请求节点之间维护一致性该用什么状态模型、什么事务通道、什么路由策略。每一种选择的背后都有明确的工程动机。2. CHI 七态状态机拆解从一个读请求的旅程说起2.1 七态是哪七态为什么不是五态CHI 的缓存状态常被归纳为七种稳定状态Modified、Owned、Exclusive、Shared、Invalid、Unique Clean、Unique Dirty缩写就是 M、O、E、S、I、UC、UD。MOESI 本身已经是五态覆盖了“谁拥有最新的、干净还是脏、是不是唯一副本”这些含义。CHI 在此基础上增加了 UC 和 UD 两个状态目的很明确更精细地表达“唯一副本但未修改”和“唯一副本且已修改”的情况。为什么 MOESI 不够用举一个实际场景。当某个节点持有 Exclusive 状态的副本它知道自己可以安全写入因为自己是唯一缓存者。但在 MOESI 的经典语义里E 状态不保证系统里没有其他人也缓存了相同地址其他节点后期可能还会向目录发起请求。CHI 用 UC 状态表示“我不仅持有唯一副本而且系统通过目录已经确认没有其他人持有”这样后续的清理和监听动作就能省掉一大截。七态最大的价值在于减少不必要的一致性流量。多节点系统中一个地址被反复监听和答复是很耗费带宽的UC/UD 让我们明确知道“这地址就我一个人有”后续处理就可以直接走快速路径。2.2 用一个读请求走一遍状态转换路径我用一个最典型的场景走一遍状态机路径。假设节点 RN-A 发出 ReadShared 请求想读取地址 X而节点 RN-B 当前持有 X 的 Modified 副本。完整的交互序列可以简化表示为RN-A - HN: ReadShared HN - RN-B: SnoopRead RN-B - HN: DataResp Comp HN - RN-A: CompData第一拍是 RN-A 把请求发到 Home NodeHN 就是负责该地址一致性裁决的节点。HN 查目录发现 RN-B 持有脏数据于是向 RN-B 发 SnoopRead。RN-B 收到监听后把自己的数据返回给 HN状态从 M 转向更宽松的状态同时带 Comp 完成信号。HN 把数据转发给 RN-A同时更新目录状态告诉它现在地址的持有者信息已经发生了改变。这条主路径就是状态机最核心的骨架。如果目录里记录 RN-A 已经持有 UC 状态整个流程就会大幅缩短RN-A 的读请求甚至不需要触发跨节点监听HN 直接返回数据或者确认信号即可。这就是 UC/UD 这两个状态带来的直接收益。多节点并发场景下七态模型的优势主要体现在这里。2.3 用三段式状态机的思维看 CHI 控制器做嵌入式或者 FPGA 开发的工程师对状态机建模都很熟经典的三段式写法是第一段时序逻辑保存当前状态第二段组合逻辑根据当前状态和输入计算下一个状态第三段输出逻辑产生控制信号。CHI 的一致性控制器搬进这套框架其实是天然契合的。第一段是状态寄存器记录每个 cache line 当前处于七态中的哪一种。这个状态集是有限的所以它可以是一张表也可以是一组触发器。第二段是次态逻辑输入包括本节点发出的请求类型、收到的监听请求、数据响应、完成响应等事件输出就是下一个状态。第三段是输出逻辑决定要不要发出 Snoop、要不要回 Data、要不要更新目录表。有不少芯片验证工程师看不懂协议规格书里大段大段的文字描述一看状态转换表反而茅塞顿开就是这个原因。用 Verilog 写状态机和用 C 语言给 STM32 写按键消抖状态机本质上是同一个方法论定义状态集合、定义事件集合、定义转换条件。CHI 只是把事件从按键换成了 Request 和 Snoop把输出从 LED 换成了总线响应复杂度指数上升但骨架没有变。芯片里真正落地的 CHI 控制器往往不是一个状态机在单打独斗而是拆成请求状态机、监听状态机、响应状态机等多个模块。它们之间通过内部握手信号通信从宏观上看就是一个大型三段式状态机的分工协作。3. 六个协议的状态机模型对比状态集合、触发器和拓扑假设3.1 状态集合对比从四态到七态六个协议的状态集合差异很大但基本都能从 MESI/MOESI 这个家族里找到根源。下面这张表是我在对比时常用的简表协议一致性模型内核典型状态集合是否依赖目录CHIMOESI 超集I、UC、UD、SC、SD、O、M 等是Home Node 全局裁决TileLink-CMESI 衍生有效/脏两维状态约四态半目录式Root Manager 集中管理CXLMESI 变体主机端缓存代理维护精简状态主机 Home Agent 主导CCIXACE 系 MOESIM、E、S、I、O 等支持多种监听组合OpenCAPI目录式简化模型加速器端状态很精简是主机内存目录Gen-Z目录式内存语义Valid/Invalid/Shared/Dirty 位图风格是核心交换机目录不能只看状态数量就评判协议优劣。CHI 状态多看上去复杂但每个状态的含义边界清晰状态跳转逻辑反而规整。TileLink-C 状态少但它通过权限升级、降级这样的复杂操作来弥补语义控制逻辑也不简单。CXL 的状态模型精简是因为它把一致性职责拆给了主机端和设备端极不对称的两侧。另外要注意状态集合是协议公开定义的最小集合实际芯片实现时还会引入过渡状态、退化状态、调试状态。比如某个状态在等待数据返回期间硬件可能会插入一个临时的等待态这种情况规范不会细管只要求对外表现一致。3.2 监听机制对比Home Node 裁决与分布式监听一致性的关键问题永远是谁负责知道一个地址有哪些缓存者。六个协议在这个问题上的答案分成两个流派。CHI 是典型的目录化裁决派。所有一致性请求先打到 Home Node由 Home Node 查目录再定向发监听。这种方式的优势是监听报文只在需要的地方出现不浪费带宽代价是每个地址在 Home Node 上要保存目录信息访存请求也会在 HN 上形成汇聚点。TileLink-C 也是集中管理但风格不同。它的拓扑是树Root Manager 是根Client 是叶。A 通道上行请求B 通道下行监听C 和 D 通道处理响应和补拍E 通道完成一致性保障。树形拓扑让每个 Client 只有一条上行路径不需要多少路由决策状态机相应简化。CXL 把主机和设备放在不对称位置。Home Agent 在主机侧Caching Agent 在设备侧设备不能自作主张决定目录怎么维护。CXL 的 Back-Invalidation 机制就是主机主动作废设备端缓存副本的通道。Gen-Z 和 OpenCAPI 更像是“请求者无需感知其他人”的设计。目录放在核心交换器或内存控制器里请求方发出操作由目录去裁决冲突。从状态机视角看请求方状态机非常简洁复杂度集中在目录端。3.3 拓扑假设带来的状态机简化协议状态机的复杂度和它假设的物理拓扑强相关。这是个很值得展开的观察点。CHI 预设的场景是 RN-F、RN-D、HN、SN 在 Mesh 或 Ring 这种片内网络上多对多连接所以协议设计必须考虑路由信息、源目标标识、多跳路径。状态机里因此要留够事务标签空间并处理请求乱序、跨节点抢占等复杂并发情况。TileLink-C 预设的场景是树形拓扑从叶子到根路径唯一。路由在系统集成时通过地址映射固定下来运行时不需要额外决策。拓扑简化带来的红利是状态机可以向纵深方向优化节点之间通过握手信号精确控制不用预留大面积重路由逻辑。Gen-Z 预设的是带交换机的内存语义网络每个组件有独立标识和可配置路由表。拓扑不再是整形树而是多跳交换网所以状态机要能处理跨交换机的请求转发、队列压力和流控回退。当你评估一个协议适不适合自己的系统先看自己的拓扑再谈状态机。拓扑不匹配状态机再完善也用不上。4. 比特层面的较量消息类型、头部字段与流水线开销4.1 消息/通道体系的设计差异状态机定义的是语义真正落地时挑战在于这些共识怎么编码成比特流。六个协议在这层分化出三种不同的设计取向。CHI 把请求、响应、数据、监听都承载在统一的 flit流量单元上通过链路层格式区分不同类型。flit 宽度通常是可配置的典型实现有 32、40、64、128 bit 几种。统一的 flit 带来的是链路层格式简单、适配不同物理层宽度的能力代价是解析逻辑需要判断 flit 类型再决定按什么字段解析。TileLink-C 走的是物理分通道路线。A/B/C/D/E 五个通道各自独立每个通道有固定的 opcode、param、source、address、data、mask 字段布局。它在硬件上实现仲裁很直接谁家的通道被占用一目了然还可以针对不同通道单独做流控。这种设计在开源 SoC 中非常受欢迎因为逻辑透明、调试直观。CXL、CCIX 这类基于 PCIe 的协议需要在 PCIe TLP 之上叠加一致性协议层。它们的比特布局受限于 PCIe 体系头部中有大量格式类型、流量类别、标签字段需要维护。好处是和现有 PCIe IO 生态兼容坏处是协议栈层次多报文头开销明显。4.2 包头开销与事务标签宽度三种位宽策略事务标签位宽直接决定系统能同时跟踪多少笔在途事务。标签越宽并发能力越强能隐藏的内存访问延迟越多但标签位宽也意味着包头变长链路有效载荷率下降。这是工程上典型的取舍问题。CHI 的 TxnID 体系比较完善它把事务关联拆解成请求事务标识和响应事务标识Home Node 可以通过标识把监听请求和原始请求关联起来。TileLink-C 的 source 字段位数由实现者决定通常留出足够的并发通道数。PCIe 体系内的协议则受制于 TLP 的 Tag 字段并发规模有一定上限。实际部署时还有另一个容易忽略的带宽开销字节使能掩码。写一个 cache line 的部分字节时协议必须在数据侧携带 Byte Enable否则接收方不知道该更新哪些字节。CHI 的写数据段带 Byte EnableTileLink-C 的 A 通道也有 maskPCIe 体系部分协议在投递部分写时需要额外的写操作指令来表达掩码。对比协议时把掩码开销算进有效带宽往往比单纯看链路速率更能说明问题。4.3 虚拟通道和流控机制对有效带宽的影响很多人在比较协议时只看状态机和消息结构但真正影响系统延迟和面积的往往是流控机制。CHI 链路层的信用管理、PCIe 体系的信用仲裁、TileLink-C 的通道握手这些机制决定了数据能多快从链路一端流动到另一端。虚拟通道的引入是为了解决不同类流量之间的互相阻塞。一致性请求、数据回传、监听请求如果挤在同一个物理通道里一个长时间的数据突发可能阻塞紧急的监听报文导致性能连锁恶化。CXL 在 PCIe 体系上提供虚拟通道来隔离请求和响应CHI 在链路层也支持流量类别区分TileLink-C 则用物理通道天然隔离了请求、监听、数据、响应。流控机制的另一个侧面是死锁避免。网络互连中如果 A 等待 B、B 等待 C、C 又等待 A系统就卡死了。协议层必须通过协议的通道优先级、缓存资源分配、事务依赖规则来打破这种循环。我在实际验证中见过不少死锁问题根因往往不在状态机表格本身而在路由层和流控层的交界处。5. PBR 路由上的策略之战从地址哈希到策略路由5.1 先说清楚 PBR 是什么不是什么看到 PBR 三个字母做图形学或者游戏开发的朋友可能第一反应是 Physically Based Rendering 物理渲染材质。如果你是在找“没有 PBR 材质之前一般用什么材质”那大概率想问的是 Blinn-Phong、Lambert 之类的经验模型这属于另一个世界的事本文不展开。本文要聊的是互连协议里的 PBRPolicy Based Routing策略路由。它解决的核心问题是芯片里一笔请求从发起节点出发以后怎么决定下一站去哪。是去内存控制器还是去某个 Home Node还是去某个 IO 控制器靠什么规则来定。在没有 PBR 之前CHI 体系里最常见的做法是把地址做哈希然后按哈希值把请求分发到一组 Home Node 上。这种方式简单但是不灵活。哈希是固定的没法根据流量热点动态调整不能让高优先级流量走专属路径也不能对某个内存控制器做定向隔离。PBR 就是在这个背景里出现的本质上是把“去哪”的决策从一把死板的哈希算法换成一个可配置的策略查找表。5.2 CHI 的 PBR从固定哈希到策略表CHI 的 PBR 让系统集成者可以预定义若干路由策略每个策略包含地址匹配条件、目标 Node、可选的属性覆盖项。请求到达后硬件按优先级逐条匹配策略表命中后按策略里指定的路径转发。一个简化的策略表示例routing_policy: - id: 0 priority: 3 addr_range: [0x0000_0000, 0x3FFF_FFFF] traffic_class: [Normal, Background] target: home_node_0 - id: 1 priority: 2 addr_range: [0x4000_0000, 0x4FFF_FFFF] traffic_class: [LatencyCritical] target: home_node_1 - id: 2 priority: 1 addr_range: [ANY] target: home_node_2这里的关键不是具体语法而是它的优先级和覆盖逻辑。高优先级的条目可以单独挑出某一段地址、某一类流量做特殊处理剩下的按低优先级默认规则走。这和 Linux 系统里的策略路由 ip rule 在思路上有相似之处不再只按目标地址查表而是把源、流量类别、优先级等一起纳入决策因子。区别在于硬件版本的 PBR 是 ASIC 里的查找逻辑延迟要求固定条目规模受限于 TCAM 或 SRAM 大小不能像软件那样无限制地加规则。PBR 带来的实际收益在 Cache 亲和性场景下特别明显。比如系统里有两个内存控制器地址区间本来交错哈希到两个控制器上但某个业务流对其中一个控制器的比例需要调整哈希方案做不了这种细粒度控制PBR 可以直接覆盖规则把特定流量导到指定控制器。5.3 其他协议怎么解决“这个包去哪”的问题六个协议在路由决策上的侧重点完全不一样。TileLink-C 的路由基本在编译期或者系统集成期就确定完了。地址段到 Manager 的映射是静态配置树形拓扑下每个请求只是沿着唯一路径上行到 Root不存在运行时的策略路由需求。这个设计很符合开源 SoC 的风格简单、确定、可预期但缺乏运行时调整的空间。CXL 基于 PCIe 物理层路由主要由主机配置 HDM 解码器来决定“哪个地址区间归哪个设备”。它不叫 PBR但地址解码和策略配置的思想类似。设备侧的可控性不强地址解码的主权在主机端。CCIX 和 OpenCAPI 都跑在交换拓扑上需要借助转发路径上的路由逻辑但它们在一致性目录里还有一层“谁拥有这个地址”的查询这两层职责是分开的。Gen-Z 给每个组件分配 ID请求通过核心交换器按组件 ID 转发到目标交换器内部用的是类似网络交换机的路由表由拓扑管理器预先下发。它的策略存储在交换器层而不是每个请求节点各自维护。对比下来能看出一个规律PBR 强调“每个请求节点都带自己的策略视角”而 CXL 和 Gen-Z 这种体系更偏向“全局基础设施统一裁决”。两者没有绝对优劣取决于你对系统细粒度控制的需求有多强。6. 面对实际选型这份对比到底怎么用6.1 一张表看懂六个协议的核心差异综合对比表如下方便做选型时快速横向参考协议典型一致性模型拓扑假设路由机制典型实现/生态适合什么场景CHI七态目录化Mesh/Ring 片内多对多PBR 策略路由Arm 服务器 SoC、Neoverse 生态大规模一致性、高端 CPU 互连TileLink-C两维四态集中管理树形拓扑静态地址映射Rocket Chip、Chipyard开源 RISC-V SoC、对面积敏感设计CXL主机主导 MESI 变体PCIe 拓扑HDM 解码 PCIe 路由CXL 联盟生态AI 加速卡、设备内存扩展CCIXACE 系 MOESIPCIe 拓扑PCIe 路由 目录上一代 FPGA 加速器兼容老设计时可参考OpenCAPI目录式简化模型自有交换拓扑ID/地址路由IBM POWER FPGA 生态低延迟加速器互连Gen-Z目录式内存语义交换机网络组件 ID 路由并入 CXL 前的研究参考内存语义系统研究、CXL 演进参考这张表不能直接告诉你选哪个但能帮你把问题定位到“我的拓扑是什么、我的控制粒度需求是什么、我的生态倾向于哪边”这几个答案清晰之后协议基本就浮出水面了。6.2 按芯片类型选协议的建议如果你在做 Arm 服务器 SoCCHI 几乎是默认路径。Neoverse 体系已经围绕 CHI 生态建起了完整的网组件、验证 IP 和工具链。这种时候不建议从头实现完整状态机用成熟组件集成、专注在系统级的拓扑和 PBR 策略设计上性价比最高。如果你在做 RISC-V 开源 SoCTileLink-C 是上手最友好的选择。Rocket Chip 的 L2 一致性管理器可以直接用五通道的交互逻辑在开源代码里也容易读懂。要对外接 CXL 或者 PCIe可以做桥接层把 TileLink 的一致性语义转换到 CXL 协议这部分工作有挑战但开源社区已有不少参考实践。如果你在做 AI 加速器CXL 是目前最值得压注的方向。主机与设备之间的缓存一致性、内存池化都在 CXL 规划内生态和工具链都在快速成熟。OpenCAPI 和 CCIX 不是不能做而是生态投入已经明显收缩除非有历史包袱否则不建议新项目入场。如果是做内存语义类的系统研究Gen-Z 的设计值得复盘。它把内存访问和 IO 访问统一到同一套语义上思路很先进后来 CXL 也吸收了类似内存池化概念。研究机构做原型验证时Gen-Z 的目录式一致性模型仍然是很好的学习素材。6.3 工程落地时容易被低估的细节最后说几个工程里最容易翻车、但很少被文章讨论的地方。第一个是死锁避免。状态机表做对只是及格线真正困难的是多笔事务并发时不会把自己锁死。协议规范通常给出了死锁避免的指导原则但具体通道的缓存分配、优先级设置、依赖关系需要自己设计。我在验证项目里见过最多的问题都不是状态机跳错而是队列资源和路由优先级配置不对导致的活锁。第二个是验证的激励不好构造。一致性协议验证靠的是海量随机并发、竞态攻击、定向边界测试。纯看状态图找 bug 效率很低建议用形式化验证工具做死锁检查同时配合随机流量做长时间压测把多节点并发竞赛彻底跑一遍。第三个是 PBR 策略表的热路优化。策略查找不能每次都走慢速路径否则会成为系统瓶颈。实际芯片里通常会把最近命中的策略条目放在高速缓存结构里同时保证策略更新时的一致性。这个部分协议规范不会细管完全靠实现者的功底。第四个容易被忽略的点是协议的“开源”程度。CHI 的规范公开但成熟参考设计多数还是商业 IPTileLink-C 是在开源框架里有完整实现能直接看代码CXL、CCIX、OpenCAPI、Gen-Z 则大多是规范先行核心代码在各自 IP 厂商手里。选择协议的同时要评估自己能获取到多深的参考资料。我个人做互连方案对比的习惯是先写一个端到端的时延模型和带宽模型把状态机冲突概率、路由时延、流控往返时间都估算一遍再回到协议细节逐步校准。别一上来就比状态数或者口号那很容易被片面的复杂度带偏。把数据通路上的竞态问题打光再谈功能完善——这个顺序在我看来比任何协议选型都重要。
