Scale-up互连协议深度解析：状态机、PBR路由与比特级对比

最近在推一个基于Chiplet的Scale-up互连项目，做到验证阶段才发现，光是背得住CHI的七态、说得清TileLink的TL-C握手，根本不够用。真正的问题全在比特和状态机层面：一个状态迁移少了一个时钟周宿，snoop响应就乱了；路由表里某个字段按路径解析还是按目标解析，直接影响整片网络的时延和死锁行为。

这篇东西就是想把Scale-up互连里最核心的那一层撕开：从ARM AMBA CHI的七态缓存状态机开始，讲到PBR路由在一致性网络里到底怎么落地，再横向对比CHI、TileLink、CXL、UCIe、OMI、AXI这六个开放协议，在状态机、路由机制和线协议格式上的真实差异。适合做SoC互连、Chiplet集成、一致性协议验证的同学，也适合刚入行、想搞明白“协议层面对比到底比什么”的工程师。

1. Scale-up互连为什么值得做到比特级

1.1 从Scale-up场景理解互连协议栈的层次

Scale-up和Scale-out是两种完全不同的扩张思路。Scale-out靠加节点，节点之间通过网络通信，一致性通常交给分布式软件；Scale-up则是在一台机器内部把计算资源、内存池、加速器连成一个整体，CPU访问远端内存和访问本地内存的语义差别要尽量小。这样一来，互连协议就不只是搬运数据，它必须参与缓存一致性、内存语义、QoS和故障隔离。

我们平时说协议栈，往往只记得物理层、链路层、事务层这些名词。但在Scale-up场景里，真正决定系统行为的是三层东西：链路层的流控和纠错、事务层的请求响应匹配、缓存一致性层的状态迁移。任何一个层面出问题，表现都是整机性能抖动或者随机性的数据错误。

很多项目在看协议选型时只看带宽数字，比如“这个协议支持多少GT/s”。但带宽只是最表层，真正决定系统能不能稳定跑起来的是状态机和路由策略。协议级对比要回答的问题不是“谁快”，而是“在同样的缓存行冲突、同样的多die拥塞、同样的QoS要求下，谁的语义更完整，谁的实现更不容易出死锁”。

1.2 为什么拿状态机和比特流说话

把协议往下拆到状态机和比特，是因为这两个东西是最不骗人的。

协议文档可以写得很美好，说“支持全一致性”“支持多级拓扑”，但一落到RTL里，状态机的状态个数、迁移条件、位宽定义全部要精确。少一个状态，某个缓存行可能就找不到正确的owner；多一个状态，面积和验证工作量立刻上去。比特层面更直接：同样的读请求，CHI的REQ flit和TileLink的请求信道字段布局完全不同，解析错了就是错误地址访问，连仿错的机会都没有。

所以真正有参考价值的互连协议对比，一定是在两个固定坐标系里做横切：状态机坐标系（缓存行有哪些状态、允许哪些迁移）和比特坐标系（flit怎么编码、路由字段怎么解析）。这篇后面全部围绕这两个坐标系展开。

2. 六个协议：选谁入局，怎么分类

2.1 六个协议全景：CHI、TileLink、CXL、UCIe、OMI、AXI

标题里说“六个开源协议”，这里先说明一下口径。严格讲，这六个里面有的是开放规范，有的存在完整开源实现，有的是行业标准。放在一起比不是因为它们许可证一样，而是因为它们都被广泛用在Scale-up互连的某个关键位置，且规范或实现都公开可查。

AMBA CHI是ARM推出的Cache Coherent Interconnect协议，广泛应用在服务器SoC和多die互联，缓存状态机和snoop机制设计得相当完整。TileLink则是Rocket Chip和Chisel生态里最常见的SoC互连协议，被很多开源CPU项目拿来当默认互连总线。CXL是建立在PCIe物理层之上的高速互连协议，专门解决加速器、内存扩展和主处理器之间的一致性共享。UCIe是Chiplet裸片间互连的开放标准，主要定义die-to-die适配层，不做缓存一致性，但它是Scale-up物理集成的关键底座。OMI是OpenCAPI家族的内存接口协议，走串行内存语义，适合做开放内存扩展。AXI虽然本身不支持硬件一致性，但它是NoC和SoC里最基础的传输协议，几乎所有一致性协议最终都要把事务落到AXI类的事务上去。

