芯片互连协议深度对比：CHI七态与PBR路由在Scale-up场景中的工程实践

做芯片互连的朋友应该都有一种体验：平时聊协议头头是道，一旦落到 RTL 里写状态机，或者在上板后抓 Deadlock，才发现那些“资历很老”的互连协议每个都有自己的脾气。尤其 Scale-up 场景，核数翻倍、内存距离拉长、缓存一致性域变大，协议一个字节的字段设计差异，最后都会变成面积、功耗、时序和验证成本上的真金白银。

今天这篇文章，我把目光聚焦在六个在开源/开放生态里经常被拿来对比的互连协议：TileLink、CHI、AXI4、CXL、UCIe、OCP。不聊 PPT 上的“带宽多少、时延多低”，而是直接下探到比特和状态机层面：报文里哪位是路由信息，哪位是 Poison 位，状态机里哪条迁移路径最容易死锁，仲裁器面对多个返回事务时又该怎么选。标题里那个“CHI 七态”也好，“PBR 路由”也好，今天都会掰开揉碎讲清楚。

这篇文章适合的人也很明确：准备在 Scale-up 项目里选互连协议但拿不准主意的架构师；被 Cache Coherence 状态机折磨过的验证工程师；以及想从 RTL 层面真正理解协议差异的芯片设计学生。看完之后，你可以直接拿这套对比方法和排查思路去套自己的项目。

1. 为什么 Scale-up 场景要把协议拆到比特级看

1.1 Scale-up 互连到底在解决什么问题

先对齐一下概念。Scale-up 和 Scale-out 最大的区别，在于 Scale-up 是“把一台机器的能力往上堆”：加核、加内存、加加速器，但所有资源仍然在同一个一致域里，操作系统看到的是一整台逻辑机器。Scale-out 则相反，靠网络把多台机器连起来，一致性问题通常丢给应用层或者分布式框架去处理。

Scale-up 场景里，互连协议要面对的挑战非常具体：缓存一致性广播域变大，监听/目录请求的时延必须可控；内存带宽需要翻倍，片间链路上的数据位宽和频率都在飙升；还有新硬件加入，比如 CXL 内存扩展、UCIe Chiplet，这些设备可能没有传统 Cache Master 的状态机，却要参与一致域内的读写。

这时候，如果你只看协议手册里的“特性支持”表格，很难回答几个关键问题：这个协议会不会在某个 corner case 下等不到响应？事务在路由器里绕圈会不会整条链路堵死？升级一个协议版本，我的 RTL 要改多少个状态？答案全部藏在报文格式和状态转移图里，必须在比特和状态机层面看协议。

1.2 比特级视图：协议本质是信号的约定

比特级解剖互连协议，说白了就是看两种东西：信号线或报文里的字段定义，以及字段在不同事务类型里的含义。

以 AXI4 为例，它拆成五个通道（读地址、读数据、写地址、写数据、写响应），每个通道里除了数据、地址，还有 ID、Len、Size、Burst、QoS、Region 这些信号。看起来不复杂，但 Scale-up 场景一旦引入多路互连，ID 的分配策略、Outstanding 事务数量、乱序返回能力，都会直接决定系统能不能跑到满带宽。

到了 CHI、TileLink 这类带一致性的协议，比特级的信息量会暴涨。CHI 的报文里除了地址和数据，还带 NodeID、TXID、TgtID、Opcode、Resp、Tag、Poison 等一堆控制位。Tag 用来做数据流控制，Poison 用来标记数据损坏，Resp 字段要区分 Comp、CompData、CompCMO 等等。TgtID 和 NodeID 怎么编码，直接决定了路由器能不能高效做分布式路由。

TileLink 和 CHI 不完全一样。TileLink 的通道设计是 A、B、C、D、E 五个虚拟通道，每个通道都有 Opcode、Param、Source、Sink 等字段。Source 是客户端 ID，Sink 是管理器 ID，Param 在不同通道里含义不同，在 A 通道里代表权限类型，在 B 通道里代表 Probe 的原因。这些字段在比特层的可读性比 CHI 好不少，但灵活性不如 CHI。

