第4章内存子系统优化

4、内存子系统优化：低功耗内存选择、内存带宽与功耗平衡、缓存优化策略

好，咱们接着聊内存子系统。说实话，在嵌入式视觉系统里，内存往往是功耗的大头。我见过不少项目，CPU算力明明够用，结果被内存拖了后腿——功耗压不下去，帧率也上不来。这一章，我就把内存这块的坑和经验，掰开了跟你们讲讲。

选内存，很多人第一反应是「容量够大就行」。但做低功耗设计，你得看内存的工作电压和刷新频率。

举个例子。同样是DDR，DDR3L的工作电压是1.35V，DDR4是1.2V，LPDDR4更是低到1.1V。别小看这零点几伏的差距。我在一个手持设备项目里，把DDR3L换成LPDDR4，整机功耗直接降了15%。

  低功耗内存选型优先级（我个人习惯）：
  LPDDR4/LPDDR4X：适合电池供电的视觉设备，带宽够用，功耗最低
DDR4：适合对成本敏感、功耗要求不极端的产品
SRAM：适合小容量、高实时性的缓存场景（比如行缓冲）
PSRAM：折中方案，容量比SRAM大，功耗比DRAM低

你想想看，一个视觉系统跑30fps，每帧要处理几兆字节的数据。内存每多耗0.1W，散热和续航都是问题。所以我的建议是：能用LPDDR就别用DDR，能用DDR就别用普通SDRAM。

一个小技巧： 选内存时留意一下「自刷新电流」这个参数。有些LPDDR4在自刷新模式下只有几十微安，非常适合待机场景。我曾在智能门锁项目里靠这个把待机功耗压到了0.1mW以下。

做视觉的人，总担心带宽不够。但带宽越高，功耗越大——这是铁律。为什么？因为高带宽意味着更高的时钟频率、更宽的数据总线，这些都会增加动态功耗。

我见过一个团队，为了跑4K分辨率，上了双通道LPDDR4，结果功耗爆表，散热压不住。后来一分析，其实单通道LPDDR4的带宽已经够用，只是他们代码里DMA传输没优化好。

这里我给你们一个经验公式：

实际所需带宽 = 分辨率 × 帧率 × 像素位深 × 1.5（安全系数）

举个例子，1080p@30fps，RGB888：

1920 × 1080 × 30 × 24 = 1.49 Gbps ≈ 186 MB/s
加上安全系数 ≈ 280 MB/s

你看，单通道LPDDR4（约3.2 GB/s）绰绰有余。根本不需要双通道。

注意： 别只看理论带宽。实际有效带宽往往只有理论值的60%-70%。因为内存有刷新周期、总线竞争、地址映射开销。我建议你留出至少30%的余量。

那怎么平衡？我的做法是：

嗯，这里要注意。有些SoC支持动态频率调整。你可以在高负载时跑高频，低负载时降频。我在一个AI摄像头项目里就是这么干的——白天跑高频处理视频流，晚上降频只做运动检测，整机功耗降了40%。

缓存优化，说白了就是减少CPU去内存里「取数据」的次数。每次cache miss，CPU都要等几十甚至上百个时钟周期，功耗也上去了。

我曾经在一个图像处理项目里，发现同样的算法，优化缓存前后性能差了3倍。怎么做的？就三点：

视觉处理有个特点——数据访问往往是连续的。比如做卷积，你访问像素(i,j)时，大概率马上要访问(i,j+1)和(i+1,j)。所以：

  避坑指南： 我曾经在做一个边缘检测算法时，没注意数据对齐，结果每次读取都跨两个cache line，性能直接腰斩。后来加了个__attribute__((aligned(64)))，问题解决。

现代处理器都有硬件预取器。但有时候它猜不准你的访问模式。这时候你可以手动预取：

// ARM Cortex-A系列手动预取示例
__builtin_prefetch(&next_line[0], 0, 3);  // 0表示读，3表示高局部性

我习惯在循环处理图像行时，提前预取下一行数据。这样当CPU处理当前行时，下一行已经在cache里了。

有些数据只用一次，比如从传感器读来的原始数据。如果把它加载到cache里，反而会把有用的数据挤出去。这时候可以用non-cacheable或streaming模式：

一个小经验： 做图像缩放时，源图像数据往往是只读的，而且每个像素只用一次。这时候我通常把源数据放在non-cacheable区域，把目标图像放在cacheable区域。这样既避免了cache污染，又加速了写操作。

说了这么多，我给你们总结一个实际的设计流程：

最后说一句。内存优化没有银弹。每个项目都要根据实际场景去调。但只要你把上面这些原则吃透了，至少能省下30%的功耗。嗯，这就是我这些年摸爬滚打总结出来的东西，希望对你们有用。