4、ICache与DCache的区别：指令缓存与数据缓存的独立结构、各自的作用、对推理中代码与数据访问的不同影响
在STM32H7系列高性能MCU上运行神经网络推理时，Cache系统的行为往往决定了性能的上限。Cortex-M7内核采用经典的哈佛架构，指令总线和数据总线物理分离，对应地配备了独立的ICache（指令缓存）和DCache（数据缓存）。这种独立结构并非简单的硬件冗余，而是针对指令流和数据流截然不同的访问模式所做的深度优化。理解ICache与DCache的本质区别，是分析推理性能瓶颈、进行有效Cache配置的前提。
4.1 核心原理：哈佛架构下的双通道Cache设计
Cortex-M7内核的哈佛架构决定了ICache与DCache在物理上的完全独立。ICache位于内核的指令取指单元与总线接口之间，负责缓存从Flash或外部存储器读取的机器码；DCache则位于内核的加载/存储单元（LSU）与总线接口之间，负责缓存推理过程中涉及的权重、输入特征图、中间计算结果等数据。两者各自拥有独立的标签RAM、数据RAM和状态机，互不干扰。
从总线层面看，ICache和DCache都通过AXIM（AXI Master）接口访问外部存储器，但指令总线和数据总线在核心内部是分离的。这意味着在同一个时钟周期内，CPU可以同时进行取指和数据访问——只要两者都命中Cache。对于推理任务而言，这种并行性至关重要：卷积层的权重加载（数据访问）与循环体的指令执行（取指）可以重叠进行，从而隐藏存储器延迟。
ICache的典型容量为32KB（STM32H743/H750等），DCache同样为32KB，两者均为4路组相联结构，Cache行大小为32字节。这种配置在嵌入式领域属于“豪华”级别，足以容纳中等规模的推理代码段（如CMSIS-NN的卷积核函数）和部分权重数据。但需要注意的是，ICache和DCache的容量是独立的，不能相互借用——如果推理代码超过32KB，ICache就会发生抖动，而DCache即使空闲也无法分担。
4.2 判断方法：如何区分指令访问与数据访问的Cache行为
在实际调试中，区分ICache和DCache的行为差异，最直接的方法是使用STM32CubeMonitor或硬件调试器（如ST-LINK）的Cache监控功能。Cortex-M7提供了性能监测单元（PMU），其中包含以下关键计数器：
| PMU事件 | 对应Cache | 含义 | 推理场景解读 |
|---|---|---|---|
| L1I_CACHE_REFILL | ICache | 指令Cache未命中，需要从外部存储器读取 | 代码段过大或分支跳转频繁，导致指令流水线停顿 |
| L1I_CACHE_ACCESS | ICache | 指令Cache访问次数 | 反映指令取指的总频率 |
| L1D_CACHE_REFILL | DCache | 数据Cache未命中，需要从外部存储器读取 | 权重/特征图数据访问不连续，或数据量超过Cache容量 |
| L1D_CACHE_ACCESS | DCache | 数据Cache访问次数 | 反映数据加载/存储的总频率 |
通过读取这些计数器，可以计算出各自的命中率：命中率 = 1 - (REFILL / ACCESS)。在推理性能分析中，如果发现ICache的REFILL事件频繁，说明代码段存在严重的Cache抖动；如果DCache的REFILL事件频繁，则说明数据访问模式需要优化。
另一个实用的判断方法是观察执行时间与理论计算量的比值。假设一个卷积层需要执行100万次乘加运算，在400MHz主频下理论耗时约2.5ms（假设单周期MAC）。如果实际耗时达到10ms以上，且DCache命中率低于80%，则可以判定数据访问是瓶颈；如果DCache命中率很高但耗时仍然超标，则需要检查ICache是否存在指令取指停顿。
4.3 案例拆解：YOLO-Tiny推理中的ICache与DCache行为分析
以一个在STM32H743上部署YOLO-Tiny目标检测模型的实战案例来说明。该模型包含9个卷积层和6个池化层，模型权重总量约340KB，输入图像为416×416×3的RGB图。系统配置为：主频400MHz，ICache和DCache均开启，Flash等待周期为2个周期，SDRAM运行在100MHz。
初始现象：单帧推理耗时高达680ms，远超过预期的200ms。通过PMU计数器读取，发现ICache命中率仅为72%，DCache命中率为85%。进一步分析发现，ICache的REFILL事件集中在卷积核函数（约8KB）和激活函数（约2KB）的代码段，而DCache的REFILL事件集中在权重读取和中间特征图写入。
分析判断过程：
- ICache问题：YOLO-Tiny的卷积核函数包含大量循环展开和查表操作，代码段总大小约15KB，虽然小于32KB的ICache容量，但函数调用层次深，分支预测失败率高，导致指令流频繁跳转，破坏了ICache的空间局部性。
- DCache问题：权重数据以浮点数组形式存储，每次卷积操作需要遍历整个权重矩阵，访问模式为顺序读取，理论上空间局部性很好。但实际发现，由于SDRAM的页策略和Cache行大小（32字节）的匹配问题，部分权重行被反复驱逐和重载。
实际操作步骤：
// 1. 使用PMU计数器定位瓶颈
DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk; // 使能周期计数
// 读取ICache和DCache事件
uint32_t icache_refill = DWT->ICACHE_REFILL;
uint32_t icache_access = DWT->ICACHE_ACCESS;
uint32_t dcache_refill = DWT->DCACHE_REFILL;
uint32_t dcache_access = DWT->DCACHE_ACCESS;
// 2. 优化ICache：将卷积核函数放入ITCM（指令紧耦合内存）
// 将热点函数重定位到ITCM地址段
__attribute__((section(".itcm"))) void conv2d_kernel(...) { ... }
// 3. 优化DCache：调整权重存储格式为NHWC并增加对齐
// 将权重数组按32字节对齐，减少Cache行跨越
__attribute__((aligned(32))) float weights[340 * 1024];结果对比：将卷积核函数放入ITCM后，ICache命中率提升至96%，推理耗时降至420ms；进一步将权重数据按32字节对齐并调整访问顺序后，DCache命中率提升至93%，最终推理耗时稳定在280ms。虽然仍未达到理论最优值，但性能提升了58%。
风险与代价：ITCM容量有限（64KB），不能容纳所有代码；权重对齐可能增加存储碎片。此外，DCache的写回策略（Write Back）在推理结束后需要手动Clean，否则可能导致数据不一致。
4.4 常见误区与总结复盘
误区一：认为ICache和DCache可以互相借用。这是对哈佛架构的误解。ICache和DCache在物理上是独立的，ICache无法缓存数据，DCache也无法缓存指令。在推理任务中，如果代码段过大导致ICache抖动，不能通过增大DCache来缓解。
误区二：只关注DCache而忽视ICache。很多开发者习惯性地认为推理是“数据密集型”任务，因此只优化数据访问。但实际上，复杂的推理代码（如多分支的激活函数、动态形状处理）同样会产生严重的指令取指瓶颈。在STM32H7上，ICache的未命中代价与DCache相同，都需要从外部Flash读取，而Flash的访问延迟远高于SRAM。
误区三：忽略Cache行大小的影响。STM32H7的Cache行大小为32字节，这意味着每次未命中都会加载32字节的数据。如果推理代码或数据频繁跨越Cache行边界，会导致额外的未命中。例如，一个结构体数组如果每个元素大小为40字节，那么每读取一个元素就可能触发两次Cache行加载。
误区四：认为开启DCache就万事大吉。DCache的写回策略（Write Back）虽然提高了写性能，但也带来了数据一致性问题。在推理过程中，如果DMA外设直接访问内存（如摄像头采集），而DCache尚未将数据写回，就会导致DMA读到陈旧数据。此时需要手动执行SCB_CleanDCache()或配置为Write Through模式。