CXL 呢，它的链路层基于 PCIe 物理层，但事务层完全是另一套协议。CXL 有三种类型：CXL.io（类似 PCIe 事务）、CXL.cache（设备主动缓存一致性）、CXL.mem（内存语义访问）。其中 CXL.mem 的报文里，地址和元数据是混在一个 68B 或 256B FLIT 里的，D2D（Device-to-Device）路由信息的编码方式，直接影响内存扩展场景下的跳数。

UCIe 比较特殊，它更多定义物理层和裸片间适配层，协议层往往透传 CHI、CXL 或者自定义协议。但 UCIe 的 FLIT 格式、Sideband 信号、CRC/Debug 字段仍然很重要，因为这些比特决定了跨 Die 传输时谁先发、谁等待、出错怎么重试。

所以，比特级视图解决的是“协议到底怎么说话”的问题。不考虑编码细节，你连一个协议的 QoS 怎么实现都说不清楚。

1.3 状态机视图：协议同时是行为的约束

比特级视图告诉你协议说什么，状态机视图告诉你协议做什么。互连协议里的状态机，通常分为两类：一类是缓存一致性状态机，一类是链路/传输状态机。

缓存一致性状态机最经典的就是 MESI、MOESI，还有今天要聊的 CHI 七态。这类状态机的输入是 CPU 本地请求、片上监听请求、写回请求等等，输出是缓存行的状态切换和报文发送。状态机设计得不好，轻则多打一拍（额外延迟），重则整个系统死锁。

链路/传输状态机则包括路由状态机、虚拟通道信用状态机、重试状态机等。PBR 路由机制在报文层面做路径选择，但路由决策最终要在状态机层面落地。比如每个路由器端口维护队列状态、仲裁状态、信用计数，一旦某个队列满，上游必须停发，否则丢包或死锁。

在一篇博文里把两类状态机全拆一遍不现实，我选择两个最关键的切入：CHI 的七态状态机讲一致性，PBR 路由讲报文在互连网络里怎么流动。

2. 六个协议选型与整体架构对比

2.1 这六个协议分别是什么

开始字节级对比之前，先把我选的六个协议是什么、来自哪个生态、解决什么问题说清楚。这样后面聊状态机时，你不至于串台。

先声明一个概念：严格说起来，CHI、AXI4、CXL、UCIe 都属于开放标准，而不是开源软件意义上的许可证协议，它们由 ARM、CXL 联盟、UCIe 联盟等组织维护，规范文档公开，但 RTL 代码不一定开放。TileLink 是真正在 RISC-V 开源社区里长出来的协议，Rocket Chip、SiFive 的很多设计里都带 TileLink 实现。OCP 是更早时期的开放核心协议，现在已经不活跃，但它的很多思想（请求/响应分离、并发传输）至今仍值得看。

2.2 为什么选这六个

选择这六个，不是因为它们是同一类东西，而是因为它们刚好覆盖了 Scale-up 互连的不同层次。

TileLink 和 CHI 是“一致性协议”的代表，一个来自开源 Chisel 生态，一个来自 ARM 体系，拿它们俩做状态机对比最有价值。AXI4 是“非一致性数据传输协议”的代表，Scale-up 系统里依然有大量寄存器配置、DMA、流式数据传输走 AXI4。CXL 是现代 Scale-up 内存和加速器互连的关键协议，直接从缓存一致性扩展到内存语义。UCIe 是 Chiplet 时代的物理/适配层标准，多个 Die 拼接成一颗大芯片时，它就是低位宽的“最后一段路”。OCP 虽然老，但它是很多现代协议的前身，拿来当横截面参照刚好。

这套组合还有个好处：协议复杂度是一个阶梯。OCP 和 AXI4 相对简单，适合先看比特；TileLink 和 CHI 进入一致性状态机；CXL 把一致性、路由、内存语义揉在一起；UCIe 再把视角拉回物理层和跨 Die 适配。一路看下来，你对“协议到底在哪些层面做事”会有完整的概念。

2.3 协议分层：别拿物理层去比事务层

