做数字IC后端PR的人十个有九个被short短路虐过。白天跑完route晚上打开Innovus或者ICC2的DRC报告一眼扫过去全是short坐标密密麻麻几百个心态直接崩。这活儿看着不大但处理起来特别磨人手工在GUI里一个个拆线、找原因、改线宽、绕线运气差的话一晚上都耗在上面。而且越是到项目末期floorplan已经基本定型可用资源越来越少short就越容易反复出现。这篇东西主要讲我在实际项目中用Innovus和ICC2修复short的经验。我会从short的产生原因开始讲到两个工具各自适合的自动化修复流程再把报告解析、局部ECO、批量脚本这些环节拆开揉碎顺便把踩过的坑也一起列出来。适合正在做数字IC后端PR、被route后short搞得头疼的工程师尤其是刚接触Innovus或ICC2、想跳过一些弯路的新人。1. 为什么short是PR阶段最头疼的“拦路虎”1.1 short到底是什么以及它在EDA工具里长什么样short字面意思就是两条本不该相连的金属线连到了一起。在详细布线阶段工具会沿着track布线理论上每条net都有独立的route路径但由于局部congestion、pin access冲突、via打滑、甚至floorplan上某个macro旁边的绕线空间太小工具就可能把两根net的金属线段挤到同一个位置造成电气上短路。在Innovus和ICC2的报告里short一般会标注出坐标、layer、涉及的net名称以及一个“short bounding box”或者“DRC violation区域”。比如Innovus的verify_drc报告里会出现类似“SHORT: M4 area: (12.345, 6.789) to (12.555, 7.001), net: clk_net_123 vs data_net_456”这样的记录。ICC2的check_routes输出也类似但格式略有不同通常会给出一个violation ID以及两条net的名字。值得注意的是short不只有“net对net”这一种。还有一种常见情况是同一根net内部的segment互相搭叠导致形成loop或者power/ground的rail和signal metal连在一起这种已经不是普通ECO能解决的得去查PG规划。所以修复之前先搞清楚short类型千万不要一上来就乱拆线。1.2 产生short的根本原因工具的前提假设太乐观了很多工程师会遇到一个现象同样的block用Innovus跑出来short有20个用ICC2跑出来可能只有5个或者反过来。这并不代表某个工具一定差而是两个工具的global routing和detail routing算法对congestion的预估不一样。从根上讲short高发区通常集中在几种场景一是block边缘靠近hard macro的地方绕线通道被pin access和fixed cell夹得很窄工具到了detail route阶段才发现实际可用track不够二是clock tree绕线密集区尤其是useful skew或者balance做得很紧的区域clock net会占用大量高层metal挤压了信号线的通道三是bump region / IO区域电源地mesh和信号线叠在一起经常出现M5/M6层的short。我的理解是global route阶段工具拿的是resource estimation它觉得这块区域能塞下这么多线但到了detail route阶段实际要考虑线宽、spacing、min area、via enclosure等一堆rule真实可用空间比预估缩水了。于是short就像一个泄压阀所有被压扁的绕线需求都从那里冒出来。1.3 手工修复和自动化修复的核心差异手工修short本质上是“拆掉缠在一起的耳机线再一根根理清”。你可以选中一条net删掉局部route手动编辑绕线路径绕过另一个net。麻烦在于一个block几百个short人肉去弄不仅慢而且很容易顾此失彼修好这个又弄坏了那个。自动化修复的思路则是让工具基于DRC反馈自动对short区域执行局部拆线、重新绕线甚至调整附近cell的位置或绕线阻塞。常见做法有三种一是让工具自带的detail route / ECO route去自动修正二是通过脚本解析报告批量对short涉及的区域做局部reroute三是用routing blockage或cell padding把“事故高发区”的资源释放出来让工具绕开。真正干活的时候这三种方式往往要组合着来。先跑一轮自动修复看看能不能压到个位数剩下的再单独看报告、定点解决。接下来我会把两个工具的具体操作拆开来讲。2. 全流程准备数据、设置与DRC检查2.1 动手修short前先把数据和环境确认到位很多同事一看到short报告就直接在Innovus里敲ecoRoute这个习惯很不好。我踩过几次坑之后现在固定了一套准备动作先花10分钟确认环境和数据后面能省出好几个小时。首先要确认当前design是route之后、且所有floorplan和placement的改动都已经固定下来了。因为修short本质上是在“已经布的线上做局部手术”如果后续还要改floorplan或者挪macro那这些修复大概率会失效等于白干。其次是确认库和techfile没有问题。Innovus环境里要确认已经读入了完整的MMMC view典型情况是setup和hold两个view以及先进的metal layer定义、via rule、min area rule都来自统一的techfile。ICC2环境里要检查design library创建时是否用了正确的ref lib和qrc techfile。如果库里signoff用的DRC rule deck和PR工具内部用的route rule不一致修出来的short可能是“工具眼里修好了Calibre眼里照旧”。最后是保存checkpoint。Innovus用saveDesignICC2用write_lib / save_block。建议在保存时加上时间戳比如saveDesign block_route_short_fix_start.enc方便万一修坏了回退。2.2 如何准确跑出short报告两个工具的命令差异Innovus里查short最直接的方式是跑verify_drcverify_drc -report innovus_drc.rpt -limit 10000 -noEco这个命令会输出所有DRC violation其中就包含short。加-limit是为了让报告先覆盖一部分如果short数量巨大limit太小会漏掉后面的但也不要一股脑把几十万条全打出来文件太大反而不好解析。通常我习惯先设10000跑一遍如果报告显示“number of violations exceeds limit”再加大。ICC2里对应的命令是check_routes -type short -out_file icc2_short.rpt-type short可以只过滤出short这样报告文件里全是需要处理的对象解析起来清爽很多。ICC2还有更细的选项比如-type {short open}同时查两类也可以配合-layers只查特定metal但一般不建议一上来就限层容易漏掉跨层short。跑完后打开报告重点关注三个信息坐标、layer、net name。Innovus报告里的坐标通常是“M4 area: (x1, y1) to (x2, y2)”格式ICC2则可能给一个polygon或者point list。不管哪种格式核心是拿到一个“short发生的最小包围盒”后面局部ECO要用的就是这块区域。2.3 报告解析别用眼睛硬扛写个脚本分类第一次看到几百条short报告时很多人会选择导入GUI里高亮查看。但几百条高亮叠在一起五颜六色根本看不清反而浪费时间。我自己习惯的做法是先把报告按layer和坐标聚个类。常用的是Tcl脚本或者直接在工作目录里用grep/awk先粗筛一遍grep SHORT innovus_drc.rpt | awk {print $2} | sort | uniq -c | sort -rn这样能快速知道short集中在哪一层。比如发现M5层有80个shortM2层只有3个那问题大概率出在M5的routing channel规划上可以优先处理M5相关区域而不是对M2那3个小short花太多精力。ICC2的报告也可以用类似方式处理。解析完后建议大家把结果整理成一个简单的CSVnetA、netB、layer、x_min、y_min、x_max、y_max、violation_id。后面写自动修复脚本时直接读这个CSV就行比每次重复解析原始报告快得多。3. Innovus自动化修复short的实战方法3.1 先让NanoRoute“自己洗一遍”自动ECO思路Innovus底层的布线引擎是NanoRoute在修复short这件事上它自带一套比较实用的局部ECO机制。我的通用流程是先不手工干预直接跑一轮globalDetailRoute让工具自己对short做一次修正setNanoRouteMode -routeWithTimingDriven true setNanoRouteMode -routeWithSiDriven true setNanoRouteMode -drouteEndIteration 20 globalDetailRoute跑完之后再verify_drc看一遍short数量。如果是比较温和的congestion问题这一轮往往就能消掉一大半short。这里有个细节值得注意drouteEndIteration这个参数控制detail route的迭代轮数设置太大会让运行时间爆炸设置太小小case可能处理不到位。20轮是我从很多block上试出来的一个折中值供参考。如果一轮globalDetailRoute之后short还剩下不少说明局部区域已经“病入膏肓”单纯全局洗一遍没用需要针对具体net做定点修复。3.2 定点修复deleteRoute ecoRoute的局部外科手术定点修复的核心思路是对short涉及的net把局部route拆掉然后让工具重新绕。Innovus里我常用的组合是deleteRoute和ecoRoutedeleteRoute -nets {data_net_456} ecoRoute -net data_net_456但直接删整条net有个风险如果这条net本身布得很好只是在一个局部和别的net打架删掉整条net等于让它“推倒重来”可能会引发新的congestion或时序问题。所以更精细的做法是先选中short的那个 bounding box只删掉这个区域内的routing segmentset box {12.345 6.789 12.555 7.001} deleteRoute -box $box -nets data_net_456 ecoRoute -box $box -net data_net_456这里-box参数限定范围只拆掉short区域附近的线工具重新绕线时也只在附近找路影响面小得多。用这种“手术刀式”的修复基本上能把单个short的影响控制在很小范围。但要注意deleteRoute之后ecoRoute不保证一定能绕开有些net在局部就是无路可走。如果你发现某个net反复在同一坐标区域修不好那就别再死磕这一条线了先看看周边有没有spare cell可以挪走、有没有blockage可以调整或者上层/下层通道能否利用。3.3 批量自动化解析报告后循环修short单个short手工修还行几十个上百个就得靠脚本了。我自己的自动化框架大概长这样第一步verify_drc生成报告用Tcl正则把short信息提取出来set fh [open innovus_drc.rpt r] set short_list {} while {[gets $fh line] 0} { if {[regexp {SHORT: (\S) area: \(([0-9.]), ([0-9.])\) to \(([0-9.]), ([0-9.])\), net: (\S) vs (\S)} $line match layer x1 y1 x2 y2 netA netB]} { lappend short_list [list $layer $x1 $y1 $x2 $y2 $netA $netB] } } close $fh第二步对每个short区域做局部ECO。但这里有个巨大的坑如果几百个short同时处理工具并行绕线时可能互相干扰修了A又造成B。所以我的策略是分层分批每批最多处理20到30个short修完一批就跑一次verify_drc确认没有新增再进下一批set batch_size 20 set count 0 foreach short_info $short_list { set x1 [lindex $short_info 1] set y1 [lindex $short_info 2] set x2 [lindex $short_info 3] set y2 [lindex $short_info 4] set netA [lindex $short_info 5] set box $x1 $y1 $x2 $y2 deleteRoute -box $box -nets $netA ecoRoute -box $box -net $netA incr count if {$count % $batch_size 0} { verify_drc -report check_batch_$count.rpt -limit 10000 -noEco } }这个脚本的核心逻辑其实很简单解出坐标拆线重绕验证。真正干活时需要根据报告格式调整正则表达式不同Innovus版本输出会略有差异但思路是通用的。3.4 影响范围分析修short有没有引入新问题修short最大的风险不是修不好而是修好了short却弄出了open或者把timing搞坏了。所以在每轮批量修复之后除了查short数量还要顺手看一眼open和DRC的变化。Innovus里可以这样一起查verify_drc -report drc_after_fix.rpt -limit 100000 -noEco verifyConnectivity -type all -noEco如果发现open增多多半是deleteRoute时把不该删的segment也删了或者ecoRoute重新绕线时没接上。遇到这种情况可以把open的net也放进下一轮ecoRoute里让工具补线。时序的话如果修short的过程中删了关键net的线重新绕线可能路径变长。所以项目后期我一般会在修short之后跑一轮快速时序检查至少看看setup/hold有没有致命violation别等到signoff才发现。4. ICC2自动化修复short的实战方法4.1 ICC2的short检查与报告格式ICC2的思路和Innovus不完全一样但检查环节很直观check_routes -type short -out_file icc2_short.rpt跑完后报告里会有每一条short的具体信息。ICC2的violation格式通常会带一个violation ID然后列出坐标、layer、netA/netB还可能包括涉及的instance pin。比如VIO-12345 SHORT M5 (10.20, 20.30) (10.50, 20.60) net: clk_buf_inst/Z vs data_net_78解析的时候除了net name建议把violation ID也记下来因为后面用ICC2命令修复时有些版本支持直接按violation ID操作比按net名更精确。4.2 ICC2的自动修复route_eco与refine_routeICC2里修short最直接的工具是route_eco。它的一个优点是可以直接对short做出响应route_eco -cleanup_short这条命令会让工具自动扫描short并尝试清理。如果你的库和block规模不大跑一条route_eco -cleanup_short往往就很有效。它内部会拆开short的route重新绕尽量避免影响其他net。如果short比较顽固可以加-reroute_nets_for_timing之类的选项让它在修short的同时兼顾时序但代价是runtime会明显增加。我一般只在short和目标net时序都很紧的情况下才加这个选项。还有一种更“暴力”的方式就是先手动拆线再重绕remove_routes -nets [get_nets $net_name] -detail_route route_eco -nets [get_nets $net_name]不过这个操作跟Innovus里deleteRoute ecoRoute一样尽量别拆整条netICC2里可以先获取short包围盒再用remove_routes配合-bbox参数局部拆线set bbox [list $x1 $y1 $x2 $y2] remove_routes -nets [get_nets $net_name] -bbox $bbox -detail_route route_eco -nets [get_nets $net_name] -bbox $bboxICC2的route_eco在局部重绕时会调用整个绕线资源计算比Innovus的ecoRoute更谨慎一点但run time也更长。如果short数量很多建议一样采用分批处理策略。4.3 ICC2批量修复short的Tcl框架ICC2批量修复其实和Innovus框架很像核心就是四点解析报告、聚合short、分批修复、循环验证。下面是一个简化的批量处理框架set short_nets {} set fh [open icc2_short.rpt r] while {[gets $fh line] 0} { if {[regexp {VIO-\S\sSHORT\s\S\s\(([0-9.]), ([0-9.])\)\s\(([0-9.]), ([0-9.])\)\snet:\s(\S)\svs\s(\S)} $line match x1 y1 x2 y2 netA netB]} { lappend short_nets $netA lappend short_nets $netB # 也可以按坐标保存这里先省略 } } close $fh set short_nets [lsort -unique $short_nets] foreach net_name $short_nets { route_eco -cleanup_short -nets [get_nets $net_name] check_routes -type short -out_file check_${net_name}.rpt }这里有个小细节把netA和netB都放进列表里是为了防止只修一条net导致另一条仍然悬空。不过当你对netA做route_eco时netB通常也会被自动避让所以实际执行时可以减少重复操作只对“对应short区域更主动的一方”下手。具体哪方主动我会看哪条net更长或更critical——短的那条更容易绕优先动它。4.4 Innovus和ICC2修short的思路差异对照两个工具在修复short上的能力差异不是“谁好谁差”而是处理方式不一样下面这张表是我从实际项目里总结的对比项InnovusICC2查short命令verify_drc -reportcheck_routes -type short自动清理globalDetailRoute / nanoRoute ECOroute_eco -cleanup_short局部定向修复deleteRoute ecoRoute -boxremove_routes -bbox route_ecorun time通常较快适合大批量迭代相对更重建议分批报告格式text正则提取较方便text带violation ID适合场景short数量多、block规模大局部顽固short、timing敏感block说到底两个工具都可以自动化修复short关键是找到适合自己项目的“修复-检查-再修复”循环。如果你对Innovus更熟就先用Innovus修个七八成剩下用ICC2补反过来也行。5. 实操总结、常见坑与排查记录5.1 修short时最容易踩的5个坑第一个坑不做快照就动手。修short的ECO操作是不可逆的尤其是deleteRoute这种拆线动作一旦拆了发现修不回来连原始布线都没了。所以开工前务必saveDesign或者write_lib最好留两个快照一个是修复前一个是第一轮修复后。第二个坑只看short不查open。删线重绕很容易引入open而且open比short更隐蔽因为有些open藏在via里GDS上看着连上了实际没连。所以修复循环里一定要加上verifyConnectivity或者类似检查。第三个坑忽略设计规则耦合。先进工艺下short修复可能和double patterning、metal tip-to-tip、same net spacing等规则耦合。你修好了一个M5 short但重新绕线后M5到M5的space不满足另一条ruleDRC总数反而不降反升。遇到这种情况不要死磕工具先回归到floorplan或者routing guidance。第四个坑把所有short都交给自动ECO。工具不是万能的。一个block里如果有50个short分布在不同的congestion hotspot自动ECO可能修好30个剩下20个怎么都修不完。这时继续重复跑globalDetailRoute只会浪费时间正确做法是打开GUI定位剩下的区域手动观察为什么绕不过去可能是一个memory旁边的通道被堵死了。第五个坑忽略power/ground short。如果报告里short涉及VDD/VSS别按信号short修。这种往往不是绕线问题而是PG mesh规划漏了或者是某个power switch cell pin access失败。直接用ECO删线会越搞越糟要回到powerplanning阶段去查。5.2 顽固short的排查思路如果经过多轮自动修复某些short还在原地我建议按下面的顺序排查先看坐标附近有没有hard macro。Hard macro的blockage边界可能不完整导致工具误认为这里有绕线空间实际到了macro边缘就被pin和obstruction挡住。可以在macro周围加一个小的soft blockage或routing halos把工具“扫”出去。再看是不是有repeater buffer或者hold buffer插得过于密集。有时候修timing时插了一堆buffer占掉了本应给绕线用的track这就是为什么修完timing再回头跑routeshort会一下子多起来。这种情况可以适当做legalization/padding把这些buffer分散开。然后查一下short关联的net里有没有特殊net比如clock或者reset。特殊net通常有guide和shielding绕线自由度很低。如果short和clock net有关不要硬拆先去adjust clock routing, 或者把clock net转成non-fixed让工具重新分配路径。最后如果所有手段都试过了short还是消不掉那就是底层routing资源真的不够了。这时要回到floorplan看看能否挪出一个标准单元、调整某些macro位置或增加routing layer。短期先用route blockage让工具绕开这个区域留到下一版floorplan再根治。5.3 一点实战心得先看类型再选择修法我现在拿到short报告第一件事不是敲命令而是把short分成三类一类是分散、数量少、发生在空旷区域的short这类直接局部拆线重绕即可风险最小。一类是密集抱团、集中在某个区域的一簇short这种基本是congestion爆表正确做法是调整blockage、spare cell或floorplan而不是挨个修。还有一类是和clock、power相关的short这种要回到source层去修不能光在route上做文章。分类之后再去决定是用Innovus还是ICC2用全局route还是局部ECO。说实话很多项目里80%的short都是congestion类型剩下的20%才需要真正的“手术”。如果一上来就把所有short都当作孤立的DRC去修那真会把人累死。修short这件事干多了你会发现本质上考验的不是工具熟练度而是对design的理解。工具只是执行者真正决定short能不能修干净、修了之后稳不稳的是你对congestion、floorplan、特殊net和物理规则的理解深度。希望这些实战经验能让大家少熬几个夜。
