企业官网建设流程全解析

聊到 Scale-up 互连，很多人的第一反应是“这不就是数据中心里把机器插在一起吗”。其实差别很大：Scale-out 是加机器，靠网卡和交换机堆吞吐；Scale-up 是换“大发动机”，让 CPU、内存、加速器、甚至多颗 CPU 之间像同一台机器一样协同，共享同一个内存视图。而要做到这一点，背后的互连协议必须在缓存状态机、消息字段、路由决策这些极底层的地方斤斤计较。

这篇文章我不打算做那种“六个协议各讲五分钟”的科普，而是把它们真正放到比特和状态机层面来回拆。我们以 ARM CHI 的七态缓存状态为锚点，一直拆到 PBR（物理地址路由）如何决定一个请求去哪个节点，再把 CHI、TileLink、OmniXtend、CXL.cache、OpenCAPI、CCIX 这六个开放协议放到同一张桌子上做横向对比。适合谁看？做处理器/加速器架构的、写 RTL 做验证的、搞系统软件和模拟器的，还有想折腾开源互连协议的学生，这篇应该都能挖到点东西。

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

1.1 从 Scale-out 到 Scale-up：为什么一致性成了分水岭

传统互联网应用扩容的思路很简单：无状态服务前面挂负载均衡，后面挂一堆机器，请求随便打到哪台都行。这种模式对机器之间的通信延迟容忍度很高，因为业务数据都去数据库或缓存里拿，机器之间不需要“互相看对方的缓存”。

但到了 AI 训练、大数据分析、高性能计算这类场景，计算节点之间要频繁共享数据结构、同步中间结果，如果每次共享都要落到远端内存，性能就彻底废了。更好的做法是让多个请求者通过互连协议感知彼此对同一块内存的缓存状态：你知道这个数据有人在用、有没有被改过、改完要不要通知别人。这套机制就是缓存一致性协议，也是 Scale-up 互连和普通网络互连最本质的分水岭。

普通以太网不管你在哪个核上缓存了什么，而一致性互连协议要在硬件层面维护一个分布式状态机：每个缓存行此刻处于什么状态，我这个核可不可以直接写，还是必须先问一下其他人。协议干得好不好，直接决定多核、多芯片、多节点的扩展效率。

1.2 协议栈分层：不能只看“缓存状态”那一层

理解协议之前，先有个分层概念。一个完整的互连协议栈，大致是物理层、链路层、事务/协议层、以及路由与系统地址映射。物理层管电信号和编码，链路层管流控和可靠传输，而大家天天讨论的 MESI、MOESI、CHI 七态，都在事务/协议层；PBR 路由则在协议层和系统映射之间。

很多初学者一上来就背缓存状态，结果真正看协议报文时懵了：为什么一个读请求要拆成好几个 FLIT？为什么还要单独的 Data 通道？因为状态机只是“规定行状态怎么变”，实际通信要靠报文里的字段和路由信息来表达。所谓“比特和状态机层面”，就是这个意思：状态机决定行为规则，比特字段决定消息怎么组织、怎么寻址、怎么被路由到正确的节点。

拿 CHI 举例，一个典型的读请求要经过 Req、Data、Rsp 至少三个阶段，每个阶段都是独立 FLIT，里面除了地址和操作码，还带着 NodeID、属性位、事务 ID 等一堆字段。对比协议，首先要对比的就是这些消息骨架和状态定义。

1.3 为什么是这六个协议：选取标准先讲清楚

严格说，CHI、CXL、OpenCAPI、CCIX 这些规范是开放标准，但 License 未必完全“开源”；真正的开源协议代表是 TileLink 和 OmniXtend。我把它们放进同一张桌子的理由是：它们都拥有公开的规范或开源参考实现，而且在 Scale-up 互连链条上各有典型位置，对比起来有区分度。

• ARM CHI：现代自研 SoC 和高性能互连的事实基线，状态机和消息设计最完整。
• TileLink：RISC-V 生态活跃的开源互连协议，Rocket Chip、OpenPiton 都在用。
• OmniXtend：把缓存一致性搬到以太网上，研究分布式一致性的好样本。
• CXL.cache：当前数据中心加速器一致性的主流方向，和 PCIe 物理层深度绑定。
• OpenCAPI：IBM 推动的开放加速器互连，一致性语义和 OMI 接口比较有特点。
• CCIX：虽然已被 CXL 吸收，但它和 CXL 同源于 PCIe 环境下的一致性扩展，历史对比价值高。

