当前位置：首页 > news >正文

超低功耗信号处理实战：从数据搬运到事件驱动的能效设计

news 2026/8/26 12:40:03

看到"The Future of Ultra-Low Power Signal Processing"这个题目，我第一反应不是那些天花乱坠的概念，而是几年前调试一款可穿戴心电设备时的场景：一枚CR2032纽扣电池，系统待机电流要求低于1µA，可光是传感器的上电瞬间就冲出去3mA。那时候我才真切意识到，超低功耗信号处理根本不是"选个低功耗芯片"那么简单，它是一整套从算法、架构到电路、系统协同设计的方法论。这篇文章我想从实践视角，把这条路子上真正关键的东西拆开讲清楚。

1. 数据搬运才是真正的功耗黑洞：一个被忽视的物理现实

很多人一提超低功耗，第一反应是"算得越少越省电"或者"主频降下来就行"。这个直觉对了一半，但真正干过底层的人都知道，今天的信号处理系统中，绝大部分能量根本烧不在计算上，而是烧在了数据搬运上。

1.1 把账算明白：一次计算远没有一次搬数据贵

我拿40nm工艺下的典型数据举例。一次8位乘累加运算（MAC），能耗大约0.2pJ；访问一次片上SRAM，能耗大约5pJ，差了25倍；如果数据跑到DRAM里走一趟，那是200pJ的级别，差了三个数量级；要是通过无线把1比特发出去，能耗直接跳到100pJ到1000pJ甚至更高。

这意味着什么？意味着如果你设计的信号处理算法让数据在存储器和计算单元之间来回倒腾，哪怕算法本身算得再高效，功耗也压不下来。我之前接触过一个语音降噪项目，团队花大力气优化了神经网络算子，把MAC次数砍了一半，结果一测整机功耗没降多少。后来用profiling工具一看，问题出在特征提取环节频繁把中间结果写回外部Flash。把中间数据改成流式处理、全部留在片上SRAM里滚动更新之后，整机功耗直接降了40%。这个教训让我记住一句话：超低功耗信号处理的核心不是"省着算"，而是"让数据尽量待在原地"。

1.2 边缘智能的兴起把功耗问题推到了前线

那么为什么这个话题会在今天变得这么重要？因为信号处理的前沿正在从云端向终端迁移。老派的处理模式是传感器把原始数据一股脑传到后台，服务器去做特征提取、降噪、识别。这在功耗上是最差的选择——传感器节点的无线发射功耗往往占总功耗的大头，传1比特信息的能量足够在本地执行几百次运算。

现在的主流思路是"前端计算、边缘决策"：在传感器旁边就把信号处理掉，只把精简后的结构化结果传出去。这带来一个物理层面的硬约束：终端设备大多数靠电池供电，甚至是靠能量采集供电，功耗预算卡得死死的。可穿戴设备、助听器、植入式医疗设备、工业无线传感节点，每一个场景都在用一套极其吝啬的功耗预算，要求设备完成此前需要一颗完整处理器才能完成的任务。所以"The Future of Ultra-Low Power Signal Processing"的本质，就是研究如何在这个物理约束下，把信号处理的能效推到极致。

2. 从"持续采样"到"事件驱动"：让系统只在有意义的时刻工作

传统的信号处理系统有一个默认假设：信号是连续变化的，所以要持续采样、持续处理。这个假设在墙插供电的年代没有太大问题，但在超低功耗领域它就是最大的浪费来源。实际物理世界产生的信号，绝大多数时间都是稀疏的、偶发的、事件性的。

2.1 始终开启的ADC是功耗刺客

我先举一个具体场景：语音活动检测（VAD）。在很多设备里这功能需要始终在线，等待用户说出唤醒词。传统方案是让麦克风、ADC和DSP一直跑，16kHz采样、16bit量化、逐帧做FFT和能量判断。这一套下来的系统功耗通常在几毫瓦到几十毫瓦量级。

但人说话这个事件，一天里累积起来可能不到十几分钟。剩下的23小时45分钟，系统都在处理"无声"这种毫无信息量的信号，能量全部浪费了。事件驱动架构的思路完全不一样：平时系统深度休眠，只有模拟比较器或者专用事件检测电路捕捉到信号越过阈值，才唤醒ADC和处理链路。

2.2 事件驱动不只靠软件，硬件层面才是关键

有意思的是，真正高效的事件驱动不是靠MCU跑一个轮询循环去"检查有没有事件"，而是用硬件异步逻辑去做。比如电平交叉ADC（Level-Crossing ADC）就是典型的例子：它不按固定时钟采样，而是在输入信号越过预设电平阈值时才产生一个样本。信号平坦时不产生任何数据，处理单元彻底休息；信号剧烈变化时自动增加采样密度。这种器件能把信号本身的信息量转化成采样率，而不是用固定采样率去迁就最坏情况。

