企业官网建设流程全解析

上个月调一个缓存一致性的死锁问题，在一台满是逻辑分析仪和协议 trace 的台子上蹲了一周，最后定位到的是一个很少有人注意的CHI Empty 状态在 snoop 命中的边界行为。这让我重新意识到一件事：Scale-up 互连协议里真正值钱的细节，往往不在 ppt 上的架构图里，而在状态机跳转和报文比特位里。大模型把单个计算节点的内存墙和带宽墙逼到极限之后，CHI、CXL、UCIe、TileLink 这些协议被频繁放到一起比较，但"CHI 七态""PBR 路由"具体解决什么问题、在链路层长什么样子，很多人其实是模糊的。这篇文章把这六个开放互连协议放到同一张工作台上，从状态机和比特两个维度做一次完整解剖，重点放在 CHI 七态设计和 CXL 3.x 的 PBR 路由上，适合正在做多 die 互连、异构计算、内存池化以及 SoC 一致性设计的工程师参考。

1. Scale-up 卷土重来：为什么一致性问题从片内蔓延到了机柜

1.1 从 Scale-out 到 Scale-up，算力互联的逻辑变了

过去十年大家谈起大规模计算，默认路线是 Scale-out：一个集群里堆几千台服务器，靠以太网或者 RDMA 把任务拆开。这个模式对训练吞吐还行，但对单个大模型推理、图数据遍历这类强依赖任务并不友好。LLM 集群的瓶颈逐渐从"能不能有足够算力"变成"一台机器能不能装下一个大模型、能不能低延迟访问起全部内存"，于是 Scale-up 重新成了主角。

Scale-up 的典型诉求是：多个芯片或者多台主机进入同一个一致性域，看到同一份内存，某个进程在前一个节点写入的数据，后一个节点无需手动 Flush 就能读到。这比普通消息传递更贴近单机编程模型，代价是协议复杂度从总线级上升到了网络级。

Scale-up 和传统多路服务器里的 CPU 互联很不一样。多路服务器时期，UPI 这类协议只管几个 CPU 插槽之间的缓存一致性，拓扑基本固定，距离短、节点少。AI 时代的 Scale-up 要面对的是 GPU、CPU、内存池、DPU 混合的拓扑，可能有交换机，可能有跨板卡甚至跨机柜的链路。拓扑从一条总线变成一张网，光靠传统的一致性协议是扛不住的。

1.2 协议栈出现了"三明治"结构

现在的互连系统很少是一个协议从头包到尾，普遍是"底层物理传输 + 中间一致性/事务处理 + 上层内存语义"的组合。一个 CXL 内存扩展设备下面跑的是 PCIe 的物理层和链路层，上面跑的是 CXL.mem 的内存语义；一颗复用 CHI 接口的加速器芯粒，内部可能是 TileLink 或者 AXI 做组件互连，到了 Die-to-Die 适配层再用 UCIe 把物理信号送出去。

这种分层带来一个实际问题：每个层级都可以选不同协议，而跨层级组合时，状态机、事务 ID、流控逻辑必须严格咬合。很多人只盯着某一层的协议比较，放到整个 Scale-up 系统里就容易踩坑。所以下面先花一节把这个坐标系拉平，再逐个深入。

2. 六个常被放在一起比较的互连协议，其实处在不同层级

2.1 一份"出身表"看六协议

标题里说的六个开放协议，按我的习惯列一下：

有件事得先说清楚：这里说的"开源"，并不都是源代码级开源。TileLink 是真正 BSD 授权的开放协议，RTL 直接放在 Rocket Chip 里可以随便看；CHI、CXL、UCIe、PCIe 是规范公开的开放标准，配套生态里有大量开源实现或者参考验证环境。所以横向对比的时候我更愿意叫"开放协议族"，但多数讨论场景直接用"开源"两个字的语境也成立。

从这张表能看出来，六个协议并不是竞争关系。UCIe 和 PCIe 解决的是物理层问题，CHI、ACE、TileLink、CXL 解决的是更高层的一致性和内存语义问题。真正的战场在后者，但物理层的选型又会影响前者的效率和成本。

2.2 CHI 和 CXL 为什么总被并列，却不能互相替代

CHI 和 CXL 被放一起比较，是因为它们都在讨论"缓存一致性"，都定义了一组比较完整的状态集合和 snoop 流程。但两者动机差别很大。

CHI 诞生于 ARM 高性能 SoC 时代。多个 CPU 簇和一个统一的 LLC/Home 连在 NoC 上，距离是片上毫米级，节点数量有限，带宽极高，延迟极低。CHI 把请求、响应、数据、监听拆成独立通道，让多个事务可以在 NoC 上并发流水，这是它的一大优势。

