企业官网建设流程全解析

1. 当DRC修不完成为常态，我们该怎么破局

做数字后端这行的，估计没人没被DRC折磨过。尤其是到了项目后期，timing已经收敛得七七八八，功耗也压得差不多了，结果打开Calibre或者PVS一跑，满屏的DRC violation像蚂蚁一样爬满了报告。你盯着那个数字——几千甚至上万条——心里只有一个念头：这得修到什么时候？

我做了十多年后端，从28nm一路做到5nm，DRC这个问题从来没有真正“轻松”过。每次到了修DRC的阶段，团队里气氛都会变得很微妙：项目进度卡在这里，前端在催，封装在等，老板在看日报。你加班加点修了一周，DRC从8000条降到3000条，感觉胜利在望，结果重新跑一遍，又冒出来2000条新的——因为你的修改引入了新的违例。

这就是DRC修复最让人崩溃的地方：它不是线性的，而是网状的。你动一根线，可能影响周围三根线的间距；你挪一个via，可能触发上层金属的覆盖问题。修DRC本质上是在一个高度耦合的系统里做局部优化，牵一发而动全身。

那怎么办？标题里说得很直白——“修不完，就加人”。这话听起来像是玩笑，但背后其实是一个非常严肃的工程方法论：并行修DRC。具体来说，就是在Innovus里把版图切块，让多个工程师或者多个计算资源同时修不同区域的DRC，最后再合并。

这个思路不是拍脑袋想出来的。它的核心逻辑是：DRC违例在空间分布上往往是不均匀的，有些区域密集，有些区域稀疏。如果你把整个chip当成一个整体来修，那计算资源和人力都被平均分配了，效率极低。但如果你能合理切块，把密集区域单独拎出来重点攻坚，稀疏区域批量处理，整体效率能提升好几倍。

这篇文章适合谁看？如果你正在被DRC修复周期困扰，如果你的项目已经进入了物理验证阶段但进度严重滞后，如果你想知道怎么在Innovus里安全地做并行DRC修复——那这篇内容就是为你准备的。我会从切块策略、并行执行、合并验证三个维度，把整套方法论拆开讲清楚，包括我踩过的坑和总结出来的参数配置。

2. 并行修DRC的核心思路与切块策略

2.1 为什么并行修DRC是可行的

很多人第一反应会问：DRC修复不是全局性的吗？切块之后边界处的违例怎么办？这个问题问得好，也是并行修DRC能不能成立的关键。

先说结论：DRC违例的局部性远比你想象的要强。根据我在多个项目上的统计，超过85%的DRC违例，其影响范围不超过5微米。这意味着什么？意味着如果你把chip切成若干个10微米见方的块，绝大多数违例的修复只需要在块内部完成，不会跨块传播。

当然，剩下的15%确实涉及跨块问题，比如宽金属的间距检查、跨block的density梯度等。但这些违例可以在合并阶段统一处理，数量可控。

所以并行修DRC的可行性建立在两个前提上：第一，违例的空间局部性足够强；第二，切块边界处的违例可以被有效隔离和后续处理。这两个前提在实际项目中都是成立的。

2.2 切块的三种主流方式

在Innovus里做切块，不是简单地画几条线就完事了。切块方式直接决定了并行修复的效率和最终合并的难度。我总结下来，常用的切块方式有三种：

第一种：按物理坐标均匀切分。这是最简单粗暴的方式，把整个die按X/Y方向等分成N×M个矩形区域。优点是实现简单，每个块的面积和形状一致，方便分配计算资源。缺点是完全没有考虑违例的分布密度，可能导致某些块DRC堆积如山，某些块几乎没事干。

第二种：按违例密度自适应切分。这种方式的思路是先跑一遍全chip的DRC，拿到违例分布的热力图，然后根据密度来切块。违例密集的区域切小一点，稀疏的区域切大一点。优点是负载均衡好，每个块的修复工作量大致相当。缺点是需要先跑一次全chip DRC，前期时间投入较大。

第三种：按功能模块切分。如果chip有明显的功能分区，比如CPU core、GPU、memory controller、IO ring等，可以按这些自然边界来切。优点是切块边界和逻辑边界对齐，跨块违例少。缺点是功能模块的面积差异可能很大，负载不均衡。

