4、协同策略总览：面积优化与DRC修复的并行工作流

各位好，我是老陈。做了十几年芯片后端，我越来越觉得一个道理：面积优化和DRC修复，从来就不是两件事。你想想看，很多团队把它们拆成两个阶段——先拼命压面积，最后再一股脑儿修DRC。结果呢？修完DRC，面积又涨回去了。白忙活一场。

今天这一章，咱们从宏观视角看看，怎么让这两件事并行跑起来。

为什么非要并行？

我见过太多项目，前期压面积压得特别狠，到了tape-out前两周，DRC错误堆成山。然后整个团队通宵达旦地修，修完一看，面积比最初还大了5%。

为什么会这样？

因为面积优化和DRC规则是相互制约的。你为了省面积，把线间距压到极限，DRC就报错。你为了修DRC，把线拉开，面积就变大。这是天生的矛盾。

我个人习惯的做法是：从项目第一天起，就把DRC检查嵌入到面积优化的每一步里。不是先优化再检查，而是边优化边检查。

并行工作流的三个层次

我把这个并行策略分成三个层次，你可以根据项目阶段灵活选用。

层次	粒度	典型操作	我踩过的坑
第一层：全局规划	芯片级	floorplan阶段预判DRC热点区域	曾经有个项目，我忽略了电源网络密度对DRC的影响，结果后期修了整整两周
第二层：局部迭代	模块级	标准单元placement后立即跑局部DRC	有一次我偷懒没跑，结果一堆最小间距违例，拆了重做
第三层：精细调优	单元级	针对关键路径做面积-规则联合优化	这个层次最费时间，但效果也最明显

并行工作流的典型流程

下面这张图是我自己总结的流程，你可以直接拿去用。

并行工作流的关键动作

说白了，这个流程的核心就三个动作：

1. 预判：在floorplan阶段，根据工艺规则和设计规模，提前标出哪些区域容易出DRC问题。比如电源网络密集区、高密度标准单元区。
2. 边做边查：每做完一步优化，立刻跑一次局部DRC。不要等到全部做完再跑。我习惯在placement后、clock tree后、routing后各跑一次。
3. 联合反馈：面积优化的结果要反馈给DRC修复，DRC修复的结果也要反馈给面积优化。两者互相调整，直到收敛。

避坑指南

我曾经在一个28nm的项目上吃过亏。当时我太相信工具了，觉得工具会自动处理好面积和DRC的平衡。结果呢？工具确实处理了，但它优先保时序，面积和DRC都被牺牲了。最后我手动调了三天才搞定。

所以我的建议是：不要完全依赖工具的自动优化。工具是死的，人是活的。你要在关键节点上人工介入，比如：

• 当面积优化导致DRC违例超过1000个时，停下来看看是不是策略有问题
• 当DRC修复导致面积增加超过3%时，检查是不是修得太保守了
• 当两者反复震荡不收敛时，考虑是不是floorplan本身就有问题

实际项目中的经验数据

我整理了一下最近三个项目的并行工作流效果，供你参考：

项目	工艺节点	传统串行流程耗时	并行流程耗时	面积节省
AI加速芯片	7nm	6周	4周	8%
物联网SoC	28nm	4周	3周	5%
通信基带	12nm	5周	3.5周	6%

你看，并行工作流不仅省时间，面积还能再优化一点。原因很简单：早发现问题，早调整，不用走回头路。

嗯，这一章就讲到这里。记住一句话：面积优化和DRC修复，不是对手，是队友。让它们并行工作，你的版图会感谢你的。