低功耗岗位地图：省电这件事，到底由哪些人分工完成
更新时间：2026-09-15。本文是「集成电路大类 · 低功耗设计与验证」入门层系统篇第 45 篇。前面 44 篇讲的是「事」——功耗从哪来、怎么省、怎么量、怎么兜；这一篇讲「人」。很多新人以为「做低功耗」是一个岗位，投简历时搜「低功耗工程师」却发现岗位描述千差万别：有的其实在写 RTL，有的在调 UPF，有的天天跑 IR-drop，有的在写唤醒固件。这篇把这条链上的角色一次性摊开，帮你对上号。系统地图见低功耗导读。
一、为什么低功耗会「长出」专门岗位
低功耗天然横跨多个传统专业，这是它岗位分化的根因：
- 它既是功能问题，又是物理问题：省不省电取决于架构和 RTL（决定翻不翻转），又取决于电压、电源网络、工艺漏电、封装散热（物理与工艺）；
- 它引入了一套独立的意图描述：UPF/CPF 不写在 RTL 里，需要有人专职维护电源域、隔离、保持、电源序；
- 它制造了一类普通功能验证覆盖不到的 bug：断电后 X 传播、隔离漏夹、上下电序错误，逼着验证侧长出「低功耗验证」专岗；
- 它的指标在硅前只能间接估算：从 .lib 功耗表到门级功耗签核，再到板级实测，需要一整条「算—量—对账」的队伍。
所以在一家有规模的公司，低功耗不是一个人，而是一条至少 6~9 个角色协作的流水线；在小公司，这些角色可能压在两三个工程师身上，但职责并不消失，只是合并了。
二、岗位地图总览
下面逐个拆。
三、九个核心角色逐个看
① 系统/低功耗架构师
- 做什么：把产品需求（续航、TDP、数据中心电费）翻译成功耗预算和电源状态机（哪些域常开、哪些可关、几档电压频率、各状态驻留 residency 目标）。预算实战见功耗预算实战。
- 输入：产品规格、电池/散热约束、典型 use case；输出：分模块功耗预算表、电源域划分草案、电源状态表 PST 雏形。
- KPI：整机能效、预算命中率、架构级省电收益。
- 技能：懂软硬件权衡、能算账（焦耳/任务、占空比）、熟悉 SoC 电源架构。
② 低功耗 RTL / 设计工程师
- 做什么：写能省电的 RTL——让综合器推断时钟门控、做操作数隔离、数据通路减少无效翻转、正确接入 retention/isolation/level-shifter 控制信号、设计可断电模块的保存恢复接口。直觉见低功耗 RTL 与毛刺与无效翻转。
- 输入：微架构、电源域划分、UPF 接口约定；输出：带低功耗意图的 RTL、门控使能、电源控制握手。
- KPI：综合后门控覆盖率、模块动态功耗、回归不引入功能 bug。
- 技能：Verilog/SystemVerilog、综合工具、时序基础。
③ UPF / 电源意图工程师
- 做什么：用 UPF（或 CPF）描述电源域、电源开关、隔离、保持、电平转换和电源状态表，保证意图在综合、P&R、验证间一致传递。背景见 UPF 是什么、低功耗格式速览。
- 输入：架构的域划分和电源序；输出：可被实现与验证共同吃用的 UPF 文件、PST。
- KPI：意图与架构一致、跨工具零分歧、ECO 后意图不破。
- 技能：IEEE 1801 UPF、低功耗单元库、对综合/后端/验证流程都要懂一点，是典型的「粘合剂岗位」。
④ 物理 / 电源完整性（PI）工程师
- 做什么：设计电源网格（ring/stripe/rail）、做静态/动态 IR-drop 分析、电迁移 EM 检查、去耦电容 decap 规划、功耗-压降联动。直觉见 IR-Drop、电源网络。
- 输入：门级功耗/电流分布图、floorplan、封装与焊线模型；输出：达标的 PDN、IR-drop/EM 签核报告。
- KPI：最坏角点压降 < 阈值、无 EM 违例、decap 面积合理。
- 技能：P&R 工具、寄生提取、封装协同。
⑤ 库 / 特征化（characterization）工程师
- 做什么：生成和维护标准单元/宏单元的
.lib功耗数据——内部功耗表、漏电、状态依赖功耗，提供 HVT/LVT/多 Vt 单元与电源门控/隔离/保持专用单元。格式见 功耗模型。 - 输入：SPICE 模型、单元电路、corner 定义；输出：多 corner 的时序/功耗库。
- KPI：库精度（硅-库相关性）、corner 覆盖、专用单元齐备。
- 技能：SPICE 仿真、器件物理、统计与拟合。偏底层、门槛高、岗位少但稀缺。
⑥ 低功耗验证工程师
- 做什么：在 UPF 加持的仿真里验证断电不丢该留的状态、隔离值正确、上下电序合法、电源状态覆盖完整、X 不传播到活着的域；写电源相关断言和检查。见低功耗验证。
- 输入：RTL+UPF、电源状态表、验证计划；输出：低功耗 testbench、断言、覆盖率与签核检查报告。
- KPI：电源状态/电源序覆盖率、隔离与保持检查收敛、逃逸的低功耗 bug 数。
- 技能：SystemVerilog/UVM、UPF、X 传播、形式验证（低功耗形式）。
⑦ 功耗分析 / 签核工程师
- 做什么：在 RTL 与门级用真实活动（SAIF/向量）算动态+漏电功耗，定位热点，跑多 corner/多模，估峰值功耗与涌流（di/dt），给出可签核的功耗报告。见功耗分析两条线、功耗报告怎么读。
- 输入：网表、库、SAIF、场景向量；输出：分模块功耗、热点、峰值/平均、与预算的对账。
- KPI：硅前估算与硅后实测的相关性、签核零返工。
- 技能：PrimePower/PrimeRail 类工具、向量工程、统计。
⑧ 电源管理（PM）固件 / 软件工程师
- 做什么：写驱动和策略——DVFS governor、idle/c-state 选择、何时进哪个睡眠态、唤醒源配置、外设 runtime PM、residency 统计。见 CPU 电源管理、MCU 低功耗。
- 输入：硬件电源状态机、功耗模型；输出：OS/固件里的 PM 策略、residency 遥测。
- KPI：实际 residency 达标、续航实测、不破坏实时性。
- 技能：C、RTOS/Linux PM 框架、能读波形和电流曲线，是软硬交界处。
⑨ 板级测量 / 封装与热设计
- 做什么：用电流探头/电源分析仪量真实 P(t)，做功耗-预算对账；封装侧做结温、热点、散热、热阻网络，必要时参与 2.5D/3D 热-电协同。见功耗怎么测、功耗与发热。
- 输入：样片、板级设计、场景脚本；输出：实测电流/能耗、热像、功耗异常单。
- KPI：实测达标、问题闭环回写设计。
- 技能：仪器（示波器、分析仪、热像仪）、电源完整性 PDN、热仿真。
四、岗位间最常见的边界与扯皮点
低功耗的协同成本几乎都发生在接口上，新人提前知道能少走弯路：
- IR-drop 超标，归物理还是归封装？ Die 内网格是 PI 工程师的事，但供电压降经过焊球/封装/PCB 一路连乘，常常要封装和板级一起给模型；不早点拉封装进场，后端怎么加 stripe 都压不下去。
- UPF 归设计还是验证？ 意图本身由设计/架构定义，但验证往往最先发现 UPF 写得无法仿真或与实现不一致。成熟团队让 UPF 成为设计交付物、验证提检查，而不是甩给验证「帮我补」。
- 功耗超标谁背锅？ 若预算在架构阶段就没分清楚、没给 residency 假设，超标时 RTL、固件、物理会互相推。功耗预算表之所以要写责任列，就是为了这一刻——哪一行谁签收。
- 峰值涌流 di/dt 归签核还是板级？ 芯片同时开关电源域产生的涌流，硅上要看 decap，板上要看 LDO/电容响应，两边的模型必须对齐，否则样片复位时才发现 BOR 被触发。
- 热漏电正反馈归谁？ 见功耗与热的耦合：热了漏电更高、更热，签核用的结温和热设计必须共用同一条热模型链。
五、一张 RACI 表：典型低功耗任务谁负责
R=负责执行、A=最终担责、C=被咨询、I=被告知。不同公司会有出入，但这张表能帮新人理解「这件事该找谁签字」。
| 任务 | 架构 | RTL | UPF | 物理PI | 库 | 验证 | 签核 | 固件 | 板级/热 |
|---|---|---|---|---|---|---|---|---|---|
| 定整机功耗预算与电源态 | A/R | C | C | C | I | I | C | C | C |
| 写低功耗 RTL / 门控 | I | A/R | C | I | I | C | I | I | I |
| 维护 UPF 与 PST | C | C | A/R | C | C | C | I | I | I |
| 电源网格/IR-drop/EM | I | I | C | A/R | C | I | C | I | C |
| 隔离/保持/上下电验证 | C | C | C | I | I | A/R | I | C | I |
| 门级功耗与峰值签核 | C | I | C | C | C | I | A/R | I | C |
| governor/睡眠策略/residency | C | I | I | I | I | I | I | A/R | C |
| 板级电流实测与对账 | C | I | I | C | I | I | C | C | A/R |
| 结温/散热/热阻 | C | I | I | C | C | I | C | I | A/R |
读这张表有两个要点：第一，架构师在「定预算」上是 A，在几乎所有执行项上是 C——他不亲手做，但每一项都要咨询他，因为他握着总预算；第二，UPF 工程师一行里 C 特别多，说明电源意图是串起设计、物理、验证的中枢，改一处域划分要通知的人最多。
六、大公司 vs 创业公司：同一个标签，不同的活
招聘网站上同一个「低功耗工程师」title，在不同规模公司里可能是完全不同的工作内容，求职时要按「职责」而不是「title」判断：
- 大芯片公司（手机 SoC、CPU、服务器）：分工细，你可能只做 UPF、只做 IR-drop 签核、或只做库特征化。优点是能在一个点上做到很深、工具和流程齐全；缺点是前两年很难看到全链，容易「只会跑这一步」。建议主动参与跨环节评审，把上下游补全。
- MCU / IoT / 模拟混合信号公司：续航是产品命脉，低功耗往往是「全栈小团队」：一个人可能从电源态定义、RTL 门控、UPF 一路管到板级微安实测，连漏电流是哪颗上拉电阻贡献的都要自己拿万用表查。成长快、体感强，但工具链和流程可能较朴素。
- 创业公司 / 无电池与能量采集方向：见能量采集入门，预算紧到微瓦级，要求对 duty cycle、峰值压降、checkpoint 有近乎本能的把握，软硬全包，最锻炼人也最缺经验沉淀。
- 数据中心 / 服务器与电源软件公司：岗位更偏系统与软件侧——RAPL 封顶、整机功耗调度、PUE、能效指标，见数据中心功耗，硬件背景的人进去做电源策略和性能/瓦优化很有差异化。
七、入行路径与成长阶梯
- 入门最宽的两个口：低功耗 RTL / 低功耗验证。会 SystemVerilog + 一点综合/UVM 就能切入，需求也最大。
- 价值高、门槛也高的两个口：UPF/电源意图（要求全流程视野）和库特征化（要求器件/SPICE 底子），人少、难替代。
- 软硬结合的差异化口：PM 固件。纯硬件背景补软件、或纯软件背景补功耗直觉，都能形成稀缺组合，因为省电的大头最终靠 residency 和策略落地。
- 成长三阶段：① 会用工具在单一环节出报告；② 能跨两三个环节做权衡和对账；③ 能从产品目标定义预算、电源架构和协同机制（架构师）。越往上，「算账 + 协同」比「点工具」越重要。
一个实用的自测：拿到「续航目标三年」这句话时，第一反应如果是「我去调工具看功耗」，还停在第一阶段；如果是「我要先确认电池折损和场景占空比、把预算分到模块并指定责任人」，就已经具备架构视角。判断自己更适合哪条路径，可以看平时更享受哪种时刻：是把一个时序或功耗数字优化到极限的踏实感，还是在多个互相冲突的目标之间谈出一个大家都能接受的方案的协调感。前者更适合往深做（UPF、PI、库、签核），后者更适合往宽做（架构、PM 固件、跨团队对账）。两条路没有高下，低功耗这条链既需要钻得极深的专家，也需要看得极广的统筹者，而资深岗位往往要求你先在一个点上钻深，再主动把视野向前后各延一棒。
八、常见误区
- 以为「会跑功耗工具 = 低功耗专家」：工具只出数字，定义场景、判断数字合不合理、跨环节对账才是价值。
- 以为低功耗是后端的事：七成省电决策在架构和 RTL 就定了，后端只能在既定架构里挤水分。
- 以为固件无关：同一颗芯片，糟糕的唤醒策略可以让实测续航只有理论值的一半。
- 以为岗位分得越清越好：低功耗强依赖交接，愿意跨出自己环节去理解上下游的人，晋升最快。
结语
「做低功耗」不是一个岗位，而是一句产品承诺在九个角色之间的接力：架构定预算、RTL 和 UPF 把省电做进设计、物理和库给它能落地的物理基础、验证和签核证明它对且准、固件在真实场景里把省电跑出来、板级和热设计用实测闭环。新人对号入座时，先问自己更喜欢「算账和权衡」（架构/签核）、「描述和实现」（RTL/UPF/物理）、还是「证明和测量」（验证/板级），就能快速定位入口。
一句话收口：低功耗没有『一个』对口岗位，只有一条谁都不能掉棒的省电接力链——找到你最想负责的那一棒，再往前后各看一棒，你就有了整条链的竞争力。
总结
「做低功耗」不是一个岗位，而是架构、RTL、UPF、物理 PI、库特征化、验证、签核、电源固件、板级测量九个角色协作的接力链，因为它同时横跨功能与物理、需要独立意图描述、制造普通功能验证覆盖不到的 bug；接口扯皮集中在 IR-drop 归属、UPF 责任、超标的预算背锅等处，要靠 RACI 和带责任列的预算表裁定，成长关键则是先在一个环节钻深、再主动跨向上下游。