做协议对比最容易犯的错误，就是拿一个协议的事务层去比另一个协议的物理层，然后得出“XX协议明显不行”的结论。实际工程里，协议是可以纵向叠放的：UCIe 在底下，上面透传 CHI 或 CXL；CXL 在中间，宿主端用 PCIe 物理层，设备端还要跑 CXL.cache/CXL.mem 状态机；AXI4 可以在最外层做 IO 互联，但一致性任务交给 CHI 去管。

要真正解剖协议，建议先把每个协议按照物理层、链路层、事务层、一致性层四个维度拆开。物理层管电平、时钟、均衡；链路层管 FLIT 对齐、CRC、流控（Credit）；事务层管读写请求、完成响应、错误报告；一致性层管缓存状态、监听、写回。CHI 的“七态”是在一致性层回答问题；PBR 路由则横跨链路层和事务层，因为路由表要查报文里的目标 ID，而 Credit 流转又发生在链路层。

分层看协议，还有一个额外的好处：替换某个层次时，你很清楚接口应该切在哪里。比如你用 UCIe 承载 CHI 报文，只需要把 CHI 的 flit 做一次适配，不用改 CHI 的状态机。

3. 从 CHI 七态看一致性状态机设计

3.1 状态建模：从 MESI、MOESI 到 CHI

讲 CHI 七态之前，先回到经典一致性模型。MESI 有四个状态：Modified（唯一脏）、Exclusive（唯一干净）、Shared（共享干净）、Invalid（无效）。MOESI 加了一个 Owned（共享脏）。MESI 的问题是，如果多个 CPU 共享读一个缓存行，其中一个 CPU 改了数据，其他 CPU 必须收到监听，而且不能把陈旧数据落到内存里，否则要用总线事务去处理。

MOESI 的 Owned 状态允许某个 CPU 持有脏数据，但其他 CPU 也持有同一份数据的副本，读请求可以直接从持有 Owned 的 CPU 拿数据，不需要先把脏数据写回内存。这个设计减少了很多不必要的内存访问，代价是状态机更复杂：一个行可能出现“多份共享 + 一份脏副本”的组合，而这份脏副本要始终知道自己承担着“为其他共享者提供数据”的责任。

CHI 在状态建模上进一步往前走。CHI 的缓存行状态不再停留在 MESI 这种“枚举”概念上，而是把“唯一性”和“数据有效性”拆开考虑。每个缓存行可以归属某个 Home Node，Home Node 记录这个行被谁以什么权限持有。RN-F 和 RN-I 节点向 Home Node 发请求，Home Node 再通过 Snp 消息去监听其他节点。

CHI 的缓存行状态集合，在网上有“七态”的口头说法。这个“七态”并不是所有 ARM 文档里都有个显眼的七格子列表，而是工程师在使用 CHI 做协议分析时，对稳定状态和过渡状态的一种归纳。

3.2 七态到底指哪七个

我习惯把 CHI 的缓存状态用三个维度去看：Unique/Shared（独占还是共享）、Clean/Dirty（是否和内存一致）、Data/Empty（缓存行数据是否有效）。三三得八，理论上有八个组合，但在 CHI 的实际状态机里，大多数情况下只使用其中一部分。

经常被列出来的稳定状态有六个：

UCE 是 CHI 相对传统 MOESI 增加的一个重要状态。它表示这个节点虽然拿到了唯一权限，但缓存行里还没有有效数据。这种状态在“分配但不填充”或“写入部分数据”的场景里非常有用。比如你要对一个 64B 缓存行做 32B 写操作，可以先申请为 UCE，再写入其中的 32B，而不需要先把整行从内存读出来。

那么第七个状态是什么？不同资料口径不一。有些资料把带上 Error/Poison 标记的无效数据状态算进去，有些把 I/O Device 访问时使用的“Non-Cacheable”状态归进来。从我实际做协议验证的经验看，与其纠结第七个格子叫什么名字，不如记住一个结论：CHI 状态机的核心不是“七个状态本身”，而是状态之间有哪些迁移路径、哪些迁移需要 Home Node 介入、哪些迁移会导致数据写回。工程建设永远要落在迁移路径上，而不是状态名词上。