对做算法的工程师来说，事件驱动架构意味着算法设计思路需要改变：不能再假设输入是"连续的均匀采样序列"，而要适应"不规则到达的稀疏事件流"。很多现成的DSP算法库直接搬上来是不行的，需要重新设计面向事件流的滤波和特征提取逻辑。这里有一个实操中的重点：事件阈值和迟滞（hysteresis）一定要联合调。阈值设太低，噪声会频繁触发事件，系统永远醒着，功耗反而更高；阈值设太高，漏掉有效信号，召回率崩掉。我倾向于设置两层阈值和一段迟滞区间，让事件在"越过上限才触发、跌回下限之下才停止"，这样能有效抑制临界抖动带来的反复唤醒。

2.3 从架构收益看事件驱动

从功耗账来看，事件驱动带来的收益不是百分之几十，而是数量级。把"始终开启的400mW DSP流水线"换成"1mW级别的模拟事件检测器+偶尔唤醒的DSP核"，整体平均功耗可以降低两个数量级以上。这也是神经形态芯片、事件相机这些技术路线备受关注的根本原因——它们把事件驱动这个理念贯彻到了硬件的最底层。在事件相机里，每一个像素只有当检测到光强变化时才输出事件，静态场景下芯片几乎不耗电。对于视觉信号处理来说，这无疑是效率上的革命。

3. 在器件与电路层面榨出每一纳瓦：近阈值计算与电源管理

事件驱动解决的是"什么时候干活"的问题，但一旦开机干活，我们仍然希望在每一纳秒的计算里榨出极致的能效。这时候就得把视角下沉到电路和器件层面。

3.1 电压平方效应：近阈值计算为什么是香饽饽

数字CMOS电路的动态功耗公式是：

P = α · C · V² · f

其中α是翻转率，C是负载电容，V是供电电压，f是时钟频率。注意那个V²——电压从1.0V降到0.5V，功耗直接降到四分之一。这就是近阈值计算的核心逻辑：把供电电压压到接近晶体管阈值电压（Vth）附近，通常0.4V~0.5V，用显著的频率下降换取数量级的功耗下降。

为什么不是在更低电压下运行？因为当Vdd低到接近Vth时，晶体管开关速度急剧恶化，延迟可能增加10倍甚至更多。而且工艺偏差的影响被放大，芯片间性能差异巨大，极端情况下逻辑门根本没法可靠翻转。所以近阈值计算适用的场景非常明确：那些不需要高吞吐、但对能效极度敏感的信号处理任务，比如持续运行的生物电信号监测、环境传感数据预处理等。

3.2 实际设计中如何做电压和频率的协同调度

做系统设计时，不能简单地把电压降到0.5V然后期望一切照旧。我在实际项目中一般按下面几步来操作：

分析任务的实时性需求：哪些信号处理路径必须保证低延迟（比如心电的R波检测），哪些任务可以容忍延迟（比如长期趋势统计）。按这个把功能模块拆成不同电压域。
建立电压-频率查找表：先估算或实测每个频率点所需的最低电压，在软件层通过DVFS（动态电压频率缩放）机制按需切换，而不是全程跑在最高性能点。
对关键时序路径做角落分析：近阈值下时序收敛是头疼事，需要特殊设计的标准单元库（比如带额外上拉管、大驱动能力的单元），这一点如果流片前验证不充分，默认工作频率要留足余量。

有一个容易踩的坑：很多人以为"降低主频就省电"，结果只是把频率砍下来但电压没跟着降。处理器空闲时频率降了一半，但电压还是原来的值，这时动态功耗随f下降了一些，但漏电功耗一点没省，整机功耗大头可能反而变成静态功耗了。正确的做法永远是把电压和频率绑在一起调，先降电压、再降频率，反过来升频的时候先升电压再升频率。

3.3 能量采集系统里的功耗跷跷板

当系统靠太阳能、热电或振动能量采集供电时，功耗管理又多了一层约束：能量供给是动态变化的，可能突然有一大块能量进来，也可能长时间一分没有。这时候超低功耗信号处理系统不仅要"省着花"，还要"看着余额花"。

我的经验做法是三级能量管理：

第一级用硬件比较器监控能量存储单元的电压，分三档：能量充足、能量吃紧、能量告急。
第二级由MCU依据档位动态调整信号处理任务的强度和周期，比如150档时跑完整的FFT和神经网络推理，能量吃紧时只跑简单的时域特征判断。
第三级是彻底关断非必要外围设备的电源轨，只保留事件检测唤醒链路。