这六个协议放在一起比，正好覆盖了Scale-up互连的完整链路：物理底座是UCIe，传输通道是CXL和OMI，Cache一致性核是CHI和TileLink，而AXI是中间纽带的传输语义。

2.2 对比维度：事务语义、一致性模型、路由机制

对比协议不能堆参数，要有统一维度。我实际用的对比框架是四层：事务语义、一致性模型、路由机制、工程生态。

事务语义指协议如何描述读、写、原子操作、预取和缓存维护操作。比如CHI的事务类型非常多，有ReadOnce、ReadClean、ReadShared、WriteFull、WriteUnique等；TileLink也支持Get、Put、ArithmeticOp等操作，但它是基于channel的请求-响应模型，语义组织方式和CHI的节点模型差异很大。

一致性模型是核心，决定了缓存行状态机的复杂度和snoop机制。CHI七态、TileLink的MESI变体、CXL.cache的host/device共享模型，各有取舍。

路由机制是很多对比文章忽略的部分。一致性网络里请求不一定走最短路径，它要考虑缓存行当前在哪个节点、snoop要转发给谁、QoS要保证多少。这里的“策略路由”，在互连领域就体现为PBR（Path Based Routing，路径基路由），我会在后面专门展开。

工程生态决定你上手能不能跑起来。TileLink的优势是Rocket Chip/Chipyard有大量开源代码直接读；CHI有比较成熟的商业VIP，开源实现也可以找到；CXL有丰富的spec和仿真模型；UCIe则有越来越完整的开源PHY参考设计。

3. 缓存状态机解剖：从CHI七态说起

3.1 CHI七态的含义与状态位编码

CHI的状态机算是这套对比里最复杂的。稳定状态我习惯记为七个：I（Invalid）、SC（Shared Clean）、SDC（Shared Dirty Clean，共享但数据有待回写）、UDC（Unique Dirty Clean，唯一但数据有待回写）、UC（Unique Clean）、UCE（Unique Clean Exclusive）和M（Modified）。

这里注意，CHI里“Dirty”和“Clean”的含义和外面常说的脏位不完全一样。CHI的Dirty指的是“本节点是否负责把数据回写到内存”，重点在回写职责，不只是数据是否被改过。SDC和UDC是“有待回写的共享/唯一”状态，这在多die互连里非常重要，因为数据能不能被其他die读取，取决于owner节点是否愿意提供。

状态位在硬件里通常用2到3个bit编码。稳定状态不需要把所有可能组合都编码出来，因为有些组合非法。比如M状态下的行一定不是共享的，那valid、shared、dirty、unique四个标志位就可以按合法组合压缩编码。保存这个编码设计时，务必要给扩展留空间，CHI后续版本加状态就是靠保留编码实现兼容的。

3.2 TileLink的MESI变体与状态表达

TileLink的缓存状态比CHI简单，主要落在MESI这个大家熟悉的模型上：I（Invalid）、S（Shared）、E（Exclusive）、M（Modified）。在需要支持dirty共享的扩展场景里，还可以看到接近MOESI的变体，增加O（Owner）态或者把dirty信息单独表达。

TileLink和CHI最大的差别是它没有像CHI七态那样把“回写职责”和“共享状态”拆得那么细。CHI的UDC、SDC可以精确表达“这个节点虽然不拥有唯一权，但它手里有脏数据，需要负责回写”，TileLink的标准MESI模型里，dirty数据基本只在M态存在，一旦共享就必须回写。这意味着在同样的一致性目录实现里，CHI可以让一个节点持有脏数据的同时允许其他节点共享读，TileLink则更倾向于先回写再做共享。

不能说谁绝对好，而是取舍不同。CHI为了性能减少回写次数，代价是状态机复杂、RTL验证量大；TileLink为了工程简洁，选择更保守的迁移策略，适合中小规模SoC。实际项目里我还见过直接把CHI事务翻译成TL-C的桥，状态语义上就必须做“降级”，否则dirty共享语义会丢。

