最近在梳理 Scale-up 互连协议的时候我把 CHI、TileLink、ACE、CXL、UCIe、OpenCAPI 这六个协议从比特到状态机逐层过了一遍。标题里那半句“从 CHI 七态到 PBR 路由”其实藏着两条主线一条看缓存一致性状态机到底把“谁拥有这行数据”画成了几个状态一条看报文在互连网络里转发时到底拿哪几个比特来做决策。这篇文章想把这两条线拆开揉碎适合三类人看正在做 SoC 互连或 chiplets 方向的设计验证工程师、被 Scale-up 生态各种缩写搞晕的软件栈同学、以及想把协议对比当成案例来学的 RISC-V/Chipyard 玩家。我会尽量用说人话的方式把每个协议的报文结构、状态集合、路由思路和坑位都摆出来。1. 为什么要较真到“比特和状态机”层面1.1 Scale-up 与 Scale-out 的本质差别先讲一个容易被忽略的前提。Scale-out 的思路是“加节点”每台机器自己管自己的缓存和内存节点之间靠消息通信跨节点一致性基本不做或者做得很粗。Scale-up 的思路是“加资源”把更多核、更多内存控制器、更多加速器塞进同一个一致性域里大家看到的是一份共享地址空间某一行缓存数据可能同时在好几个位置出现。打个比方Scale-out 就像公司开了一堆独立小办公室各写各的白板靠邮件同步结果Scale-up 是把所有人塞进一个大会议室共用一块白板那你就必须定一套规则谁拿笔、谁先擦、谁写了又划掉之后别人能不能看到旧内容。互连协议就是这套规则的文字版和电路版。规则里最难的三件事恰恰就是报文长什么样比特层面、数据在不同缓存里处于什么状态状态机层面、请求应该发给谁路由层面。不做协议级对比你永远只是在看概念 PPT。1.2 协议级对比的正确打开方式我在对比时习惯按三个维度切而不是拿“谁支持一致性强”“谁带宽高”这种话来回说比特维度通道怎么分、报文头有哪些字段、数据是 packet 还是 flit、事务 ID 怎么复用、有没有 CRC/ECC。状态机维度缓存行在客户端是什么状态管理器目录端是什么状态哪些事件触发状态迁移数据所有权怎么转移。路由维度一个请求从发起节点到目标节点的路径由什么决定是查地址表、走哈希散列还是交给策略路由决策。这三个维度是互相咬死的。状态机决定了报文的 opcode 种类路由决定了报文头里必须携带哪些 ID 和地址位比特宽度反过来又限制了状态机的并发能力。只看其中一个很容易得出错误结论。比如 CHI 看起来比 TileLink 复杂但如果只看包格式不看目录模型你就理解不了它为什么要搞那么多 snoop 类型。1.3 六个协议是怎么圈出来的我选的六个协议是拿“覆盖半径”来圈的TileLink 代表 RISC-V/Chipyard 生态最常见的 SoC 内互连协议ACE 代表 AXI 时代的补丁式相干扩展CHI 代表服务器级多节点 Mesh 互连的今天和未来CXL 代表机架级内存池化和 Scale-up 系统的新型互连UCIe 代表芯片到芯片die-to-die的物理与传输层标准OpenCAPI 则是加速器相干接口里曾经被寄予厚望的开放路线。CCIX、Gen-Z 我这次先不展开它们要么已经并进 CXL 路线要么生态声音已经弱了拿来凑数没意思。需要说明一点“开源协议”这四个字口径不一。TileLink 从头到尾都是开放的规范、RTL、验证工具都能拿到ACE、CHI 的规范 AMBA 系可以申请获取也有社区 RTL 实现CXL 和 UCIe 是联盟公开规范实现要自己搭OpenCAPI 当年也开源过 FPGA 参考 IP。所以这里讲的“开源”我按“规格公开、存在可学习实现”来理解而不是纯 License 意义上的开源。2. 比特层面报文、通道与链路帧结构2.1 先建立一个统一的分析框架拿几个协议直接对着看比特是容易劝退的因为每个协议对“一个消息”的叫法和封装都不一样。我建议先建立一个统一分层视角物理层PHY负责电信号和时钟链路层负责流控、报文边界和错误重传传输层如果存在负责把上层消息变成统一 flit 或 TLP协议/事务层负责表达“读”“写”“snoop”这些语义。在这个框架下六个协议的差异点就很清晰了协议主要通道/流传输单元流控方式典型错误保护TileLinkA/B/C/D/E 五通道beat一拍一数据源/目标端 valid-ready 握手无强制 CRC靠端到端检查ACEAXI 五通道 AC/CR/CDbeat握手 缓存一致性管理器无强制 CRCCHIREQ/RSP/SNP/DAT 四通道flit/packetCredit 信用计数CRC retryCXLcxl.io/cxl.cache/cxl.memflit/TLPcredit 重传FEC CRCUCIeD2D 逻辑通道/流flitcreditCRC retry crosstalk 规避OpenCAPI请求/响应/数据流TLP 风格报文creditCRC 重传这张表填完你会发现一个共性凡是走片外、跨 die 或者跨机箱的协议全部上了 CRC、retry 和 credit凡是只在片内 SoC 里转悠的协议可以用简单的 valid-ready。这不是偶然片外链路的信道噪声和延迟方差大得多你不能让协议层每拍都去做重传决策必须下沉到链路层统一处理。2.2 CHI 的四通道与 flitCHI 把消息按语义分成四个通道REQ请求、RSP响应、SNPsnoop 探测、DAT数据。每个通道有独立的 credit 流控也就是说跑 REQ 的链路粒度耗尽不会挡住 DAT 的数据传输。这么做是为了避免一致性协议里最常见的死锁一个节点在等数据的同时另一个节点需要 snoop 探测才能把数据让出来。通道分开了阻塞域也分开了。报文头里值得记住的字段有四个Opcode事务类型、TgtID目标节点 ID、SrcID源节点 ID、TxnID事务 ID。地址位宽在典型实现里按 48 位算TxnID 的宽度决定了你这个节点最多能同时挂多少个未完成事务——这直接决定带宽利用率。数据通道在常见配置下按 32B 或 64B flit 组织128 位和 256 位链路宽度都有。很多初学 CHI 的人会问“CHI 是包还是 flit”我的理解是协议层是 packet链路层再接一层 flit 封装加上 CRC 和 flow control 字段。你看 header 时把这两层分开就不会乱。2.3 TileLink 的 A~E 五个通道TileLink 用字母通道名这是它和 AXI/CHI 最明显的区别。A 通道是请求B 通道是探测probeC 通道是响应/释放releaseD 通道是数据响应E 通道是授权的最终确认grant ack。其中 E 通道是很多人刚上手时会漏掉的关键TileLink 的一致性协议要求授权必须闭环客户端收到 D 通道的 Grant 之后必须回一拍 E 的 GrantAck管理器收到 E 之后才认为这次转移真正结束。漏了 E协议检查器立刻报错。A 通道的报文头包含 opcode、param、size、source、address、mask 等字段。source 字段是客户端给自己的事务起的编号D 通道回数据时靠 sink 字段指回对应的请求方。这里的核心思想是“一个请求一个 source ID”并发事务数受 source 位宽限制。数据路径的 beat 宽度通常等于总线宽度比如 64 位或 128 位burst 由 size 字段指示这一点和 AXI 的 AxLEN 类似但语义更收敛。2.4 ACE 的相干扩展通道ACE 是在 AXI4 基础上加了三个相干通道AC相干请求地址、CR相干响应、CD相干数据。它的思路是“兼容旧世界”非一致性的 master 继续用 AW/W/B/AR/R一致性 master 额外走 AC/CR/CD由一致性管理器统一调度。ACE 的 snoop 类型很长一串ReadClean、ReadShared、ReadNotSharedDirty、ReadUnique、Clean、CleanShared、MakeInvalid 等等跟 CHI 的 SNP opcode 有大量对应关系。但从协议工程的角度看ACE 最大的问题在于它把一致性相关的状态机摊在各通道的 sideband 信号里而不是像 CHI 那样把“协议语义”和“传输机制”彻底拆开。结果就是信号多、组合逻辑复杂、验证矩阵爆炸。ARM 后来推 CHI 取代 ACE本质上就是嫌旧方案在可组合性和时序收敛上吃亏。如果你是新手ACE 可以作为学习 MESI 扩展到总线上的入门材料但新项目就别指望它扛大梁了。2.5 CXL 的三种协议封装CXL 一口气定义了三种协议cxl.io 走 PCIe 兼容路径负责设备枚举和传统 IOcxl.cache 管设备侧缓存一致性cxl.mem 管内存访问和内存池化。三种协议可以在同一条链路上按优先级动态复用这就在比特层面引入了“协议标签”的概念——同样是一个 flit你得先看它的协议类型才知道后面字段怎么解析。在 flit 封装上CXL 跟随 PCIe 规范的演进较早版本用类似 68B 的 flitCXL 3.0 时代进入更宽的 256B flit 体系把 FEC、CRC 和重传机制都糅进物理层。理解 CXL 的比特结构时我建议你先忘掉“一个请求一个包”的直觉把它想象成一条持续流动的流水线每个 flit 里可能混着 cxl.mem 的读请求、cxl.cache 的 snoop 响应和 cxl.io 的配置写。这也是为什么 CXL 的调度器必须支持严格优先级仲裁一个 flit 放错了等级延迟抖动就会变大进而影响整机性能。2.6 UCIe 与 OpenCAPI 的传输层差异UCIe 是所有协议里最好被误解的一个它本身不定义缓存一致性状态机也不定义“读”“写”这种事务语义它只解决一件事——让不同来源的 die 之间可靠、低延迟地搬运数据。UCIe 的比特层面由三块组成物理层bump、lane、时钟、die-to-die 适配层把上层协议映射成统一 flit负责 CRC、retry、串扰规避以及协议层映射支持 PCIe、CXL、流式协议。你在 UCIe flit 头里看到的信息主要是流标识stream ID、长度、CRC 这些运输字段而不是一致性状态。OpenCAPI 的报文结构更接近传统总线事务请求、响应、数据分开组织数据粒度常见为 64B 或 128B链路层同样有 credit 和 CRC。它的特色是把地址翻译作为核心能力设备端通过 MMIO 和地址映射访问主机内存相干性依赖主机内存模型和共享页表管理。这套设计在 IBM POWER 生态里有实际落地后来被 CXL 生态挤压现在更多作为历史案例和经验参考而不是新项目首选。2.7 比特层面的五个共性规律把六个协议摊开看绕来绕去其实跑不出五个规律。第一所有协议都有 request/response/data/snoop 四类语义只是通道组织方式不同第二所有协议都要求有一个事务 IDsource/tag/txnid用来把请求和响应配对这个字段的位宽就是并发上限第三所有协议都带了优先级/QoS 字段哪怕早期 TileLink 没有显式 QoS你也可以通过不同通道的仲裁权重来等效实现第四凡是跨 die 或跨设备链路的全部无条件上 CRC、retry、credit第五片内协议倾向轻量化握手片外协议倾向 flit 化流控。这五条记住后面看任何一个新协议都能快速定位它的设计坐标。3. 状态机层面从 CHI 七态说起3.1 CHI 的缓存状态到底怎么数先回答标题里最扎眼的“CHI 七态”。严格对着规范走CHI 的 RN-F全一致请求节点缓存主数据态是六个IInvalid、UCUnique Clean、UCEUnique Clean Empty、UDUnique Dirty、SCShared Clean、SDShared Dirty。那第七个态从哪来业内流传的说法有的把“Snoop Filter 里的 Present/Pass 状态”算进去有的把“UCE 从 UC 里单独拎出来之后 UD/US 过渡态”也加进去所以在聊天、面试和博客里会出现“七态”这个口径。我的建议是你自己心里先把六态背熟遇到“七态”这种说法时反问一句对方的计数口径是什么。通常对方会说“把 UCE 算一态再算上目录的独占过渡态”或者干脆是记成了 MESI 的七种权限组合。这其实正说明一个道理——协议状态数不是一个客观事实而是你站的角度。站在缓存端是一个数站在 Home 节点目录端是另一个数站在 L3 的 snoop filter 入口又是第三个数。把这三种视角分开比纠结“到底几个态”重要得多。六个主数据态的含义可以这样理解I无效没有任何数据。UC唯一干净只有当前节点有这份数据且和内存一致。UCE唯一干净但内容无效数据是空的这个态专门用来支持“我马上要全写别给我传旧数据”省掉一次数据搬运。UD唯一脏当前节点独占修改内存是旧值未来需要回写。SC共享干净多个节点可持有内存是最新值。SD共享脏数据被修改过但还允许被其他节点共享读内存是旧值必须由某个持有者负责提供数据。SD 态是 CHI 里最有意思的设计。它本质上是 MESI 里 Owner 思路的变体脏数据不一定只有一个人持有只要大家约定“谁能拿这行数据当权威源”就能在保留共享读性能的同时不急着写回内存。一次典型迁移大概是这样的节点 A 发起 ReadUnique 读一份它打算改的数据Home 节点查到这行数据在节点 B 手里是 UD于是给 B 发 snoop 要求让出。B 的数据经 Home 转给 AB 的状态降成 IA 拿到数据后落在 UD 或 UCE。整个过程里Home 扮演裁判角色维护目录视图真正搬数据的动作可能发生在 B 和 A 之间也可能绕到 Home 中转这由互连拓扑决定。理解关键就一句话状态下沉在节点仲裁权上缴给 Home。3.2 TileLink 的 I/C/E/M 与目录元数据TileLink 的状态模型比 CHI 难背一点因为它把“权限级别”和“脏位”分开了。数据态主要有四个IInvalid、CClean/Shared、EExclusive、MModified同时带一个 Dirty 元数据位。所以你看 TileLink 的协议文档时会发现它不怎么说“SD 态”而是说“共享且脏”的属性组合。TileLink 的一致性管理器侧会维护每行数据的 Valid、Dirty、Permission 信息通过 A/B/C/D/E 五通道的数据流来同步这些信息。TileLink 请求用 AcquireBlock/AcquirePerm 来获得权限带一个 grow 参数表示想“成长”到什么级别管理器用 Grant/GrantData 响应客户端用 GrantAckE 通道确认管理器主动发 Probe 降级客户端权限时带一个 cap 参数。这套“成长/限制”的表达方式比 CHI 的 opcode 列表抽象了一层代价是初学者需要先理解“权限等级”和“数据结构”是两个维度。我自己学的时候画了个小表请求方想要什么权限、管理器能给什么权限、数据是脏是干净三者一组合状态迁移就全出来了。TileLink 状态机相对好理解的根本原因是它把目录集中化了。一个地址区间只有一个管理器所有一致性决策都收口到这一处客户端之间的交互全部要过管理器。这个设计牺牲了一点并行度换来了可组合性和可验证性这也是为什么 Chipyard 生态能靠 TileLink 轻松组合出几十个核的 SoC。3.3 ACE 与 CXL 的 MESI 变体ACE 的状态模型跟 MESI 家族非常接近常见描述是 I/C/E/M 加脏位本质上是一致性管理器加 snoop 总线。它的转移路径主要靠 AC 通道的相干读/写请求和 CR 通道的响应来驱动。由于 ACE 是给 AXI 做扩展所以它没有像 CHI 那样专门设计 UCE 这种“空数据独占”态总线读写时数据搬运路径比较直白但这也意味着某些场景下会有多余的数据传输。CXL.cache 的缓存状态也是 MESI 变体设备侧缓存行通常有 Modified、Shared、Exclusive、Invalid 几种状态通过 cxl.cache 的请求和 snoop 消息来协调。CXL.mem 侧又是另一套逻辑主机的内存控制器通过 HBIback-invalidate把失效消息推给缓存的设备处理的是“设备缓了主机的内存行”这个场景。如果你把 CXL.cache 和 CXL.mem 分别看会发现它们其实服务的是两种不同的 Scale-up 目标cxl.cache 是让设备加速器安全地用主机缓存cxl.mem 是让内存从主机里被拉出来池化。两种场景的状态机复杂度根本不在一个量级。3.4 状态机对比总表协议客户端状态集目录/管理器状态数据所有权特点主要触发事件CHII/UC/UCE/UD/SC/SDHome 节点目录Present/Pass/转移中脏数据可共享SD按需回写REQ/SNP/RSP/DAT 四通道事务TileLinkI/C/E/M Dirty管理器集中维护 ValidDirtyPermission权限成长/降级显式可控Acquire/Release/Probe/GrantACEI/C/E/M 加脏位一致性管理器传统 MESI 扩展AC/CR/CD 相干事务CXL.cacheM/S/E/I主机侧 HBI 管理设备缓存挂靠主机内存cxl.cache 请求/失效CXL.mem无设备缓存态主机内存控制器内存池化、托管读写/回写/失效UCIe无透传无不感知缓存在 D2D 流上运载上层协议OpenCAPI依赖主机内存模型MMU/地址翻译设备地址映射相干请求经地址翻译路由这张表的核心结论是状态机复杂度不完全等于协议成熟度而是和“你打算让缓存一致性域覆盖多大物理范围”强相关。片内单 die 做四态足够片内多 die 上七态也不一定够跨设备做内存池化时真正难的反而变成失效广播和地址路由这正好把我们推向下一章。4. 路由这件小事PBR 与转发策略4.1 先给 PBR 正名“PBR”这三个字母在不同圈子撞衫撞得厉害。图形学圈子里PBR 是 physically based rendering材质渲染那一套网络圈子里PBR 是 policy-based routing策略路由。在 Scale-up 互连协议这个上下文里我借用的正是网络圈的“策略路由”思想转发决策的查表键不再只是目的地址而是“地址 协议类型 事务类型 QoS/优先级 节点编号”联合起来的一张表。为什么需要联合键因为在一个大系统里同样一个地址区间的读请求来自普通 CPU 核和来自实时加速器的请求对延迟和带宽的要求完全不同同一个节点发出的写请求走一致性写还是非一致性写去往的 Home 节点可能不一样同一条链路上的报文如果全都挤同一个虚拟通道一旦高优先级流量被低优先级报文卡住整个系统的延迟尾巴立刻变恶。PBR 的核心就是把调度和转发的策略显式化。CHI、CXL、UCIe 在底层都做了一定程度的 PBR只是各自叫法和实现角度不一样。4.2 CHI 的 Home 节点选择与 snoop 路由CHI 的 Mesh 里有很多 Home 节点HN-F一个请求到了之后必须决定找谁承办。这不是查一张大表而是用地址位直接算。常见做法是把地址的低位去掉块内偏移后按 interleave 切分再配合 XOR 散列摊开保证相邻地址落到不同 Home避免热点。我把一个简化的计算写了出来def home_index(addr, block_offset_bits6, num_hns16): a addr block_offset_bits low a (num_hns - 1) high (a 4) (num_hns - 1) return (low ^ high) % num_hns这套“按地址哈希选 Home”的机制从网络路由的角度看就是一种静态 PBR查表键是地址位策略是散列函数路由目标是 Home 节点。优点是不需要维护转发表规模扩展到几十个节点也能保持低延迟缺点是地址布局要规划好两个 Hash 位选得不好某些地址区间就挤到同一个 Home 上。snoop 路由则是另一条线。Home 节点拿到数据行的目录信息后决定给哪些持有者发 SNP。CHI 里还有一种点到点的“snoop 转发”模式数据可以由持有者直接回给请求方经不经过 Home 都行。这样就把“目录仲裁路径”和“数据搬运路径”解耦是 CHI 能支撑高并发互连的关键。在网格拓扑里报文的 TgtID 会被路由器解析成二维方向的跳数这也是 PBR 的另一个维度地址哈希只是选端点Mesh 内部走 X-Y 路由还是协商式路由又独立影响延迟和收敛性。4.3 TileLink 的“单管理器”路由模型TileLink 的路由模型在所有协议里最简单但简单不等于粗糙。它的每个地址区间只有一个管理器因此请求方的路由动作本质上就是一次地址区间查表这个地址归哪个管理器管就把 A 通道请求发给谁。Chipyard/Diplomacy 里你可以把系统地址空间切成若干个区间每个区间挂一个或多个占位管理器之间的互不重叠由工具强制检查。这种“单管理器”模型的好处是做验证的人在状态上不会分裂同一时间对同一地址的一致性决策只有一个权威不存在两个 Home 抢同一份目录视图的情况。坏处也很直观——管理器成为热点所有跨节点的 cache line 操作都要挤向同一个点。所以 TileLink 在实际大型 Scale-up 系统里需要靠地址切片把不同地址区间分布到多个切片上来做并行本质上是把“哈希路由”迁移到了系统设计阶段而不是运行时由协议自动完成。如果你在做比赛原型或学术 SoCTileLink 的简单路由让你能快速跑通如果你要冲百万行级缓存一致性服务的场景CHI 的运行时哈希会更合适。规模决定路由策略的复杂度这是选型时的一条铁律。4.4 CXL 的 Fabric 与点对点转发CXL 3.0 之前的模型是主机为中心的星型拓扑路由压力集中在一台主机的 root port 上。CXL 3.0 引入 Fabric 和交换以后路由就从“你找我还是我发给你”变成“整个网络里的 switch 都知道该往哪送”。CXL 的报文头里需要带足够的标识让 switch 做决策目标是某个内存设备某个加速器还是回到某个主机这跟以太网交换机查 MAC 表思路相似只不过查表键里混进了内存地址和协议类型。cxl.cache 的请求还带 Cache ID 和 Cache Tag路由时要把这些信息也一并考虑switch 才能把失效消息准确投给那个缓存了对应行的设备。这个层面我理解就是典型的 PBR 落地一个 flit 到达 switchswitch 同时看地址位、协议位、请求类型位然后决定转发队列方向和优先级。CXL 的交换结构设计是否高效直接决定了内存池化系统能不能在不加网络层的情况下把几十个主机连成一套可共享内存的 Scale-up 系统。4.5 UCIe 的 die-to-die 流路由与 OpenCAPI 的地址路由UCIe 的路由粒度和前面几个协议不太一样它不关心单个内存地址归谁它只负责把不同的“流”复用同一条 D2D 物理链路。UCIe 逻辑层支持多路协议流同时存在每个流带一个流标识适配层按流标识做多路复用和解复用。路由决策发生在“谁来抢占当前链路”这个层面属于链路级策略路由。你可以用 UCIe 同时运载一个 CXL 流和两个 PCIe 流但带宽怎么分、哪个流优先级更高是适配层策略决定的。OpenCAPI 则回到地址路由的老路。它的事务层把地址翻译成目标设备的内存端口然后走请求/响应/数据三条独立通路。它不像 CHI 那样跑 Mesh 多跳更多是点对点或小规模星型。OpenCAPI 对“谁是地址翻译者”有很明确的划分主机侧负责把物理地址翻译成设备可识别的地址设备侧则通过 MMIO 和通道寄存器配好映射。这个设计在加速器场景很好用因为加速器不关心整机内存拓扑只要知道自己能访问哪一段就行。4.6 PBR 的关键设计维度把几个协议的转发逻辑抽象出来你会发现真正要决策的问题其实只有五个查表键包含哪些维度纯地址TileLink 区间查表、地址加事务类型CHI 的 opcode 影响 snoop 路径、地址加协议类型加 QoSCXL 交换。决策粒度按连续地址区间、按单个缓存行、还是按 flit 流。虚拟通道切分有多少个 VC分别给哪些流量用这是死锁避免的主要手段。保序模型同地址的请求是否严格保序跨地址是否允许乱序。流控联动credit 是发起端记账还是接收端授权credit 状态本身也是路由能否继续的前提。如果把这五个维度放回到六个协议里一个清晰的判断就出来了协议进化的大方向是把路由信息从“只有地址”逐步升级为“地址 事务语义 服务质量”也就是 PBR 的思路在硬件互连里越来越普及。不要再觉得策略路由只是网络路由器的专属名词了。5. 横向对比六个协议六种哲学5.1 一张表看透六个协议协议定位状态模型路由模型报文单元适用规模生态代表TileLinkRISC-V SoC 内一致互连I/C/E/M Dirty单管理器地址区间查表beat片内多核Rocket Chip、ChipyardACEAXI 时代的相干扩展MESI 变体集中管理器 snoop 总线beat中低端移动 SoC已由 CHI 取代CHI服务器级一致互连六态 过渡态哈希选 Home Mesh 转发packet/flit多 die/几十节点Neoverse 生态CXL机架级内存与设备互连cxl.cache MESI 变体Fabric switch 查表flit/TLP多主机内存池化CXL 联盟生态UCIedie-to-die 物理传输无状态透传流标识复用flit单个封装内多 die还是制定中的硅前生态OpenCAPI加速器相干接口依赖主机 MMU地址映射路由TLP 风格点对点加速器POWER 生态这张表有一个隐藏的阅读方法从右上往左下看你会发现协议的责任边界在往外扩。TileLink 只管片内CHI 管封装内多 dieCXL 管跨机箱的多主机内存池UCIe 把自己定位成最底层的运输工。把边界画清楚很多争论其实就散了——比如“TileLink 能不能替代 CHI”这种问题本质是问“片内协议能不能干片外调度”答案当然是不合适链路可靠性工程就不是人家要解决的题。5.2 选型建议如果你的项目是 RISC-V 内核、Chipyard 流程、可综合的 RTL 原型TileLink 是第一选择。它和 Diplomacy 参数系统深度绑定加核、加外设、加一致性域的配置成本远低于其他协议。如果你的目标是 ARM 服务器级性能或者需要一个已经验证过的多节点一致互连架构CHI 是事实标准。你需要准备的是协议验证能力光有一个 RTL 网表没意义。如果你做的是内存池化、异构内存、CXL switch 这类系统级产品CXL 3.0 是你绕不开的协议。它的比特层面和状态机还在快速演进跟联盟规范要保持同步。如果你做的是先进封装里的 chipletsUCIe 作为 D2D 链路层值得重点投入但它的上层协议映射得自己定不能指望 UCIe 替你解决一致性。OpenCAPI 面向的是特定历史节点上的加速器场景现在新项目里它基本不是首选除非你要兼容存量 POWER 生态或做协议考古。5.3 开源源码与学习材料怎么选TileLink 的直接学习资源是 Chipyard 和 Diplomacy 生成出来的 RTL你可以跑 verilator 仿真搭配 TileLink 协议检查器看违规。CHI 的学习资源里有公开的规范文档和大学公开的简化 RTL 实现想深入的话先把链路层 credit 逻辑吃透再去看协议层状态机。CXL 的公开实现到目前为止主要集中在 Linux 内核的 CXL 驱动栈和 QEMU 的 CXL 仿真上硅前协议细节要看联盟发布的 spec。UCIe 的 RTL 参考实现目前还不是完全开放更多靠链路工作组的文档和测试芯片来学习。OpenCAPI 当年的 FPGA 参考 IP 和文档现在还挂在网上做协议演进研究的人可以去翻。6. 实操验证怎么把一个协议跑起来6.1 TileLinkChipyard 里跑通一致性事务我的建议是从一个最小的双核加共享 L2 的配置开始。流程大致是拉下 Chipyard 仓库切到你熟悉的分支用subsystem配置定义两个 Rocket 核和一个 Banked L2跑make verilog生成 RTL再用 verilator 仿真跑一个简单的裸机多核程序。验证时不要只关心结果对不对重点去观察 A/B/C/D/E 通道的信号波形。你会看到某个核发起 AcquireBlock 之后管理器向持有者发 Probe然后数据通过 D 通道返回最后 E 通道盖棺定论。TileLink 生态里我最推荐的是它的协议检查器很多协议违例不是功能错乱而是时序超时。把TileLinkMonitor打开之后它会在每个通道的 beat 上做协议断言检查。比如你写了一个错误的占位让两个 master 同时认领同一地址区间检查器会在仿真一开始就红。这种错误在手写 RTL 时极难发现检查器让你在几分钟内定位到 bug这是协议验证的最佳实践。6.2 CHI用参考实现和协议检查器CHI 的完整 RTL 在大厂手里公开环境里能跑的主要是两种路径一是用 gem5 里基于 CHI 的 coherence protocol 模型做架构级仿真二是找大学开源的 CHI 子集 RTL 做学习。用 gem5 时要注意CHI 模型对系统配置的约束比 MESI 强节点数量、Home 节点映射、地址交错位都要先配好不然仿真会在一致性消息上卡住。我实际跑过的经验是先不要急着上多节点 Mesh先用一个 RN-F 加一个 HN-F 加一个 SN-F 的最小闭环验证一次 ReadUnique 的完整消息序列。每看到一条 REQ、一条 SNP、一条 RSP、一条 DAT 都记录下来和规范里的 message sequence 图对比。把最小闭环画熟再扩展到多个节点、多 Home 哈希你才能真正体会到 CHI 的互连不是“一根总线”而是一张需要转发策略的网络。6.3 CXLQEMU 仿真实验近几年 QEMU 已经支持 CXL 设备仿真的雏形可以搭一个带 CXL 内存设备的虚拟系统。启动参数大致长这样qemu-system-x86_64 -machine q35 -m 8G \ -device pxb-cxl,bus_nr0x80,idcxl.port0,buspcie.0 \ -device cxl-rp,idrp0,buscxl.port0,chassis0,slot2 \ -device cxl-type3,busrp0,memdevmem0,idcxl.mem0 \ -object memory-backend-file,idmem0,size4G,shareon参数细节随 QEMU 版本会变重要的是理解三件套先建 CXL 的根端口rp再在它下面挂一个 type3 内存设备最后用 memory-backend-file 把物理内存映射进来。启动之后在客户机里用lspci看到 CXL memory 设备然后用 NUMA 绑定去访问它。这套环境对验证“CXL 内存能不能被系统正常识别”非常有用但注意它不会替你验证 CXL 的一致性状态机那是 QEMU 目前还没有覆盖到的部分。做协议级学习QEMU 更适合理解“系统怎么看待 CXL 内存”不是“CXL 内部怎么维护一致”。6.4 UCIe 与 OpenCAPI生态验证UCIe 目前真正公开可跑的完整 RTL 很少最务实的做法是用厂商提供的 D2D PHY 模型做仿真或者用联盟发布的协议测试向量做适配层测试。如果你没有 license可以先拿系统级仿真器把不同协议流混跑验证多路复用和带宽分配的调度逻辑。OpenCAPI 则有 FPGA 平台的参考 IP如果你手头有支持它的 FPGA 板卡可以跑一个简单的加速器访问主机内存的 demo这对理解它的地址翻译流程很有帮助。7. 常见问题与排查心得7.1 通道对不齐、握手方向搞反这是所有手写互连 RTL 的第一大坑。TileLink 的 A/B 通道是主端发请求C/D/E 通道的方向各有不同一不留神就把握手信号的方向接反。CHI 也一样REQ 会带reqflitvalid/reqflitlast这些控制位忽略last会导致链路层把两条报文拼错。排查手段只有一个先看波形里的 valid/ready/credit 时序再用协议检查器断言不要直接去对数据内容。数据内容错了可能是业务逻辑通道时序错了是协议违例两者定位难度差一个量级。7.2 状态机画错漏了 snoop 触发路径我见过最常见的状态机错误是只画了“发起请求后等待响应”的路径漏掉了“被 snoop 打断”的路径。比如一个处于 UD 态的缓存行在等待自己发起的写回完成时突然收到 MakeInvalid如果你没有定义这个中间态的降级路径协议就死锁了。写状态机时要牢记一条铁律在你等待任何响应期间snoop 通道都可能来消息你必须在每个状态里回答“收到 snoop 怎么办”。如果回答不上来那就把状态再拆细拆到能在每个状态给出明确反应为止。7.3 目录与缓存状态不一致CHI 这类带目录的协议最隐蔽的 bug 是 Home 节点的目录视图和真实缓存状态慢慢跑偏。常见原因有三个Release 消息没带正确的返回状态、snoop filter 更新晚了一拍导致重复建链、事务 ID 复用导致旧响应覆盖新事务。建议在验证环境里加一个 Python 写的 golden model把所有事务按地址跟踪每次迁移后对比目录状态、缓存状态、数据所有权三者是否一致。这个 golden model 不用很复杂但要把“同一地址同一时刻只有一个 owner”这个不变式守住。7.4 哈希散列与 Home 映射算错CHI 这种靠地址位选 Home 的协议一旦 interleave 配置和地址切图不一致请求就会发到错误的 Home然后响应永远回不来。排查时先算清楚每个地址区间的块内偏移位宽再验证哈希掩码。写脚本批量生成地址集跑通仿真观察所有读请求确实都落到了预期 Home 上。这个脚本建议作为项目的一部分固化下来每次改地址映射都要跑一遍。7.5 被“PBR”两个名字带偏搜索资料时如果直接搜 “PBR 协议”大概率看到的是图像渲染的 PBR 材质模型和互连协议一点关系都没有。网络里搜 “PBR 路由”又是策略路由的老家。我的建议是搜协议文档时带上限定词比如 “CHI home node hash routing”“CXL fabric switching policy”或者直接翻规范原文的 “routing/routing scheme” 章节。跨术语的坑看起来很蠢但确实会浪费新手整整一个下午。7.6 仿真慢跑不出多节点事务协议验证最容易遇到的尴尬是 RTL 仿真太慢几百万拍跑不完一个真实工作负载。我的经验是分三步走第一步用 TLM 事务级模型验证算法和协议行为第二步用随机激励加协议检查器跑 RTL第三步才上典型工作负载做性能采样。随机激励要重点注入 backpressure也就是故意让 valid 和 ready 抽风把 credit 状态打到极端协议的死锁问题才暴露得出来。等这些跑顺了再上形式化验证去证明“不会出现两个 owner”这类不变式。做协议对比和验证这几年我最大的体会是别把协议当成一份要背的字典要把它当成一局棋。每一个字段、每一个状态、每一条 snoop 路径都是设计者在“延迟、带宽、面积、可验证性”之间反复权衡后落下的棋子。你不需要每个协议都精通到能手写 RTL但至少要能在自己的项目里快速说清楚这个协议把一致性仲裁放在哪、把路由决策放在哪、把错误恢复放在哪。最后分享一个我习惯的小动作拿到任何新互连协议规范先不要读正文直接翻它的 transaction 时序图和状态转移表把最简单的“读一个被别处修改过的数据”在纸上走一遍。这个动作看着笨但比任何仿真工具都能训练直觉。六个协议的细节还有很多可以展开的边角比如 CHI 的死锁避免通道依赖、TileLink 的 release data 与 grant data 重叠传输、CXL 的 HBI 延迟影响这些后面有机会再单独写。你先把手头最小的那个一致性事务跑通比什么都有用。 
长河君 · 2026/9/21 1:22:42 · 阅读 1.2k Scale-up互连协议深度对比：从CHI七态到PBR路由的比特与状态机解析
最近在梳理 Scale-up 互连协议的时候我把 CHI、TileLink、ACE、CXL、UCIe、OpenCAPI 这六个协议从比特到状态机逐层过了一遍。标题里那半句“从 CHI 七态到 PBR 路由”其实藏着两条主线一条看缓存一致性状态机到底把“谁拥有这行数据”画成了几个状态一条看报文在互连网络里转发时到底拿哪几个比特来做决策。这篇文章想把这两条线拆开揉碎适合三类人看正在做 SoC 互连或 chiplets 方向的设计验证工程师、被 Scale-up 生态各种缩写搞晕的软件栈同学、以及想把协议对比当成案例来学的 RISC-V/Chipyard 玩家。我会尽量用说人话的方式把每个协议的报文结构、状态集合、路由思路和坑位都摆出来。1. 为什么要较真到“比特和状态机”层面1.1 Scale-up 与 Scale-out 的本质差别先讲一个容易被忽略的前提。Scale-out 的思路是“加节点”每台机器自己管自己的缓存和内存节点之间靠消息通信跨节点一致性基本不做或者做得很粗。Scale-up 的思路是“加资源”把更多核、更多内存控制器、更多加速器塞进同一个一致性域里大家看到的是一份共享地址空间某一行缓存数据可能同时在好几个位置出现。打个比方Scale-out 就像公司开了一堆独立小办公室各写各的白板靠邮件同步结果Scale-up 是把所有人塞进一个大会议室共用一块白板那你就必须定一套规则谁拿笔、谁先擦、谁写了又划掉之后别人能不能看到旧内容。互连协议就是这套规则的文字版和电路版。规则里最难的三件事恰恰就是报文长什么样比特层面、数据在不同缓存里处于什么状态状态机层面、请求应该发给谁路由层面。不做协议级对比你永远只是在看概念 PPT。1.2 协议级对比的正确打开方式我在对比时习惯按三个维度切而不是拿“谁支持一致性强”“谁带宽高”这种话来回说比特维度通道怎么分、报文头有哪些字段、数据是 packet 还是 flit、事务 ID 怎么复用、有没有 CRC/ECC。状态机维度缓存行在客户端是什么状态管理器目录端是什么状态哪些事件触发状态迁移数据所有权怎么转移。路由维度一个请求从发起节点到目标节点的路径由什么决定是查地址表、走哈希散列还是交给策略路由决策。这三个维度是互相咬死的。状态机决定了报文的 opcode 种类路由决定了报文头里必须携带哪些 ID 和地址位比特宽度反过来又限制了状态机的并发能力。只看其中一个很容易得出错误结论。比如 CHI 看起来比 TileLink 复杂但如果只看包格式不看目录模型你就理解不了它为什么要搞那么多 snoop 类型。1.3 六个协议是怎么圈出来的我选的六个协议是拿“覆盖半径”来圈的TileLink 代表 RISC-V/Chipyard 生态最常见的 SoC 内互连协议ACE 代表 AXI 时代的补丁式相干扩展CHI 代表服务器级多节点 Mesh 互连的今天和未来CXL 代表机架级内存池化和 Scale-up 系统的新型互连UCIe 代表芯片到芯片die-to-die的物理与传输层标准OpenCAPI 则是加速器相干接口里曾经被寄予厚望的开放路线。CCIX、Gen-Z 我这次先不展开它们要么已经并进 CXL 路线要么生态声音已经弱了拿来凑数没意思。需要说明一点“开源协议”这四个字口径不一。TileLink 从头到尾都是开放的规范、RTL、验证工具都能拿到ACE、CHI 的规范 AMBA 系可以申请获取也有社区 RTL 实现CXL 和 UCIe 是联盟公开规范实现要自己搭OpenCAPI 当年也开源过 FPGA 参考 IP。所以这里讲的“开源”我按“规格公开、存在可学习实现”来理解而不是纯 License 意义上的开源。2. 比特层面报文、通道与链路帧结构2.1 先建立一个统一的分析框架拿几个协议直接对着看比特是容易劝退的因为每个协议对“一个消息”的叫法和封装都不一样。我建议先建立一个统一分层视角物理层PHY负责电信号和时钟链路层负责流控、报文边界和错误重传传输层如果存在负责把上层消息变成统一 flit 或 TLP协议/事务层负责表达“读”“写”“snoop”这些语义。在这个框架下六个协议的差异点就很清晰了协议主要通道/流传输单元流控方式典型错误保护TileLinkA/B/C/D/E 五通道beat一拍一数据源/目标端 valid-ready 握手无强制 CRC靠端到端检查ACEAXI 五通道 AC/CR/CDbeat握手 缓存一致性管理器无强制 CRCCHIREQ/RSP/SNP/DAT 四通道flit/packetCredit 信用计数CRC retryCXLcxl.io/cxl.cache/cxl.memflit/TLPcredit 重传FEC CRCUCIeD2D 逻辑通道/流flitcreditCRC retry crosstalk 规避OpenCAPI请求/响应/数据流TLP 风格报文creditCRC 重传这张表填完你会发现一个共性凡是走片外、跨 die 或者跨机箱的协议全部上了 CRC、retry 和 credit凡是只在片内 SoC 里转悠的协议可以用简单的 valid-ready。这不是偶然片外链路的信道噪声和延迟方差大得多你不能让协议层每拍都去做重传决策必须下沉到链路层统一处理。2.2 CHI 的四通道与 flitCHI 把消息按语义分成四个通道REQ请求、RSP响应、SNPsnoop 探测、DAT数据。每个通道有独立的 credit 流控也就是说跑 REQ 的链路粒度耗尽不会挡住 DAT 的数据传输。这么做是为了避免一致性协议里最常见的死锁一个节点在等数据的同时另一个节点需要 snoop 探测才能把数据让出来。通道分开了阻塞域也分开了。报文头里值得记住的字段有四个Opcode事务类型、TgtID目标节点 ID、SrcID源节点 ID、TxnID事务 ID。地址位宽在典型实现里按 48 位算TxnID 的宽度决定了你这个节点最多能同时挂多少个未完成事务——这直接决定带宽利用率。数据通道在常见配置下按 32B 或 64B flit 组织128 位和 256 位链路宽度都有。很多初学 CHI 的人会问“CHI 是包还是 flit”我的理解是协议层是 packet链路层再接一层 flit 封装加上 CRC 和 flow control 字段。你看 header 时把这两层分开就不会乱。2.3 TileLink 的 A~E 五个通道TileLink 用字母通道名这是它和 AXI/CHI 最明显的区别。A 通道是请求B 通道是探测probeC 通道是响应/释放releaseD 通道是数据响应E 通道是授权的最终确认grant ack。其中 E 通道是很多人刚上手时会漏掉的关键TileLink 的一致性协议要求授权必须闭环客户端收到 D 通道的 Grant 之后必须回一拍 E 的 GrantAck管理器收到 E 之后才认为这次转移真正结束。漏了 E协议检查器立刻报错。A 通道的报文头包含 opcode、param、size、source、address、mask 等字段。source 字段是客户端给自己的事务起的编号D 通道回数据时靠 sink 字段指回对应的请求方。这里的核心思想是“一个请求一个 source ID”并发事务数受 source 位宽限制。数据路径的 beat 宽度通常等于总线宽度比如 64 位或 128 位burst 由 size 字段指示这一点和 AXI 的 AxLEN 类似但语义更收敛。2.4 ACE 的相干扩展通道ACE 是在 AXI4 基础上加了三个相干通道AC相干请求地址、CR相干响应、CD相干数据。它的思路是“兼容旧世界”非一致性的 master 继续用 AW/W/B/AR/R一致性 master 额外走 AC/CR/CD由一致性管理器统一调度。ACE 的 snoop 类型很长一串ReadClean、ReadShared、ReadNotSharedDirty、ReadUnique、Clean、CleanShared、MakeInvalid 等等跟 CHI 的 SNP opcode 有大量对应关系。但从协议工程的角度看ACE 最大的问题在于它把一致性相关的状态机摊在各通道的 sideband 信号里而不是像 CHI 那样把“协议语义”和“传输机制”彻底拆开。结果就是信号多、组合逻辑复杂、验证矩阵爆炸。ARM 后来推 CHI 取代 ACE本质上就是嫌旧方案在可组合性和时序收敛上吃亏。如果你是新手ACE 可以作为学习 MESI 扩展到总线上的入门材料但新项目就别指望它扛大梁了。2.5 CXL 的三种协议封装CXL 一口气定义了三种协议cxl.io 走 PCIe 兼容路径负责设备枚举和传统 IOcxl.cache 管设备侧缓存一致性cxl.mem 管内存访问和内存池化。三种协议可以在同一条链路上按优先级动态复用这就在比特层面引入了“协议标签”的概念——同样是一个 flit你得先看它的协议类型才知道后面字段怎么解析。在 flit 封装上CXL 跟随 PCIe 规范的演进较早版本用类似 68B 的 flitCXL 3.0 时代进入更宽的 256B flit 体系把 FEC、CRC 和重传机制都糅进物理层。理解 CXL 的比特结构时我建议你先忘掉“一个请求一个包”的直觉把它想象成一条持续流动的流水线每个 flit 里可能混着 cxl.mem 的读请求、cxl.cache 的 snoop 响应和 cxl.io 的配置写。这也是为什么 CXL 的调度器必须支持严格优先级仲裁一个 flit 放错了等级延迟抖动就会变大进而影响整机性能。2.6 UCIe 与 OpenCAPI 的传输层差异UCIe 是所有协议里最好被误解的一个它本身不定义缓存一致性状态机也不定义“读”“写”这种事务语义它只解决一件事——让不同来源的 die 之间可靠、低延迟地搬运数据。UCIe 的比特层面由三块组成物理层bump、lane、时钟、die-to-die 适配层把上层协议映射成统一 flit负责 CRC、retry、串扰规避以及协议层映射支持 PCIe、CXL、流式协议。你在 UCIe flit 头里看到的信息主要是流标识stream ID、长度、CRC 这些运输字段而不是一致性状态。OpenCAPI 的报文结构更接近传统总线事务请求、响应、数据分开组织数据粒度常见为 64B 或 128B链路层同样有 credit 和 CRC。它的特色是把地址翻译作为核心能力设备端通过 MMIO 和地址映射访问主机内存相干性依赖主机内存模型和共享页表管理。这套设计在 IBM POWER 生态里有实际落地后来被 CXL 生态挤压现在更多作为历史案例和经验参考而不是新项目首选。2.7 比特层面的五个共性规律把六个协议摊开看绕来绕去其实跑不出五个规律。第一所有协议都有 request/response/data/snoop 四类语义只是通道组织方式不同第二所有协议都要求有一个事务 IDsource/tag/txnid用来把请求和响应配对这个字段的位宽就是并发上限第三所有协议都带了优先级/QoS 字段哪怕早期 TileLink 没有显式 QoS你也可以通过不同通道的仲裁权重来等效实现第四凡是跨 die 或跨设备链路的全部无条件上 CRC、retry、credit第五片内协议倾向轻量化握手片外协议倾向 flit 化流控。这五条记住后面看任何一个新协议都能快速定位它的设计坐标。3. 状态机层面从 CHI 七态说起3.1 CHI 的缓存状态到底怎么数先回答标题里最扎眼的“CHI 七态”。严格对着规范走CHI 的 RN-F全一致请求节点缓存主数据态是六个IInvalid、UCUnique Clean、UCEUnique Clean Empty、UDUnique Dirty、SCShared Clean、SDShared Dirty。那第七个态从哪来业内流传的说法有的把“Snoop Filter 里的 Present/Pass 状态”算进去有的把“UCE 从 UC 里单独拎出来之后 UD/US 过渡态”也加进去所以在聊天、面试和博客里会出现“七态”这个口径。我的建议是你自己心里先把六态背熟遇到“七态”这种说法时反问一句对方的计数口径是什么。通常对方会说“把 UCE 算一态再算上目录的独占过渡态”或者干脆是记成了 MESI 的七种权限组合。这其实正说明一个道理——协议状态数不是一个客观事实而是你站的角度。站在缓存端是一个数站在 Home 节点目录端是另一个数站在 L3 的 snoop filter 入口又是第三个数。把这三种视角分开比纠结“到底几个态”重要得多。六个主数据态的含义可以这样理解I无效没有任何数据。UC唯一干净只有当前节点有这份数据且和内存一致。UCE唯一干净但内容无效数据是空的这个态专门用来支持“我马上要全写别给我传旧数据”省掉一次数据搬运。UD唯一脏当前节点独占修改内存是旧值未来需要回写。SC共享干净多个节点可持有内存是最新值。SD共享脏数据被修改过但还允许被其他节点共享读内存是旧值必须由某个持有者负责提供数据。SD 态是 CHI 里最有意思的设计。它本质上是 MESI 里 Owner 思路的变体脏数据不一定只有一个人持有只要大家约定“谁能拿这行数据当权威源”就能在保留共享读性能的同时不急着写回内存。一次典型迁移大概是这样的节点 A 发起 ReadUnique 读一份它打算改的数据Home 节点查到这行数据在节点 B 手里是 UD于是给 B 发 snoop 要求让出。B 的数据经 Home 转给 AB 的状态降成 IA 拿到数据后落在 UD 或 UCE。整个过程里Home 扮演裁判角色维护目录视图真正搬数据的动作可能发生在 B 和 A 之间也可能绕到 Home 中转这由互连拓扑决定。理解关键就一句话状态下沉在节点仲裁权上缴给 Home。3.2 TileLink 的 I/C/E/M 与目录元数据TileLink 的状态模型比 CHI 难背一点因为它把“权限级别”和“脏位”分开了。数据态主要有四个IInvalid、CClean/Shared、EExclusive、MModified同时带一个 Dirty 元数据位。所以你看 TileLink 的协议文档时会发现它不怎么说“SD 态”而是说“共享且脏”的属性组合。TileLink 的一致性管理器侧会维护每行数据的 Valid、Dirty、Permission 信息通过 A/B/C/D/E 五通道的数据流来同步这些信息。TileLink 请求用 AcquireBlock/AcquirePerm 来获得权限带一个 grow 参数表示想“成长”到什么级别管理器用 Grant/GrantData 响应客户端用 GrantAckE 通道确认管理器主动发 Probe 降级客户端权限时带一个 cap 参数。这套“成长/限制”的表达方式比 CHI 的 opcode 列表抽象了一层代价是初学者需要先理解“权限等级”和“数据结构”是两个维度。我自己学的时候画了个小表请求方想要什么权限、管理器能给什么权限、数据是脏是干净三者一组合状态迁移就全出来了。TileLink 状态机相对好理解的根本原因是它把目录集中化了。一个地址区间只有一个管理器所有一致性决策都收口到这一处客户端之间的交互全部要过管理器。这个设计牺牲了一点并行度换来了可组合性和可验证性这也是为什么 Chipyard 生态能靠 TileLink 轻松组合出几十个核的 SoC。3.3 ACE 与 CXL 的 MESI 变体ACE 的状态模型跟 MESI 家族非常接近常见描述是 I/C/E/M 加脏位本质上是一致性管理器加 snoop 总线。它的转移路径主要靠 AC 通道的相干读/写请求和 CR 通道的响应来驱动。由于 ACE 是给 AXI 做扩展所以它没有像 CHI 那样专门设计 UCE 这种“空数据独占”态总线读写时数据搬运路径比较直白但这也意味着某些场景下会有多余的数据传输。CXL.cache 的缓存状态也是 MESI 变体设备侧缓存行通常有 Modified、Shared、Exclusive、Invalid 几种状态通过 cxl.cache 的请求和 snoop 消息来协调。CXL.mem 侧又是另一套逻辑主机的内存控制器通过 HBIback-invalidate把失效消息推给缓存的设备处理的是“设备缓了主机的内存行”这个场景。如果你把 CXL.cache 和 CXL.mem 分别看会发现它们其实服务的是两种不同的 Scale-up 目标cxl.cache 是让设备加速器安全地用主机缓存cxl.mem 是让内存从主机里被拉出来池化。两种场景的状态机复杂度根本不在一个量级。3.4 状态机对比总表协议客户端状态集目录/管理器状态数据所有权特点主要触发事件CHII/UC/UCE/UD/SC/SDHome 节点目录Present/Pass/转移中脏数据可共享SD按需回写REQ/SNP/RSP/DAT 四通道事务TileLinkI/C/E/M Dirty管理器集中维护 ValidDirtyPermission权限成长/降级显式可控Acquire/Release/Probe/GrantACEI/C/E/M 加脏位一致性管理器传统 MESI 扩展AC/CR/CD 相干事务CXL.cacheM/S/E/I主机侧 HBI 管理设备缓存挂靠主机内存cxl.cache 请求/失效CXL.mem无设备缓存态主机内存控制器内存池化、托管读写/回写/失效UCIe无透传无不感知缓存在 D2D 流上运载上层协议OpenCAPI依赖主机内存模型MMU/地址翻译设备地址映射相干请求经地址翻译路由这张表的核心结论是状态机复杂度不完全等于协议成熟度而是和“你打算让缓存一致性域覆盖多大物理范围”强相关。片内单 die 做四态足够片内多 die 上七态也不一定够跨设备做内存池化时真正难的反而变成失效广播和地址路由这正好把我们推向下一章。4. 路由这件小事PBR 与转发策略4.1 先给 PBR 正名“PBR”这三个字母在不同圈子撞衫撞得厉害。图形学圈子里PBR 是 physically based rendering材质渲染那一套网络圈子里PBR 是 policy-based routing策略路由。在 Scale-up 互连协议这个上下文里我借用的正是网络圈的“策略路由”思想转发决策的查表键不再只是目的地址而是“地址 协议类型 事务类型 QoS/优先级 节点编号”联合起来的一张表。为什么需要联合键因为在一个大系统里同样一个地址区间的读请求来自普通 CPU 核和来自实时加速器的请求对延迟和带宽的要求完全不同同一个节点发出的写请求走一致性写还是非一致性写去往的 Home 节点可能不一样同一条链路上的报文如果全都挤同一个虚拟通道一旦高优先级流量被低优先级报文卡住整个系统的延迟尾巴立刻变恶。PBR 的核心就是把调度和转发的策略显式化。CHI、CXL、UCIe 在底层都做了一定程度的 PBR只是各自叫法和实现角度不一样。4.2 CHI 的 Home 节点选择与 snoop 路由CHI 的 Mesh 里有很多 Home 节点HN-F一个请求到了之后必须决定找谁承办。这不是查一张大表而是用地址位直接算。常见做法是把地址的低位去掉块内偏移后按 interleave 切分再配合 XOR 散列摊开保证相邻地址落到不同 Home避免热点。我把一个简化的计算写了出来def home_index(addr, block_offset_bits6, num_hns16): a addr block_offset_bits low a (num_hns - 1) high (a 4) (num_hns - 1) return (low ^ high) % num_hns这套“按地址哈希选 Home”的机制从网络路由的角度看就是一种静态 PBR查表键是地址位策略是散列函数路由目标是 Home 节点。优点是不需要维护转发表规模扩展到几十个节点也能保持低延迟缺点是地址布局要规划好两个 Hash 位选得不好某些地址区间就挤到同一个 Home 上。snoop 路由则是另一条线。Home 节点拿到数据行的目录信息后决定给哪些持有者发 SNP。CHI 里还有一种点到点的“snoop 转发”模式数据可以由持有者直接回给请求方经不经过 Home 都行。这样就把“目录仲裁路径”和“数据搬运路径”解耦是 CHI 能支撑高并发互连的关键。在网格拓扑里报文的 TgtID 会被路由器解析成二维方向的跳数这也是 PBR 的另一个维度地址哈希只是选端点Mesh 内部走 X-Y 路由还是协商式路由又独立影响延迟和收敛性。4.3 TileLink 的“单管理器”路由模型TileLink 的路由模型在所有协议里最简单但简单不等于粗糙。它的每个地址区间只有一个管理器因此请求方的路由动作本质上就是一次地址区间查表这个地址归哪个管理器管就把 A 通道请求发给谁。Chipyard/Diplomacy 里你可以把系统地址空间切成若干个区间每个区间挂一个或多个占位管理器之间的互不重叠由工具强制检查。这种“单管理器”模型的好处是做验证的人在状态上不会分裂同一时间对同一地址的一致性决策只有一个权威不存在两个 Home 抢同一份目录视图的情况。坏处也很直观——管理器成为热点所有跨节点的 cache line 操作都要挤向同一个点。所以 TileLink 在实际大型 Scale-up 系统里需要靠地址切片把不同地址区间分布到多个切片上来做并行本质上是把“哈希路由”迁移到了系统设计阶段而不是运行时由协议自动完成。如果你在做比赛原型或学术 SoCTileLink 的简单路由让你能快速跑通如果你要冲百万行级缓存一致性服务的场景CHI 的运行时哈希会更合适。规模决定路由策略的复杂度这是选型时的一条铁律。4.4 CXL 的 Fabric 与点对点转发CXL 3.0 之前的模型是主机为中心的星型拓扑路由压力集中在一台主机的 root port 上。CXL 3.0 引入 Fabric 和交换以后路由就从“你找我还是我发给你”变成“整个网络里的 switch 都知道该往哪送”。CXL 的报文头里需要带足够的标识让 switch 做决策目标是某个内存设备某个加速器还是回到某个主机这跟以太网交换机查 MAC 表思路相似只不过查表键里混进了内存地址和协议类型。cxl.cache 的请求还带 Cache ID 和 Cache Tag路由时要把这些信息也一并考虑switch 才能把失效消息准确投给那个缓存了对应行的设备。这个层面我理解就是典型的 PBR 落地一个 flit 到达 switchswitch 同时看地址位、协议位、请求类型位然后决定转发队列方向和优先级。CXL 的交换结构设计是否高效直接决定了内存池化系统能不能在不加网络层的情况下把几十个主机连成一套可共享内存的 Scale-up 系统。4.5 UCIe 的 die-to-die 流路由与 OpenCAPI 的地址路由UCIe 的路由粒度和前面几个协议不太一样它不关心单个内存地址归谁它只负责把不同的“流”复用同一条 D2D 物理链路。UCIe 逻辑层支持多路协议流同时存在每个流带一个流标识适配层按流标识做多路复用和解复用。路由决策发生在“谁来抢占当前链路”这个层面属于链路级策略路由。你可以用 UCIe 同时运载一个 CXL 流和两个 PCIe 流但带宽怎么分、哪个流优先级更高是适配层策略决定的。OpenCAPI 则回到地址路由的老路。它的事务层把地址翻译成目标设备的内存端口然后走请求/响应/数据三条独立通路。它不像 CHI 那样跑 Mesh 多跳更多是点对点或小规模星型。OpenCAPI 对“谁是地址翻译者”有很明确的划分主机侧负责把物理地址翻译成设备可识别的地址设备侧则通过 MMIO 和通道寄存器配好映射。这个设计在加速器场景很好用因为加速器不关心整机内存拓扑只要知道自己能访问哪一段就行。4.6 PBR 的关键设计维度把几个协议的转发逻辑抽象出来你会发现真正要决策的问题其实只有五个查表键包含哪些维度纯地址TileLink 区间查表、地址加事务类型CHI 的 opcode 影响 snoop 路径、地址加协议类型加 QoSCXL 交换。决策粒度按连续地址区间、按单个缓存行、还是按 flit 流。虚拟通道切分有多少个 VC分别给哪些流量用这是死锁避免的主要手段。保序模型同地址的请求是否严格保序跨地址是否允许乱序。流控联动credit 是发起端记账还是接收端授权credit 状态本身也是路由能否继续的前提。如果把这五个维度放回到六个协议里一个清晰的判断就出来了协议进化的大方向是把路由信息从“只有地址”逐步升级为“地址 事务语义 服务质量”也就是 PBR 的思路在硬件互连里越来越普及。不要再觉得策略路由只是网络路由器的专属名词了。5. 横向对比六个协议六种哲学5.1 一张表看透六个协议协议定位状态模型路由模型报文单元适用规模生态代表TileLinkRISC-V SoC 内一致互连I/C/E/M Dirty单管理器地址区间查表beat片内多核Rocket Chip、ChipyardACEAXI 时代的相干扩展MESI 变体集中管理器 snoop 总线beat中低端移动 SoC已由 CHI 取代CHI服务器级一致互连六态 过渡态哈希选 Home Mesh 转发packet/flit多 die/几十节点Neoverse 生态CXL机架级内存与设备互连cxl.cache MESI 变体Fabric switch 查表flit/TLP多主机内存池化CXL 联盟生态UCIedie-to-die 物理传输无状态透传流标识复用flit单个封装内多 die还是制定中的硅前生态OpenCAPI加速器相干接口依赖主机 MMU地址映射路由TLP 风格点对点加速器POWER 生态这张表有一个隐藏的阅读方法从右上往左下看你会发现协议的责任边界在往外扩。TileLink 只管片内CHI 管封装内多 dieCXL 管跨机箱的多主机内存池UCIe 把自己定位成最底层的运输工。把边界画清楚很多争论其实就散了——比如“TileLink 能不能替代 CHI”这种问题本质是问“片内协议能不能干片外调度”答案当然是不合适链路可靠性工程就不是人家要解决的题。5.2 选型建议如果你的项目是 RISC-V 内核、Chipyard 流程、可综合的 RTL 原型TileLink 是第一选择。它和 Diplomacy 参数系统深度绑定加核、加外设、加一致性域的配置成本远低于其他协议。如果你的目标是 ARM 服务器级性能或者需要一个已经验证过的多节点一致互连架构CHI 是事实标准。你需要准备的是协议验证能力光有一个 RTL 网表没意义。如果你做的是内存池化、异构内存、CXL switch 这类系统级产品CXL 3.0 是你绕不开的协议。它的比特层面和状态机还在快速演进跟联盟规范要保持同步。如果你做的是先进封装里的 chipletsUCIe 作为 D2D 链路层值得重点投入但它的上层协议映射得自己定不能指望 UCIe 替你解决一致性。OpenCAPI 面向的是特定历史节点上的加速器场景现在新项目里它基本不是首选除非你要兼容存量 POWER 生态或做协议考古。5.3 开源源码与学习材料怎么选TileLink 的直接学习资源是 Chipyard 和 Diplomacy 生成出来的 RTL你可以跑 verilator 仿真搭配 TileLink 协议检查器看违规。CHI 的学习资源里有公开的规范文档和大学公开的简化 RTL 实现想深入的话先把链路层 credit 逻辑吃透再去看协议层状态机。CXL 的公开实现到目前为止主要集中在 Linux 内核的 CXL 驱动栈和 QEMU 的 CXL 仿真上硅前协议细节要看联盟发布的 spec。UCIe 的 RTL 参考实现目前还不是完全开放更多靠链路工作组的文档和测试芯片来学习。OpenCAPI 当年的 FPGA 参考 IP 和文档现在还挂在网上做协议演进研究的人可以去翻。6. 实操验证怎么把一个协议跑起来6.1 TileLinkChipyard 里跑通一致性事务我的建议是从一个最小的双核加共享 L2 的配置开始。流程大致是拉下 Chipyard 仓库切到你熟悉的分支用subsystem配置定义两个 Rocket 核和一个 Banked L2跑make verilog生成 RTL再用 verilator 仿真跑一个简单的裸机多核程序。验证时不要只关心结果对不对重点去观察 A/B/C/D/E 通道的信号波形。你会看到某个核发起 AcquireBlock 之后管理器向持有者发 Probe然后数据通过 D 通道返回最后 E 通道盖棺定论。TileLink 生态里我最推荐的是它的协议检查器很多协议违例不是功能错乱而是时序超时。把TileLinkMonitor打开之后它会在每个通道的 beat 上做协议断言检查。比如你写了一个错误的占位让两个 master 同时认领同一地址区间检查器会在仿真一开始就红。这种错误在手写 RTL 时极难发现检查器让你在几分钟内定位到 bug这是协议验证的最佳实践。6.2 CHI用参考实现和协议检查器CHI 的完整 RTL 在大厂手里公开环境里能跑的主要是两种路径一是用 gem5 里基于 CHI 的 coherence protocol 模型做架构级仿真二是找大学开源的 CHI 子集 RTL 做学习。用 gem5 时要注意CHI 模型对系统配置的约束比 MESI 强节点数量、Home 节点映射、地址交错位都要先配好不然仿真会在一致性消息上卡住。我实际跑过的经验是先不要急着上多节点 Mesh先用一个 RN-F 加一个 HN-F 加一个 SN-F 的最小闭环验证一次 ReadUnique 的完整消息序列。每看到一条 REQ、一条 SNP、一条 RSP、一条 DAT 都记录下来和规范里的 message sequence 图对比。把最小闭环画熟再扩展到多个节点、多 Home 哈希你才能真正体会到 CHI 的互连不是“一根总线”而是一张需要转发策略的网络。6.3 CXLQEMU 仿真实验近几年 QEMU 已经支持 CXL 设备仿真的雏形可以搭一个带 CXL 内存设备的虚拟系统。启动参数大致长这样qemu-system-x86_64 -machine q35 -m 8G \ -device pxb-cxl,bus_nr0x80,idcxl.port0,buspcie.0 \ -device cxl-rp,idrp0,buscxl.port0,chassis0,slot2 \ -device cxl-type3,busrp0,memdevmem0,idcxl.mem0 \ -object memory-backend-file,idmem0,size4G,shareon参数细节随 QEMU 版本会变重要的是理解三件套先建 CXL 的根端口rp再在它下面挂一个 type3 内存设备最后用 memory-backend-file 把物理内存映射进来。启动之后在客户机里用lspci看到 CXL memory 设备然后用 NUMA 绑定去访问它。这套环境对验证“CXL 内存能不能被系统正常识别”非常有用但注意它不会替你验证 CXL 的一致性状态机那是 QEMU 目前还没有覆盖到的部分。做协议级学习QEMU 更适合理解“系统怎么看待 CXL 内存”不是“CXL 内部怎么维护一致”。6.4 UCIe 与 OpenCAPI生态验证UCIe 目前真正公开可跑的完整 RTL 很少最务实的做法是用厂商提供的 D2D PHY 模型做仿真或者用联盟发布的协议测试向量做适配层测试。如果你没有 license可以先拿系统级仿真器把不同协议流混跑验证多路复用和带宽分配的调度逻辑。OpenCAPI 则有 FPGA 平台的参考 IP如果你手头有支持它的 FPGA 板卡可以跑一个简单的加速器访问主机内存的 demo这对理解它的地址翻译流程很有帮助。7. 常见问题与排查心得7.1 通道对不齐、握手方向搞反这是所有手写互连 RTL 的第一大坑。TileLink 的 A/B 通道是主端发请求C/D/E 通道的方向各有不同一不留神就把握手信号的方向接反。CHI 也一样REQ 会带reqflitvalid/reqflitlast这些控制位忽略last会导致链路层把两条报文拼错。排查手段只有一个先看波形里的 valid/ready/credit 时序再用协议检查器断言不要直接去对数据内容。数据内容错了可能是业务逻辑通道时序错了是协议违例两者定位难度差一个量级。7.2 状态机画错漏了 snoop 触发路径我见过最常见的状态机错误是只画了“发起请求后等待响应”的路径漏掉了“被 snoop 打断”的路径。比如一个处于 UD 态的缓存行在等待自己发起的写回完成时突然收到 MakeInvalid如果你没有定义这个中间态的降级路径协议就死锁了。写状态机时要牢记一条铁律在你等待任何响应期间snoop 通道都可能来消息你必须在每个状态里回答“收到 snoop 怎么办”。如果回答不上来那就把状态再拆细拆到能在每个状态给出明确反应为止。7.3 目录与缓存状态不一致CHI 这类带目录的协议最隐蔽的 bug 是 Home 节点的目录视图和真实缓存状态慢慢跑偏。常见原因有三个Release 消息没带正确的返回状态、snoop filter 更新晚了一拍导致重复建链、事务 ID 复用导致旧响应覆盖新事务。建议在验证环境里加一个 Python 写的 golden model把所有事务按地址跟踪每次迁移后对比目录状态、缓存状态、数据所有权三者是否一致。这个 golden model 不用很复杂但要把“同一地址同一时刻只有一个 owner”这个不变式守住。7.4 哈希散列与 Home 映射算错CHI 这种靠地址位选 Home 的协议一旦 interleave 配置和地址切图不一致请求就会发到错误的 Home然后响应永远回不来。排查时先算清楚每个地址区间的块内偏移位宽再验证哈希掩码。写脚本批量生成地址集跑通仿真观察所有读请求确实都落到了预期 Home 上。这个脚本建议作为项目的一部分固化下来每次改地址映射都要跑一遍。7.5 被“PBR”两个名字带偏搜索资料时如果直接搜 “PBR 协议”大概率看到的是图像渲染的 PBR 材质模型和互连协议一点关系都没有。网络里搜 “PBR 路由”又是策略路由的老家。我的建议是搜协议文档时带上限定词比如 “CHI home node hash routing”“CXL fabric switching policy”或者直接翻规范原文的 “routing/routing scheme” 章节。跨术语的坑看起来很蠢但确实会浪费新手整整一个下午。7.6 仿真慢跑不出多节点事务协议验证最容易遇到的尴尬是 RTL 仿真太慢几百万拍跑不完一个真实工作负载。我的经验是分三步走第一步用 TLM 事务级模型验证算法和协议行为第二步用随机激励加协议检查器跑 RTL第三步才上典型工作负载做性能采样。随机激励要重点注入 backpressure也就是故意让 valid 和 ready 抽风把 credit 状态打到极端协议的死锁问题才暴露得出来。等这些跑顺了再上形式化验证去证明“不会出现两个 owner”这类不变式。做协议对比和验证这几年我最大的体会是别把协议当成一份要背的字典要把它当成一局棋。每一个字段、每一个状态、每一条 snoop 路径都是设计者在“延迟、带宽、面积、可验证性”之间反复权衡后落下的棋子。你不需要每个协议都精通到能手写 RTL但至少要能在自己的项目里快速说清楚这个协议把一致性仲裁放在哪、把路由决策放在哪、把错误恢复放在哪。最后分享一个我习惯的小动作拿到任何新互连协议规范先不要读正文直接翻它的 transaction 时序图和状态转移表把最简单的“读一个被别处修改过的数据”在纸上走一遍。这个动作看着笨但比任何仿真工具都能训练直觉。六个协议的细节还有很多可以展开的边角比如 CHI 的死锁避免通道依赖、TileLink 的 release data 与 grant data 重叠传输、CXL 的 HBI 延迟影响这些后面有机会再单独写。你先把手头最小的那个一致性事务跑通比什么都有用。