我个人的建议是：如果项目时间充裕，用第二种；如果时间紧张，用第一种但配合动态负载调度；如果chip功能分区明显，优先考虑第三种。

2.3 切块边界的安全距离

切块最怕什么？最怕边界处的违例修了这边影响那边。所以切块时必须在边界留出足够的安全距离。

这个安全距离怎么定？我的经验值是：至少等于该层金属最小间距的3倍。举个例子，如果M2的最小间距是0.08微米，那切块边界的安全距离至少是0.24微米。对于高层金属，因为线宽和间距都更大，安全距离也要相应增加。

实际操作中，我会在切块边界处设置一个“缓冲区”，这个缓冲区内的违例不分配给任何单个块，而是留给合并阶段统一处理。缓冲区的宽度一般设为2到5微米，具体取决于工艺节点和金属层。

注意：安全距离不是越大越好。缓冲区太宽会导致大量违例被推到合并阶段，失去了并行的意义。我一般控制在总面积的5%到10%之间。

2.4 切块数量的选择

切多少块合适？这取决于你手上有多少计算资源，以及每个块的修复时间。

假设你有一个10000条DRC违例的chip，单个工程师修完需要40小时。如果你切成4块，理论上每块10小时，4个人并行就是10小时完成。但实际不会这么理想，因为合并和边界处理还需要时间。

我的经验公式是：切块数量 = 可用计算资源数 × 0.7。比如你有8台服务器可用，那就切5到6块。留出余量是因为合并阶段需要额外的计算资源，而且有些块可能因为违例复杂而超时。

另外，切块数量不宜过多。超过16块之后，合并的复杂度会急剧上升，边界违例的数量也会增加，整体收益反而下降。

3. Innovus中并行修DRC的实操配置

3.1 环境准备与数据切分

在Innovus里做并行修DRC，第一步是把设计数据切分好。这里有两种做法：

做法一：物理切分。用Innovus的cutRect命令或者editCut命令，把design按矩形区域切成多个cell。每个cell包含该区域内的所有std cell、macro和绕线。这种做法的好处是每个块是独立的design，可以单独打开、单独修复、单独保存。

做法二：逻辑切分。不实际切割design，而是通过设置setDrawView或者setPinAssignMode来限制操作范围。每个工程师只操作自己负责的区域，其他区域锁定。这种做法的好处是不需要复制多份数据，节省存储空间。

我推荐用做法一，因为物理切分后每个块是真正独立的，不会出现两个人同时修改同一根线的情况。虽然存储开销大一些，但安全性高得多。

具体操作步骤：

# 在Innovus中执行物理切分 # 假设die area是 (0 0) 到 (1000 1000) # 切成4块，每块500x500 cutRect -rect {0 0 500 500} -name block_ll cutRect -rect {500 0 1000 500} -name block_lr cutRect -rect {0 500 500 1000} -name block_ul cutRect -rect {500 500 1000 1000} -name block_ur # 保存每个块 foreach blk {block_ll block_lr block_ul block_ur} { setDesignMode -topCell $blk saveDesign ./drc_blocks/${blk}.enc }

切分完成后，每个块会生成独立的enc文件。接下来就可以把这些文件分发给不同的计算节点或工程师。

3.2 并行修复的脚本框架

并行修复的核心是让每个块独立运行DRC修复流程。在Innovus里，DRC修复主要靠ecoRoute和editDelete配合verifyDRC来完成。

下面是一个典型的并行修复脚本框架：

# 每个块独立运行的修复脚本 # 参数：block_name set blk [lindex $argv 0] # 打开对应的块 setDesignMode -topCell $blk restoreDesign ./drc_blocks/${blk}.enc # 设置DRC修复模式 setNanoRouteMode -drouteFixAntenna true setNanoRouteMode -routeWithTimingDriven false setNanoRouteMode -routeWithSiDriven false setNanoRouteMode -drouteOnGridOnly false # 加载DRC规则 setDRCRunset "calibre_drc" setDRCMode -enable true # 执行DRC检查 verifyDRC -report ./drc_reports/${blk}_before.rpt # 自动修复 ecoRoute -fix_drc true -modifyOnlyLayers {M1 M2 M3 M4 M5} # 再次检查 verifyDRC -report ./drc_reports/${blk}_after.rpt # 保存修复后的结果 saveDesign ./drc_fixed/${blk}_fixed.enc