后面几节里，我会把每个协议在状态机和消息路由上的核心思路拉出来，逐个解剖。

2. 缓存状态机大乱斗：从 MESI 到 CHI 七态，再到各家“方言”

2.1 先把这个基础补明白：MESI 和 MOESI 在干什么

要理解 CHI 七态，先看回经典 MESI。它给每个缓存行定义了四个状态：Modified（我改过，别人没有）、Exclusive（只有我有，但没改）、Shared（大家都有，且干净）、Invalid（无效）。核心思想是，写入前如果状态不是 Modified/Exclusive，要先去获得唯一所有权。

MOESI 在 MESI 基础上加了一个 Owned 状态：某个缓存行被多个节点共享，但其中有一个节点拥有最新数据并负责写回。这么一加，读操作有时不需要访问内存，降低延迟。CXL.cache 等协议在语义上基本是 MOESI 的变体。

但真实协议不能只有这么几个稳定状态。因为现代 CPU 和加速器会做部分写、空行分配、压测时的流水线重放，需要更细的状态来准确描述“我这个缓存行有没有有效数据”“数据是不是只覆盖了一部分”“我能不能在写回前先把数据借给别人”。于是我们看到 CHI 把状态拆得更细。

2.2 核心解剖：CHI 七态到底比 MESI 多了哪些东西

CHI（Coherent Hub Interface）是 ARM 针对多核、多 chiplet、以及跨芯片一致性场景设计的互连协议。它的缓存行状态不止四个，最常被引用的七态是：

• I：Invalid，无效。
• UC：Unique Clean，唯一且干净，没有其他副本。
• UD：Unique Dirty，唯一且脏，数据需要最终写回。
• UDP：Unique Dirty Partial，唯一、脏，但只覆盖行内部分字节。
• UCE：Unique Clean Empty，唯一且干净，但数据内容无效或未初始化。
• SC：Shared Clean，多个副本共享且干净。
• SD：Shared Dirty，多个副本共享，但本节点拥有最新数据。

这七个状态的含义，比 MESI 更容易理解的一点是它把“部分有效”和“空行”显式拆出来。UDP 在乱序执行和向量访存时非常有用，比如一个 CPU 对一个 64B 缓存行只写了 8B，其他字节还是旧数据，这时缓存行就是 UDP，而不是完整的 UD。UCE 则更多出现在分配缓存行但还没真正填充数据的场景。

状态之间怎么迁移？举个例子，如果目标缓存行处于 SC，而一个 CPU 想执行写操作，协议通常会发起一次向其他共享者的窥探（Snoop），把 SC 状态变成 UC/UD，再允许写入；如果是 UDP，写满全部字节后可以升级为 UD。这种迁移不是一次完成的，中间会穿插 Req、Snp、Data、Rsp 多个事务，所以协议终端里要做一个非常严谨的状态机来记录“当前到哪一步了”。

2.3 TileLink 的一致性状态：一套不那么“命名你认识”的协议

TileLink 是 RISC-V 社区里最常见的开源互连协议，常见有 TL-UL、TL-UH 和 TL-C 三个层次。TL-C 引入了完整的缓存一致性支持，但它的状态名不是 MESI 那套，而是 None、Branch、Trunk、Dirty 之类，第一次接触会有点别扭。

• None：缓存行无效。
• Branch：可能有多个节点有副本，数据干净，类似 MESI 的 Shared。
• Trunk：当前节点持有唯一所有权，但数据干净，类似 Exclusive 或 Unique Clean。
• Dirty：当前节点持有唯一所有权且数据被修改，类似 Modified/Unique Dirty。

命名虽然不同，状态转移的语义和 MESI/MOESI 家族是相通的。TL-C 最有特色的是它采用五个通道 A/B/C/D/E 来完成一致性交互：发起者走 A 通道发送 Acquire，接收者用 D 通道返回 Grant，中间的探测用 B 通道，数据释放走 C 通道，最后 E 通道结束整个事务。这个通道结构非常干净，很适合在 open-source RTL 里做实现和调试。

2.4 CXL.cache、OpenCAPI、CCIX 的状态设计：MESI 的现代化变体