3.3 一次读请求的状态迁移走查

用一个具体场景来说明七态状态机怎么工作。

场景：两个 CPU 都通过 RN-F 节点挂在互连网络上，CPU0 对地址 A 发起一次 ReadShared 请求。假设地址 A 在 CPU1 的 L2 Cache 里当前处于 UD（Unique Dirty）状态。

第一步，CPU0 的 RN-F 发起 ReadShared，报文先到地址 A 所属的 Home Node。Home Node 查目录，发现 CPU1 持有该行的唯一脏副本。

第二步，Home Node 向 CPU1 的 RN-F 发 SnpShared，也就是监听请求，询问 CPU1 是否愿意把自己的唯一脏数据共享给别人。

第三步，CPU1 的状态从 UD 迁移到 SD。这就是 CHI 里很有意思的一步：CPU1 不需要先写回内存，而是直接把数据返回给 Home Node，再由 Home Node 转发给 CPU0。CPU1 保留一份数据，状态变成 SD，它仍然是这份共享数据里的 Owner。

第四步，Home Node 把数据以 CompData 方式返回给 CPU0，CPU0 的状态变成 SC。

第五步，如果后面 CPU0 要写这个地址，发 ReadUnique 请求，Home Node 会给 CPU1 发 SnpUnique，CPU1 收到后必须把自己的 SD 行置为 I，如果数据脏，则把数据写回内存，写回完成后 CPU0 拿到唯一权限。

这个走查看起来简单，但里面隐藏了几个 Scale-up 场景特别在意的点：SD 状态存在的时间窗口，决定了监听时延；数据是否需要写回，决定了内存带宽；UCE 状态的处理方式，决定了 Partial Write 场景的性能。

3.4 TileLink 与 CHI 的状态机对比

TileLink 的一致性状态模型和 CHI 不完全一样。TileLink-C 的缓存状态来自自家的一套定义，最常见的说法是五个状态：Invalid、Clean、Dirty、Shared、Missed？其实 TileLink 把权限和有效性拆得更开：每个缓存行持有状态可以用三层位来表示，分别是 Valid、Dirty、IsHit？我用更工程化的方式描述：

在 Rocket Chip 的 TileLink 实现里，缓存行状态通常被归纳为 I（Invalid）、C（Clean，共享或独占但未写）、D（Dirty）、以及带 Probe 处理时的过渡状态。TileLink 的设计哲学是让状态机更规则化，五个通道 A/B/C/D/E 对应不同的传输阶段：A 通道发起请求，B 通道接收上级的 Probe/访问请求，C 通道返回响应或转发探测的数据，D 通道把数据/响应发给请求方，E 通道结束整个事务。

对比 CHI 和 TileLink 状态机，有几个显著差异。

CHI 的 Home Node 概念比 TileLink 更明显。CHI 的每个地址归一个 Home Node 管，Home Node 拥有目录、可以发起监听、裁决数据返回。TileLink 里没有严格的 Home Node 概念，每个 Manager 可以自主决定是否响应、如何处理 Probe，目录逻辑通常由 L2 控制器自己实现。这意味着 TileLink 协议本身更“软”，但实现起来更容易出现各种私有扩展。

状态粒度方面，CHI 的七态模型比 TileLink 的经典状态更细，尤其是 UCE 状态，给 Partial Write 和 DMA 操作带来了明确定义。TileLink 想做到同样效果，更多是靠 Manager 端的 policy 控制，而不是协议状态本身。

事务间依赖方面，CHI 用 TXID 和 TgtID 来跟踪事务，还定义了 Comp、CompData、CompCMO 等完成类型，事务生命周期非常清楚。TileLink 用 Source 和 Sink 做事务配对，语义简单，但事务层级更浅，复杂的一致性协议（如分布式共享内存）在 TileLink 上要自己做扩展。

4. PBR 路由机制与协议报文的落地

4.1 PBR 是什么