CXL 诞生于大数据中心。它要解决的是把远端的设备内存、内存池、甚至另一台主机的内存，以缓存一致的方式接进来。距离从几十厘米到几十米，中间要过交换机和重定时器。CXL 在事务层除了要维护一致性，还必须处理足够大的连接数、跨越交换结构的路径选择、热插拔这类 PCIe 世界带来的问题。所以 CXL 在底层复用 PCIe 的物理/链路层，在路由设计上明显比 CHI 走得更远。

CHI 有清晰的 Home 节点概念，所有复杂请求由 Home 统一协调，适合片上集中式管理。CXL 的拓扑里没有一个假设中的"中心 Home"，多级交换、多主机、多端口同时转发，必须引入更灵活的路由机制。PBR 就是在这个背景下出现的。

3. CHI 七态拆解：MESI 到 MOESI，再到带 Empty 的状态集合

3.1 七态到底多出的是什么

传统一致性协议大家最熟的是 MESI。四个状态：Modified、Exclusive、Shared、Invalid，核心是区分"你独占改过""你独占没改过""大家共享""不在你这"。后来 MOESI 加了一个 O（Owned），允许一个持有脏数据的节点把数据借给别人读，但最终由它负责回写，省去了每次读都要先读到 Home 再转发的问题。

CHI 在此基础上进一步演化，形成了七态。通常指下面这七个：

前五个其实是 MOESI 熟悉的变化，关键是后两个 Empty 状态。Empty 的意思是：这一块 cache line 的 tag 信息在，但数据内容没有拿到。说白了就是"一个空位"。这个设计看着反直觉，实际场景里非常有用。

举个例子，当一个 agent 想要执行一次 ReadUnique 去拿一块独占的缓存行来写，但另一个 agent 还持有一份干净副本时，常规做法是先把数据 snoop 回来再写入，浪费一拍。如果允许先建立 UCE 占位，等数据真正需要时才取，或者配合某些不需要读旧值的写分配策略，就能减少一次无效的数据搬移。再看 SCE，它表示"我参与共享这个地址，但我手里没有数据"，这对 snoop 过滤器的维护很有价值——别人查一致性时知道这个节点也"在群里"，但不会误以为它有数据而要求它回包。

3.2 状态机里一个读请求的完整足迹

拿一个最普通的 ReadShared 请求来走一遍。假设 RN-A 发起读，Home 是 LLC，RN-B 手里有一份 Sc 副本。

RN-A 处于 I，向 Home 发 REQ 通道的 ReadShared。Home 收到后判断：这个地址存在共享副本，于是向 RN-B 发 SNP 通道的 SnoopReadShared。RN-B 回 RSP，说自己有 Sc 副本。Home 收集到所有响应后，向 RN-A 发 DAT 通道的 CompData，把数据带过来，同时更新自己内部的目录信息。RN-A 收到数据，状态从 I 变成 Sc。整个过程要经历 REQ、SNP、RSP、DAT 四种通道，四个参与角色，一拍都不能错。这也是为什么我在调试死锁时最怕看的情况：一个事务卡在 Home 等 RSP 超时，另一个事务卡在 RN 等 DAT，互相等。

如果是 ReadUnique 就复杂多了。RN-A 想独占写，Home 需要确保其他副本全部失效。对持有 UD 的节点，Home 会发 SnoopReadUnique，要求对方回写数据并转成 I；对持有 Sc/UCE 的节点，可以只要求失效。RN-A 最终拿到的是 Uc 还是 UD，取决于它接下来是否真写了数据。这里状态机还要配合缓存替换策略，比如一个 UCE 状态的行被替换时，由于没有数据，它不需要产生回写，直接丢弃 tag 就行。

CHI 七态在实际工程里"够用但费神"。每个状态都要在 snoop 过滤器和数据 RAM 两边维护，验证的状态转换矩阵比 MESI 大好几倍。尤其是 Empty 状态，如果数据 RAM 里有 tag 位却没有有效数据位，一旦 snoop 过滤逻辑写错，很容易出现"地址命中但从空 RAM 里读出了随机数据"这种极难复现的 bug。

3.3 七态对比 ACE 和 CXL 的一致性状态集合

