1. 功耗优化概述：摩尔定律与功耗墙、ISP在移动SoC中的地位、协同设计的必要性、功耗优化的核心指标

各位同学好，我是老周。今天开始咱们聊ISP协同设计里的功耗优化。说实话，功耗这个话题在芯片圈子里越来越烫手。我入行那会儿，大家拼的是谁家芯片能跑多快；现在呢，谁家芯片能在同样功耗下多干点活，谁才是赢家。

1.1 摩尔定律与功耗墙

摩尔定律大家都不陌生——每18个月晶体管密度翻一番。但有个问题很多人忽略了：密度翻倍，功耗也跟着涨。到了28nm以后，漏电流开始失控，频率提升也撞上了天花板。这就是所谓的“功耗墙”。

为什么会这样？简单说，工艺越先进，晶体管的静态功耗占比越大。我做过一个28nm的ISP芯片，静态功耗占了总功耗的30%还多。到了7nm，这个比例能冲到50%以上。你想想看，芯片还没干活呢，一半的电已经烧掉了。

我个人习惯把功耗墙拆成两个维度来看：

• 动态功耗墙：频率越高、翻转率越大，功耗越高。ISP里像素时钟动不动几百MHz，这块是重灾区。
• 静态功耗墙：漏电流随温度指数增长。ISP长时间跑视频流，芯片温度上来后，漏电会恶性循环。

我在项目中遇到过一件事：某款手机ISP在4K60fps模式下，芯片温度从85°C升到105°C，静态功耗直接翻了一倍。从那以后，我对温度仿真再也不敢马虎了。

1.2 ISP在移动SoC中的地位

现在的手机SoC里，ISP（图像信号处理器）已经不是配角了。你看看这几年的旗舰芯片，ISP占的芯片面积越来越大，功耗占比也越来越高。

注意看ISP的功耗占比——10%到20%。看起来不高？但ISP是持续运行的。你刷个短视频、打个视频电话，ISP都在工作。CPU和GPU可以休眠，ISP不行。所以ISP的功耗优化，直接影响手机的续航体验。

1.3 协同设计的必要性

说到协同设计，我得先讲个教训。我曾经参与过一个项目，ISP的硬件团队和软件团队各干各的。硬件把Pipeline设计得特别高效，但软件那边为了兼容老平台，用了很多低效的调度策略。结果呢？硬件省下来的功耗，全被软件浪费了。

协同设计，说白了就是硬件和软件一起商量着来。具体包括几个层面：

1. 架构层协同：ISP的硬件架构要支持软件动态调频调压。比如不同场景下，Pipeline的哪些模块可以关掉。
2. 算法层协同：图像算法要考虑硬件实现代价。一个算法效果再好，如果硬件实现要翻倍面积，那就不划算。
3. 调度层协同：任务调度要匹配硬件的功耗状态。比如帧率下降时，自动降低某些模块的时钟。
4. 验证层协同：功耗仿真要带上真实的软件负载。空载仿真出来的功耗数据，基本没有参考价值。

你想想看，ISP是一个复杂的图像处理Pipeline，从RAW域到RGB域再到YUV域，中间有几十个处理模块。每个模块的功耗特性都不一样。如果不做协同设计，很容易出现“木桶效应”——某个模块功耗爆表，拖累整个芯片。

1.4 功耗优化的核心指标：mW/帧

聊功耗优化，得先知道怎么衡量。业界最常用的指标是mW/帧——处理一帧图像消耗多少毫瓦。

为什么用这个指标？因为ISP的负载是帧驱动的。30fps和60fps的功耗完全不同。只看总功耗没有意义，得看每帧的能耗。

我举个例子：

• 芯片A：跑30fps时功耗300mW，mW/帧 = 10
• 芯片B：跑30fps时功耗360mW，mW/帧 = 12

芯片A比芯片B省电20%。但如果芯片B能跑到60fps呢？

• 芯片B：跑60fps时功耗600mW，mW/帧 = 10

这时候两个芯片的能效就一样了。所以mW/帧这个指标，能帮你公平地比较不同帧率下的功耗表现。

能效比 = 帧率 (fps) / 功耗 (mW)
mW/帧 = 功耗 (mW) / 帧率 (fps)

在实际项目中，我习惯把mW/帧拆成三个子指标：

嗯，这里要注意：存储功耗往往是被低估的。ISP需要频繁读写帧缓冲，DDR的访问功耗有时候比计算单元还高。我做过一个统计，某款ISP在4K分辨率下，DDR访问功耗占了总功耗的35%。所以别光盯着计算单元，存储也是大头。

下面这张图展示了ISP功耗优化的核心逻辑：

这张图把ISP功耗优化的逻辑串起来了。从顶层目标mW/帧出发，拆成三个方向，每个方向有具体手段，最后通过协同设计落地。后面的章节，我们会逐一深入每个方向。