2. CXL.cache协议基础：概念、消息类型、事务流归纳总结
CXL.cache，说白了就是让加速器和CPU能共享同一份缓存数据。你做ATE测试时，最头疼的往往是「这个请求到底该不该命中？」，而答案全藏在这套协议里。我当年刚接触CXL时，光理解它那套消息类型就花了一周。
2.1 核心概念：宿主与设备间的缓存协同
CXL.cache定义了一种主从关系——Host（通常是CPU）持有全局内存的一致性视图，而Device（加速器）通过Request和Snoop两套通道与Host交互。设备内维护自己的缓存，但必须遵循Inclusion或Exclusive策略。嗯，这里有个容易踩的坑：设备缓存的有效位（Valid）和脏位（Dirty）管理完全靠自己，协议只负责告知你「该块现在归谁管」。
- Cache Line状态：类似MESI协议，CXL.cache引入了Modified、Exclusive、Shared、Invalid四种基本状态，外加一个Forward状态用于直通。
- 设备角色：Device可以是带有私有缓存的加速器（如GPU的L2），也可以是没有缓存的纯数据搬运引擎。我曾在项目中遇到过一颗AI芯片，它把CXL.cache的Request通道当DMA用，结果缓存一致性全乱套了——因为你必须按协议维护Cache Tag。
- 事务粒度：一律以64字节（Cache Line）为单位，不支持部分写。
2.2 消息类型：三通道体系
CXL.cache一共定义了三个物理通道：Req（请求）、Rsp（响应）和Data（数据）。你别看名字简单，每通道的消息种类加起来有十几种。我把常见类型整理成了一张表：
| 通道 | 消息名称 | 方向 | 用途简述 |
|---|---|---|---|
| Req | RdCurr | Device→Host | 读取当前值，不改变状态 |
| Req | RdOwn | Device→Host | 请求独享所有权（可写） |
| Req | RdOnce | Device→Host | 一次性读取，设备不缓存 |
| Req | WrCurr | Device→Host | 写回但不改变共享状态 |
| Req | WrInv | Device→Host | 写回并使其他副本失效 |
| Rsp | RspHit | Host→Device | 命中，携带数据状态 |
| Rsp | RspMiss | Host→Device | 未命中，需要内存填充 |
| Rsp | SnpCurr | Host→Device | 嗅探，要求返回当前数据 |
| Data | NonData | 双向 | 不带数据的控制传输 |
| Data | Data | 双向 | 64B有效载荷 |
你看，光是Req通道就有5种。我习惯把RdOnce理解成「看一眼就走」，而RdOwn才是真正的读写准备。做芯片验证时，最难覆盖的是WrInv和RdOwn的交叉场景——你想想看，如果设备先发出RdOwn拿到E状态，然后另一颗设备又发WrInv，中间需要Host做Snoop广播。
2.3 事务流：一个完整读请求的旅程
光记消息类型没用，得串成流程才能写出测试向量。下面我用手绘风格的SVG图展示一个典型的读独享事务流：
流程看着简单，但我在ATE测试中最先遇到的bug是——Device发了RdOwn后，Host居然没有做Snoop就直接返回了数据。结果另一个缓存里还留着脏数据，直接导致一致性漏洞。所以写测试向量时，你要刻意构造出「多个缓存同时请求同一行」的场景。
2.4 关键事务流对比
除了读独占，CXL.cache还有写回、一次性读、复合请求等。我把最常用的三种事务流做了个对比：
| 事务类型 | 典型消息链 | 缓存状态变化 | 设备侧要求 | 实测避坑 |
|---|---|---|---|---|
| RdCurr（读当前） | Req:RdCurr → SnpCurr → RspHit(Data/S) → Data | 保持S或I | 不修改本地Tag | Host可能返回Stale数据？要检查Snoop顺序 |
| RdOwn（读独享） | Req:RdOwn → SnpCurr → RspHit(Data/E) → Data | 从I/S → E | 需要标记为可写 | 务必等待RspHit后才修改 |
| WrInv（写回并失效） | Req:WrInv → (内部检查) → RspHit + DataDone | 从M → I | 先确保是唯一拥有者 | 写回的同时其他设备可能正读 |
2.5 事务流中的时序约束
做ATE测试时，光知道消息类型和流程还不够，你得理解每对消息之间的延迟窗口。CXL.cache并没有规定严格的时间槽，但有三条硬性约束：
- 请求到第一次响应的最大延迟：Host必须在65536个时钟内返回RspHit或RspMiss，否则Device可以超时重试。
- 数据通道的数据头对齐：Data通道的数据包必须与Req/Rsp通道的事务ID对齐，不能出现数据包先到但请求还没发出的情况。
- Snoop响应的顺序性：对于同一个Cache Line，所有Snoop响应必须在Rsp之前完成。
我个人习惯用Pattern Generator造一个「Host慢响应」的用例：正常情况Host在10~20个cycle返回，我故意把它拉到65000个cycle，看看Device会不会误触发重试。结果我遇到过一个芯片在55000个cycle时就放弃了——它的超时计数器设短了。嗯，这些细节只能靠ATE暴力遍历才能发现。