ACE 的一致性模型基本还是 MESI，实现相对简单，在总线带宽要求不太高的场景下很成熟。CXL.cache 的状态集合在我看来更接近一个工程化裁剪版：它需要支持设备端缓存，但设备的缓存不可能像 CPU 那样维护太多共享表项，所以它把状态控制在比 MESI 多一些但比 CHI 简单很多的范围内，并引入 Back-Invalidation 机制，让 Home 可以主动通知设备端某行失效。

CHI 的七态在片上 NoC 这样延迟极低、带宽极高的环境里能发挥最大价值。一旦距离拉长、延迟变大，状态机每一步交互的代价都会被放大，CXL 那套"能少走一步就少走一步"的设计就更实用。这是我在对比两个协议时最深的感觉：状态集合的大小不是越全越好，要看物理环境能不能支撑得起这么多状态带来的交互开销。

4. 比特层面解剖：CHI 报文在链路上究竟怎么组织

4.1 REQ、RSP、DAT、SNP 四通道与事务流水账

CHI 的事务层定义了四个逻辑通道，分别承担不同职责：REQ 是请求者向 Home 发起的操作，RSP 是参与节点向 Home 返回的结果，DAT 负责传输数据，SNP 是 Home 向其他可能持有副本的节点发出的监听。四个通道相互独立，意味着一个事务在 NoC 上可以拆成多个阶段同时跟其他事务交错，流水线利用率和总线利用率都能提高。代价也很现实：你必须为每个通道准备独立的 credit 流控，通道之间一旦出现 credit 互相等待，死锁排查就非常酸爽。

链路层把事务层报文封装成 packet，通常以 flit 为单位在物理链路上传输。一个 packet 包含 header 和可选的 data payload。header 里最关键的信息是事务 ID（TxnID）、源 ID（SrcID）、目标 ID（TgtID）和操作码（Opcode），这三者共同决定一个请求从哪里来、到哪里去、对应哪个事务。这里要特别强调：当一个 REQ 因为超时被重发时，TxnID 不能简单地重新利用，否则新旧两个事务会同时在系统里乱窜，数据一致性会出问题。

4.2 把典型 REQ Header 的字段逐个拆开

CHI 的字段位宽在不同实现里是可配置的，我见过的最小配置和最大配置能差出一倍多。下面用一份比较典型的工程配置来展示字段设计逻辑：

这些位加起来已经超过 100 位，实际还会加上 tunable 的 metadata 位。从设计角度看每个字段都代表一次权衡。Addr 用 44 位可以把 16TB 物理地址空间都覆盖到，但对一个只做 CXL 内存扩展的设备芯片，42 位甚至 36 位就够了，省下的位数可以转给 SrcID 或者 TxnID，提高并发事务数。SrcID 和 TxnID 的位数决定了系统最多能同时承载多少在飞事务，这是 Scale-up 系统估算带宽时一个关键参数。

我遇到过一种情况：为了降低布线压力，把 SrcID 截短，结果系统在某个聚合场景下大量事务因为 ID 冲突被 stalls。要定位这类问题，最直接的办法是抓链路层 flit，把每个 packet 的 SrcID+TxnID 拉出来做重叠统计。一旦发现某个 ID 对的重叠率超过一定阈值，基本可以断定 ID 空间给少了。

4.3 DAT 通道与链路效率的计算

DAT 通道的 payload 里最核心的是 cache line 数据，再加上字节有效位、CRC/ECC 校验位。以 64B cache line、128 位物理链路位宽为例，一次 ReadShared 事务大概可以这样估算链路消耗：REQ header 一个 flit，SNP header 一个 flit，RSP header 一个 flit，DAT 需要 4 拍左右把 64B 数据带完，加上校验，整个事务在数据通路上要占用大约 7 到 8 个 flit 时间。如果链路上只有一个事务在跑，利用率很低；只有靠多事务流水交错，才能把有效数据占比提上去。

这也是为什么 CHI 这类协议强调"多通道并发"的原因。光看单事务延迟，可能不如简单总线直接；看吞吐，流水线优势就非常明显了。比特层面的效率从来不是单看一拍能传多少数据，而是看在重负载下协议控制头和数据 payload 的比例是否合理。

5. PBR 路由：当互连不再是一根总线，而是一张网

5.1 为什么 Scale-up 协议必须解决路由问题

CHI 的七态解决的是"一个缓存行可以处在什么状态"，但状态机必须建立在"请求能送达正确节点"的基础上。片上 NoC 的路由相对简单，大多是固定的 mesh 或环形拓扑，地址和节点 ID 跟物理位置有明确对应。一旦 Scale-up 拓扑引入交换机、多级组合和动态路径，问题就变成：一个包里装着的目标 ID，经过中间的交换结构时，谁来决定往哪个端口转发？