3.3 CXL如何适配和简化状态机

CXL的缓存状态模型分两类：一类是host管理的一致性，一类是device侧的缓存一致性。在CXL.cache里，device缓存行也有一套状态，主要是M、S、E、I这类MESI骨架，再根据caching layer的不同加一些修饰位。和CHI相比，CXL启动时少了一些细节：它大量依赖home agent做熟思，device端的状态机简化了SNP（snoop）的处理。

这个简化的背后是CXL的定位问题。CXL主要服务外部加速器和内存扩展，链路距离和物理层开销比片上互连大很多，如果把CHI那么重的状态机全部搬到跨PCIe的链路上，时延会高到不可接受。所以CXL选择把复杂一致性判断放在主机侧，device侧只需要维护一个相对简单的状态集，并严格按照host发来的snoop消息迁移状态。

在比特层面，CXL的缓存状态常见是放在Meta字段里和地址的某些位拼在一起传递。我们调试时踩过的坑是，device侧状态字段在clean和dirty判断上和host侧不一致，两边握手都成功但最终数据把数据库改坏了。所以状态机的对照表一定要做成跨角色的检查表，不能只看单侧状态。

4. PBR路由：从地址路由到路径路由

4.1 从网络策略路由理解互连中的PBR

互连网络里的路由，最早也最简单的是按目的地址查表：每个数据包带一个目标节点ID，每一级交换节点根据表项转发，等价于传统网络里的目的地路由。这种方式在树形拓扑里很自然，但到了Scale-up的网格、环形、多die交叉拓扑阶段，问题就来了——目标ID决定“去哪”，但不决定“怎么去”。

这里就是PBR（Path Based Routing，路径基路由）发挥作用的地方。在互连语境里，PBR的意思是：路由决策不只看目标节点，还看事务类型、发起者ID、QoS等级、当前链路负载和一致性目录信息。这跟网络里“策略路由”的思路是一致的：传统路由是“到目的地走最优下一跳”，策略路由是“指定类型的流量必须走指定路径”。

在一致性互连里，PBR要解决的核心问题是路径的非对称性。比如CPU读一个内存地址，请求先从RN（Request Node）到HN（Home Node），HN做目录查询后，可能要发起snoop到远端cache，然后数据从远端cache走到请求者。这一串过程里，请求路径和数据路径可能完全不同，如果只按目标地址路由，snoop可能走到一个已经失效的节点。

4.2 PBR在CHI、TileLink和UCIe中的落地

CHI虽然没有在规范里直接叫“PBR”，但它的事务路由机制本质就是路径感知的。CHI里每个节点有NodeID，RN发起请求时，flit里带的是自己的RNID和目标HNID。中间的路由节点在转发时，会根据flit类型决定走snoop通道还是数据通道，并根据RTID（Request Transaction ID）维护事务状态。

更接近PBR的是CHI里对snoop的转发处理。HN给远端cache发snoop时，snoop flit里除了目标地址，还要带SNP target的路径信息，这样才能让snoop按对应路径到达持有缓存行的节点。这个路径信息是动态维护的，不是简单查个全局表，它会结合启动时的路由配置和实时链路状态做决策。

TileLink的模型更简单，它不定义全局路由协议，节点间通过TileLink channel直接连接，路由逻辑在上层用Diplomacy等机制生成。好处是代码里能清晰看到每个master和slave之间的连接路径，坏处是大规模网络里需要自己实现路径感知。我们在Chipyard里做多核设计时，经常在periphery总线处手工指定route，避免默认路由把所有请求都压到同一个crossbar上。

UCIe的定位是die-to-die适配层，它不直接参与一致性路由，但它定义了死的结构来透传上层协议的路由信息。所以UCIe接口的位宽规划时，最重要的不是数据位，而是要把Meta和sideband信号的比例留够，否则上面跑CHI时根本塞不下路由字段。

4.3 路由表维护、QoS与死锁避免

PBR带来最麻烦的问题就是路由表一致性和依赖循环。

