1. Cache Coherency概述
1.1 什么是缓存一致性
多核系统里，每个CPU都有自己私有的缓存。同一个内存地址的数据，可能会在多个缓存中留下副本。问题来了——如果其中一个核修改了本地缓存里的值，其他核看到的还是老数据，程序就乱了。
缓存一致性要解决的，说白了就是：保证所有缓存对同一内存地址的读操作，都能拿到最新写入的值。
我刚开始做SoC验证时，遇到过一件印象很深的事。一个双核系统，核0写了一个共享变量，核1轮询等它变。结果核1永远等不到——因为核1的缓存里还是旧副本，核0的写根本没通知过去。后来发现是总线监听逻辑有个bug，监听到写到一半就丢了。嗯，从那以后我设计一致性子系统时，一定会用形式化工具把读写顺序跑一遍。
核心记忆点：缓存一致性 ≠ 内存一致性。前者管的是多缓存副本之间怎么同步，后者管的是所有内存访问在不同线程里的全局序。别搞混。
1.2 为什么需要一致性
直接的原因：正确的多线程语义。没有一致性，锁变量、共享队列、标志位这些基础同步机制全部失效。你想想看，连一个简单的自旋锁都没法实现——A核释放锁，B核读到的锁状态还是锁定，系统直接死锁。
更深层的原因，和UCIe（Chiplet互连）也有关。当不同芯片let通过UCIe互联时，缓存一致性协议要跨越物理封装边界。我调试过的某次UCIe链路上，一个cache line的snoop请求在物理层被重排序了，导致目的核收到失效命令比实际写操作还晚。那一次让我彻底明白：不只协议逻辑要对，物理传输的保序同样致命。
警告：在UCIe场景下，一致性不仅仅是软件模型问题，它直接绑定了物理层的事务排序、信用控制和重传机制。忽略哪一环，都会埋雷。
1.3 缓存一致性问题的根源
归纳起来三个字：副本多。具体拆解：
- 写传播：一个核改了值，必须让所有其他核知道。
我曾经用逻辑分析仪抓总线，发现某SoC的写传播堵在写缓冲里，因为仲裁器优先级设错了，监听请求一直抢不到总线。折腾了两天才定位到。 - 写串行化：所有核必须看到同一顺序的写操作。
比如核0写5、核1写7，所有核最终要么看到(5→7)要么(7→5)，不能出现先后不一。
这两个条件缺一不可。很多初创公司芯片流片回来才发现，自己的监听协议虽然能传播，但串行化没做好——核0和核1同时改同一个变量时，有的核看到的是核0在先，有的核看到的是核1在先。那恭喜你，得到了一个“随缘一致”的架构。
避坑指南：我在一个项目里曾用“总线顺序”代替“全局顺序”，结果在某次压力测试下总线流控把事务重新排序，一致性直接崩溃。后来强制要求所有监听请求必须携带全局时间戳才搞定。千万别以为总线不会重排序——它真会。
1.4 常见的缓存一致性协议
最经典的是MESI协议。四种状态：
| 状态 | 含义 | 缓存行是否修改 | 其他核是否有副本 |
|---|---|---|---|
| Modified (M) | 本核独占且已修改，内存已过时 | 是 | 无 |
| Exclusive (E) | 本核独占且未修改，内存最新 | 否 | 无 |
| Shared (S) | 多个核有副本，内存最新 | 否 | 有 |
| Invalid (I) | 无效，不持有有效数据 | – | – |
我习惯把MESI看作一辆车的四个档位——M是踩油门冲出去了（数据脏），E是空档滑行（独占但干净），S是坐在车上但车没动（共享），I就是下车了（无效）。每次状态迁移都有对应的总线事务，比如读缺失、写回、监听失效等。
衍生协议还有MOESI（加O状态）、MESIF（加F状态用于过滤转发）。在UCIe场景下，跨Die的监听通常需要支持MESIF或MOESI，因为远程Die的延迟高，用F/O状态可以减少不必要的总线流量。我参与过的一个UCIe原型里，就是因为没加F状态，导致远端核每次都要发起全广播监听，带宽直接爆了。
1.5 一致性协议在UCIe中的挑战
UCIe作为Die-to-Die互连，把一致性协议搬上去，有几个特殊坑：
- 延迟差异：本Die监听几十ns，跨Die可能要几百ns，协议状态机必须容忍异步延迟。
- 信用控制：UCIe用FLIT传输，每个事务消耗信用。如果一个监听请求发出后对方一直没有信用返回，状态机卡死。我在调试时抓UCIe trace，发现有一个Die的监听信用池被死锁在NACK里，因为接收端Buffer满了，发送端还在不停重试——我后来加了超时退出机制才解开。
- 原子性：UCIe不支持跨Die的原子操作直接锁总线，需要额外的原子事务封装。比如sc/ld的操作在物理层要拆成多个消息，顺序不能乱。
SVG图：多核缓存一致性问题的核心结构
图中展示了一个典型双核系统：每个Core有自己的L1 Cache（运行MESI协议），通过UCIe互连共享内存。红色箭头表示读写请求和监听信号。当CPU0修改L1中的缓存行时，必须通过UCIe向CPU1发送snoop invalidate，确保CPU1的副本失效。如果这个inv信号延迟或丢失，就会产生不一致——也就是我前面提到的那个差点让项目打板的bug。
附：常用一致性协议对比
| 协议 | 状态数 | 状态名 | 主要特点 | 常见应用 |
|---|---|---|---|---|
| MSI | 3 | M, S, I | 没有Exclusive状态，每次读都广播 | 早期系统，效率低 |
| MESI | 4 | M, E, S, I | 添加Exclusive状态，减少总线流量 | 大部分CMP处理器 |
| MOESI | 5 | M, O, E, S, I | 增加Owned状态，允许脏共享 | AMD Opteron, ARM CCI |
| MESIF | 5 | M, E, S, I, F | Forward状态，指定响应者 | Intel QPI, UCIe远程监听 |
我个人在UCIe项目中倾向使用MESIF的变体，尤其是跨Die监听时。F状态可以指定某个Die作为转发放，避免所有Die都参与监听仲裁——这对降低UCIe链路上的监听风暴至关重要。
调试建议：如果你正在调试UCIe上的一致性协议，一开始别急于看完整timing diagram。先抓三个信号——snoop request、snoop response、data transfer——确认这三者的顺序和信用流是否匹配。我曾经花三天追一个协议死锁，最后发现是两个Die的信用初始化不一致，请求和响应永远对不上。