数字IC后端设计实战：ICC2自动修复绕线后Physical DRC的高效策略
1. 绕线后DRC问题：从“灾难现场”到“小菜一碟”
做数字IC后端的朋友，估计都经历过这个场景：费了九牛二虎之力，终于把时序（timing）调干净了，长舒一口气，准备收工。结果打开Error Browser一看，好家伙，几十上百个Physical DRC（设计规则检查）违例密密麻麻地躺在那里，瞬间血压就上来了。尤其是项目到了后期，Floorplan已经冻结，不可能再动，这时候看到一堆DRC，简直让人头皮发麻。
我刚开始干这行的时候，也特别怵这个。总觉得DRC是绕线工具没做好，得自己手动去修。后来踩坑踩多了才明白，能让工具自己干的活，坚决不要自己动手。手动修DRC不仅效率低，还容易引入新的时序问题，得不偿失。ICC2（或者它的前身ICC）提供了非常强大的自动化DRC修复能力，关键在于我们怎么去用好它。
首先，我们要对绕线后的DRC有一个正确的认识。看到几十个DRC，先别慌，这其实是件“好事”。为什么这么说？这说明你的设计利用率可能比较适中，工具在绕线时为了满足时序和拥塞（congestion）要求，做出了一些权衡，导致局部空间紧张产生了DRC。如果绕线后一个DRC都没有，你反而要警惕了：是不是设计太小了？或者面积利用率（utilization）太低了？工具可能为了“偷懒”而过度优化，牺牲了其他性能。
常见的绕线后DRC类型主要有这么几种：短路（Short）、不同网络间距违例（Diff Net Spacing）、同网络间距违例（Same Net Spacing）、线端间距违例（End of Line Spacing），在先进工艺下还有天线效应违例（Antenna）和双 patterning 相关的奇环违例（Odd Cycle）。我们的策略是，先看总量，再看分类，最后分析根源。
当你看到只有几十个DRC时，恭喜你，这属于“幸福的小烦恼”。你完全可以直接用这个数据库去提取寄生参数（RC extraction），生成SPEF文件，然后送到PrimeTime去做时序签核（timing signoff）。这些DRC交给工具自动修复就行，根本不需要你手动干预。我经手过的项目，几乎没有手动修过DRC，全是靠工具流程跑干净的。
2. 核心策略一：巧用route_opt的迭代次数
工具自动修复DRC，最直接、最常用的命令就是route_opt。但很多人只知道用，却不清楚里面的门道。route_opt命令有一个关键参数：-effort或者更具体地说，是它内部route_detail引擎的迭代次数。这个次数，直接决定了工具修复DRC的“决心”有多大。
默认情况下，route_detail引擎会运行40轮（iteration）。但它很智能，如果发现DRC数量降不下去了，它会提前退出。所以，我们第一步要做的，就是增加这个迭代次数，给工具更多“思考”和“尝试”的空间。
# 基础用法：启动route_opt进行优化和DRC修复 route_opt -effort high # 更精细的控制：单独对绕线进行优化，并增加DRC修复力度 route_opt -incr -only_design_rule但是，光增加route_opt的力度还不够。在项目后期，我们经常遇到的情况是，跑完一轮route_opt，大部分DRC修掉了，但总剩下那么几个“顽固分子”，反复迭代也消不掉。这时候，我们需要一个组合拳。我的经验是，采用“增量绕线优化 + 针对性引导”的策略。
首先，我会用以下命令进行一轮强力的、专注于DRC的优化：
# 专注于修复设计规则违例，对时序影响较小 route_opt -incr -only_design_rule -effort high这个命令告诉工具：“哥们儿，别太操心时序了（前提是时序已经基本干净），集中火力把这些碍眼的DRC干掉。”
如果这样跑完还有残留，特别是那些集中在某个拥挤区域的违例，我会检查绕线拥塞图。有时候，工具是因为全局拥塞而无法在局部腾出空间。这时，一个更激进的命令是：
# 允许工具进行更大幅度的布线调整，甚至可能轻微恶化时序来换取DRC的修复 route_opt -incr -effort high -max_drc_effort_level high这个-max_drc_effort_level high参数是个“大招”，它会显著增加运行时间，但也会让工具尝试更激进的布线调整，比如更大幅度地移动线缆（wire），甚至插入少量缓冲器（buffer）来绕开障碍。使用这个参数前，一定要确保时序有足够的余量（slack），并且做好备份，因为它可能会对时序产生意想不到的影响。
3. 核心策略二：使用Routing Guide进行“外科手术”
如果增加迭代次数效果不佳，特别是当DRC集中在几条特定的网络（net）上时，routing guide就是一个神器。它的思路很直观：告诉工具，在某个区域，某条线应该怎么走，给工具划个“重点区域”。
比如，你发现有一条很长的时钟线，因为绕了远路，和旁边的电源线挨得太近，产生了大量的间距违例。手动调整很麻烦，这时候就可以用routing guide。
首先，在GUI里或者用脚本抓取有问题的网络和区域：
# 示例：获取产生DRC的nets和它们的bbox（边界框） get_drc_violations -type {Spacing SameNet} # 获取特定类型的DRC set problem_nets [get_nets -of [get_drc_violations]] # 找到有问题的网络 foreach net $problem_nets { set bbox [get_attr [get_net_shapes -of $net] bbox] # 获取该网络形状的边界 # 创建一个略大于该bbox的guide区域 create_routing_guide -name guide_${net} -bbox $bbox -layers {M3 M4} -net $net }创建guide后，再次运行route_opt或route_detail：
route_opt -incr -effort high -use_guide true工具在优化时，会优先尊重你设置的routing guide，尝试在guide指定的层（比如上面的M3, M4）和区域内重新布线，从而避开DRC高发区。
这里有个实战技巧：不要一开始就创建guide。先让工具自由发挥跑一轮，看看它卡在哪里。然后针对这些“顽固点”创建小而精确的guide，再跑优化。这样效率最高。如果一开始就加很多guide，反而会束缚工具的手脚，可能让问题更糟。
4. 实战案例：项目后期无法修改Floorplan的紧急修复
现在，我们代入文章开头提到的场景：项目后期，Floorplan不能动，timing刚调干净，但出现了几十个Short和Spacing DRC。这时候该怎么办？
我的标准操作流程是这样的：
第一步：诊断与分类首先，用report_drc命令生成详细的DRC报告，并按类型和位置排序。用GUI高亮（highlight）这些违例，看看它们是分散的，还是集中在某个模块（block）或几条线周围。
report_drc -format summary > drc_summary.rpt report_drc -format detailed -violations > drc_detail.rpt如果发现是分散的零星违例，大概率用策略一（增加迭代）就能解决。如果发现是集中在几条长线或者某个拥挤的通道（channel）里，那就要考虑策略二（routing guide）。
第二步：执行自动化修复（策略一为主）我会先跑一轮保守但全面的修复：
# 备份当前绕线结果，非常重要！ save_block -as design_before_drc_fix # 执行高强度的增量绕线优化，重点攻DRC route_opt -incr -only_design_rule -effort high -max_drc_effort_level medium跑完后，立刻再报一次DRC，看数量变化。如果从50个降到5个，效果显著。如果只降到40个，说明工具遇到了瓶颈。
第三步：针对“顽固分子”进行手术（策略二）假设剩下的10个DRC，有8个都集中在一条数据总线和电源strap交叉的区域。我会这样做：
- 在GUI中框选这个区域。
- 找出穿过这个区域的所有网络（可以用
get_nets -within [get_selection]）。 - 为这些网络创建一个覆盖该区域的routing guide，并限制在较高的金属层（比如M5以上），因为高层金属通常布线资源更宽裕。
create_routing_guide -name guide_congested_area -bbox { {x1 y1} {x2 y2} } -layers {M5 M6 M7} -nets [get_nets -within [get_selection]] - 再次运行优化，这次启用guide：
route_opt -incr -effort high -use_guide true
第四步：最后的“杀手锏”脚本如果以上方法都试了，还剩下几个Short怎么也修不掉（这在超深亚微米工艺中偶尔会出现），我会祭出“通用脚本”。这个脚本的思路很简单粗暴，但非常有效：
- 用
get_drc_violations -type Short抓出所有短路的网络。 - 将这些网络上的绕线形状（wire shapes）全部删除（
remove_routing）。 - 对这些网络执行一次局部的、快速的ECO绕线（
route_eco）。
# 示例脚本片段（需根据实际情况调整） set short_nets [get_nets -of [get_drc_violations -type Short]] foreach net $short_nets { remove_routing -net $net } # 重新绕线被删除的网络 route_eco -nets $short_nets -effort high注意：这个方法有风险！删除绕线可能会暂时破坏时序。所以务必在操作前保存设计，并且在执行route_eco后，必须立即进行时序分析，确保没有引入新的违例。通常，工具在重新绕线时会尽量保持原有的拓扑结构，但对关键路径（critical path）还是有影响。
5. 不同DRC数量级的应对心法
根据我多年的经验，绕线后DRC的数量级直接决定了我们的应对策略和心态：
- 几十个DRC：这是“理想情况”。如前所述，直接让工具自动修复，然后可以准备时序签核。心态是轻松的。
- 几百个DRC：这需要引起重视。首先要分析原因。是局部拥塞爆炸了？还是某些宏模块（macro）周围的绕线通道（channel）太窄？如果是项目前期，可以尝试调整宏模块的摆放或优化电源网络（power mesh）。如果是项目后期，不能动Floorplan，那么核心思路就是“分而治之”：先用上述的guide方法隔离最严重的区域，再用自动化命令修复。同时，要密切监控时序，因为修复大量DRC可能会恶化时序。
- 几千甚至上万个DRC：这通常是前端设计或布局（placement）有严重问题的信号。比如标准单元（std cell）密度过高，或者物理约束（physical constraints）设置不合理。这时候，单纯靠后端绕线工具修是事倍功半的。必须回溯到布局阶段，甚至需要和前端工程师讨论设计结构。遇到这种情况，第一步不是慌，而是暂停自动化修复，先做根本原因分析（Root Cause Analysis）。
6. 高级技巧与避坑指南
除了上面两大核心策略，还有一些实战中的小技巧和需要注意的“坑”：
技巧一：分层修复（Layer Promotion）对于间距违例，特别是同层金属（same layer）的间距问题，可以尝试允许工具将线“提升”到更高层金属去绕。高层金属间距规则通常更宽松。可以在route_opt中设置：
set_route_options -groute_allow_layer_change true route_opt -incr -effort high技巧二：利用ZRoute引擎ICC2的ZRoute引擎在修复复杂DRC方面比传统的基于网格（grid-based）的引擎更强大。确保你在使用较新的版本，并启用了ZRoute：
# 检查并设置绕线引擎 get_route_options set_route_options -zroute true route_opt -incr避坑指南一：修复与时序的平衡DRC修复和时序收敛（timing closure）永远是一对矛盾。在项目后期，我们的原则是“在保证时序签核的前提下，尽可能修复DRC”。因此，每执行一轮DRC修复，必须紧跟一轮时序分析（report_timing）。我习惯写一个Tcl脚本来自动化这个循环：
set max_iter 5 for {set i 0} {$i < $max_iter} {incr i} { route_opt -incr -only_design_rule -effort high report_drc > drc_iter$i.rpt # 检查关键路径时序是否恶化超过阈值 report_timing -max_paths 10 > timing_iter$i.rpt # 如果时序恶化严重，则回退到上一步保存的设计 if {[check_timing_degradation timing_iter$i.rpt]} { load_block design_before_iter$i break } save_block -as design_after_iter$i }避坑指南二：注意天线效应修复天线效应（Antenna）违例的修复比较特殊。工具通常通过插入二极管（diode）或者跳层（layer hopping）来解决。在后期修复中，插入二极管可能会带来面积和漏电（leakage）的微小增加，需要评估。确保route_opt命令中包含了天线修复选项：
route_opt -incr -effort high -antenna true避坑指南三：与物理验证工具的联动有时，ICC2内建的DRC检查与签核用的物理验证工具（如ICV或Calibre）的规则略有差异。为了确保万无一失，一个高效的方法是：将ICC2数据库导出，用物理验证工具快速跑一个DRC，然后把违例位置反馈给ICC2，用read_physical_verification_results命令读入，再针对这些位置进行精准修复。这能避免在ICC2里修了半天，到Calibre里还是报错的情况。
最后我想说，数字后端设计就像一场马拉松，而绕线后修DRC就是最后几公里。体力（工具算力）和策略（经验方法）同样重要。看到DRC别头疼，把它当成一个优化设计、加深对工具理解的契机。我自己的习惯是，每次修完一个棘手的DRC问题，都会简单记录下场景和命令，积累多了就成了自己的“武器库”。工具在迭代，工艺在进步，但解决问题的思路是相通的——分析根源，善用自动化，敢于尝试，谨慎验证。希望这些实战中的土办法和正经策略，能帮你更从容地应对下一个项目的DRC挑战。