DMA与Cache协同架构：系统总线拓扑、交互路径与硬件一致性方案
这一章，我们来聊聊DMA和Cache到底是怎么“住”在同一个系统里的。说白了，就是搞清楚它们之间的路怎么走、信号怎么传、数据怎么打架又怎么和好。
我刚开始做嵌入式的时候，总觉得DMA和Cache是各干各的——DMA搬数据，Cache加速CPU访问，井水不犯河水。直到有一次调试一个视频采集卡驱动，画面一直出现撕裂和花屏，查了三天才发现是DMA写的数据被Cache“藏”起来了，CPU读到的全是旧数据。嗯，从那以后，我再也不敢小看这个协同架构了。
3.1 系统总线拓扑：谁跟谁连在一起
先看一张最典型的嵌入式SoC总线拓扑图。你想想看，CPU、DMA控制器、Cache、内存、外设，它们都挂在一条或多条总线上。但挂的方式不同，性能差异巨大。
核心观点：总线拓扑决定了DMA和Cache之间是“直连”还是“绕路”，直接影响数据一致性的维护成本。
常见的总线拓扑有这几种：
| 拓扑类型 | 特点 | 典型场景 |
|---|---|---|
| 单总线共享 | 所有主设备（CPU、DMA）和从设备（内存、外设）挂在同一条总线上 | 低端MCU，如STM32F4 |
| 多总线交叉开关 | CPU和DMA各有独立总线路径到内存和外设 | 高性能应用处理器，如i.MX8 |
| 环形/网状拓扑 | 通过片上网络（NoC）互联，路径可动态选择 | 多核SoC，如鲲鹏、英伟达Tegra |
我的经验：在单总线架构下，DMA和CPU争抢总线带宽是家常便饭。我曾经在一个音频采集项目里，DMA占着总线不放，导致CPU响应中断延迟从5μs飙升到50μs。解决办法是给DMA通道设置优先级，或者用多总线架构把音频数据通路独立出来。
3.2 DMA与Cache的交互路径：数据到底走了哪条路
搞清楚总线拓扑之后，我们来看看数据在DMA和Cache之间到底是怎么流动的。这里有个关键点：DMA不经过Cache。它直接读写物理内存，而CPU读写的是Cache中的副本。
为什么会这样？因为DMA的设计初衷就是绕过CPU，直接搬数据。如果DMA每次读写都要经过Cache，那还不如让CPU自己搬呢。但这就带来了一个经典问题——缓存一致性问题。
3.2.1 三种典型交互路径
- 外设→DMA→内存（DMA写）：DMA从外设FIFO读数据，写入内存。此时CPU如果Cache中有这块内存的副本，就会读到旧数据。
- 内存→DMA→外设（DMA读）：DMA从内存读数据，写入外设。如果CPU之前修改了Cache中的数据但还没写回内存，DMA就会读到旧数据。
- 内存→DMA→内存（内存拷贝）：DMA在两个内存区域之间搬数据。如果源或目标区域被Cache缓存，同样会出现一致性问题。
避坑指南：我曾经在一个网络协议栈加速项目里，用DMA把网卡数据直接搬到应用缓冲区，结果应用层一直收到乱序包。查了两天发现是CPU的Cache里还残留着上一轮的数据，DMA写的新数据被Cache“无视”了。解决方案是在DMA传输完成后，对共享缓冲区执行一次Cache无效化操作。
3.2.2 交互路径上的关键节点
数据从DMA到Cache（或反过来），中间会经过几个关键节点：
- 总线仲裁器：决定谁先使用总线。优先级设置不当会导致DMA或CPU饿死。
- 内存控制器：管理DDR的读写时序。DMA的突发传输长度如果和内存页大小不匹配，性能会大打折扣。
- Cache控制器：负责Cache的填充、淘汰和写回策略。它决定了CPU什么时候能看到DMA写的数据。
- 一致性总线（如ACE/CHI）：在支持硬件一致性的系统中，这条总线负责在DMA和Cache之间同步数据。
3.3 硬件一致性方案概述：让DMA和Cache“握手言和”
解决DMA和Cache一致性问题，有两条路：软件维护和硬件维护。这一节我们先看硬件方案，因为它是从架构层面解决问题的根本办法。
3.3.1 硬件一致性方案有哪些
| 方案名称 | 工作原理 | 优点 | 缺点 |
|---|---|---|---|
| ACE/CHI总线协议 | DMA通过一致性总线发送监听请求，Cache控制器自动无效化或更新 | 对软件透明，性能高 | 硬件复杂度高，功耗大 |
| IOMMU/SMMU | DMA访问内存时经过IOMMU，IOMMU维护与CPU Cache的一致性 | 支持虚拟化，隔离性好 | 增加DMA访问延迟 |
| 硬件监听（Snoop） | DMA写内存时，总线主动通知所有Cache控制器 | 实时性好 | 总线带宽消耗大 |
| 非一致性直接访问 | DMA和CPU使用不同的内存区域，或通过配置寄存器强制Cache不缓存 | 实现简单 | 需要软件手动管理，容易出错 |
我个人习惯：在项目初期就确定好一致性方案。如果SoC支持ACE/CHI，我倾向于用硬件一致性，省心。如果是不支持硬件一致性的MCU，那就老老实实做软件维护——在DMA传输前后加Cache操作指令。千万别混用，否则调试起来会怀疑人生。
3.3.2 ACE/CHI总线协议的工作流程
以ARM的ACE（AXI Coherency Extensions）为例，DMA写内存时的大致流程是这样的：
- DMA发起写请求到一致性总线。
- 总线控制器检查目标地址是否在某个CPU的Cache中。
- 如果在，总线发送监听请求给对应的Cache控制器。
- Cache控制器将对应行标记为无效（或写回并无效）。
- 总线确认所有Cache已更新后，允许DMA完成写操作。
- CPU下次访问该地址时，Cache缺失，从内存加载最新数据。
你看，整个过程对软件是透明的。CPU和DMA各干各的，硬件帮你搞定一切。但代价是总线流量增加了——每次DMA写都可能触发一次或多次监听事务。
性能权衡：硬件一致性不是免费的。我记得在一个4核Cortex-A72平台上做视频编解码，DMA频繁写内存，ACE总线的监听流量占到了总线带宽的30%。后来我们通过调整DMA的突发长度和缓存行对齐，把监听开销降到了10%以下。
3.3.3 IOMMU/SMMU方案
IOMMU（I/O Memory Management Unit）是另一种硬件一致性方案。它给DMA提供了一个“虚拟地址空间”，DMA看到的地址和CPU看到的物理地址可能不同。IOMMU负责地址翻译，同时维护与CPU Cache的一致性。
这个方案在虚拟化场景下特别有用。比如在QNX或Linux的KVM中，多个虚拟机共享同一个DMA控制器，IOMMU可以保证每个虚拟机只能访问自己的内存区域，同时保持Cache一致性。
但IOMMU也有代价——每次DMA访问都要经过地址翻译，延迟增加几十纳秒。对于高吞吐量的场景（比如NVMe SSD），这个延迟可能成为瓶颈。
3.3.4 如何选择硬件一致性方案
我总结了一个简单的选择指南：
- 单核MCU，无MMU：别折腾硬件一致性了，用软件维护。Cache操作指令（如ARM的DCache Clean/Invalidate）足够用。
- 多核应用处理器，有MMU：优先用ACE/CHI硬件一致性。如果SoC不支持，就用IOMMU+SMMU。
- 虚拟化场景：必须用IOMMU/SMMU，否则虚拟机之间的数据隔离无法保证。
- 实时性要求极高（<1μs延迟）：硬件一致性可能引入不可预测的延迟。这种情况下，我建议把DMA和CPU的数据区放在不同的内存区域，用非一致性方案，配合Cache锁定（Cache Lockdown）来保证实时性。
曾经踩过的坑：在一个工业控制项目中，我用了ACE硬件一致性，以为万事大吉。结果发现DMA中断响应时间从2μs变成了10μs，原因是ACE的监听事务占用了总线，导致中断控制器访问内存被阻塞。最后我们给中断控制器分配了独立的总线优先级，才解决问题。所以，硬件一致性不是银弹，你得了解它的副作用。
3.4 本章小结
DMA和Cache的协同架构，说白了就是解决“谁的数据是最新的”这个问题。总线拓扑决定了它们之间的物理路径，交互路径决定了数据流动的方式，硬件一致性方案则提供了从架构层面解决问题的工具。
记住三个关键点：
- DMA不经过Cache，这是所有一致性问题的根源。
- 硬件一致性方案（ACE/CHI、IOMMU）对软件透明，但会消耗总线带宽和增加延迟。
- 选择方案时要综合考虑SoC能力、实时性要求和虚拟化需求。