聊完微观状态机，再看宏观路由。标题里的“PBR 路由”，在不同语境下有不同全称。在网络设备语境里，PBR 常被写成 Policy-Based Routing（策略路由），意思是根据源地址、端口、协议类型等策略来决定报文走哪条路径，而不是只按目的地址查最长前缀。在互连协议语境里，我更多把它理解为 Packet-Based Routing（基于包的路由）或者基于策略的路径选择：每个报文到了路由器之后，路由器要决定送到哪个输出端口，依据是报文头里的地址、目标 ID、流量类型，以及当前网络的拥堵状态。

不用纠结缩写本义，重点在于 PBR 解决的是什么问题：在一张由多个路由节点（RN、HN、SN、路由器）组成的互连网络里，怎么让一个报文从源节点到达目标节点，同时又不能让两个报文互相等待对方释放资源，也就是不能产生协议死锁或路由死锁。

传统 NoC 里的路由算法有确定性路由（如维序路由）和自适应路由（根据拥堵状态选路）两大类。互连协议里做 PBR，通常也是先确定一个无死锁的路由函数，再叠加策略。比如 CHI 的路由器可以根据 TgtID 查路由表，也可以根据 QoS 字段选择不同虚拟通道（VC）。CXL 的“路由”也在链路和事务两个层面出现：物理层用 PCIe 的 BDF 和 TC/VC 做初步分类，协议层再用 HDM（Host-managed Device Memory）地址区间决定去某个内存设备还是去对端 Cache。

4.2 六个协议各走各的路由路

先把六份协议在路由方面的设计逐个过一遍，你会发现它们对“路由”这件事的抽象层次完全不一样。

AXI4 的路由最朴素，完全靠地址解码。每个 Slave 的地址区间在系统里被预先划分好，Master 发出事务后，互联矩阵根据地址高比特位选择一个或多个 Slave，如果碰到多个 Master 同时访问同一个 Slave，就由互联矩阵内部的仲裁器按优先级或者轮询选一个。AXI4 没有显式的报文头里的“目标 ID”概念，ID 只是用来匹配同一笔事务的读写请求和响应。所以 AXI4 只能做到“固定地址映射 + 静态路径”，做不了自适应路由。

OCP 比 AXI4 抽象高一截。OCP 有明确的命令通道和数据通道，命令通道里有 Address、Cmd、DataValid 等信号，从设备根据地址和命令类型决定是否接受请求。OCP 的路由逻辑同样以地址解码为主，但 OCP 的请求/响应分离做得更彻底，支持多个 Outstanding 并发，每个请求带 ThreadID 或 TagID，响应可以乱序返回。这为后来很多 SoC 互连 IP 奠定了基础。

TileLink 的路由逻辑和 AXI4 类似，靠地址解码找到目标 Manager，但 TileLink 的事务并发机制更强。每个 Client 维护一组 Source ID，每个 Manager 维护一组 Sink ID，事务的请求/响应通过 Source 和 Sink 配对，可以支持大量 Out-standing 事务。多 TileLink 互联时，需要增加 DoNotBypass 等信号来防止乱序穿越。

CHI 的路由信息在报文头里非常明确。每个 CHI 报文都有 NodeID、TXID、TgtID，路由器拿到 TgtID 就能查表往目标节点方向转发。CHI 还支持多种 Home Node 分布方式：可以是集中式目录，也可以 Per-Address 做地址哈希分布到多个 Home Node，这样路由表就不是一张大表，而是可以分布式实现。监听请求则通过 Home Node 向多个目标节点广播或组播，这会带来路由扇出和响应聚合的复杂度。

CXL 的路由是另一个路数。CXL.cache 和 CXL.mem 报文在链路层被封装成标准 FLIT，链路层路由依赖 PCIe 的 Requester ID/Device ID，相当于在“路由表”里每个 Endpoint 有唯一标识。CXL 还引入了 ARB/MUX 级别的选择逻辑，Host 侧可以支持多个 CXL 设备同时访问，设备侧要能区分来自不同 Host 的消息。更重要的是，CXL 里有一个 HDM（Host-managed Device Memory）机制，设备内存被映射到主机物理地址空间，主机发起的访问就能直接通过地址解码找到设备，而不需要设备参与复杂路由。