一致性路由表和多级缓存目录一样，存在“表项检不到”的情况。尤其在多die热插拔、低功耗状态切换时，某些节点进入断电态但表里还标着可路由，这时snoop就会落到黑洞。我们现在的做法是在每个入口节点做路由表校验，校验失败直接返回错误完成而不是无限重试，至少保证错误可定位。

死锁是另一个重灾区。PBR可以让不同事务类型走不同物理或虚拟通道，如果没规划好依赖，可能出现：A类请求等B类请求释放缓冲区，B类请求又在等A类响应的循环。CHI的防死锁思路是分层分配虚拟网络，把请求、响应、snoop、data分到独立通道；TileLink则靠通道间严格排序避免反向依赖。但这些机制都依赖PBR的合理配置，路由交叉了，任何死锁避免方案都可能失效。

QoS字段在这里不是点缀。CHI的REQ和DAT flit里都带QoS位，CXL里有TC（Traffic Class），PBR算法在路径选择时会把QoS字段纳入权重。实际测试里我们发现，如果QoS字段全写成同一个值，低优先级流量会饿死高优先级流量，因为每个节点都认为大家优先级一样，缺乏抢占理由。做协议实现时至少预留两级QoS并打通到仲裁器，这是最基本的。

5. 比特级协议格式对比解剖

5.1 CHI的REQ、RSP、DAT、SNP四通道flit

CHI把通道分成四类：REQ（请求）、RSP（响应）、DAT（数据）、SNP（snoop）。这也是CHI和其他协议最大的结构差异——它有显式snoop通道，用于直接向缓存节点发起一致性探测。

REQ通道的flit是最小的，一般32bit或64bit，包含请求类型、目标地址、RNID、HNID、QoS等字段。RSP通道用于事务完成标记，DAT通道负载数据，SNP通道则承载snoop语义。四个通道在物理上可以是独立的信号组，也可以是复用同一物理链路的虚拟通道。

比特层面有个容易忽略的设计：CHI flit的头部并不是把所有字段都对齐到字节边界。为了压位宽，很多字段是按bit位紧凑排列的，解析器必须按照规范精确取位。我曾经在一次自研CHI封装里看错了flags位域偏移，结果整个flit解析全部错位，所有请求都发去了错误的地址区间。之后我们直接在代码里写了位域解析单元测试，并把规范的位图直接生成解析表，避免人工记偏移。

5.2 TileLink的channel模型与CXL的flit设计

TileLink是完全不同的编码风格。它没有统一的flit封装，而是通过五个逻辑channel的valid-ready握手来传递操作和响应。从比特角度看，TileLink更像并行总线的风格：地址线、数据线、操作码各占一组信号，没有复杂的逐级封装。

这样做的好处是RTL可读性极强，Chisel代码里直接生成定制的TileLink接口，调试时按信号名抓波形就知道事务走到哪一步。坏处是频率和线利用率不好，每个channel的信号宽度是提前定死的，不能像CHI那样按需封装出不同大小的flit。

CXL则走了另一条路。CXL flit建立在PCIe的TLP之上，格式非常规范，带header、payload、CRC，还支持细化调度。它把数据、元数据和完整性校验都封装在一个相对大的包结构里，链路效率更高，但解析逻辑比TileLink复杂好几个量级。CXL的链路层还集成了CRC校验和重传机制，这在片上互连协议中很少见，本质上是因为CXL要跑在长距离PCB走线上，误码率比芯片内高得多。

5.3 链路层编解码与QoS位域的实际影响

协议在data flit上的设计取舍，直接反映在链路线利用率和时延上。CHI的链路层通常带简单的错误校验，多数实现不重传，靠上层恢复；CXL则强制CRC和可选重传，时延高但更适合外插设备。TileLink大多数实现根本不定义链路层校验，因为它默认在芯片内部，信号质量可预期。

