CXL cache coherence 模型：基于目录的一致性，主从设备角色
这一节我们来聊聊 CXL.cache 的核心——目录一致性模型。说实话，我第一次接触这个概念的时候，脑子里的画面全是"这到底是个什么鬼目录？"后来做了几个 CXL 验证项目才慢慢捋顺。你想想看，多设备共享内存，如果不靠目录来追踪缓存行状态，那非乱套不可。
为什么需要目录？
传统监听协议里，每个 CPU 核都要广播监听，总线压力巨大。CXL.cache 走的是另一条路：基于目录的一致性。说白了，就是用一个集中或分布式的目录记录每一块缓存行被谁缓存了、处于什么状态。这样只有相关方收到监听，带宽省了一大截。
我在 ATE 测试中经常要验证目录的正确性——比如目录记录丢失导致数据腐败，那问题就大了。我记得有一次仿真发现目录状态没及时更新，结果 Device 读回了脏数据，整整查了两天……
主从设备角色拆解
CXL.cache 的拓扑里，角色分得很清楚：
- 主设备（Host）：也叫 Home Agent。它掌管目录，负责裁决、监听、最终数据一致性。Host 端通常有 CPU、内存控制器、CXL 控制器，目录一般放在这里。
- 从设备（Device）：也叫 Requesting Agent。它发出缓存请求，比如读、写、预取。Device 内部也有自己的 Cache，但不直接管理目录。
习惯上，我把 Host 看作"交警"，Device 看作"车辆"。交警（目录）知道每辆车在哪条路上，有没有故障，需不需要让行。
目录协议的工作流程
虽然 CXL.cache 属于 CXL.io 之外的独立协议，但一致性基本流程如下：
- Device 发起请求（比如读取缓存行）
- Host 查目录：看这行在哪个 Agent 手里、什么状态。
- 若需要监听：Host 向持有该行的 Device 或 CPU 发监听。
- 数据返回：持有者返回数据（可能被修改过）。
- 完成确认：Host 更新目录状态，通知请求者完成。
这个流程里任何一个环节出错，都可能导致缓存不一致。我在测试时遇到过一种坑：监听响应（Snoop Response）的延迟超出预期，Host 超时误判，结果目录胡乱更新……嗯，这就是典型的边界情况。
目录的状态与转换
典型目录状态包括：
| 状态 | 含义 | 可共享？ | 脏数据？ |
|---|---|---|---|
| I (Invalid) | 本地缓存无效 | — | — |
| S (Shared) | 干净数据，只读 | 是 | 否 |
| E (Exclusive) | 仅此一份，干净 | 否 | 否 |
| M (Modified) | 唯一且脏 | 否 | 是 |
每当 Device 请求写数据，Host 会检查目录：如果当前是 S 或 E，需要先发送监听让其他缓存失效；如果是 M，则需要先回写。这就是"写缺失需要监听"的底层逻辑。
SVG 架构图：主从设备与目录
下面这张图展示了 CXL.cache 基于目录一致性的核心交互。
从 ATE 测试角度看主从角色
大家做 ATE 时，最头痛的是怎么构造"目录冲突"场景。比如：
- Device 读新行：目录查不到，Host 必须从内存取。
- Device 写旧行：目录状态是 M，需要先监听回写。
- Host 主动监听：比如内存迁移场景，Device 必须能在规定时钟内回应 Snoop。
我个人习惯把测试向量分成三块：
- 请求类：读/写/预取，覆盖状态 I、S、E、M 转换。
- 监听从类：Host 主动发 Snoop，Device 响应 Hit 或 Miss。
- 目录错误类：强制注入目录状态错误，观察协议层报错。
秘诀：在 ATE 的 pattern 里，我会把目录初始状态手动设成一个已知值，再让 Device 发请求。这样结果是否合理，一眼就能看穿。
避坑总结
说几个实战中遇到的高频问题：
- Device 的 Snoop 响应超时：Host 可能重复监听，也可能直接走错误路径。测试时需要设置不同响应延迟。
- 目录 entry 被置换：CXL 规范里支持目录缓存（类似 TLB），换入换出会导致短暂的一致窗口。我曾在验证中发现目录 miss 后，Host 用了一个过时的状态——差点以为 IP 有 bug。
- 主从误配：如果 Device 假装自己是 Host 发监听，协议直接崩掉。好在 CXL 物理层会校验角色，但 ATE 最好也加个非法角色注入测试。
嗯，目录一致性这部分内容够深，也够坑。实战中最好的学习方式就是让仿真跑一个错例，然后对照协议手册看哪里没对齐。下一块我们就要进入具体的 CXL.cache 状态机细节，不过那是后面的事了。