2. 协同设计流程：传统串行流程的痛点、协同设计方法论、统一数据模型与标准
各位同行，今天我们来聊聊功耗收敛与时序收敛的协同设计流程。说实话，这个话题我憋了很久想跟大家分享。我在做后端设计的头几年，一直沿用传统的串行流程——先搞定时序，再回头处理功耗。结果呢？每次都是拆东墙补西墙，项目延期成了家常便饭。
2.1 传统串行流程的痛点
传统的设计流程，说白了就是一条流水线。前端把RTL扔过来，后端先做综合，然后跑静态时序分析（STA）。时序过了？好，开始做功耗分析。功耗超标了？那就得回头改设计。
我遇到过最惨的一次，是一个7nm的AI芯片项目。时序收敛花了8周，结果功耗分析发现动态功耗超标了40%。没办法，只能降电压、降频率，时序又崩了。来回折腾了3个月，最后不得不砍掉一半的功能模块。嗯，那滋味真不好受。
传统串行流程的三大痛点：
- 时序与功耗的“跷跷板效应”：你压时序，功耗就涨；你降功耗，时序就崩。串行流程根本没法同时优化。
- 迭代周期长：每次修改都要重新跑综合、布局、时钟树综合、布线。一个完整的迭代周期至少2-3周。
- 数据一致性差：时序分析用的寄生参数和功耗分析用的寄生参数，往往来自不同的抽取工具。结果就是两边算出来的数据对不上。
为什么会这样？我后来想明白了。传统流程把时序和功耗当成两个独立的问题来处理。但实际上，它们共用同一个物理实现——标准单元、互连线、时钟网络。你动一个，另一个必然受影响。
2.2 协同设计方法论
那怎么解决呢？我的答案是：把时序和功耗放在同一个优化循环里。这不是什么高深的理论，说白了就是让它们“同时被看见、同时被优化”。
我个人习惯把协同设计方法论拆成三个层次：
| 层次 | 核心思想 | 我常用的工具/方法 |
|---|---|---|
| 物理层协同 | 在布局、时钟树综合、布线阶段，同时评估时序和功耗 | Innovus的时序-功耗联合优化引擎 |
| 逻辑层协同 | 在综合阶段，用统一的代价函数同时优化时序和功耗 | Design Compiler的Topographical模式 |
| 系统层协同 | 在架构设计阶段，提前评估不同方案的时序-功耗权衡 | PrimeTime PX + 早期功耗估算 |
举个例子。在物理层协同中，我常用的做法是：在布局阶段就开启功耗驱动的时序优化。具体来说，就是让布局器在摆放标准单元时，不仅考虑时序路径的长度，还考虑单元的漏电功耗和动态功耗。这样摆出来的结果，时序和功耗都更均衡。
我的一个小技巧：
在Innovus中，我会同时打开setOptMode -timingDriven true和setOptMode -powerDriven true。然后设置一个权重参数，比如setOptMode -powerEffort high。这样工具就会在优化时序的同时，自动尝试降低功耗。我曾经在一个28nm的项目上，用这个方法把动态功耗降了12%，而时序只损失了不到3%。
逻辑层协同也很关键。我记得有一次，一个同事问我：“综合阶段功耗优化到底有没有用？”我的回答是：“有用，但要看你怎么用。”如果你只是跑个默认的功耗优化脚本，那效果确实有限。但如果你在综合时就把后端物理信息（比如线负载模型、单元驱动强度）考虑进去，那效果就完全不一样了。
我建议的做法是：在综合阶段使用Topographical模式。这个模式会读入一个粗略的布局信息，让综合器能更准确地预估线长和负载。这样综合出来的网表，时序和功耗的预估误差能控制在5%以内。后续后端优化起来就轻松多了。
2.3 统一数据模型与标准
协同设计能不能落地，关键看数据模型。你想想看，如果时序分析工具和功耗分析工具用的不是同一套数据，那协同就是一句空话。
目前业界的主流做法是：基于统一的寄生参数模型（SPEF）和统一的时序库（Liberty）。但光有这些还不够。我遇到过最头疼的问题，是不同工具对同一个物理结构的理解不一致。
我曾经踩过的坑：
有一次，我用StarRC抽取寄生参数，然后用PrimeTime做时序分析，再用RedHawk做功耗分析。结果发现，同一个节点上的电容值，两个工具算出来差了15%。查了半天，原来是RedHawk默认用了更精细的网格划分，而StarRC用的是粗网格。从那以后，我强制要求所有工具使用同一套物理规则文件（Tech LEF + QRC Tech File），并且统一网格划分的粒度。
统一数据模型的核心，我总结为三点：
- 统一的物理描述：所有工具使用相同的LEF/DEF文件，确保对标准单元、宏单元、互连线的理解一致。
- 统一的时序库：使用同一个Liberty库文件，包括NLDM、CCS、ECSM等模型。特别注意，功耗分析用的库和时序分析用的库必须是同一个版本。
- 统一的寄生参数：使用同一个SPEF文件，并且确保抽取时的温度、电压条件与后续分析一致。
说到标准，目前业界最成熟的是IEEE 1481（Delay and Power Calculation Standard）和IEEE 1801（UPF）。UPF这个标准特别重要，它定义了功耗意图的描述方式。我建议所有做低功耗设计的团队，都强制使用UPF来管理电源域、电压岛、电平转换器这些信息。
下面这张图，是我自己总结的协同设计数据流。你可以看到，所有数据都汇聚到一个统一的“数据湖”里，然后时序分析和功耗分析共享同一套物理视图。
你看，这个模型的核心就是“一次建模，多次使用”。所有工具都从同一个数据湖里读取信息，优化结果也写回同一个数据湖。这样就能保证时序分析和功耗分析看到的是同一个物理世界。
统一数据模型的关键检查清单：
- ✅ 所有工具使用相同的Tech LEF和QRC Tech File
- ✅ 时序库和功耗库来自同一个Liberty文件
- ✅ SPEF文件在相同温度、电压条件下抽取
- ✅ UPF文件完整描述所有电源域和电压岛
- ✅ 布局后的DEF文件在时序和功耗工具间保持一致
最后说一句，协同设计不是一蹴而就的。我刚开始推行的时候，团队里也有抵触情绪，觉得增加了工作量。但坚持下来之后，大家都尝到了甜头——项目迭代周期缩短了30%以上，流片一次成功的概率也大大提高了。嗯，这就是我想分享的。
可可精品资料库