1. 当DRC修不完成为常态我们该怎么破局做数字后端这行的估计没人没被DRC折磨过。尤其是到了项目后期timing已经收敛得七七八八功耗也压得差不多了结果打开Calibre或者PVS一跑满屏的DRC violation像蚂蚁一样爬满了报告。你盯着那个数字——几千甚至上万条——心里只有一个念头这得修到什么时候我做了十多年后端从28nm一路做到5nmDRC这个问题从来没有真正“轻松”过。每次到了修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 手动修复的优先级策略自动修复跑完之后每个块里还会剩下一些“硬骨头”。这时候就需要手动修复。手动修复要有优先级不能眉毛胡子一把抓。我的优先级排序是Short和Open这两类违例直接影响功能必须最优先修复。Min Area和Min Width这类违例影响良率优先级次之。Spacing和Enclosure这类违例数量最多但影响相对较小可以批量处理。Density和Antenna这类违例通常在最后阶段统一处理。在Innovus里可以用verifyDRC -type来筛选特定类型的违例然后集中修复。# 只查看Short类违例 verifyDRC -type short -report ./drc_reports/${blk}_short.rpt # 只查看Spacing类违例 verifyDRC -type spacing -report ./drc_reports/${blk}_spacing.rpt3.4 计算资源的分配与调度并行修DRC需要计算资源。如果你有LSF或者SGE这样的集群调度系统可以直接把每个块的修复任务提交上去。# 提交4个块的修复任务到LSF集群 for blk in block_ll block_lr block_ul block_ur; do bsub -n 8 -R rusage[mem32000] -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 边界违例的常见类型与修复方法边界违例主要有以下几种违例类型产生原因修复方法Spacing两个块的绕线在边界处间距不足调整其中一根线的路径或者增加间距Enclosurevia在边界处被切断导致覆盖不足在边界处补全via或者移动via位置Min Area边界处的金属面积被切分后不足合并后重新计算面积必要时补patchShort两个块的绕线在边界处短路检查net连接删除冗余绕线修复边界违例时我一般会先把边界区域的绕线单独提取出来在一个小范围内集中修复避免影响已经修好的块内部。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_BLOCK5.5 常见问题速查表问题现象可能原因排查方法解决方案切块后DRC增多边界效应对比切块前后的DRC报告优化切块边界合并阶段统一处理自动修复无效规则复杂/资源不足查看ecoRoute日志手动筛选规则先rip-up再修复合并后Timing恶化绕线改动过大对比修复前后的timing报告限制修复范围优先保护关键net数据冲突net分配不明确检查net assign记录切块时明确net归属合并后LVS失败边界连接错误查看LVS报告中的open/short检查边界net连接补全被切断的绕线6. 一些实操心得和避坑建议说了这么多方法论和脚本最后分享几个我在实际项目中总结出来的心得。第一切块不是越细越好。我早期做过一个项目为了追求并行度把chip切成了20多块。结果合并阶段花了整整三天边界违例修了又修最后整体时间比不切块还长。后来我总结切块数量控制在4到8块之间是最优的超过这个范围合并成本会吃掉并行带来的收益。第二一定要保留切块前的完整备份。并行修复过程中如果某个块出了问题你需要能够回退到切块前的状态。我习惯在切块前把整个design打包备份包括所有的脚本和报告。这个习惯救过我好几次。第三边界缓冲区的违例要单独建一个报告。不要把边界违例和块内违例混在一起。单独建报告的好处是合并阶段可以快速定位边界问题不用在几千条违例里翻找。第四并行修复期间不要改工艺文件。如果切块用的DRC规则和合并后用的规则不一致那合并后的验证结果就没有意义了。所有块必须使用完全相同的DRC runset。第五合并后的全chip DRC一定要跑。不要因为时间紧就跳过这一步。我见过一个项目合并后直接signoff结果在封装阶段发现短路追溯回去发现是边界处两根线重叠了。返工的成本远大于跑一次全chip DRC的时间。第六团队协作时沟通比技术更重要。并行修DRC涉及多人协作每个人负责的块不同但边界是共享的。如果两个人对边界的处理方式不一致合并时必然出问题。我的做法是在开始修复之前先开一个短会明确边界的处理规则比如“边界处的绕线统一由左侧块负责修复”或者“边界缓冲区内的违例统一由组长处理”。这套并行修DRC的方法我在最近三个项目上都用过平均能把DRC修复周期缩短40%到60%。当然具体效果取决于design的复杂度和团队的熟练程度。但核心思路是不变的合理切块、并行执行、谨慎合并、严格验证。如果你正在被DRC修不完困扰不妨试试这个思路。一开始可能会觉得麻烦但一旦跑通一次后面就是流水线作业了。