CXL 3.x 给出的答案之一是 PBR，Port Based Routing。这个名字直译是"基于端口的路由"，但它更多是一种转发思想，而不是像 IP 路由那样维护一张全网路由表。PBR 的核心是每个交换端口维护一个转发表：进端口之后，根据包的目的信息查表，确定要出哪个端口，然后原样转发。

5.2 ID-Based Routing 遇到规模问题，PBR 如何破局

早期 CXL 交换机的转发方式主要是 ID-Based Routing。它很直观：每个目标组件分配一个 ID，交换结构内部维护 ID 到端口的对应表。拓扑简单时非常好用，一个包进来查一次表就知道往哪走。可一旦拓扑变成多级交换、多个内存池挂在不同层级、设备热插拔频繁，ID-Based Routing 的表项数量和更新复杂度会迅速失控。每个交换机都要知道全局 ID 信息，端口上有一点拓扑变化，相关表项都得同步，这在数据中心规模下很痛苦。

PBR 的思路更像是二层交换机的 MAC 学习/转发表。它不要求每个交换机理解全局拓扑，只要求在某个端口上收到包的时候，根据包的关键字段对照本端口的转发表项，决定下一跳方向。这样每一级交换机只需要维护与当前端口相关的表项，规模大了以后表项不会无限膨胀，拓扑变更的影响也被限制在局部端口。

在实际实现里，PBR 和 ID-Based Routing 并不是非此即彼。一个大型 CXL Fabric 可能用 PBR 做核心转发的骨架，在请求路径上用 ID 做端到端关联，在响应路径上依靠 PBR 表把完成数据准确定位到具体端口。这也解释了为什么在协议 trace 里你会看到同一个事务在入口和出口打上不同的转发标签，这是交换结构在"翻译"路径信息。

5.3 PBR 与一致性状态机在端到端路径上的配合

这里有一个容易混淆的认知：PBR 只解决"包往哪走"，它不会改变 CHI 或 CXL 的状态机。一致性状态永远由链路端点的缓存管理器和 Home 节点维护，PBR 只是一个透明的传送者。但 PBR 引入后带来一个非常实际的工程问题：回包路径和请求路径可能不一致。

一个请求从端口 1 进来，PBR 表把它的响应留在端口 4 出去，这是完全合法的。但如果表项更新滞后，或者响应包的某些字段（比如 SrcID）在交换结构里被改写后没有正确还原，回包就可能从另一个端口跑掉，导致事务悬挂。所以你现在回头看 CHI 七态里那些"等 RSP 超时"的死锁场景，在带 PBR 的 CXL Fabric 里会以更大规模的形式重演。调试这类问题，我的习惯是先在交换结构入口给每个事务打一个全局时间戳，看它进入和离开的端口时间线，再结合端点的状态机 dump 做对齐，比漫无目的地翻报文要快得多。

从 CHI 七态到 PBR 路由，背后的思维变化很清楚：状态机把缓存行的正确性管好，路由机制把请求的抵达管好，两者分开解决，又必须合在一起调试。这种"事务状态"和"传输路径"的分离，是新一代互连协议最关键的设计哲学。

6. 六协议横向对比：延迟、带宽、实现成本的真实取舍

6.1 一张表看关键指标

把前面梳理的信息压缩成一张对比表，方便做选型参考：

这张表最大的价值不是判断谁"更强"，而是帮你看清每个协议所处的位置。CHI 的性能上限极高，但把它拿到机柜级距离上跑，光是链路层重传和延迟补偿就够喝一壶；CXL 在机柜级很方便，但它依赖 PCIe 物理层，端到端延迟比 CHI 这种片上协议高一到两个数量级；UCIe 根本不回答一致性状态问题，但它决定了上层协议到底能在多宽的物理管道上跑。

6.2 选型逻辑：按场景倒推协议

我个人的选型习惯是先画拓扑，再数跳数，最后才做协议决策。

如果是多 die 封装内的一致性互连，die 之间距离在毫米级，节点的数量在几个到几十个，优先考虑 CHI 或者 TileLink。CHI 的成熟度高、验证生态全，但授权和 IP 成本高；TileLink 在开源 RISC-V 生态里非常好用，源码就在手边，改起来没有障碍。这里有个工程判断：如果团队能接受开源的调试链路，TileLink 的性价比往往比 CHI 更高；如果目的是做成通用对外接口、跟第三方 IP 无缝对接，CHI 的兼容性优势就体现出来了。