UCIe 作为 Die-to-Die 互连，它的路由更像“最后一跳的搬用工”。多个 Die 拼接时，UCIe 定义了 Die-to-Die 适配层，可以把 CHI/CXL 等的报文包成 UCIe FLIT，在物理链路上传输。UCIe 本身不一定做多跳路由，但如果一个 Chiplet 内部有多个 Die 或多个端口，UCIe 需要支持简单的端口选择策略。此时，上层协议的 TgtID / 地址信息会透传到 UCIe 适配层，由适配层决定发给哪个物理端口。

4.3 路由死锁与扰流机制

PBR 路由设计里绕不开的话题是死锁。Scale-up 互连网络不是一根线，而是一张网。路由器之间可能存在环形依赖：A 等待 B 释放缓冲区，B 等待 C，C 又等待 A。如果不做设计约束，任何报文都可能卡死在环里。

互连协议层面常见的解法有三种。第一种是维序路由，先沿一个方向走完，再换到另一个方向，保证不会出现“我占着东向路由去等西向缓冲区”的环形等待。第二种是虚拟通道（VC），把同一个物理通道拆成多个逻辑通道，不同类型的报文走不同 VC，这样读请求、读数据、监听、写回可以分开排队，防止“响应等请求、请求等响应”的协议死锁。第三种是 PBR 里可以叠加的“策略”：比如高优先级流量可以抢占低优先级 VC，低优先级的包必须定期放行，防止活锁。

CHI 对死锁非常敏感，因为它的监听（Snp）和响应（Comp）是多对多的。如果一个 RN 发出读请求后，又收到了针对同一个地址的 SnpUnique，而它的读请求正在等 Home Node 返回数据，这里如果处理不好就会卡死。CHI 的应对方式是明确规定监听请求可以随时插入，但节点必须在发送端维护好信用（Credit）和缓冲区，保证在收到监听时至少能接收并处理，同时还要在状态机里定义“从监听返回响应”和“从普通请求返回响应”之间的优先级。

CXL 在路由死锁上继承了 PCIe 的 TC/VC 机制，又增加了 FLIT 级流控。CXL.mem 的访问有严格的信用控制，设备侧和主机侧通过 Link Layer Credit 来防止对端队列满。遇到出错或重试时，CXL 定义了重试机制，但重试包能走与原始包相同的 VC，避免绕路导致乱序。不过，CXL 设备如果同时支持 CXL.cache 和 CXL.mem，需要在内部状态机里处理好“同一个地址既被缓存又被内存映射访问”的冲突。

TileLink 的死锁约束比 CHI 松散一些，因为它没有强制的 Home Node 角色，所以设计者可以自由实现目录逻辑。但这种自由很可能变成验证灾难：如果 Manager 在处理 A 通道请求时又向 Client 发起 B 通道 Probe，而 Client 的 C 通道恰好被自己的请求占满，双向等待就会产生死锁。Rocket Chip 的 L2 实现里花了很大功夫去保证 B、C 通道的响应总会被处理，而不是无限等待。

5. 实操过程：比特与状态机双重解剖

5.1 从协议文档到状态转移表

我在实际做协议对比时，第一步从来不是直接看文档里的规范正文，而是先把“状态转移矩阵”拉出来。

方法很简单：列出这个协议涉及的所有稳定状态，再列出所有能够触发状态变化的输入事件，比如本地读、本地写、监听读、监听写、写回、替换、错误恢复。然后一格一格填：这个状态收到这个事件后，新状态是什么，要发出什么报文，要不要写回内存，是否需要等待响应。

以 CHI 为例，我会针对某个缓存行状态（比如 UD）列出收到 ReadShared、ReadUnique、ReadClean、SnpShared、SnpUnique、SnpClean、WriteBack 等事件后的迁移结果。这张表填完之后，协议里最容易出错的地方就浮出来了：哪些事件会让状态进入“等待数据返回”的中间态？中间态里如果又来一个监听，状态机还能不能响应？CHI 的事务状态和缓存状态是分开的：缓存行有缓存行的状态，事务有事务的生命周期状态，两者耦合时最容易出 bug。