这一套下来，设备能在光照不足的阴雨天维持基础功能，一旦阳光充足又自动恢复满血运行。太阳能供电的设备，MPPT做得再好，如果系统侧不能跟随能量变化动态调节功耗，整体效率也上不去。

4. 重新拥抱模拟域与近似计算：和精度做一笔合理的交易

数字信号处理在过去几十年里是绝对的主流，因为它精确、可重复、易于编程。但"精确"是有代价的——它需要大量的位翻转、大量的存储、大量的能量来维持。在超低功耗这条路上，越来越多的人开始重新审视模拟域计算和近似计算这两个方向。

4.1 模拟前端：把复杂留给物理器件

我们现在做可穿戴生理信号采集，几乎不会把原始信号直接丢给ADC。传感器出来的信号往往只有微伏到毫伏级别，如果不做前置放大和滤波，ADC满量程都覆盖不了有效信号，量化噪声就能把信号彻底淹没。所以模拟前端（AFE）是绕不开的。

问题是怎么设计AFE才能省电。传统的AFE是"放大器+高阶有源滤波器+ADC驱动器"，每一级运放都在耗电。低功耗设计的思路是尽量用无源器件和简单结构完成信号调理：比如用开关电容技术实现可编程增益，用无源RC网络做粗略带限，尽量压缩后级ADC的动态范围需求。

我在ECG信号采集项目里试过一种做法：直接用连续时间Σ-Δ调制器的一阶无源环路滤波器替代传统的大面积有源积分器，功耗降了一个数量级，而信号质量足够满足心率变异性分析的需求。这里的关键是和应用目标对齐——如果要做12导联的医疗级诊断，模拟前端的性能指标必须高；如果只是做日常心率监测和心律失常初筛，很多指标是可以放宽的。

4.2 近似计算：有意地让计算结果"不完美"

近似计算的思路更激进：它承认在某些信号处理任务里，输出结果不需要100%精确，允许一定的误差来换取功耗的降低。具体手段包括：

跳过不重要的比特位：比如在做图像或音频信号处理时，低位数据对结果影响小，可以直接截断相关计算路径的翻转。
降低计算精度：用8位定点替代32位浮点做特征提取，某些场景下精度损失不到1%，功耗却可以降一大截。
电压过压降导致时序违规：在非关键路径上故意让信号传播延时超一点，产生偶尔的位错误，只要错误率控制在可容忍范围，就能换来更低的功耗。

这里有一个工程上的底线：一定要搞清楚下游任务对误差的容忍度。语音识别的误差容忍度高一些，医学诊断的容忍度极低。我曾经见过一个团队把所有模块都换成近似计算，结果整机误差被逐级放大，最后识别准确率崩了。所以做近似计算，必须建立误差从源头到最终输出的传播模型，先仿真后实现，不要盲目激进。

4.3 一个真实的模拟域处理案例：语音端点检测

语音唤醒里的语音端点检测（VAD）是一个非常适合模拟域处理的任务。传统数字方案需要持续采集音频、做分帧、算能量和过零率。用模拟域实现时，可以用一个对数域能量检测器：利用MOS管在亚阈值区的指数特性直接计算信号对数能量，再用一个比较器做阈值判断。整套电路不需要时钟、不需要ADC、不需要DSP核，静态功耗可以压到微瓦级。当检测到语音能量超过阈值，才唤醒后端的数字处理子系统去做完整的唤醒词识别。

这个方案在实测中能把VAD环节的功耗从毫瓦级降到微瓦级，而语音端点检测的准确率与数字方案相比只差一两个百分点。对于始终在线的语音交互设备，这个交易非常划算。这正是未来超低功耗信号处理的一个重要方向：不追求"全数字、全精确"，而是把任务拆分，能用极低功耗模拟电路完成的功能就在模拟域完成，只把真正必要的高精度计算留给数字系统。

5. 存内计算与工具链的现实：纸面功耗和实测功耗之间隔着一条河

前面讲的都是原理层面的省电路径，但真到了工程实现阶段，你会发现理论推算的功耗和实测结果经常对不上账。这中间最大的变量，是工具链的局限和系统级的"隐藏功耗"。

5.1 存内计算：打破搬运瓶颈的架构尝试

既然数据搬运是最大的功耗黑洞，那最直接的解法就是让计算发生在数据所在的地方——这正是存内计算（Computing-in-Memory，CIM）的核心理念。它把乘加运算直接做在存储阵列内部，让数据不用搬出存储器就能完成主要计算。基于SRAM、RRAM或Flash的存内计算宏，其能效可以做到几十到上百TOPS/W，比传统"存储+独立计算"的架构高出两个数量级。