CXL 是目前数据中心加速器互连里绕不开的协议。它的 CXL.cache 子协议专门给带缓存设备使用，语义上很像 MOESI 的紧凑版本，但针对 PCIe 物理层做了很多裁剪：由于 PCIe 本身是包交换结构，CXL.cache 要把一致性请求封装成 PCIe TLP/FLIT，延迟相对片内互连更高，所以状态机会倾向于减少不必要的探测流量。

OpenCAPI 的一致性模型提供了与 CPU 缓存一致的内存访问，它更适合追求极致内存语义的加速器场景。从状态机角度看，OpenCAPI 同样实现了 MESI 变体，但它的接口抽象更偏向“内存语义”，让加速器像访问本地内存一样访问宿主内存，底层状态管理由协议的 Home Agent 和 Cache Agent 协同完成。

CCIX 和 CXL 很像，也基于 PCIe 物理层。它定义了缓存线上报、检测、写回等机制。历史意义在于验证了“在标准 PCIe 上做缓存一致性”这条路走得通，也正因为物理层先天延迟较高，最终数据中心主流选择了用更强的 CXL 来承载。但从协议学习角度看，CCIX 的状态迁移和消息字段仍值得和 CXL.cache 对照着看，能发现很多“同一个目标下的不同设计取舍”。

2.5 状态机实现风格：一段式、两段式、三段式如何影响协议落地

聊到状态机，我注意到很多工程师搜索“一段式、两段式、三段式状态机”，这话题在 Verilog/SystemVerilog 世界里确实很重要。协议状态机实现里，尤其能体现三段式的价值。

• 一段式：所有状态转移和输出写在一个 always 块里，代码少，但调试困难，组合逻辑和时序逻辑混在一起，协议状态一旦复杂就是灾难。
• 两段式：一段时序逻辑负责状态寄存器更新，一段组合逻辑负责状态转移条件和输出，逻辑清晰一些，但因为输出仍依赖当前状态和输入，容易出毛刺。
• 三段式：状态寄存器更新、次态计算、输出逻辑分别用三个块实现，输出可以用寄存器打一拍，完全消除毛刺，代价是多一拍延迟。

缓存一致性状态机对时序非常敏感，比如 CHI 里 D 通道返回 Grant 和 Data 可能花色不同，如果用一段式写完整个迁移逻辑，后续加一个部分命中、加一个 Partial 状态，可读性会迅速崩溃。我个人的习惯是：核心协议状态机一律用三段式，把次态计算函数和输出函数拆成独立逻辑，保证 RTL 仿真时能快速定位是状态迁移错还是输出驱动错。

2.6 六协议状态与实现复杂度对比

从这张表能看出，CHI 的状态设计最细、实现复杂度最高；TileLink 是开源世界里平衡得比较好的方案；CXL.cache 则在商业和数据中心场景占据主流。

3. 消息格式与 PBR 路由：比特层面真相大白

3.1 CHI 的消息要拆开看：Req、Data、Rsp、Snp 背后都是些什么

协议不能只有状态机，还要能“开口说话”。CHI 有几种核心消息类型：请求类（Req）、响应类（Rsp）、数据类（Data）、探测类（Snp）。每个消息都对应一个 Channel，在物理链路上以 FLIT 为单位传输。

一个 ReadUnique 请求的流程能很好展示比特和状态机如何联动：

• 请求端发 Req：包含事务 ID、物理地址、操作码（ReadUnique）、属性（是否允许共享、是否部分访问等）。
• Home Node 收到 Req 后，查其记录，如果需要破坏其他节点的副本状态，就向相关节点发 Snp 消息。
• 被探测节点收到 Snp 后，响应自己的缓存状态和数据情况，该写回就写回。
• 最终 Home Node 把数据返回给请求端，同时更新自己的目录状态。

这里面任何一个字段出错，都可能造成状态不一致：地址位段错了，路由去不到该去的节点；事务 ID 混乱，响应就对不上请求；操作码写错，接收方可能做出完全不同的状态迁移。所以在 RTL 验证时，除了要对着状态机做定向用例，还要做大量随机事务注入，专门抓字段级错误。

3.2 TileLink 的通道字段：五个通道怎么配合完成一次缓存交互

TL-C 的五通道模型，在比特层面更“教学友好”。A 通道传 Acquire 请求，主要字段有地址、操作码、源/目标标识等；D 通道传 Grant 数据，把请求结果和数据一起返回；B 通道用于探测，C 通道用于释放，E 通道用于结束。

