第3章：需求分析总览：需求分析在低功耗设计流程中的位置，从规格到实现的桥梁
说实话，很多工程师一上来就喜欢谈「低功耗技术」——什么时钟门控、电源域划分、DVFS……这些当然重要。但我做了十几年低功耗设计，踩过最大的坑，往往不是技术选型，而是需求没搞清楚。
你想想看，一个产品从概念到量产，中间要经过多少环节？需求分析就是那个「定调子」的阶段。调子定歪了，后面再怎么优化，也是事倍功半。
3.1 低功耗设计流程全景图
先给你一张全景图，看看需求分析到底站在哪个位置。
| 阶段 | 主要活动 | 输出物 | 低功耗关注点 |
|---|---|---|---|
| 1. 市场/产品定义 | 竞品分析、用户场景定义 | 产品需求文档（PRD） | 电池容量、续航目标、使用模式 |
| 2. 系统需求分析 | 功能分解、性能指标、功耗预算 | 系统需求规格（SRS） | 功耗预算表、工作模式定义 |
| 3. 架构设计 | 模块划分、接口定义、功耗策略 | 架构设计文档 | 电源域划分、时钟方案、电压域 |
| 4. 详细设计 | RTL编码、电路设计、软件实现 | 设计文档、代码 | 门控实现、状态机优化 |
| 5. 验证与测试 | 功能验证、功耗仿真、实测 | 验证报告、测试报告 | 功耗仿真用例、实测对比 |
| 6. 量产与维护 | 良率分析、现场问题修复 | 量产报告、维护记录 | 功耗异常分析、OTA优化 |
看到了吧？需求分析处于第2阶段，它一头连着产品定义，一头牵着架构设计。说白了，它就是那个「翻译官」——把市场部的「续航要长」翻译成工程师能懂的「待机电流小于10μA」。
核心观点：需求分析不是「写文档」，而是「建模型」。这个模型要能回答三个问题：
- 系统在什么场景下工作？
- 每个场景的功耗上限是多少？
- 功耗和性能之间怎么取舍？
3.2 为什么需求分析是低功耗的「命门」？
我遇到过不少团队，上来就拍脑袋定功耗指标。比如「待机电流小于50μA」，听起来挺严格。但实际做起来才发现——这个50μA到底是在什么条件下测的？室温？高温？有没有考虑电池老化？
嗯，这里要注意。需求分析不到位，后面就会出各种幺蛾子。
第一个坑：指标定义模糊。
我曾经接手过一个项目，客户说「功耗要低」。我问「多低？」他说「反正比竞品低就行」。这种需求，你根本没法做设计。后来我逼着他们签了份功耗预算表，每个模式、每个模块都写清楚。这才算把需求定下来。
第二个坑：场景遗漏。
你想想看，一个物联网设备，平时在睡觉，偶尔醒来发数据。但「偶尔」是多久一次？1分钟？1小时？1天？不同的频率，对功耗的要求天差地别。我见过一个团队，只考虑了「正常工作模式」的功耗，结果产品在「待机模式」下因为漏电太大，电池撑不过一周。
第三个坑：没有考虑边界条件。
低功耗设计最怕什么？最怕「极端情况」。比如温度升高时漏电会指数级增加，电池电压降低时效率会下降。这些在需求分析阶段如果不考虑，后面验证时才发现，那就得大改。
避坑指南：我曾经在一个可穿戴项目上，因为没定义「低温环境下的功耗要求」，结果产品在北方冬天户外使用时，电池续航直接腰斩。后来我们不得不在需求文档里加了一条：「-20°C环境下，待机电流不超过常温的1.5倍」。
3.3 需求分析的核心产出：功耗预算表
我个人习惯，在做需求分析时，一定会产出一张「功耗预算表」。这张表就是整个低功耗设计的「宪法」——所有后续设计都要以它为基准。
这张表长什么样？给你看个简化版：
| 工作模式 | 持续时间 | 平均电流 | 峰值电流 | 占比（时间） | 备注 |
|---|---|---|---|---|---|
| 深度睡眠 | 23小时 | 5 μA | 10 μA | 95.8% | RTC运行，SRAM保持 |
| 轻睡眠 | 30分钟 | 50 μA | 100 μA | 2.1% | 传感器轮询 |
| 活跃模式 | 30分钟 | 5 mA | 50 mA | 2.1% | 数据采集+处理 |
| 通信模式 | 1分钟 | 20 mA | 100 mA | 0.07% | BLE发送 |
| 日均总功耗 | 24小时 | ≈ 0.5 mAh | - | 100% | 电池容量需≥15 mAh（30天） |
这张表的价值在哪？它把模糊的「续航要长」变成了具体的数字。每个模式、每个模块的功耗上限都清清楚楚。架构师拿到这张表，就知道该用多大的电池、该划分几个电源域、该选什么工艺。
小技巧：做功耗预算时，我建议留出20%的余量。为什么？因为实际测试时，总会有一些「意外功耗」——比如漏电、启动浪涌、温度影响。留点余量，后面设计时心里不慌。
3.4 从需求到实现的桥梁：场景分解
有了功耗预算表，下一步就是「场景分解」。说白了，就是把用户的使用场景，拆解成系统的工作模式。
举个例子。一个智能门锁，用户的使用场景可能是这样的：
- 日常待机：门锁关着，没人靠近。系统进入深度睡眠，只保留指纹传感器和蓝牙的唤醒电路。
- 靠近唤醒：有人靠近门锁，红外传感器检测到人体，唤醒主控。主控启动指纹传感器，准备验证。
- 指纹验证：用户按下指纹，主控进行比对。比对成功，驱动电机开锁。
- 开锁完成：门打开，系统再次进入深度睡眠。
你看，一个简单的「开门」动作，被分解成了4个阶段。每个阶段的功耗需求都不一样。需求分析要做的，就是把这些场景「翻译」成系统状态机。
我习惯用一张状态图来描述：
状态机示例（伪代码）：
State: DEEP_SLEEP
- 功耗: 5 μA
- 唤醒源: 红外传感器中断
- 进入条件: 无活动超过30秒
State: WAKE_UP
- 功耗: 500 μA (持续100ms)
- 动作: 启动主控、初始化传感器
- 进入条件: 红外传感器触发
State: AUTHENTICATE
- 功耗: 5 mA (持续200ms)
- 动作: 指纹采集、比对
- 进入条件: 用户按下指纹
State: UNLOCK
- 功耗: 50 mA (持续500ms)
- 动作: 驱动电机
- 进入条件: 指纹比对成功
有了这个状态机，硬件工程师就知道每个模块什么时候该开、什么时候该关。软件工程师也知道什么时候该进低功耗模式、什么时候该唤醒。这就是「从规格到实现的桥梁」。
3.5 需求分析中常见的「隐形陷阱」
做需求分析这么多年，我总结了几条「隐形陷阱」，你写需求时一定要小心：
- 陷阱1：只关注「平均功耗」，忽略「峰值功耗」。峰值功耗虽然时间短，但会影响电源设计、电池内阻、甚至EMC。我见过一个产品，平均功耗只有1mA，但峰值电流达到500mA，结果电池电压瞬间跌落，系统复位了。
- 陷阱2：忽略「启动功耗」。很多设备在启动瞬间会有浪涌电流，可能是正常工作电流的10倍。如果需求里没写，电源设计可能扛不住。
- 陷阱3：把「理想情况」当「典型情况」。比如蓝牙通信，理想情况下1秒发一次数据。但实际场景中，可能有重传、有干扰、有信号弱的情况。这些都要在需求里考虑。
我曾经踩过的坑：有个项目，需求里写「待机功耗小于10μA」。我们设计时按10μA算的，结果量产后发现，有部分设备在高温高湿环境下待机功耗飙到了30μA。后来一查，是PCB漏电和芯片漏电叠加了。从那以后，我要求所有需求文档里必须加上「环境条件」这一栏——温度、湿度、电压范围，一个都不能少。
3.6 小结：需求分析到底要做什么？
说了这么多，总结一下。需求分析在低功耗设计流程中，就是那个「承上启下」的角色。它要做三件事：
- 把模糊的需求变成具体的数字——比如「续航长」变成「待机5μA，活跃5mA」。
- 把用户场景变成系统状态机——每个场景对应什么模式、什么功耗。
- 把边界条件写清楚——温度、电压、工艺偏差，一个都不能漏。
你想想看，如果这一步做扎实了，后面的架构设计、详细设计、验证测试，都会顺风顺水。反过来，如果这一步糊弄过去，后面就是无穷无尽的「改改改」。
我个人习惯，每次开始一个新项目，第一件事就是拉上产品经理、硬件工程师、软件工程师，一起过一遍功耗预算表。哪怕花上一周时间，也值得。因为——
「需求分析省下的时间，最终都会在验证阶段加倍还回来。」
嗯，这句话是我自己总结的，但每次想起来都觉得特别对。