📚 课程目录第4章 Cache与DMA的交互模型

4、Cache与DMA的交互模型：共享内存模型、Cache一致性问题的根源、典型SoC架构中的DMA与Cache路径

4.1 共享内存模型：CPU与DMA的“共同工作区”

在嵌入式系统中，CPU与DMA控制器通常通过共享内存进行数据交换。这种模型下，DMA负责在内存与外设之间搬运数据，而CPU则负责对内存中的数据进行计算或协议处理。共享内存模型是Cache一致性问题产生的物理基础。

  核心概念：共享内存模型要求CPU和DMA都能访问同一片物理内存区域。CPU通过Cache加速访问，DMA则直接读写物理内存（绕过Cache）。这种“两条路径”访问同一数据源，是Cache一致性问题的根源。

4.2 Cache一致性问题的根源：数据“一分为二”

Cache一致性问题的本质是：同一物理地址的数据，在Cache和主存中出现了两个不同的副本。当DMA直接修改了主存中的数据，而CPU的Cache中仍保留着旧数据时，CPU读到的就是“脏数据”。反之，如果CPU先写入了Cache但尚未写回主存，DMA读到的也是“脏数据”。

故障排查要点：在调试DMA传输故障时，如果发现数据“对不上”，首先要怀疑Cache一致性问题。典型现象是：CPU从缓冲区读到的数据与DMA实际写入的数据不一致，或者DMA搬出的数据与CPU刚刚写入的数据不一致。

4.3 典型SoC架构中的DMA与Cache路径

现代SoC（如ARM Cortex-A系列、RISC-V高性能核）中，DMA与Cache的交互路径通常经过系统总线（AXI/ACE/CHI）和内存控制器。理解这些路径是定位故障的基础。

4.4 关键路径与故障点分析

基于上述SoC架构，DMA与Cache交互的故障点主要集中在以下路径：

路径①（CPU → Cache → 内存）：CPU写入数据后，数据停留在Cache中（Dirty状态），尚未写回主存。此时如果DMA启动传输，将读到主存中的旧数据。
路径②（DMA → 总线 → 内存）：DMA完成写入后，主存数据已更新，但CPU的Cache中仍保留着旧副本（Stale状态）。CPU下次读取时，如果Cache命中，将返回旧数据。
路径③（DMA → 总线 → 外设）：外设数据通过DMA直接搬入内存，如果CPU的Cache中已有该地址的映射，同样会产生一致性问题。

排查技巧：在调试时，可以通过以下方法快速判断是否为Cache一致性问题：
1. 在DMA传输前后，对共享缓冲区执行Cache刷新（Flush）或失效（Invalidate）操作。
2. 使用非Cacheable（Non-cacheable）属性映射共享缓冲区，彻底避免一致性问题。
3. 观察数据错误是否具有“偶发性”或“地址相关性”——Cache一致性问题通常只在特定地址和特定时机出现。

4.5 不同SoC架构的Cache一致性策略对比

场景	操作顺序	Cache状态	主存状态	后果
DMA写入 → CPU读取	DMA写主存 → CPU读Cache	旧数据 (Stale)	新数据	CPU读到旧数据，逻辑错误
CPU写入 → DMA读取	CPU写Cache → DMA读主存	新数据 (Dirty)	旧数据	DMA搬走旧数据，传输错误
CPU读 → DMA写	CPU读Cache → DMA写主存	可能被逐出	被覆盖	Cache行失效，需重新加载

架构类型	一致性协议	DMA路径	软件干预需求	典型SoC
ARM Cortex-A (ACE)	MESI / MOESI	通过ACE总线监听	低（硬件自动维护）	Exynos, Snapdragon
ARM Cortex-R (AHB/AXI)	无硬件一致性	直接内存访问	高（需软件Flush/Invalidate）	TI TMS570, NXP S32
RISC-V (无扩展)	无硬件一致性	直接内存访问	高（需软件维护）	SiFive U7, 自定义SoC
RISC-V (IOMMU/Snoop)	ACE-like / CHI	通过Snoop Filter	中（硬件辅助）	Ventana, 高性能SoC
X86 (Intel/AMD)	MESIF / MOESI	通过DMA Remapping	低（硬件+IOMMU）	Core i7, EPYC

  故障排查优先级：对于无硬件一致性支持的SoC（如ARM Cortex-R、基础RISC-V），Cache一致性问题是最常见的DMA故障原因。排查时应优先检查共享缓冲区的Cache属性配置和软件维护操作（Flush/Invalidate）是否正确执行。