通道之间的握手信号采用 valid/ready 模型，不像 CHI 那样复杂的大通道需求，但在多节点互连时也会遇到死锁问题。如果需要做一致性的多核 SoC，基于 TileLink 的 Rocket Chip 是一个极佳学习样板：你能直接在 RTL 里跟踪一个 Acquire 请求如何转换成 Grant 响应，看状态从 Branch 变成 Trunk 再变成 Dirty，边看代码边对照协议文档，比单纯看论文高效得多。

3.3 CXL.cache / OpenCAPI / CCIX 的消息封装：PCIe 物理层的乱世英雄

这三个协议都跑在 PCIe 或者类似物理层上，意味着它们要面对一个本质问题：PCIe 是为外设 IO 设计的，以内存一致性为核心的流量并不是它的原生强项。

CXL 的方案是在 PCIe 物理层上定义 CXL 事务层，把请求、响应、数据做成类似 CXL.cache 的专用消息。CXL.cache 的消息字段里既有标准协议字段，也要携带 PCIe 的标识信息，比如 Requester ID、Tag，用来在链路上定位事务。

OpenCAPI 则更偏内存语义，它的核心就是把内存访问和一致性合并为一个操作，字段设计上会更接近“内存读写事务+状态信息”，降低加速器一侧的理解成本。CCIX 作为先行者，走的是在 PCIe 之上叠加一致性层的老路，虽然已被 CXL 整合，但它证明了这种叠加模式可行，也暴露了延迟和协议开销的问题。

3.4 重点来了：PBR 路由到底是哪一步

PBR 在本文语境下是 Physical Address Based Routing，中文可以叫“基于物理地址的路由”。它解决的问题是：一个请求发出后，互连网络如何决定它该去哪个 Home Node、哪个 Slope、哪个 Cache Agent？

做法很直接：对物理地址做位段解析或哈希。CHI 体系里，系统地址映射表（SAM）会指定不同地址区间对应哪个 Home Node；实现时常见做法是提取物理地址中间若干位做 Interleave，把连续地址的访问均匀分散到多个 Home Node，避免单点热点。所谓 PBR，就是这种把物理地址当作路由决策依据的方法。

为什么强调基于物理地址？因为在一致性互连里，一个缓存行（通常 64B）必须有一个稳定的归属者，谁负责维护这份数据的缓存状态，谁就是它的“家”。如果同一个地址在不同时刻路由到不同 Home Node，一致性目录就会分裂，整个系统就崩了。所以协议才会花大力气保证：同一物理地址，路由结果必须是确定、稳定、一致的。

3.5 路由计算实例：拿一个 36 位物理地址看 PBR 怎么走

假设系统有 4 个 Home Node，物理地址 36 位，缓存行大小 64B。地址的低 6 位是行内偏移，接着若干位可以作 Hash 选择。

如果系统采用简单位选路由，取地址 [8:7] 两位作为 NodeID——这里注意 [6] 是行内偏移（64B 即 2^6），所以 [7] 和 [8] 已经在行粒度之上。连续 256B 范围内的 4 个缓存行会分布到 4 个不同 Home Node，这样对顺序访问型负载很友好。如果内存访问模式随机，位选会看到明显热点，于是很多成熟实现用 CRC 或 XOR Hash 代替简单的位选，让地址位上的规律被“搅散”。

但 Hash 也不是越散越好。Hash 函数复杂会带来更大的仲裁/查表开销，也可能破坏 TLB 页内连续地址的局部性。PBR 路由设计的本质，就是在均衡性和实现复杂度之间做取舍。

3.6 各家路由机制对比

从工程视角看，片内 PBR 强调简单确定，跨节点 PBR 更关注拓扑感知和拥塞均衡。

4. 实操视角：协议选型、仿真建模与踩坑实录

4.1 方案选择：什么场景该用哪个协议

没有最好的协议，只有最合适的场景。如果你是做一颗 RISC-V 内核为主、需要开源参考实现、看重可修改性的芯片，TileLink 几乎是第一选择，因为 Rocket Chip 生态里现成的验证环境和代码太多。如果团队技术栈偏 ARM，或者需要承接现有 ARM IP 生态，CHI 更合适，但代价是协议复杂度高，验证周期更长。如果做数据中心加速器、要兼容 PCIe 生态，CXL.cache 是既定趋势。如果目标是内存语义这种特殊加速器，OpenCAPI 仍有一席之地。OmniXtend 则适合研究课题，比如你想在普通交换网络上构建一致性共享内存，它给了一个可行的开源起点。