但在实际项目中，存内计算远没有宣传中那么美。第一个问题是精度：模拟域的乘加运算受工艺偏差和噪声影响，有效位宽通常只有4-6比特，很多算法跑上去精度损失明显。第二个问题是灵活性：存储阵列一旦承担计算功能，就很难同时做常规存储，导致架构设计非常不灵活。第三个问题是外围开销：模拟计算结果的模数转换需要高精度ADC，这个ADC的功耗和面积往往把节省下来的能量又吃回去一部分。

我目前的判断是，存内计算在特定场景（比如固定的神经网络推理加速、稀疏信号处理）有明确优势，但短期内很难成为通用信号处理的主流平台。工程上做选型，还是要看具体的信号特征和算法结构，不要轻信纸面TOPS/W。

5.2 仿真很丰满，实测很骨感：隐藏功耗在哪

很多工程师在低功耗设计中习惯依赖EDA工具的功耗报告，但我要提醒一句：仿真报告和实测功耗之间的差距，可能是数量级的。普通的动态功耗仿真很难覆盖模拟IP的上电瞬态、IO翻转、片上电源网络阻抗等复杂因素，电源稳压器的静态电流和开关损耗更是经常被忽略。

我做低功耗系统开发时，给自己定了一条规矩：每个里程碑都要做一次整机实测，用精密电流探针或能量分析仪记录真实运行场景下的电流曲线。实测下来发现，几个特别容易偷电的地方：

GPIO上拉/下拉电阻：几十个引脚挂上外部上拉，每个消耗几微安到几十微安，加起来非常可观。
LDO的静态电流：很多LDO标称静态电流是微安级，但实际在某些压差条件下的静态电流可能翻几倍。
外设未彻底关断时的漏电流：虽然写了sleep函数，但某个外设的时钟没关干净，模块仍在漏电。
电源轨切换的瞬态开销：频繁唤醒-休眠会带来反复的电源稳定过程，这个过程的消耗有时远超正常工作。

在软件层面，我一般会用_SleepNow_、_PMU配置_之类的手段把低频时钟源、掉电检测、调试接口全部关掉；在硬件层面则会把不必要的电阻分压网络断开，把未使用的引脚配置为模拟输入模式避免悬空翻转。这些操作每一处省的可能只有几微安，但超低功耗的胜负恰恰就决定在这些微安上。

5.3 工具链选型的现实经验

做超低功耗数字ASIC设计时，UPF（Unified Power Format）和多电压域设计是标配。我建议从项目一开始就把功耗意图写清楚，不要等到RTL冻结之后再来补。多电压域策略上，优先保证核心信号处理逻辑的低电压域独立可控，IO和模拟IP用标准电压域供电，并在两个域之间做好电平转换。

但工具链再好，也替代不了对应用场景的把控。我在一个项目中见过"所有模块单独关断"的极致低功耗设计，但系统唤醒时需要把所有模块挨个重新初始化，导致唤醒延迟达到秒级，直接毁了用户体验。电源管理的粒度必须和业务需求匹配，不是越细越好，而是"该关的关、不该关的保留"。

6. 从项目落地看未来方向：超低功耗信号处理还能往哪走

讲了这么多原理和经验，回到"未来"这个话题。我个人的判断是，超低功耗信号处理不会走某一条单一的技术路线，而是几个方向会并行推进、互相渗透。

6.1 更聪明的异构集成：模拟、数字、传感器一家亲

未来的超低功耗信号处理芯片会越来越多地采用异构集成方案，把传感器、模拟前端、数字信号处理内核、无线通信模块甚至能量采集管理电路封装在一起。不是在PCB上拼板，而是在一颗芯片里用不同工艺节点、不同电压域实现功能一体化。这样可以将传感器和信号调理之间的寄生电容、引线损耗降到最低，缩短模拟链路的功耗。同时嵌入式非易失存储器（比如MRAM、RRAM）也会逐步成熟，为事件驱动架构提供极低功耗的代码和数据存储方案。

6.2 算法和硬件协同设计的深度绑定

传统的开发流程是算法团队先在PC上跑通，再固件移植到嵌入式平台，再考虑功耗优化。这个流程在超低功耗时代走不通了。算法必须从一开始就把"功耗预算"当成一个硬约束来设计，而不是事后优化项。信号处理算法要主动适配硬件的特性，比如利用事件稀疏度去跳过无效计算、利用低精度定点的语义生成友好代码、把数据局部性设计到算法结构里。我最近在做的几个项目，算法团队和硬件团队已经不再区分先后，而是坐在一起把功耗模型和算法结构同步迭代。