QoS位域最值得多看一眼。CHI里QoS位和Cache分配策略位经常混在一个字段里，解析出来以后要同时喂给仲裁器和缓存替换策略。CXL则把TC和Snoop潜伏期拆分得更细。这里容易出的坑是：不同IP的QoS语义不兼容，来自第三方IP的flit它自己理解的QoS范围和你的NoC不一样，所以集成时必须有重映射逻辑，否则流量调度完全失控。

6. 六协议横向对比与选型实践

6.1 关键参数横向对照表

这张表不是给你选型抄作业用的，而是看差异维度。CHI/CXL重视一致性语义；AXI/TileLink重视集成便利性；UCIe和OMI一个管物理一体化，一个管内存语义。真正选择时往往不是只选一个，而是要组合。

6.2 开源生态与上手难度实测

从可读性角度，TileLink最好上手。因为Rocket Chip/Chipyard里Diplomacy网络可以在编译期生成整个互连拓扑，你用Chisel写一个自定义master，编译后就能看到和slave之间的TileLink连接，信号结构很清晰，非常适合学习状态机。

CHI想上手就没有这么顺。规范本身非常厚，状态图极多，开源实现要么是特定IP，要么是学术项目，完整性和ARM验证环境差很多。我们的建议是先拿一个开源的CHI agent模型，把它跑在Verilator仿真环境里，配合一个简化的内存模型做仿真，重点观察snoop在不同缓存状态组合下的行为。

CXL的难点在协议栈分层多，PCIe层和CXL层叠加后调试目标不清晰。建议先用厂商提供的CXL simulator抓request/response/debug消息，理解事务到TLP的封装逻辑，再去看RTL。

UCIe现在开源参考IP数量快速增长，但是die-to-die PHY本身有大量模拟电路内容，能在数字仿真环境里看到的主要是适配层行为。OMI相对小众，参考材料少，除非要做开放内存扩展，否则可以放后面看。

6.3 按场景选型的判断逻辑

我在实际方案里一般按三类场景直接倒入选型。

第一类：芯片内部多核互连，要求强一致性，时延敏感。首选CHI，次选TileLink的TL-C。CHI更适合大规模服务器SoC，因为节点多了以后，CHI的PBR风格路由和独立snoop通道会让拥塞控制从容得多。如果团队规模不大，验证人力有限，TileLink TL-C是个更实惠的选择，特别是你已经用了Rocket Chip或Chipyard的时候。

第二类：Scale-up外部设备，比如加速器扩展、内存模组接入，或者GPU与CPU共享内存。CXL基本是这个场景的事实标准。OMI可以看作备选，适合你不想跟PCIe绑定、希望内存语义更纯粹的定制系统。

第三类：Chiplet封装内的多die互连，UCIe是底座，上面最好再包一层CHI或CXL。UCIe本身只负责物理传输和链路适配，真正的一致性、路由语义还要Layering协议。我们现在的做法是“UCIe做物理桥，CHI做一致性，NoC做内部路由”，三个协议分层配合，各管一段。

AXI在这里不是替代关系，它是所有NoC内部最常用的传输协议。往往CHI或TileLink的事务最终要转换成AXI去访问DDR控制器或外设，所以它属于通用底座，不能缺席。

7. 实操与验证：把协议吃透的几条路

7.1 用开源工具搭一套互连协议观测环境

先把环境搭起来，这是所有验证工作的前提。我们要看的信号是协议层的握手线和状态位，不需要一开始就上真实硅片。

我自己常用的组合是Chipyard生成一个带L2 Cache的多核SoC，Rocket或BOOM核通过TileLink总线访问L2，L2再通过AXI转接访问DDR。这样在仿真里既有TL-C的一致性协议可观测，又有AXI的基础业务，还能看到L2 cache的状态迁移。仿真工具推荐Verilator，速度比VCS慢但胜在开源、可脚本化。

跑通后直接用GTKWave打开波形，重点是看l2cache里每个bank的state信号。TileLink的Chisel代码里cache state通常定义成枚举值，波形里显示成数字或字符。我把枚举值打印到日志里，每次状态跳转都打一行，这样比肉眼盯波形方便得多。

如果你想直接看CHI类协议，目前可以找一个开源的CHI互联样例，把它接到模拟的RN和HN模型上。很多开源实现会自带Python或者C的参考模型，先用参考模型把事务序列打出来，再对照RTL仿真的握手时序逐拍对比。