决策时还要想清楚：你的瓶颈是延迟还是带宽，是兼容性还是可修改性。多个维度综合评估，再动手。

4.2 用开源模拟器和 RTL 项目学协议

我超级推荐的方法是“先模拟、后 RTL”。用 GEM5 或 SystemC/TLM 模型跑一遍协议流量，你能在高层看到消息序列和状态迁移；再进到开源 RTL，比如 Rocket Chip 的 TileLink 实现，GPU 风格的 OpenPiton/NoC，具体看信号和握手。我自己学 CHI 时，就是先在 QEMU 和自定义的 SystemC 模型里模拟，再对照 ARM 官方文档逐条看字段。

做一致性协议验证有一条铁律：不仅要测正向路径，更要把 snoop 与 response 乱序、多个请求指向同一缓存行、部分写和数据返回竞争这些边界场景全都覆盖掉。很多时候问题不在状态机设计时，而出现在随机流量压测下。

4.3 常见问题速查与排查思路

排查顺序我一般固定：先看链路层（有没有丢包重传），再看事务层（请求响应是否乱序），最后查状态机（有没有非法迁移）。有几次调试到凌晨的经历，最后定位到的问题不是状态机逻辑，而是地址位段提取错了一位，导致路由去错节点。所以建议验证环境里专门加地址位段断言，第一时间抓这种低级错误。

4.4 C 语言和 Verilog 建模协议状态机的两点心得

前面提过三段式硬件写法，再说说软件侧建模。用 C 语言写协议状态机时，很多人喜欢用 switch-case 硬写，状态一多就爆炸。我习惯把状态转移表做成二维表：行是当前状态，列是事件，表项指向次态和动作函数。这种表驱动方式写 CHI 这种复杂协议特别高效，每加一个事件，只需要在对应行列补一个表项。

在 Verilog 里，我的建议是每个 Agent 对应一个独立状态机模块，不要把所有 Agent 混在一起写。比如 Home Agent、Cache Agent、Snoopee 各自维护独立状态机，通过接口信号交互。这样最容易定位是哪个 Agent 先进入非法状态。线上很多朋友搜“STM32 按键状态机”“PLCopen 状态机图”，其实方法论和协议状态机完全一样：拆状态、定事件、画迁移、实现。只是协议状态机的状态更多、并发型更强、时序约束更严格而已。

5. PBR 的三个世界：别把策略路由和物理地址路由混为一谈

如果你现在去搜索引擎敲 PBR，大概率会看到两类完全不相干的结果。一类是做 3D 渲染的同学说的 Physically Based Rendering（基于物理的渲染），天天讲金属度、粗糙度、法线贴图；另一类是网络工程师说的 Policy Based Routing（策略路由），拿 ACL 和路由策略控制流量走向。而互连协议里的 PBR，是 Physical Address Based Routing，干的事情是根据物理地址决定请求在互连网络里往哪个 Home Node、哪个缓存代理走。

这三个 PBR 是三个世界的东西。搞互连协议的人和搞渲染的人聊 PBR，彼此都会沉默。所以在看协议资料时不要被热词带到沟里：文中的 PBR 一定先看上下文，如果后面跟着“路由”“地址映射”“Home Node”，那基本就是物理地址路由。

调试 PBR 路由时，有一个值得分享的小技巧：不要靠肉眼读波形去比对 Hash 结果，直接在 RTL 里加一个地址到 NodeID 的 monitor，把所有请求的物理地址和路由结果自动记录成 log。跑一轮随机测试后，用脚本检查同一个地址是否永远路由到同一个目标。只要发现一次不一致，就是 PBR 路由功能出了大问题。这种方式比事后追波形高效得多，也是我后来在多个互连项目里一直保留的调试手段。

另外，由于 PBR 路由和缓存一致性目录强相关，修改地址映射表时务必考虑运行中的缓存状态。比如你想把某个地址区间从一个 Home Node 迁移到另一个，必须先在协议层把相关缓存行逐出或写回，确认所有脏数据落位后再改路由配置。否则容易出现“写到 A 家、读却去了 B 家”的灵异现象。这个坑我在早期项目中踩过，代价是一整个版本的验证回归重跑。经验就是：协议行为要变，先让状态机归位，再动路由。