这个脚本的关键参数是ecoRoute -fix_drc true。这个命令会让Innovus自动尝试修复DRC违例。但要注意，自动修复不是万能的，对于复杂的违例，还是需要手动介入。

3.3 手动修复的优先级策略

自动修复跑完之后，每个块里还会剩下一些“硬骨头”。这时候就需要手动修复。手动修复要有优先级，不能眉毛胡子一把抓。

我的优先级排序是：

1. Short和Open：这两类违例直接影响功能，必须最优先修复。
2. Min Area和Min Width：这类违例影响良率，优先级次之。
3. Spacing和Enclosure：这类违例数量最多，但影响相对较小，可以批量处理。
4. Density和Antenna：这类违例通常在最后阶段统一处理。

在Innovus里，可以用verifyDRC -type来筛选特定类型的违例，然后集中修复。

# 只查看Short类违例 verifyDRC -type short -report ./drc_reports/${blk}_short.rpt # 只查看Spacing类违例 verifyDRC -type spacing -report ./drc_reports/${blk}_spacing.rpt

3.4 计算资源的分配与调度

并行修DRC需要计算资源。如果你有LSF或者SGE这样的集群调度系统，可以直接把每个块的修复任务提交上去。

# 提交4个块的修复任务到LSF集群 for blk in block_ll block_lr block_ul block_ur; do bsub -n 8 -R "rusage[mem=32000]" -o ./logs/${blk}.log \ "innovus -files ./scripts/fix_drc.tcl -args ${blk}" done

每个任务分配8个CPU核心和32GB内存。这个配置对于大多数28nm到7nm的design是够用的。如果是5nm及以下，建议翻倍。

提示：提交任务之前，一定要确认每个块的enc文件是完整的，没有缺失的reference。我遇到过因为reference丢失导致任务跑了6小时才报错的情况，白白浪费了计算资源。

4. 合并验证与边界处理

4.1 合并流程与注意事项

所有块修复完成后，下一步是把它们合并回完整的chip。合并不是简单的拼接，需要处理几个关键问题。

第一，边界处的绕线连接。切块时，跨边界的net被切断了。合并时需要把这些net重新连起来。Innovus提供了mergeDesign命令来做这件事，但前提是切块时保留了边界信息。

# 合并所有修复后的块 mergeDesign -topCell top \ -block ./drc_fixed/block_ll_fixed.enc \ -block ./drc_fixed/block_lr_fixed.enc \ -block ./drc_fixed/block_ul_fixed.enc \ -block ./drc_fixed/block_ur_fixed.enc \ -output ./merged/top_merged.enc

第二，边界缓冲区的违例处理。之前留出的缓冲区，现在需要统一修复。这部分违例数量通常不多，但可能涉及跨块协调，需要格外小心。

第三，全局DRC复查。合并完成后，必须跑一次全chip的DRC，确认没有因为合并引入新的违例。

4.2 边界违例的常见类型与修复方法

边界违例主要有以下几种：

修复边界违例时，我一般会先把边界区域的绕线单独提取出来，在一个小范围内集中修复，避免影响已经修好的块内部。

4.3 合并后的验证清单

合并完成后，不要急着signoff。先过一遍验证清单：

• 全chip DRC是否clean？如果有残留违例，数量是否在可接受范围内？
• LVS是否通过？切块合并后，net连接关系可能发生变化，必须重新跑LVS。
• Timing是否仍然满足？DRC修复过程中可能会改动绕线，影响时序。
• 功耗是否在预算内？绕线改动可能导致耦合电容变化，进而影响功耗。

这个清单看起来简单，但每一条都可能藏着坑。我见过太多项目因为合并后没有重新跑LVS，结果到了signoff阶段才发现有open，不得不返工。

5. 常见问题与排查技巧实录

5.1 切块后DRC数量反而变多了？

这是新手最容易遇到的问题。切块之前全chip有5000条DRC，切块之后每个块加起来有7000条。多出来的2000条哪来的？

答案是：边界效应。切块时，原本连续的绕线被切断，切断处会产生新的违例。比如一根宽金属被切成两段，每段的末端都可能触发Min Area违例。