TileLink 同理，但我会额外看 A、B、C、D、E 五个通道的握手关系。比如某个 Client 发出 A 通道的 ArithData 请求后，理论上应该在 D 通道收到 Data 或 Error 响应。如果 D 通道还没回，B 通道就收到了 Probe，这时候 Client 的缓存状态机必须能在“等待数据”的中间态正确处理 Probe，否则就会死锁或丢失一致性。

5.2 用开源实现做交叉验证

文档上的状态转移表是“应然”，RTL 里的状态机是“实然”。两者对不上，就是协议实现 bug 的高发区。

我在项目里通常拿三个开源实现做交叉验证：Rocket Chip 的 TileLink 实现、CHI 的参考实现（比如 ARM 提供的一些教学模型，或者在 GitHub 上能找到的 uCHI 级实现）、还有 CXL 控制器的一些开源验证模型。这三个实现分别代表不同协议学派的设计取舍。

验证时最常做的是随机事务注入：给每个 Client 随机发读写请求，随机控制 Probe 时序，把缓存行状态、报文队列、信用计数全部打印出来，跑几百万个周期后收集死锁、活锁、协议违例。碰到违例时，第一步不是改代码，而是把引起违例的那笔事务回放：在状态转移表里人工走一遍，看协议规范本身允不允许这条迁移路径。经常会出现“协议允许、但 RTL 实现不支持”的 case，这种问题就必须去做文档和代码的差距分析，而不是贸然加补丁。

跨协议对比时，还可以把同一个测试激励灌到两套实现里：比如让两个 CPU 同时对同一地址发起 ReadUnique，然后看 CHI 系统里 Home Node 的监听顺序和 TileLink 系统里 L2 的 Probe 顺序有何不同。这种实验会直观告诉你：哪个协议能在更短的时间内收敛，哪个协议在高冲突场景下需要更多重试。

5.3 从 RTL 断言到形式化验证

在写状态机时，我强烈建议用断言把“不变式”定死，而不是等仿真跑挂了再回头排查。简单说，不变式就是协议里那些无论时序怎么乱都必须成立的性质。

在 CHI 系统里，值得加断言的场景包括：一个缓存行在任意时刻只能被一个 Home Node 接管；对于同一地址的多个读请求，它们获得的最终数据必须一致；写回操作必须在数据真正到达 Home Node 之后才能返回 Comp；路由器的每个 VC 在物理上不允许超额分配信用。

下面放一个精简版的 Verilog 断言片段，针对 CHI 风格接口里的“收到 CompData 时缓存行必须退出等待态”做检查。

property p_resp_to_data; @(posedge clk iff !rst_n) // 当 RN 收到 CompData 且交易 ID 匹配时 // 该缓存行状态机的 wait_resp 标志必须在下拍拉低 disable iff (rst_n == 0) (req_if.comp_data_valid && req_if.txid == cur_txid) |-> ##[1:2] (cache_if.state != WAIT_RESP); endproperty assert property (p_resp_to_data) else $error("CHI protocol violation: CompData without state transition.");

这段断言的逻辑是：只要 RN 在某个节拍收到了 CompData，并且这个响应对应着当前正在等待的事务，那么缓存行状态机必须在1到2拍内脱离 WAIT_RESP 状态。如果断言失败，通常意味着响应通路和状态机之间缺少联动，比如协议栈把响应打给了错误的 TXID。

这种断言写起来不复杂，但价值非常大。批量跑随机测试时，能帮你第一时间定位是路由错了、信用错了、还是状态机转移错了，省掉大量逐波形排查的时间。

6. 常见问题与排查技巧实录

6.1 状态机不跳转，卡在某个等待态

现象：跑仿真时发现某个 RN 长时间不发新请求，内部信号显示缓存行状态一直停在 WAIT_RESP，而 D 通道始终没有数据返回。

排查思路，照着下面几步来。

先看信用：检查路由器和目标节点之间的 Credit 是否耗尽。CHI 和 CXL 都靠信用计数做流控，信用没回复，数据就不可能往前走。

再看虚拟通道：确定请求是否在某个 VC 里排队，而这个 VC 被更优先级的报文占满了。如果读数据和写数据共用一条物理链路但分开 VC，而你的 Testbench 只在写通道上灌流量，就可能出现读请求排队但信用迟迟不发的现象。

