聊到 Scale-up 互连很多人的第一反应是“这不就是数据中心里把机器插在一起吗”。其实差别很大Scale-out 是加机器靠网卡和交换机堆吞吐Scale-up 是换“大发动机”让 CPU、内存、加速器、甚至多颗 CPU 之间像同一台机器一样协同共享同一个内存视图。而要做到这一点背后的互连协议必须在缓存状态机、消息字段、路由决策这些极底层的地方斤斤计较。这篇文章我不打算做那种“六个协议各讲五分钟”的科普而是把它们真正放到比特和状态机层面来回拆。我们以 ARM CHI 的七态缓存状态为锚点一直拆到 PBR物理地址路由如何决定一个请求去哪个节点再把 CHI、TileLink、OmniXtend、CXL.cache、OpenCAPI、CCIX 这六个开放协议放到同一张桌子上做横向对比。适合谁看做处理器/加速器架构的、写 RTL 做验证的、搞系统软件和模拟器的还有想折腾开源互连协议的学生这篇应该都能挖到点东西。1. Scale-up 互连到底在解决什么问题1.1 从 Scale-out 到 Scale-up为什么一致性成了分水岭传统互联网应用扩容的思路很简单无状态服务前面挂负载均衡后面挂一堆机器请求随便打到哪台都行。这种模式对机器之间的通信延迟容忍度很高因为业务数据都去数据库或缓存里拿机器之间不需要“互相看对方的缓存”。但到了 AI 训练、大数据分析、高性能计算这类场景计算节点之间要频繁共享数据结构、同步中间结果如果每次共享都要落到远端内存性能就彻底废了。更好的做法是让多个请求者通过互连协议感知彼此对同一块内存的缓存状态你知道这个数据有人在用、有没有被改过、改完要不要通知别人。这套机制就是缓存一致性协议也是 Scale-up 互连和普通网络互连最本质的分水岭。普通以太网不管你在哪个核上缓存了什么而一致性互连协议要在硬件层面维护一个分布式状态机每个缓存行此刻处于什么状态我这个核可不可以直接写还是必须先问一下其他人。协议干得好不好直接决定多核、多芯片、多节点的扩展效率。1.2 协议栈分层不能只看“缓存状态”那一层理解协议之前先有个分层概念。一个完整的互连协议栈大致是物理层、链路层、事务/协议层、以及路由与系统地址映射。物理层管电信号和编码链路层管流控和可靠传输而大家天天讨论的 MESI、MOESI、CHI 七态都在事务/协议层PBR 路由则在协议层和系统映射之间。很多初学者一上来就背缓存状态结果真正看协议报文时懵了为什么一个读请求要拆成好几个 FLIT为什么还要单独的 Data 通道因为状态机只是“规定行状态怎么变”实际通信要靠报文里的字段和路由信息来表达。所谓“比特和状态机层面”就是这个意思状态机决定行为规则比特字段决定消息怎么组织、怎么寻址、怎么被路由到正确的节点。拿 CHI 举例一个典型的读请求要经过 Req、Data、Rsp 至少三个阶段每个阶段都是独立 FLIT里面除了地址和操作码还带着 NodeID、属性位、事务 ID 等一堆字段。对比协议首先要对比的就是这些消息骨架和状态定义。1.3 为什么是这六个协议选取标准先讲清楚严格说CHI、CXL、OpenCAPI、CCIX 这些规范是开放标准但 License 未必完全“开源”真正的开源协议代表是 TileLink 和 OmniXtend。我把它们放进同一张桌子的理由是它们都拥有公开的规范或开源参考实现而且在 Scale-up 互连链条上各有典型位置对比起来有区分度。ARM CHI现代自研 SoC 和高性能互连的事实基线状态机和消息设计最完整。TileLinkRISC-V 生态活跃的开源互连协议Rocket Chip、OpenPiton 都在用。OmniXtend把缓存一致性搬到以太网上研究分布式一致性的好样本。CXL.cache当前数据中心加速器一致性的主流方向和 PCIe 物理层深度绑定。OpenCAPIIBM 推动的开放加速器互连一致性语义和 OMI 接口比较有特点。CCIX虽然已被 CXL 吸收但它和 CXL 同源于 PCIe 环境下的一致性扩展历史对比价值高。后面几节里我会把每个协议在状态机和消息路由上的核心思路拉出来逐个解剖。2. 缓存状态机大乱斗从 MESI 到 CHI 七态再到各家“方言”2.1 先把这个基础补明白MESI 和 MOESI 在干什么要理解 CHI 七态先看回经典 MESI。它给每个缓存行定义了四个状态Modified我改过别人没有、Exclusive只有我有但没改、Shared大家都有且干净、Invalid无效。核心思想是写入前如果状态不是 Modified/Exclusive要先去获得唯一所有权。MOESI 在 MESI 基础上加了一个 Owned 状态某个缓存行被多个节点共享但其中有一个节点拥有最新数据并负责写回。这么一加读操作有时不需要访问内存降低延迟。CXL.cache 等协议在语义上基本是 MOESI 的变体。但真实协议不能只有这么几个稳定状态。因为现代 CPU 和加速器会做部分写、空行分配、压测时的流水线重放需要更细的状态来准确描述“我这个缓存行有没有有效数据”“数据是不是只覆盖了一部分”“我能不能在写回前先把数据借给别人”。于是我们看到 CHI 把状态拆得更细。2.2 核心解剖CHI 七态到底比 MESI 多了哪些东西CHICoherent Hub Interface是 ARM 针对多核、多 chiplet、以及跨芯片一致性场景设计的互连协议。它的缓存行状态不止四个最常被引用的七态是IInvalid无效。UCUnique Clean唯一且干净没有其他副本。UDUnique Dirty唯一且脏数据需要最终写回。UDPUnique Dirty Partial唯一、脏但只覆盖行内部分字节。UCEUnique Clean Empty唯一且干净但数据内容无效或未初始化。SCShared Clean多个副本共享且干净。SDShared Dirty多个副本共享但本节点拥有最新数据。这七个状态的含义比 MESI 更容易理解的一点是它把“部分有效”和“空行”显式拆出来。UDP 在乱序执行和向量访存时非常有用比如一个 CPU 对一个 64B 缓存行只写了 8B其他字节还是旧数据这时缓存行就是 UDP而不是完整的 UD。UCE 则更多出现在分配缓存行但还没真正填充数据的场景。状态之间怎么迁移举个例子如果目标缓存行处于 SC而一个 CPU 想执行写操作协议通常会发起一次向其他共享者的窥探Snoop把 SC 状态变成 UC/UD再允许写入如果是 UDP写满全部字节后可以升级为 UD。这种迁移不是一次完成的中间会穿插 Req、Snp、Data、Rsp 多个事务所以协议终端里要做一个非常严谨的状态机来记录“当前到哪一步了”。2.3 TileLink 的一致性状态一套不那么“命名你认识”的协议TileLink 是 RISC-V 社区里最常见的开源互连协议常见有 TL-UL、TL-UH 和 TL-C 三个层次。TL-C 引入了完整的缓存一致性支持但它的状态名不是 MESI 那套而是 None、Branch、Trunk、Dirty 之类第一次接触会有点别扭。None缓存行无效。Branch可能有多个节点有副本数据干净类似 MESI 的 Shared。Trunk当前节点持有唯一所有权但数据干净类似 Exclusive 或 Unique Clean。Dirty当前节点持有唯一所有权且数据被修改类似 Modified/Unique Dirty。命名虽然不同状态转移的语义和 MESI/MOESI 家族是相通的。TL-C 最有特色的是它采用五个通道 A/B/C/D/E 来完成一致性交互发起者走 A 通道发送 Acquire接收者用 D 通道返回 Grant中间的探测用 B 通道数据释放走 C 通道最后 E 通道结束整个事务。这个通道结构非常干净很适合在 open-source RTL 里做实现和调试。2.4 CXL.cache、OpenCAPI、CCIX 的状态设计MESI 的现代化变体CXL 是目前数据中心加速器互连里绕不开的协议。它的 CXL.cache 子协议专门给带缓存设备使用语义上很像 MOESI 的紧凑版本但针对 PCIe 物理层做了很多裁剪由于 PCIe 本身是包交换结构CXL.cache 要把一致性请求封装成 PCIe TLP/FLIT延迟相对片内互连更高所以状态机会倾向于减少不必要的探测流量。OpenCAPI 的一致性模型提供了与 CPU 缓存一致的内存访问它更适合追求极致内存语义的加速器场景。从状态机角度看OpenCAPI 同样实现了 MESI 变体但它的接口抽象更偏向“内存语义”让加速器像访问本地内存一样访问宿主内存底层状态管理由协议的 Home Agent 和 Cache Agent 协同完成。CCIX 和 CXL 很像也基于 PCIe 物理层。它定义了缓存线上报、检测、写回等机制。历史意义在于验证了“在标准 PCIe 上做缓存一致性”这条路走得通也正因为物理层先天延迟较高最终数据中心主流选择了用更强的 CXL 来承载。但从协议学习角度看CCIX 的状态迁移和消息字段仍值得和 CXL.cache 对照着看能发现很多“同一个目标下的不同设计取舍”。2.5 状态机实现风格一段式、两段式、三段式如何影响协议落地聊到状态机我注意到很多工程师搜索“一段式、两段式、三段式状态机”这话题在 Verilog/SystemVerilog 世界里确实很重要。协议状态机实现里尤其能体现三段式的价值。一段式所有状态转移和输出写在一个 always 块里代码少但调试困难组合逻辑和时序逻辑混在一起协议状态一旦复杂就是灾难。两段式一段时序逻辑负责状态寄存器更新一段组合逻辑负责状态转移条件和输出逻辑清晰一些但因为输出仍依赖当前状态和输入容易出毛刺。三段式状态寄存器更新、次态计算、输出逻辑分别用三个块实现输出可以用寄存器打一拍完全消除毛刺代价是多一拍延迟。缓存一致性状态机对时序非常敏感比如 CHI 里 D 通道返回 Grant 和 Data 可能花色不同如果用一段式写完整个迁移逻辑后续加一个部分命中、加一个 Partial 状态可读性会迅速崩溃。我个人的习惯是核心协议状态机一律用三段式把次态计算函数和输出函数拆成独立逻辑保证 RTL 仿真时能快速定位是状态迁移错还是输出驱动错。2.6 六协议状态与实现复杂度对比协议典型缓存状态状态风格接口/通道状态机实现难度CHII/UC/UD/UDP/UCE/SC/SD扩展 MESI显式部分/空状态Req/Resp/Data/Snp 多通道高需处理大量并行事务TileLinkNone/Branch/Trunk/DirtyMOESI 语义变体A/B/C/D/E 五通道中通道模型清晰OmniXtend基于 TileLink 语义继承 TL-C适配以太网EthernetTL 映射高需考虑丢包重传CXL.cacheMESI/MOESI 变体针对 PCIe 精简CXL.io/CXL.cache/CXL.mem中高受物理层约束OpenCAPIMESI 变体内存语义优先OMI/PCIe 类接口中CCIXMESI/MOESI 变体与 CXL 类似但历史方案PCIe 物理层中从这张表能看出CHI 的状态设计最细、实现复杂度最高TileLink 是开源世界里平衡得比较好的方案CXL.cache 则在商业和数据中心场景占据主流。3. 消息格式与 PBR 路由比特层面真相大白3.1 CHI 的消息要拆开看Req、Data、Rsp、Snp 背后都是些什么协议不能只有状态机还要能“开口说话”。CHI 有几种核心消息类型请求类Req、响应类Rsp、数据类Data、探测类Snp。每个消息都对应一个 Channel在物理链路上以 FLIT 为单位传输。一个 ReadUnique 请求的流程能很好展示比特和状态机如何联动请求端发 Req包含事务 ID、物理地址、操作码ReadUnique、属性是否允许共享、是否部分访问等。Home Node 收到 Req 后查其记录如果需要破坏其他节点的副本状态就向相关节点发 Snp 消息。被探测节点收到 Snp 后响应自己的缓存状态和数据情况该写回就写回。最终 Home Node 把数据返回给请求端同时更新自己的目录状态。这里面任何一个字段出错都可能造成状态不一致地址位段错了路由去不到该去的节点事务 ID 混乱响应就对不上请求操作码写错接收方可能做出完全不同的状态迁移。所以在 RTL 验证时除了要对着状态机做定向用例还要做大量随机事务注入专门抓字段级错误。3.2 TileLink 的通道字段五个通道怎么配合完成一次缓存交互TL-C 的五通道模型在比特层面更“教学友好”。A 通道传 Acquire 请求主要字段有地址、操作码、源/目标标识等D 通道传 Grant 数据把请求结果和数据一起返回B 通道用于探测C 通道用于释放E 通道用于结束。通道之间的握手信号采用 valid/ready 模型不像 CHI 那样复杂的大通道需求但在多节点互连时也会遇到死锁问题。如果需要做一致性的多核 SoC基于 TileLink 的 Rocket Chip 是一个极佳学习样板你能直接在 RTL 里跟踪一个 Acquire 请求如何转换成 Grant 响应看状态从 Branch 变成 Trunk 再变成 Dirty边看代码边对照协议文档比单纯看论文高效得多。3.3 CXL.cache / OpenCAPI / CCIX 的消息封装PCIe 物理层的乱世英雄这三个协议都跑在 PCIe 或者类似物理层上意味着它们要面对一个本质问题PCIe 是为外设 IO 设计的以内存一致性为核心的流量并不是它的原生强项。CXL 的方案是在 PCIe 物理层上定义 CXL 事务层把请求、响应、数据做成类似 CXL.cache 的专用消息。CXL.cache 的消息字段里既有标准协议字段也要携带 PCIe 的标识信息比如 Requester ID、Tag用来在链路上定位事务。OpenCAPI 则更偏内存语义它的核心就是把内存访问和一致性合并为一个操作字段设计上会更接近“内存读写事务状态信息”降低加速器一侧的理解成本。CCIX 作为先行者走的是在 PCIe 之上叠加一致性层的老路虽然已被 CXL 整合但它证明了这种叠加模式可行也暴露了延迟和协议开销的问题。3.4 重点来了PBR 路由到底是哪一步PBR 在本文语境下是 Physical Address Based Routing中文可以叫“基于物理地址的路由”。它解决的问题是一个请求发出后互连网络如何决定它该去哪个 Home Node、哪个 Slope、哪个 Cache Agent做法很直接对物理地址做位段解析或哈希。CHI 体系里系统地址映射表SAM会指定不同地址区间对应哪个 Home Node实现时常见做法是提取物理地址中间若干位做 Interleave把连续地址的访问均匀分散到多个 Home Node避免单点热点。所谓 PBR就是这种把物理地址当作路由决策依据的方法。为什么强调基于物理地址因为在一致性互连里一个缓存行通常 64B必须有一个稳定的归属者谁负责维护这份数据的缓存状态谁就是它的“家”。如果同一个地址在不同时刻路由到不同 Home Node一致性目录就会分裂整个系统就崩了。所以协议才会花大力气保证同一物理地址路由结果必须是确定、稳定、一致的。3.5 路由计算实例拿一个 36 位物理地址看 PBR 怎么走假设系统有 4 个 Home Node物理地址 36 位缓存行大小 64B。地址的低 6 位是行内偏移接着若干位可以作 Hash 选择。如果系统采用简单位选路由取地址 [8:7] 两位作为 NodeID——这里注意 [6] 是行内偏移64B 即 2^6所以 [7] 和 [8] 已经在行粒度之上。连续 256B 范围内的 4 个缓存行会分布到 4 个不同 Home Node这样对顺序访问型负载很友好。如果内存访问模式随机位选会看到明显热点于是很多成熟实现用 CRC 或 XOR Hash 代替简单的位选让地址位上的规律被“搅散”。但 Hash 也不是越散越好。Hash 函数复杂会带来更大的仲裁/查表开销也可能破坏 TLB 页内连续地址的局部性。PBR 路由设计的本质就是在均衡性和实现复杂度之间做取舍。3.6 各家路由机制对比协议路由依据典型做法特点CHI物理地址 SAM节点 Interleave/Hash灵活但配置复杂TileLink静态地址映射为主Manager 地址窗口简单可靠扩展靠 BankOmniXtend以太网地址 TL 地址映射网络层地址解析突破单机边界CXL.cache物理地址 PCIe RID经 Root Port/交换机路由依赖 PCIe 拓扑OpenCAPI地址映射表 一致性引擎内存语义路由贴近内存控制器CCIX物理地址 PCIe 拓扑类似 CXL 早期实现已并入 CXL 路线从工程视角看片内 PBR 强调简单确定跨节点 PBR 更关注拓扑感知和拥塞均衡。4. 实操视角协议选型、仿真建模与踩坑实录4.1 方案选择什么场景该用哪个协议没有最好的协议只有最合适的场景。如果你是做一颗 RISC-V 内核为主、需要开源参考实现、看重可修改性的芯片TileLink 几乎是第一选择因为 Rocket Chip 生态里现成的验证环境和代码太多。如果团队技术栈偏 ARM或者需要承接现有 ARM IP 生态CHI 更合适但代价是协议复杂度高验证周期更长。如果做数据中心加速器、要兼容 PCIe 生态CXL.cache 是既定趋势。如果目标是内存语义这种特殊加速器OpenCAPI 仍有一席之地。OmniXtend 则适合研究课题比如你想在普通交换网络上构建一致性共享内存它给了一个可行的开源起点。决策时还要想清楚你的瓶颈是延迟还是带宽是兼容性还是可修改性。多个维度综合评估再动手。4.2 用开源模拟器和 RTL 项目学协议我超级推荐的方法是“先模拟、后 RTL”。用 GEM5 或 SystemC/TLM 模型跑一遍协议流量你能在高层看到消息序列和状态迁移再进到开源 RTL比如 Rocket Chip 的 TileLink 实现GPU 风格的 OpenPiton/NoC具体看信号和握手。我自己学 CHI 时就是先在 QEMU 和自定义的 SystemC 模型里模拟再对照 ARM 官方文档逐条看字段。做一致性协议验证有一条铁律不仅要测正向路径更要把 snoop 与 response 乱序、多个请求指向同一缓存行、部分写和数据返回竞争这些边界场景全都覆盖掉。很多时候问题不在状态机设计时而出现在随机流量压测下。4.3 常见问题速查与排查思路现象可能原因排查建议请求卡死无响应事务 ID 匹配不上或链路流控信号没拉齐先查握手 valid/ready再查事务 ID 分配数据不一致状态机允许了不该有的写操作回放事务序列定位状态迁移触发点随机压测必挂地址 Hash 冲突或路由表有未配置区间检查 SAM 是否覆盖所有物理地址多节点死锁通道依赖形成循环等待检查是否有独立数据通道避免请求/响应共用缓冲部分写数据丢失Partial 状态处理错误重点验证 UDP/UCE 这类扩展状态排查顺序我一般固定先看链路层有没有丢包重传再看事务层请求响应是否乱序最后查状态机有没有非法迁移。有几次调试到凌晨的经历最后定位到的问题不是状态机逻辑而是地址位段提取错了一位导致路由去错节点。所以建议验证环境里专门加地址位段断言第一时间抓这种低级错误。4.4 C 语言和 Verilog 建模协议状态机的两点心得前面提过三段式硬件写法再说说软件侧建模。用 C 语言写协议状态机时很多人喜欢用 switch-case 硬写状态一多就爆炸。我习惯把状态转移表做成二维表行是当前状态列是事件表项指向次态和动作函数。这种表驱动方式写 CHI 这种复杂协议特别高效每加一个事件只需要在对应行列补一个表项。在 Verilog 里我的建议是每个 Agent 对应一个独立状态机模块不要把所有 Agent 混在一起写。比如 Home Agent、Cache Agent、Snoopee 各自维护独立状态机通过接口信号交互。这样最容易定位是哪个 Agent 先进入非法状态。线上很多朋友搜“STM32 按键状态机”“PLCopen 状态机图”其实方法论和协议状态机完全一样拆状态、定事件、画迁移、实现。只是协议状态机的状态更多、并发型更强、时序约束更严格而已。5. PBR 的三个世界别把策略路由和物理地址路由混为一谈如果你现在去搜索引擎敲 PBR大概率会看到两类完全不相干的结果。一类是做 3D 渲染的同学说的 Physically Based Rendering基于物理的渲染天天讲金属度、粗糙度、法线贴图另一类是网络工程师说的 Policy Based Routing策略路由拿 ACL 和路由策略控制流量走向。而互连协议里的 PBR是 Physical Address Based Routing干的事情是根据物理地址决定请求在互连网络里往哪个 Home Node、哪个缓存代理走。这三个 PBR 是三个世界的东西。搞互连协议的人和搞渲染的人聊 PBR彼此都会沉默。所以在看协议资料时不要被热词带到沟里文中的 PBR 一定先看上下文如果后面跟着“路由”“地址映射”“Home Node”那基本就是物理地址路由。调试 PBR 路由时有一个值得分享的小技巧不要靠肉眼读波形去比对 Hash 结果直接在 RTL 里加一个地址到 NodeID 的 monitor把所有请求的物理地址和路由结果自动记录成 log。跑一轮随机测试后用脚本检查同一个地址是否永远路由到同一个目标。只要发现一次不一致就是 PBR 路由功能出了大问题。这种方式比事后追波形高效得多也是我后来在多个互连项目里一直保留的调试手段。另外由于 PBR 路由和缓存一致性目录强相关修改地址映射表时务必考虑运行中的缓存状态。比如你想把某个地址区间从一个 Home Node 迁移到另一个必须先在协议层把相关缓存行逐出或写回确认所有脏数据落位后再改路由配置。否则容易出现“写到 A 家、读却去了 B 家”的灵异现象。这个坑我在早期项目中踩过代价是一整个版本的验证回归重跑。经验就是协议行为要变先让状态机归位再动路由。