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和OMICache一致性核是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要保证多少。这里的“策略路由”在互连领域就体现为PBRPath Based Routing路径基路由我会在后面专门展开。工程生态决定你上手能不能跑起来。TileLink的优势是Rocket Chip/Chipyard有大量开源代码直接读CHI有比较成熟的商业VIP开源实现也可以找到CXL有丰富的spec和仿真模型UCIe则有越来越完整的开源PHY参考设计。3. 缓存状态机解剖从CHI七态说起3.1 CHI七态的含义与状态位编码CHI的状态机算是这套对比里最复杂的。稳定状态我习惯记为七个IInvalid、SCShared Clean、SDCShared Dirty Clean共享但数据有待回写、UDCUnique Dirty Clean唯一但数据有待回写、UCUnique Clean、UCEUnique Clean Exclusive和MModified。这里注意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这个大家熟悉的模型上IInvalid、SShared、EExclusive、MModified。在需要支持dirty共享的扩展场景里还可以看到接近MOESI的变体增加OOwner态或者把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端的状态机简化了SNPsnoop的处理。这个简化的背后是CXL的定位问题。CXL主要服务外部加速器和内存扩展链路距离和物理层开销比片上互连大很多如果把CHI那么重的状态机全部搬到跨PCIe的链路上时延会高到不可接受。所以CXL选择把复杂一致性判断放在主机侧device侧只需要维护一个相对简单的状态集并严格按照host发来的snoop消息迁移状态。在比特层面CXL的缓存状态常见是放在Meta字段里和地址的某些位拼在一起传递。我们调试时踩过的坑是device侧状态字段在clean和dirty判断上和host侧不一致两边握手都成功但最终数据把数据库改坏了。所以状态机的对照表一定要做成跨角色的检查表不能只看单侧状态。4. PBR路由从地址路由到路径路由4.1 从网络策略路由理解互连中的PBR互连网络里的路由最早也最简单的是按目的地址查表每个数据包带一个目标节点ID每一级交换节点根据表项转发等价于传统网络里的目的地路由。这种方式在树形拓扑里很自然但到了Scale-up的网格、环形、多die交叉拓扑阶段问题就来了——目标ID决定“去哪”但不决定“怎么去”。这里就是PBRPath Based Routing路径基路由发挥作用的地方。在互连语境里PBR的意思是路由决策不只看目标节点还看事务类型、发起者ID、QoS等级、当前链路负载和一致性目录信息。这跟网络里“策略路由”的思路是一致的传统路由是“到目的地走最优下一跳”策略路由是“指定类型的流量必须走指定路径”。在一致性互连里PBR要解决的核心问题是路径的非对称性。比如CPU读一个内存地址请求先从RNRequest Node到HNHome NodeHN做目录查询后可能要发起snoop到远端cache然后数据从远端cache走到请求者。这一串过程里请求路径和数据路径可能完全不同如果只按目标地址路由snoop可能走到一个已经失效的节点。4.2 PBR在CHI、TileLink和UCIe中的落地CHI虽然没有在规范里直接叫“PBR”但它的事务路由机制本质就是路径感知的。CHI里每个节点有NodeIDRN发起请求时flit里带的是自己的RNID和目标HNID。中间的路由节点在转发时会根据flit类型决定走snoop通道还是数据通道并根据RTIDRequest 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里有TCTraffic ClassPBR算法在路径选择时会把QoS字段纳入权重。实际测试里我们发现如果QoS字段全写成同一个值低优先级流量会饿死高优先级流量因为每个节点都认为大家优先级一样缺乏抢占理由。做协议实现时至少预留两级QoS并打通到仲裁器这是最基本的。5. 比特级协议格式对比解剖5.1 CHI的REQ、RSP、DAT、SNP四通道flitCHI把通道分成四类REQ请求、RSP响应、DAT数据、SNPsnoop。这也是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 关键参数横向对照表协议典型链路宽度/位宽一致性模型路由方式目标场景开源/开放程度AMBA CHI32/64bit flit可多通道扩展CHI七态及派生状态节点ID路径感知PBR风格多核SoC、多die互连、服务器一致性互连开放规范商业IP渗透高TileLink可定制信号宽度通常按地址/数据位宽生成MESI/MOESI变体由互联拓扑编译生成连接Rocket Chip/Chipyard生态、开源CPU互连开源实现成熟CXL基于PCIe x8/x16flit层复杂MESI骨架host协同管理基于PCIe路由TLP转发加速器、内存池、外部一致性设备开放标准多厂商支持UCIedie-to-die并行/串行通道不参与一致性适配层透传路由信息Chiplet物理集成、多die封装开放标准参考IP增多OMIOpenCAPI串行通道内存语义优先内存共享语义为主内存控制器为中心路由开放内存扩展、加速器内存访问开放规范早期生态AXI独立通道位宽灵活硬件一致性弱依赖软件地址房射NoC路由SoC内部主从互连、外设访问开放规范所有EDA都支持这张表不是给你选型抄作业用的而是看差异维度。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的多核SoCRocket或BOOM核通过TileLink总线访问L2L2再通过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_typeE)时合法 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的状态位显示跑两个并发缓存访问程序你就能在波形图里看到状态机的动作。对着波形思考“为什么这里走了这条迁移路径”比我在这里把一个状态表抄十遍有效得多。