如果是把多个主机和内存池拉进同一个一致域，距离到板卡级甚至机柜级，基本只能选 CXL。CXL 的 PBR 支持让多级交换机拓扑成为可能，内存池化、多主机的热插拔和故障隔离也都有配套机制。现阶段做 Scale-up 系统，CHI 和 CXL 很可能同时存在：芯片内部走 CHI，跨芯片/跨卡走 CXL，中间用一层协议转换逻辑把两套状态机和事务 ID 映射起来。这个转换层是很多项目里最薄弱的环节，也是最容易出死锁和性能拐点的地方。

UCle 和 PCIe 更多是底座选择。UCIe 承载的是 die-to-die 物理链路，如果上层跑 CHI、CXL 或者自定义协议，UCIe 不挑食；PCIe 则是 CXL 绕不开的底层。选择时重点看链路速率、封装形式、功耗和信号完整性需求，而不是纠结它有没有一致性状态。

7. 动手验证：在开源工具链里把状态机跑起来

7.1 我建议的复现路径

理论说再多，都不如把状态机跑起来来的直观。要实际看一个缓存一致性协议的状态转换，最省事的是走 TileLink。Rocket Chip 和 Chipyard 里的 TL-C 实现是完全开源的，配一个带 L2 缓存和多个 tile 的配置，用 Verilator 仿真，再加一个简单的 liveness 脚本触发多个核同时读写同一地址，然后打开总线 trace 看 A、B、C、D、E 五个通道的握手序列。你能亲眼看见一个 request 如何从 A 通道进入。C 通道如何做 cache release，D 通道如何带数据回到请求者。

CHI 这边开源 RTL 相对少一些，但可以走验证 IP 路线。不管是商业的还是开源的 UVM 环境，都可以先构建一个最小的 RN 和 Home 对，发一轮 ReadUnique，再把 snoop 命中打开的覆盖场景扩展出来。重点观察：当另一个 RN 持 UD 时，SnoopReadUnique 的回写路径是否正确；当持有的是 UCE 时，它会不会错误地回写数据。后一种情况是 UVM 随机验证最容易砸出来的 bug，因为很多测试激励根本没构造过"没有数据的 tag 命中"。

CXL 的验证链路比较成熟的是用 QEMU 和 EDK2 做软件层模拟，再配合 CXL 一致性测试套件。但要注意，软件模拟里的 CXL 一致性模型和真实 RTL 的仲裁、credit、PBR 转发行为差得很远，验证 Fabric 级别的 PBR 路由最好放到完整的硬件仿真环境里，至少要有两个交换机级别节点，才能把回包路径不一致这种问题暴露出来。

7.2 我在实操中踩过的坑

第一个坑是协议版本混用。CHI Issue B 和 Issue C 链路层的 flit 格式不兼容，CXL 1.x 和 CXL 3.x 的许多报文字段也变了。不同小组各拿一个版本做集成，接口对接时 port width 和字段位宽对不上，跑起来直接卡死。我的习惯是集成前先做一次协议版本登记，把每个接口用的 spec 版本、flit 大小、ID 位宽写成一张表，挂在 wiki 上强制评审。

第二个坑是 Empty 状态导致的"幽灵数据"。系统里同时有真实缓存数据 RAM 和 tag RAM，Empty 状态只在 tag RAM 里有记录。如果 snoop 过滤逻辑没有把 Empty 行单独排除，一个读请求命中了这块 tag，会把不属于该行的随机数据当成有效数据返回。这个问题在单核 debug 时很难暴露，多核并发一多就神出鬼没。定位方法是在 tag RAM 里单独加一个 Empty 标志位，并在读写数据 RAM 的所有路径上做断言。

第三个坑是 PBR 表项和事务 ID 之间的时序。交换结构更新 PBR 表时，在飞的旧事务如果还引用旧端口，回包就会走错路。处理这类问题，要么在更新表项前先阻塞新请求，让旧事务全部 drain；要么设计为允许旧事务通过独立的慢路径完成。我见过因为贪图性能不做 drain 导致整个 Fabric 挂死的案例，性能优化可以后面再做，先保证一致性逻辑在极端情况下是安全的。

再分享一个小技巧：不管做哪类一致性调试，都值得在协议 trace 里加一个"状态+地址"的二维日志。单纯抓字段只能知道有什么报文在跑，加了状态和地址的联合日志，才能一眼看出某个 cache line 从 I 到 UC 再到 UD 的完整轨迹，配合地址过滤能迅速缩小可疑范围。这个习惯帮我在好几次死锁排查中省下一整天的纯机械比对时间，希望对你有用。