再看地址路由：查 TgtID 或者地址解码表，确认这个地址是否真的映射到了发响应节点的地址空间。Scale-up 系统里地址映射配置错了，请求会发到一个“没人听”的节点。

最后看事务 ID 匹配：确认 CompData 返回的 TXID 是不是和请求一致。CHI 和 TileLink 都有事务 ID，一旦 ID 匹配错，状态机通常直接卡死。

6.2 路由绕圈，活锁不断

现象：系统在低负载下完全正常，但流量一高，发现某些报文反复在不同路由器之间来回转发，始终到不了目的地，而且时不时的时序违例。

观察波形时你可以抓“同一报文的 TgtID 和路由器端口”：如果它多次经过同一个路由器但每次被仲裁器裁决到去往其他方向的端口，那就是活锁信号。

常见原因有两个。一是路由表根据 QoS 动态调整了路径，且没有做“出行次数上限”，极端情况下报文被反复打回。解决办法是给每条路由表项加一个跳数计数器，超过阈值直接丢弃或走兜底路径。二是虚拟通道分配策略有问题，比如高优先级 VC 永远抢占，低优先级 VC 饿死。检查仲裁器是否真正在“公平性”和“优先级”之间取了一个平衡点，必要时引入批次调度，保证每个 VC 每 N 拍至少能发一拍。

在协议层面，要确认协议是否允许重试报文走不同通道。CXL 的重试是可以对齐到原始 TgtID 和 VC 的，所以不会绕圈；但如果你把重试报文重新打标到另一个 VC，就可能破坏原事务的顺序，引发活锁。

6.3 协议升级带来意外回归

Scale-up 互连协议更新频繁，比如 ARM CHI 从 Issue B 出到 Issue C，增加了一些新事务和新的响应组合。每次升级，最怕的不是加了新字段，而是旧实现里的“保留位”被新协议赋予了含义。

我在升级过程里踩到过一个典型坑：旧代码把 CHI 报文头里某位当作 Reserved，一直拉低。升级后的协议把这个位置定义为 Poison/DataError 指示位，而新版本 CPU 或加速器在某些错误注入场景里会把该位置高。结果旧互连核既没有把这个位传给后续模块，也没有在本地做处理，直接把错误数据放行。

所以做协议升级时，我的经验是单独做一轮“保留位检查”：把所有 Reserved 位在 RTL 里显式拉高拉低打乱跑一轮，确认系统不会因为保留位电平变化而崩溃。同理，新增的响应类型要考虑旧状态机是否会收到未知响应，如果收到，必须走 Error 流程，不能默默忽略。

最后再说点实际的

文章写到这里，其实已经回答了标题里的两个入口：CHI 七态不是玄学，而是把缓存行的唯一性、干净性和数据有效性拆开之后得到的一组稳定状态；PBR 路由也不是只能出现在网络交换机里的概念，它同样是片上互连路由器和 CXL/UCIe 这类 Scale-up 协议每天都在做的事情。

我在实际操作中的一个体会是：协议对比这件事，千万不要停留在“谁支持的状态多、谁的带宽高”这种层面。当你真正落到比特上看报文头，落到状态机上看迁移路径时，你才会发现每个协议背后都有非常强烈的主观取舍。CHI 愿意把路由和监听做得复杂，是为了在多核大系统里获得更好的扩展性；TileLink 把状态机做得简单规则，是为了让开源硬件更容易被验证；CXL 重信用、重通道隔离，是为了在 PCIe 物理基础上塞进一致性内存语义；UCIe 刻意只做物理和适配层，是为了不绑定上层任何协议，给 Chiplet 生态留下自由组合的空间。

如果你正在做 Scale-up 互连的选型或实现，我的建议是：先把你团队最熟的协议用“状态转移矩阵 + 报文位域表”做一次完整的梳理，再拿一到两个备选协议做同样的梳理，对比差异点时会发现很多之前没意识到的隐藏约束。这个工作很费时间，但省下来的，是后面几个月排错、联调、改版的时间，绝对划算。