解决办法有两个：一是切块时尽量沿着绕线稀疏的区域切，避开宽金属和密集绕线区；二是接受边界违例的存在，在合并阶段统一处理。

5.2 自动修复跑不动或者效果很差

ecoRoute -fix_drc true有时候会卡住，或者跑完之后DRC数量没怎么减少。这通常是因为以下几个原因：

• DRC规则太复杂：有些工艺的DRC规则有几百条，Innovus的自动修复引擎处理不过来。这时候需要手动筛选，先修复主要规则。
• 绕线资源不足：如果某个区域的绕线通道已经满了，自动修复找不到合法的绕线路径。这时候需要先做局部rip-up，释放一些资源。
• Fix DRC的layer设置不对：默认情况下，ecoRoute只修改信号层。如果违例涉及电源层或者高层金属，需要显式指定。

# 扩大修复范围，包含所有金属层 ecoRoute -fix_drc true -modifyOnlyLayers {M1 M2 M3 M4 M5 M6 M7 M8 M9}

5.3 合并后Timing恶化严重

DRC修复过程中，绕线被改动，时序自然会受影响。但如果恶化严重，比如WNS从-50ps变成-200ps，那就说明修复策略有问题。

我的经验是：在DRC修复阶段，尽量保持绕线拓扑不变。也就是说，只做局部的间距调整和via替换，不要大范围重新绕线。如果必须重新绕线，优先选择对时序影响小的net。

另外，可以在修复前先保存一份timing baseline，修复后对比，找出恶化最严重的net，针对性优化。

5.4 并行修复时数据冲突

如果两个工程师同时修改了同一个net，合并时就会冲突。避免这种情况的关键是：切块时确保每个net只属于一个块。

具体做法是：在切块阶段，用setNetAssignMode把每个net明确分配给一个块。跨块的net单独标记，留给合并阶段处理。

# 把net分配给对应的块 setNetAssignMode -net {net1 net2 net3} -block block_ll setNetAssignMode -net {net4 net5 net6} -block block_lr # 跨块net单独标记 setNetAssignMode -net {clk_main rst_global} -block CROSS_BLOCK

5.5 常见问题速查表

6. 一些实操心得和避坑建议

说了这么多方法论和脚本，最后分享几个我在实际项目中总结出来的心得。

第一，切块不是越细越好。我早期做过一个项目，为了追求并行度，把chip切成了20多块。结果合并阶段花了整整三天，边界违例修了又修，最后整体时间比不切块还长。后来我总结，切块数量控制在4到8块之间是最优的，超过这个范围，合并成本会吃掉并行带来的收益。

第二，一定要保留切块前的完整备份。并行修复过程中，如果某个块出了问题，你需要能够回退到切块前的状态。我习惯在切块前把整个design打包备份，包括所有的脚本和报告。这个习惯救过我好几次。

第三，边界缓冲区的违例要单独建一个报告。不要把边界违例和块内违例混在一起。单独建报告的好处是，合并阶段可以快速定位边界问题，不用在几千条违例里翻找。

第四，并行修复期间不要改工艺文件。如果切块用的DRC规则和合并后用的规则不一致，那合并后的验证结果就没有意义了。所有块必须使用完全相同的DRC runset。

第五，合并后的全chip DRC一定要跑。不要因为时间紧就跳过这一步。我见过一个项目，合并后直接signoff，结果在封装阶段发现短路，追溯回去发现是边界处两根线重叠了。返工的成本远大于跑一次全chip DRC的时间。

第六，团队协作时，沟通比技术更重要。并行修DRC涉及多人协作，每个人负责的块不同，但边界是共享的。如果两个人对边界的处理方式不一致，合并时必然出问题。我的做法是：在开始修复之前，先开一个短会，明确边界的处理规则，比如“边界处的绕线统一由左侧块负责修复”或者“边界缓冲区内的违例统一由组长处理”。

这套并行修DRC的方法，我在最近三个项目上都用过，平均能把DRC修复周期缩短40%到60%。当然，具体效果取决于design的复杂度和团队的熟练程度。但核心思路是不变的：合理切块、并行执行、谨慎合并、严格验证。

如果你正在被DRC修不完困扰，不妨试试这个思路。一开始可能会觉得麻烦，但一旦跑通一次，后面就是流水线作业了。