4. 综合阶段协同

综合，说白了就是把RTL代码翻译成门级网表。这一步看似简单，但功耗和时序的博弈，从这里就开始了。我见过太多团队，前端扔过来一个设计，后端跑着跑着发现功耗爆了，回头一查，综合阶段就没做对。

这一章，我们聊聊综合阶段怎么把功耗和时序捏在一起考虑。我个人习惯把综合策略分成三类：面积优先、速度优先、功耗优先。但现实是，你往往需要三者兼顾。

4.1 综合策略选择：面积、速度、功耗的三角博弈

先问个问题：你综合的时候，目标是什么？

很多人会回答“时序收敛”。没错，时序是第一优先级。但功耗呢？面积呢？这三个指标就像三角形的三个角，你压下去一个，另外两个就会翘起来。

面积优先策略：适合成本敏感型设计，比如消费电子。工具会尽量复用逻辑，减少寄存器数量。但代价是路径变长，时序容易崩。我在一个IoT项目中试过纯面积优化，结果功耗没降多少，时序反而修不回来。

速度优先策略：适合高性能计算、网络芯片。工具会插入大量缓冲器，展宽路径。代价是面积暴涨，动态功耗也跟着涨。我记得有个5nm的项目，为了跑上2GHz，综合后的面积比预期大了30%。

功耗优先策略：适合电池供电设备。工具会尽量使用低功耗单元，关掉不必要的时钟门控。但代价是时序裕量变小，容易出setup违例。

我的建议是：不要走极端。先以时序为目标做一次综合，看看最差路径的裕量。然后根据裕量大小，逐步调整策略。比如裕量有200ps，那就可以放心地往功耗方向推一推。

4.2 多阈值库单元选择：HVT、SVT、LVT的取舍

多阈值库单元，是综合阶段最直接的功耗-时序权衡工具。简单说：

• HVT（高阈值）：漏电小，速度慢。适合非关键路径。
• SVT（标准阈值）：折中方案。大部分路径用这个。
• LVT（低阈值）：速度快，漏电大。只用在关键路径上。

你想想看，如果整个芯片全用LVT，时序肯定好，但漏电功耗能让你芯片发烫。反过来全用HVT，功耗低了，但芯片可能跑不到目标频率。

我在一个28nm的项目中遇到过这种情况：综合工具默认用了大量SVT，结果静态功耗超标。后来我强制工具在非关键路径上使用HVT，关键路径保留LVT，最终静态功耗降了40%，时序只损失了不到50ps。

具体怎么做？在DC或Genus中，可以用set_max_leakage_power和set_max_dynamic_power约束，配合多阈值库的set_target_library_subset命令。举个例子：

# 设置多阈值库路径
set target_library "hvt_lib.db svt_lib.db lvt_lib.db"

# 优先使用HVT，除非时序不满足
set_max_leakage_power 0
set_max_dynamic_power 0

# 允许工具在关键路径上使用LVT
set_prefer -min lvt_lib.db

嗯，这里要注意：set_prefer只是“偏好”，不是强制。如果时序实在收不了，工具还是会用LVT。所以最终还是要看报告。

4.3 综合约束与报告分析：别只看WNS

综合约束，很多人只关注时钟周期和输入输出延迟。但功耗相关的约束，往往被忽略。我个人习惯在综合阶段就加上这几条：

• 时钟门控约束：set_clock_gating_style，控制门控粒度。太细了面积大，太粗了功耗降不下来。
• 动态功耗约束：set_max_dynamic_power，给工具一个上限。
• 漏电功耗约束：set_max_leakage_power，配合多阈值库使用。

综合完成后，报告分析是关键。很多人只看WNS（最差负时序裕量），觉得WNS为正就万事大吉。其实不然。

我曾经吃过一次亏：一个项目综合后WNS是+50ps，看起来没问题。但到了后端布局布线后，WNS变成了-100ps。为什么？因为综合阶段的线负载模型太乐观了。所以我现在看报告，除了WNS，还会重点看这几项：

1. 总负时序裕量（TNS）：如果TNS很大，说明有很多路径接近违例，后端很容易翻车。
2. 功耗报告：动态功耗和静态功耗分别多少？有没有超过预算？
3. 单元利用率：如果利用率超过85%，后端布线会很痛苦。
4. 时钟门控比例：理想情况下，至少70%的寄存器应该被门控。

下面这张图，是我总结的综合阶段功耗-时序协同的决策流程：

最后，说一个我踩过的坑。有一次综合后，我看了功耗报告，动态功耗只有10mW，很开心。结果后端做完，动态功耗变成了25mW。为什么？因为综合阶段没有考虑时钟树的功耗。时钟树在后端才会真正构建，而它往往贡献了30%-50%的动态功耗。所以，综合阶段的功耗报告，请自动乘以1.5到2倍作为心理预期。

好了，这一章的内容就到这里。综合阶段的协同，说白了就是“先保时序，再抠功耗，多阈值库是利器，报告要往深了看”。