做Scale-up互连的兄弟应该都绕不开一个词协议。物理层我们能靠SerDes、D2D PHY、先进封装硬扛但真正决定系统能不能把“多个计算Die”顺畅地拧成一个逻辑单机的往往是跑在比特线上的协议语义——缓存行什么时候该失效、请求走哪条路径、路由节点到底缓冲几个flit、一个状态机跨了哪些节点保持一致。扛不住协议层的复杂度再高的带宽都白搭。这篇文章我打算把Scale-up互连里最硬核的两块解剖开一块是CHI协议里的“七态”缓存一致性状态机另一块是互连网络里的PBR路由Partially Buffered Routing部分缓冲路由。同时我会把六个常见的开源互连协议——CHI、TileLink、AXI4、AXI4-Stream、OCP、Wishbone——放在比特和状态机层面做一次横向对比。适合正在做NoC、缓存一致性互连、Chiplet/多Die系统、或者想从“会用总线”进阶到“设计互连”的人。不绕弯子直接上手拆。1. 先从 Scale-up 谈起为什么协议层比物理层更决定生死1.1 我们到底在对比什么Scale-up 和 Scale-out 的区别很多文章讲过但落到芯片工程师眼里其实一句话Scale-out 是加节点Scale-up 是把一个节点的“核、缓存、内存一致性”变成可扩展的域。也就是说你插进去一个新Die、一个新Chiplet不能只是让它的核能跑指令还要让它能正确地观察到同一份内存、同一份缓存数据——这要求整个互连网络必须维护一致性的闭环任何一环的协议语义对不上数据就脏了。所以在做这一类系统时最忌讳上来就看物理层的带宽和时延。物理层的带宽不够是“慢一点”的问题协议层的状态机不对是“静默算错”的问题。后者远比前者可怕。一个请求在Root Complex和远端Die之间转了一圈返回的数据到底对应哪个缓存状态是Unique还是Shared是Clean还是Dirty状态编码错一位结果就是整条链路上的所有核都在用同一块脏数据。我一般会先问自己三个问题协议里有多少个缓存状态这些状态之间的迁移由谁触发数据包在互连网络里经过每个节点时节点用什么策略缓冲和转发这三个问题分别对应的是“状态语义”“状态机转换”“路由与缓冲策略”也就是标题里说的“CHI七态”和“PBR路由”这两个解剖点。1.2 六个开源协议怎么选出来的很多初学者把协议理解成一份文档但工程师眼里的协议是RTL代码、验证环境、协议分析仪里的一撮信号。我选这六个协议是因为它们在开源世界里的参考实现最丰富、生态最典型而且正好覆盖了从“纯数据搬运”到“全缓存一致性”的完整光谱CHIARM AMBA体系里的一致性互连协议目前做Scale-up/多Die一致性互连绕不开的标杆。TileLinkRISC-V生态里自带一致性语义的片内互连协议有TL-UL/TL-UH/TL-C三个等级。AXI4通用内存映射总线没有一致性状态机简单直接。AXI4-Stream面向数据流不关心地址更不关心缓存。OCPOpen Core Protocol一度是点对点SoC互连的热门选择。Wishbone轻量级、极简适合小型系统。一个成熟的Scale-up互连系统一般不会只用一套协议通常是CHI或TileLink做一致性域、AXI/AXI-Stream做数据面、底层传输再套OCP或自定义包格式。这六套协议放在一起对比能让你清楚地看到“哪一层缺了状态机”“哪一层缺了路由字段”也就理解了为什么有的协议在一块芯片里只能当配角。2. CHI 七态缓存一致性从原子语义到状态机迁移2.1 七态不是凭空多出来的CHI的状态模型比经典的MESI多出一截。MESI是四态Modified、Exclusive、Shared、Invalid。CHI在一致性缓存状态上定义了七态而且这七个状态不是文档作者拍脑袋加的它们对应的是多Die互连场景里“不得不区分”的几种真实情况。按我的习惯先把这七个状态列出来状态含义关键点IInvalid缓存行无效最干净的状态UCUnique Clean唯一且干净只有本地持有未修改UDUnique Dirty唯一且脏只有本地持有已修改SCShared Clean共享且干净多个节点可能持有SDShared Dirty共享且脏多个节点持有但其中一份被改过UCEUnique Clean Empty唯一、干净、但数据体为空UDPUnique Dirty Partial唯一、脏、但只有部分字节有效UC和UD好理解就是“独占且未改”和“独占且改了”。SC和SD对应“多个节点都有”场景下的Clean与Dirty。麻烦的是UCE和UDP。UCE的意思是这个缓存行在本地具有唯一权限但是数据本身还没被真正填充——这在CHI的某些原子操作、DMA、或者远端起包场景中很常见。你拿到的不是一个完整的数据体而是一个“准备好了、可以写回”的状态。UDP则对应部分写别的节点持有了这个缓存行的一部分但当前节点持有且修改了其中一部分字节缓存系统必须知道哪些字节是有效的否则写回时会把垃圾覆盖过去。这七个状态反映到比特层面至少需要3位编码。很多工程实现里会用4位甚至用独热码原因是硬件里状态比较的扇出压力很大多花一位能省组合逻辑。如果你在做RTL实现我建议状态编码别照着文档的语义编号硬来先确认状态转移条件下哪些状态对比较密集再选编码方案——这方面独热码在FPGA上通常比二进制跳转码更快但在ASIC上可能浪费寄存器资源。2.2 状态迁移的状态机建模一段式、两段式、三段式怎么选有了状态下一步就是迁移。CHI节点收到来自RN请求节点、HN主节点、SN从节点的消息时缓存状态要按消息类型做条件跳转。比如本地缓存是UD时收到ReadShared请求如果当前系统不允许共享脏行就要先做写回把UD变成UC或SC再回应读取方。这个“先写回、再共享”的过程在状态机里就是一条带条件的迁移弧。用硬件实现这个状态机时工程师圈里经常吵一段式、两段式、三段式哪个好。我的观点是互连协议状态机除非极小的控制块否则一律别用一段式。一段式把状态跳转和输出逻辑糊在一个always块里写起来爽但综合后时序收敛难后期加一个信号就要牵连一大片逻辑而且可读性很差。两段式把状态寄存器和次态逻辑分开适合状态数少、输出简单的场景。三段式则把状态跳转、次态判断、输出逻辑彻底拆开每条路径都能单独约束、单独看时序。CHI这种跨节点、多消息类型的状态机我强烈建议三段式——因为输出逻辑通常会依赖消息类型和储能状态等多个输入拆开之后至少你能在综合报告里清晰地看到“哪一段组合逻辑成了关键路径”。2.3 状态机的 SystemVerilog 落地写法拿CHI节点状态机做一个最简示例这是在实际工程里可落地的三段式骨架不是玩具代码。假设我们只处理I、UC、UD、SC四个主要状态的简化模型// 状态编码 typedef enum logic [1:0] { ST_I 2b00, ST_UC 2b01, ST_UD 2b10, ST_SC 2b11 } cache_state_t; // 三段式第一段状态寄存器 always_ff (posedge clk or negedge rst_n) begin if (!rst_n) cur_state ST_I; else cur_state next_state; end // 三段式第二段次态组合逻辑 always_comb begin next_state cur_state; // 默认保持 case (cur_state) ST_I: begin if (req_is_read) next_state ST_UC; else if (req_is_read_shared) next_state ST_SC; else if (req_is_write) next_state ST_UD; end ST_UC: begin if (req_is_snoop_read_shared) next_state ST_SC; else if (req_is_write) next_state ST_UD; end ST_UD: begin // 必须先写回不能直接共享 if (req_is_snoop_read_shared) next_state ST_SC; else if (req_is_snoop_read) next_state ST_UC; end ST_SC: begin if (req_is_upgrade) next_state ST_UC; else if (req_is_write) next_state ST_UD; end endcase end // 三段式第三段输出逻辑 always_comb begin data_permission 0; cache_op OP_NOP; case (cur_state) ST_I: cache_op OP_FILL; ST_UC: data_permission 1; ST_UD: begin data_permission 1; cache_op OP_WRITEBACK; end ST_SC: data_permission 1; endcase end这只是个简化的骨架。实际CHI节点里Snoop响应、Dataless响应、CompData里的缓存状态都会打进状态机七态之间的迁移会用一张大状态迁移表描述。做验证的时候你可以用SystemVerilog assertion把“UD状态不能在未写回的情况下迁移到SC”这类规则写成断言跑随机测试时只要断言被击穿立刻就能抓到协议违例——这比事后翻波形高效得多。3. PBR 路由在互连网络中到底在解决什么问题3.1 头拍缓冲数据拍穿透先把名字说清楚在Scale-up互连协议语境下PBR是Partially Buffered Routing部分缓冲路由不是网络工程师常说的“PBR策略路由”。策略路由是查策略表决定下一跳部分缓冲路由是决定“一个包经过路由节点时哪些flit必须缓冲、哪些flit可以免缓冲直接转发”。因为热搜词里混了“pbr策略路由”很多人一开始会进错方向所以这里特意指出来。部分缓冲路由解决的是一个成本问题Scale-up互连里数据包的典型大小是64B到128B的缓存行拆成多个flit后才能在高位宽互联线上传输。如果每个路由节点把所有flit都缓冲下来再做转发判决缓存面积和功耗会随节点数激增——你在NoC里铺上一堆大缓冲芯片面积和散热直接爆炸。PBR的思路是只把“带头拍”header flit和少量关键元数据flit缓冲到路由节点的队列里数据体flit则直接穿透由下一级按流水线式顺序接收。这样既保证路由决策有依据又不需要每个节点给整个包留缓冲区。但省面积是有代价的。数据体穿透意味着“你还没决策完数据已经在路上”。一旦仲裁结果和实际物理路径不匹配数据就会飞错端口所以在实现PBR路由节点时你必须保证仲裁判决在数据体到达前完成——或者用更保守的背压信号把数据体挡在上一级。这个约束直接影响了状态机和流水线级数设计。3.2 PBR 与 CHI 协同时的比特级结构一个CHI数据包从RN发出到HN处理再返回RN途中可能经过两到三级路由节点。每一级的PBR逻辑都在做“头拍进场—查路由表—分配虚通道—转发”这几件事。把CHI和PBR放在一起看你会发现一个关键点CHI负责“包里装的数据语义”PBR负责“包怎么在网络里走”。两者的交汇点是包头的路由字段。一个典型的CHI请求包头拍里包含以下关键字段字段位宽常见参考作用Opcode6位左右区分ReadShared、ReadUnique、WriteBack等操作Target Address地址位宽决定路由终点Node ID8~16位请求节点/目标节点标识Cache State3~4位当前缓存状态请求携带的来源状态QoS2~4位服务质量等级决定仲裁优先级Transaction ID10~16位区分多个在途事务PBR路由节点拿到头拍后会提取Target Address和Node ID查一次路由表决定从哪个输出端口走。CHI场景里通常还要多查一次“这是REQ类、RSP类还是DAT类”因为不同协议类型走不同的虚通道。这一步不能省略如果REQ和DAT混在一个通道里数据请求可能绕到数据包后面形成协议层死锁。真正做RTL的时候我经常提醒团队把“持拍”和“通过”两个状态分开。持拍是指头拍在路由节点停留等待资源通过是指数据体不需要缓冲直接往下一级走。这两个状态对应的信用credit管理逻辑完全不同。持拍占用一个条目通过只占用线的一部分空闲窗口。写状态机时如果只在头拍状态里做资源申请数据体穿透状态的逻辑会非常简单如果你试图“顺便”在数据体状态里再判断一次路由那就违背了PBR的初衷时序大概率收不紧。4. 六个开源协议在比特和状态机层面的横向解剖4.1 一张表看穿六个协议的核心差异把这六个协议放在同一张表里可以从宏观层面快速定位各自的“生态位”。这里的参数不是某个厂商的精确数据手册值而是工程实现里的常见范围具体RTL集成时还要看配置。协议一致性支持缓存状态数拓扑路由机制缓冲策略典型使用场景CHI有七态或可裁剪多层互连/NoC基于Node ID、地址的路由全缓冲或PBR多Die、一致性域扩展、高性能Scale-upTileLinkTL-C有TL-UL无TL-C约五态类似MESI点对点/星型/分层固定主从链路无显式路由多数全缓冲RISC-V SoC、一致性SoC集成AXI4无无主从双向通道地址译码器选择从机通道FIFO内存映射外设、DMAAXI4-Stream无无点对点流无地址纯流向流FIFO数据流处理、通信IPOCP无无点对点为主配置映射简单握手缓冲定制SoC、IP核互联Wishbone无无共享总线/交叉开关地址译码选择简单寄存器缓冲教学、轻量级MCU系统这六个协议里真正有身份感的其实是CHI和TileLink一个面向大系统的全一致性互连一个面向RISC-V核的片内一致性互连。AXI、AXI-Stream、OCP、Wishbone都没有缓存一致性状态机它们更多扮演“搬数据”的角色。做Scale-up系统时常见组合是用CHI或TileLink搭一致性骨架用AXI接DDR/DMA控制器用AXI-Stream接通信IP。4.2 关键差异背后的设计取舍先看状态机复杂度。CHI的七态意味着硬件里至少几十条状态迁移弧每一条都要处理消息类型、缓存状态、Snoop结果三类输入的组合。TileLink的TL-C则做了个简化它把一致性操作划分成A、B、C三个通道状态大约五类Invalid、Clean、Dirty三档再细分基本是MESI的变种。对大多数单Die多核SoC来说TL-C这个复杂度是合适的但如果你想在互连网络上做多协议桥接——把TileLink的一致性请求转成CHI的SNP请求——你就会发现状态对齐非常痛苦因为TL-C里“Dirty”不像CHI的UD/SD那样区分得那么细桥接时不可避免要做状态映射的近似处理。再看路由机制。AXI4、AXI-Stream、OCP、Wishbone本质上都不携带路由字段。AXI是靠地址译码器把一笔事务送到对应的从机Wishbone是类似的总线选择逻辑OCP走点对点互连压根没有“经过中间节点”的概念。所以在这些协议里讨论PBR是没有意义的——没有路由表可查也不存在头拍和数据拍之分。CHI和TileLink才是真正能承载“Scale-up互联拓扑”的协议因为它们天然支持多节点、多跳、带地址路由的一致性事务。缓存策略的差异也很关键。全缓冲状态机写起来最省心每个包在整个节点上都被完整缓存仲裁逻辑只需要在队列非空时做调度不会出现“数据体已经穿过去了但仲裁结果还没出来”的时序险象。但代价是每个节点的面积和功耗上去了。PBR的实现复杂度比全缓冲高但它能在路由节点上省下大量SRAM面积收益在几十个节点的NoC上非常可观——这也是为什么我会把它和CHI放在一起讲因为CHI场景里节点多、跳数多、一致性流量重最适合发挥PBR的价值。4.3 不同场景的选型建议如果只做单Die内的多核SoCTileLink是个性价比很高的选择状态机简单RISC-V生态配套成熟。如果要做多Die、多Chiplet甚至机柜级Scale-up那就得用CHI或者至少是带一致性扩展的NIUNetwork Interface Unit帮助你桥接。如果你只是在做外设接入AXI4仍然是兼容性之王做流式数据搬运AXI4-Stream最轻快做教学或超轻量控制器Wishbone简单得让人感动但它真不适合跟一致性系统搭伙。我见过不少团队做了一个“用CHI做NoC、但底层数据通路还是AXI风格”的混合设计最后在协议转换上浪费了几个月。协议选型不是选最好看的而是选“状态机匹配你系统规模”的。用量化方式说节点数少于4个TileLink或AXI协同足够节点数上到8个、16个CHI的分层拓扑和PBR/虚通道优势才会真正体现出来。5. 实战环节如何用状态机视角验证一个 Scale-up 互连5.1 从状态机跑飞排查谈起我调试互连状态机时最常遇到的故障不是逻辑算错而是“状态机卡死”。卡死的原因绝大多数不是协议文档写错而是你漏了一条迁移弧某个状态下收到某种消息你忘了定义它的次态行为于是默认保持原状态结果后端队列一直等不到释放信号整条链路的信用credit耗尽事务就悬死了。排查这个问题的第一工具不是波形是断言。我在RTL里给每个协议节点都会写一组基础断言比如“任何状态收到消息后必须在N拍内产生回复或推进状态”跑随机验证时只要断言超时就能反推是哪个迁移弧漏了。第二工具是覆盖率统计。CHI七态之间满打满算有几十条迁移弧如果覆盖率报告里某条弧永远没踩到你要么没构造对应场景要么就是状态机设计里有死路径。还有一个非常容易被忽略的点复位后的初始状态。CHI节点上电时所有缓存状态必须是I不能有任何“X态”或“UC态”。如果RTL里用了没有复位值的内存作为状态存储综合后状态机上电可能是乱码首个事务就会打到错误的状态上。我在验证环境里会专门跑一条“上电后立即发起ReadUnique”的用例专查复位残留问题。5.2 一致性广播风暴与 PBR 缓冲的联动问题Scale-up互连里真正容易炸的是广播类一致性请求。一个远端节点发起ReadSharedHome Agent需要向所有持有该缓存行的副本发Snoop请求。假如系统里有16个节点同时在做清理和共享操作广播风暴能把路由节点和缓冲队列瞬间打满。这时候PBR的“只缓冲头拍”策略虽然省面积但如果队列深度配置过小头拍一样会排队数据体的穿透通道被上游阻塞后整个系统的有效带宽反而比全缓冲还差。这类问题的最佳解法是“动静分离”把一致性控制报文REQ、SNP、RSP和纯数据报文DAT拆到不同的虚通道里并且给前者配置固定的小缓冲、后者配置PBR穿透路径。这样即使广播风暴来的时候控制报文也有专用的存储出去的路不会和数据报文互相抢占缓冲。这个设计模式算不上什么黑科技但我在好几个项目里都看到因为偷懒把两类报文混在一个FIFO里事后被死锁问题反复折磨。排查缓冲联动问题时我一般先看“信用计数”和“队列水位”。信用计数降为0但队列没满说明有丢信用的逻辑Bug队列满但信用计数正常那大概率是上游把量打满了需要查调度仲裁的公平性。这两个信号一起看能快速定位是协议层还是微架构层的问题。5.3 几个值得收藏的排查技巧最后分享几个我调试Scale-up互连时比较管用的土办法第一个技巧是“单包追踪”。在验证环境里打只允许一个事务从发起端走完整条链路所有节点的队列水位只应该有这个事务的包。此时抓波形看头拍和数据拍经过每个节点的时间戳能准确算出每一跳的固定时延和调度时延。如果发现某一跳的时延远超预期该节点大概率在等待某个资源——接下来查它的状态机条件即可。第二个技巧是“制造乱序”。很多互连问题平时不出现是因为事务顺序碰巧线性。你可以随机给不同事务配置不同优先级打乱数据体到达顺序再看目标节点的状态机是否还能正确响应。CHI场景里乱序最容易暴露的是缓存状态回写竞态一个ReadUnique还没处理完另一个Snoop又插进来如果状态机没有做中间态intermediate state缓存最后一定丢数据。第三个技巧是用形式化验证跑“无死锁证明”。对状态机规模不大的互连块用形式化工具穷举所有状态组合证明“不存在终态卡死且队列非空”的状态。这个方法对CHI节点这种中等规模状态机非常有效对多节点整体互连则可能状态爆炸所以建议对单节点做形式化对全网做动态仿真。第四个技巧是留意“超时计数器”的粒度。Scale-up互连里每个事务都有一个全局超时时间从请求发出到最终接收数据。如果超时口径不同可能引发误报一个请求真的被阻塞时有的节点超时触发重试而另外的节点还在等待响应最终造成状态机双活。做超时设计时统一口径比调大数值重要得多。6. 写在最后的一点实操体会我在多个项目里被CHI的“七态”坑过也被PBR的“数据体穿透”坑过回头想想坑都不在协议本身而在“协议语义到状态机实现”的映射精度上。协议文档画的状态图只是纸上谈兵真正决定成败的是你把哪条迁移弧写漏了、把哪类控制报文混进了数据队列、把哪个超时计数器配置错了粒度。所以我一直觉得做Scale-up互连最重要的能力不是会读协议文档而是能把文档翻译成一群可验证的状态机、一组可量化的缓冲策略再用断言和覆盖率把它们拴住。如果你正打算在系统里引入CHI或者准备把TileLink的一致性域扩展到多Die建议先从小规模、低跳数的拓扑练手把状态机的迁移覆盖率和PBR的缓冲水位调明白再往大规模扩张。这种系统没法靠“试出来的稳定性”硬扛只能靠一层层比特级、状态机级的较真堆出来。
