CXL.cache 状态机与转换归纳总结
状态机这东西，说白了就是 CXL.cache 协议的“心脏”。你想想看，Host 和 Device 之间那么多 Cache Line 飞来飞去，谁该写、谁该读、谁该无效，总得有个规矩。这个规矩就是状态机。
我常跟团队说，状态机就是 CXL.cache 的“身份证”。每个 Cache Line 此刻是什么身份，决定了你能对它做什么，不能做什么。乱七八糟的转换，轻则数据不一致，重则系统直接挂掉。
核心状态：7 个关键角色
CXL.cache 状态机一共有 7 个状态。嗯，这里要注意，不是所有 Device 都必须支持全部状态，但核心的那几个，你绕不过去。
| 状态 | 全称 | 简单理解 |
|---|---|---|
| I | Invalid | 这个 Cache Line 无效。你手里没数据，或者数据是脏的。 |
| S | Shared | 只读，且数据干净。别人也有这份数据，你不能乱动。 |
| E | Exclusive | 只读，但你是唯一拥有者。数据干净，可以随时升级成 M。 |
| F | Forward | 只读，你是被指定的“转发者”。别人缺数据时，你可以直接给。 |
| M | Modified | 数据脏了，只有你有最新版本。你是唯一写过的那个。 |
| SnpF | Snoop Forward | 类似 F，但这是被 Snoop 请求激活的临时状态。 |
| SnpI | Snoop Invalid | Snoop 命中后，数据无效了。你手里如果有脏数据，得写回去。 |
个人小提示： 我刚开始看这 7 个状态时，头很大。后来我总结了一句话——“I、S、E、F、M 是常规身份，SnpF 和 SnpI 是被 Snoop 打出来的临时身份”。你记住这个逻辑，再看状态转换就顺多了。
状态转换：每一步都有因果
状态不会自己乱跳。每一次转换，背后都有一个明确的请求或响应。我个人习惯把转换分成三类：
- Cache 请求引发的转换：比如你发一个 RdCurr，数据回来了，状态从 I 变成 S。
- Snoop 请求引发的转换：比如 Host 发 Snoop 来查你的 M 状态，你交出数据后，状态变 SnpI。
- 监听响应触发的转换：比如你收到一个 HitME 响应，原来在 S 状态，现在得进 I 了。
这里我提一个坑——E 状态到 M 状态的转换。很多芯片第一次流片回来，E 状态升级到 M 时出了问题。为什么？因为你是唯一拥有者，升级时不用通知别人，但你自己得保证数据的局部性还在。ATE 测试时，这块特别容易漏测。
几个关键转换，你得记牢
- I → M：写分配。你发 WrCurr，Host 把拿脏权给你。我在项目里见过很多次，如果 WrCurr 的地址在 Host 那边也是 M，你拿到的是脏数据，但状态写的还是 M，后面就出大事了。
- M → I：写回无效。你被 Snoop 命中，或者你主动写回。切记，写回时数据得完整，字节不能少。
- S → I：别人写这个地址了。你收到 SnoopInv，乖乖把 S 状态清掉。
- E → M：刚才说过的。注意，这个转换不需要全局写许可，但如果你自己 TLB 有冲突，也会挂。
避坑： 我曾经遇到过 Hw1RspD 据为“Snoop hit with data”时，Device 该进 SnpF 还是 SnpI，得看 Host 给的 Meta 信息。如果 Meta 告诉你需要 Forward，你就进 SnpF；如果只是让你无效，就是 SnpI。很多 ATE 用例没区分这个，测出来全是 Pass，实际跑 OS 就概率性死机。
状态转换表：测试的“字典”
我自己做 ATE 测试时，会打印一张状态转换表贴在工位上。你想想看，不查表，你哪记得住 SnoopInv 来的时候，M 状态和 E 状态的处理方式完全不同？
| 当前状态 | 触发操作 | 下一状态 | 关键点 |
|---|---|---|---|
| I | RdCurr / RdOwn | S / E | 数据回来才能推进 |
| S | WrCurr | M | 获取写许可，脏数据 |
| E | WrCurr | M | 无需全局许可，直接脏 |
| M | SnoopInv | SnpI | 写回数据，然后清状态 |
| F | SnoopInv | I | 转发完数据，直接无效 |
| SnpF | 数据传输完成 | I | 临时状态，用完即弃 |
| SnpI | 写回完成 | I | 脏数据必须写回 |
测试策略核心： 你在 ATE 上测状态机，不是测“这个请求走不通”，而是测“这个请求走完后状态对不对”。我个人习惯在每个转换点后插入一个状态读取操作，确认状态机没有“卡在半路”或者“跳到不该去的状态”。
SVG：状态机核心逻辑与转换节奏
下面这张图是我画的整个状态机流转骨架。你能看到，I 状态是“大本营”，所有请求几乎都从 I 开始。M 状态和 SnpI 是“终局”，数据要处理完才能回去。
测试策略：怎么测状态机才靠谱
我做过几十次 CXL.cache 的状态机测试。说实话，最难的不是让状态机跳过去，而是让它跳到正确的地方，并且数据一致。
- 边界转换全覆盖：从 I 出发，把所有能到的状态都走一遍。别只走 S 和 M，E 和 F 容易漏。
- 回环测试：从 M 回到 I，再从 I 到 S，再从 S 到 M……连续来回切换，看状态机会不会卡住或者丢步。
- Snoop 干扰测试：在状态机快转换完但还没稳定时，注入 Snoop 请求。这是最容易出 BUG 的地方。
- 数据完整性校验：每次状态转换后，读一次 Cache Line 内容，确认数据没有被篡改或者截断。
特别提醒： 有些 ATE 平台在测 Snoop 响应时序时，对 SnpF 和 SnpI 的处理不够严格。我曾经发现 Device 把 SnpF 当成了 SnpI，数据没转发，反而写回了，结果 Host 直接读到了脏数据，系统瞬间 hang 死。这个坑，你测的时候多打几个 pattern 进去跑跑，别省。
好了，状态机这块，你掌握这些转换逻辑和测试方法，基本就能覆盖 90% 的实战场景了。剩下的 10%，靠你的耐心和你的 Pattern 覆盖率。