第四章：CCIX协议架构 — 一致性协议与传输层
做CCIX测试这么多年，我最深的感受是：搞懂协议架构，比背一百条规范条文都管用。说白了，CCIX的架构就是两层：一致性协议层 和 传输层。这两层各管一摊，但又必须配合得天衣无缝。下面我把这两层拆开揉碎了讲，顺便聊聊我在项目中踩过的坑。
4.1 整体分层模型
CCIX把协议栈分成了三层，但测试中最常打交道的就下面两层：
| 层 | 职责 | 核心问题 |
|---|---|---|
| 一致性协议层 | 维护多主设备间的缓存一致性 | 什么时候该回写？什么时候该无效？ |
| 传输层 | 保证消息可靠送达、流控、分片重组 | credit够不够？丢包了怎么办？ |
再往上是链路层和物理层，但那是另一门课的内容。今天我重点说这两层。
测试重点： 一致性协议层主要测“状态机跳转”是否正确；传输层主要测“credit管理”和“重传机制”。不要混在一起测，否则出问题了都不知道是协议层的锅还是传输层的锅。
4.2 一致性协议层 – 缓存状态机
CCIX的一致性协议基于MESI的变体。我记得在一本规范里看到，CCIX加了一个叫“UD”的状态，专门处理脏数据跨互连的场景。我们测试时最常撞到的就是状态机跳转不对。
核心状态有五种：
- M (Modified) – 只有我改过，数据在我手里，别人都没有。
- S (Shared) – 我只有读的份，别人也可能有。
- I (Invalid) – 我用不了，得去拿。
- E (Exclusive) – 只有我有，但没改过，干净。
- UD (Unmodified Dirty) – 这个比较特殊，数据在互连网络里“脏”着，但没人修改它。
我曾经在项目中遇到一个bug：两个加速器同时读同一个地址，协议层应该给两个S状态，结果状态机跑成了E和I。查了大半天，发现是一致性协议的“探听（Snoop）”超时逻辑写错了。你想想看，探听如果丢了一个回应，状态机就永远卡在中间状态，系统直接卡死。
避坑指南： 测试时一定要构造“探听丢失”场景。我曾经用硬件触发器模拟探听响应延迟，发现不少实现会在超时后直接发“无效”信号，导致主设备被动回写。这个行为合规但不高效，性能测试会暴露问题。
4.2.1 一致性事务类型
CCIX定义了三种基本事务：
- ReadOnce – 读一次，不要保留缓存副本。
- ReadUnique – 我读完要独占，别人手上的副本都得无效。
- WriteUnique – 我写之前先拿独占权，然后直接写。
你可能会问：“那WriteBack呢？” 我习惯把回写归为隐式操作，因为它通常是状态机自动触发的，不需要外部发起。
4.3 传输层 – 可靠送信的管家
传输层的角色其实很朴实：把一致性协议层产生的消息，切成合适大小的包，加上序列号、流控标签，然后扔给链路层。收端再拼回去，检查有没有丢包乱序。
我个人认为传输层最难测的是Credit机制。CCIX用的是基于Credit的流控，每个发送端都得预先拿到接收端的Credits才能发数据。如果Credit分配不对，系统要么死锁，要么带宽浪费。
| 传送类型 | Credit类型 | 典型坑点 |
|---|---|---|
| Request | ReqCredit | 请求credit耗尽时，transmitter没及时回收，导致发不出新请求 |
| Response | RspCredit | 响应credit被占用但没人释放，造成“假死” |
| Data | DataCredit | 数据宽度与credit粒度不匹配，经常出算错 |
危险动作： 不要在生产测试中用“满credit”启动环境。我见过团队为了省事，初始化时把所有设备的credit给到最大，结果某次链路抖动后credit丢失，系统卡了十几分钟才恢复。建议每次都按规范做“初始credit交换”才能测试真实场景。
4.3.1 包格式与序列号
传输层给每个消息分配一个事务ID（TID），加上序列号（SN）。SN是收发两端对账用的。比如发送端发了三个包：SN=0,1,2，接收端只收到0和2，那它就会发一个NAK要求重传SN=1。
// 伪代码示意：传输层重传逻辑
if (recv_sn != expected_sn) {
send_nak( expected_sn );
retry_buffer[expected_sn].wait_retransmit = true;
}嗯，重传是CCIX传输层的硬伤。因为延迟太高，很多实现干脆放弃重传，直接让上层协议超时。但规范里规定必须支持重传，否则一致性协议无法保证一致性。
4.4 两层之间的交互
一致性协议层发指令（比如“ReadUnique”），传输层把它封装成Request包加上TID和SN。接收端传输层解包后，把内容递给上层。返回时也一样。两者之间的接口叫“TRP（Transport to Protocol Interface）”，我参与过的项目里，这个接口定义最容易出歧义。
4.5 两层测试策略
我习惯把测试分为两层独立验证：
- 一致性协议层测试： 用预置的序列（比如M->E->S->I）驱动DUT，检查状态机跳转是否符合规范中的状态表。特别注意“invalid to exclusive”这种跨级跳转是否被合法阻止。
- 传输层测试： 构造大量短包、长包、混包，观察credit分配和重传机制。我在一次测试中发现，当数据包大小正好等于链路层MTU时，credit计数器会溢出为零，然后整个链路锁死。
小技巧： 做传输层测试时，可以用硬件注入单比特错误，看能否触发重传。如果错误注入后系统没有反应——说明传输层的CRC校验或重传逻辑根本没跑通，立刻报bug。
4.6 总结一句话
一致性协议层决定“数据该不该用”，传输层决定“数据能不能送到”。
你测CCIX互操作性，本质上就是在验证这两层配合得好不好。我个人建议：先把传输层的credit和重传测稳，再测一致性协议的状态机。否则状态机测不过，你不知道是协议逻辑写错了，还是消息在半路丢了。顺序对了，问题好定位。