7.2 状态机验证与断言

状态机验证最好的工具是形式化验证，但很多人觉得形式化门槛高。其实SymbiYosys这套开源工具链已经可以做不少事情，核心是把RTL转成逻辑模型后，用smtbmc引擎去遍历状态空间，检查我们写的不变式。

不变式是状态机验证的灵魂。以TileLink的TL-C为例，我们写过这么几条断言：第一，缓存行不能从Modified直接跳到Shared，中间必须经过数据回写；第二，同一个缓存行同一时刻只能有一个master处于Exclusive或Modified；第三，当主设备发起Release时，必须在下一个握手周期内收到ReleaseAck，否则状态机卡死。

如果不想写SystemVerilog断言，也可以用Python对状态转移逻辑做单元测试。把状态转移函数写成纯函数，输入当前状态和事件，输出下一状态，然后用穷举或者随机序列去测它是否满足约束。这种方式很轻，适合早期验证。

def next_state(state, event): # 简化示例：TL-C状态下I -> E 只在AcquireBlock(grant_type=E)时合法 if state == "I" and event == "AcquireBlock(E)": return "E" if state == "E" and event == "ReleaseData": return "I" raise IllegalTransition(state, event)

这条代码虽然简单，却能把协议文档里很多“按理说不会发生”的非法迁移变成程序里的异常。我们后面在写CHI状态机参考模型时也是这个思路，先把合法迁移矩阵写在Python里，再让RTL仿真的事件流来驱动它比对。

7.3 调试心得：那些容易被忽略的比特

真到调试阶段，踩得最多的坑往往不是协议文档里的生僻字段，反而是一些最不起眼的位。

第一个是CRC和奇偶校验。CHI链路层不做端到端CRC时，很多人会漏掉flit里残留的spare位没置成约定值，导致接收端校验报错。看起来是偶发错误，实际是发送端根本没对spare位做初始化。建议在封装flit时把每个保留字段都显式复位，不要依赖上游信号默认值。

第二个是PBR相关表项。多die互连里，路由表项和低功耗状态的联动经常出问题。当一个die进入休眠时，如果PBR表没有同步更新，请求还是按老路径发过去，snoop就永远没响应。我们在验证时专门加了“低功耗唤醒后路由表重新加载”的日志点，抓这种问题一次就能定位。

第三个是QoS位域的语义转换。CXL的TC和CHI的QoS字段取值范围不同，转换逻辑如果不写清楚边界，低优先级可能被映射成最高优先级。我们后来把所有跨协议转换函数都做成查表模式，而不是公式缩放，这样既能打印每一条映射关系，又方便测试覆盖边界值。

还有一点关于过境接口选择：在Chiplet封装里，UCIe的sideband通道不一定够塞复杂路由扩展字段，所以我会在协议适配层把路由信息提前压缩，不能等到协议栈最底层才去处理。这个压缩过程必须在验证环境里单独测试，否则真实互连时会出现因为路由字段被截断而导致的访问错误。

最后再分享一点我的体会

做互连协议对比最忌讳的是看文档想象。文档上的状态机看起来边界清楚，一跑到真实仿真里，各种稀疏信号、跨时钟域握手、路由表重配置的组合会让你怀疑自己到底有没有看懂协议。

我的习惯是先把协议的状态机迁移图手工抄一遍，再去读代码和波形。因为抄一遍你就会发现哪些迁移是核心路径，哪些是扩展路径。比如CHI的七态，真正在一般业务里高频出现的状态迁移其实就那么六七条，剩下的都是为边界场景准备的。把这个优先级理清楚，再看比特层面的解析，就不会被协议厚度吓倒。

如果你也想动手验证一次，最划算的切入点还是TileLink。下载一个Chipyard，用默认配置生成双核SoC，改一下L2的状态位显示，跑两个并发缓存访问程序，你就能在波形图里看到状态机的动作。对着波形思考“为什么这里走了这条迁移路径”，比我在这里把一个状态表抄十遍有效得多。