“做数字后端的人最怕听到的反馈就是Innovus跑完布线之后DRC报出一堆Metal Short天线效应Antenna EMC也冒出来几条甚至还有几十个net因为route不完整挂着partial conflict。这种时候新手喜欢一条一条打开layout去手修老手则是先把报告分类、分区、排优先级再决定是手动修线还是直接上ECO。”这段话几乎是我每次做DRC cleanup时的真实写照。接下来我就按实际项目里的做法把Innovus DRC修复的全流程拆开讲一遍重点集中在Metal Short和天线效应这两类高频violation上最后分享几个ECO路由的实用技巧和对应的排查经验。这套方法无论是刚入手数字后端、正在跑Innovus流程还是已经碰到DRC爆表但不知道怎么系统处理的同学都能直接拿来参考。修DRC本身不是什么高深技术难就难在“别把一个问题修成三个问题”。所以在动手之前先把整体思路理顺。1. 拿到DRC报告先别乱动分类、分区、分优先级1.1 把DRC按修复方式拆成四类才能对症下药DRC violation在Innovus里少说也有几十种类型但站在修复方法的角度我可以把它们收敛成四类Metal Short类不同net的金属走线短接在一起或者power/ground跟信号线短接这类问题通常需要删线、推线、换层、重新绕线来解决。Antenna/EMC类长金属线在制造工艺中积累电荷威胁到栅氧化层这类问题靠跳层断线、插antenna diode或插buffer处理。Spacing/Min Area类线间距不足、金属面积太小、via覆盖不够等这类一般是局部congestion严重或者绕线质量差导致的推线或调整绕线约束就能解决。其他工艺相关类比如slot rule、metal density、特殊层次规则等这类往往不是靠改线能解决的需要回到floorplan或power mesh阶段去看。我见过很多新人拿到report后不管三七二十一就从第一条violation开始修。这是效率最低的做法。因为不同类型的DRC背后原因完全不同short更多是routing congestion的问题antenna是信号完整性和工艺问题min area很多时候是绕线空间的“副产品”。混在一起修很容易把时间浪费在越修越乱的道路上。1.2 先分类再分区我给修DRC定的三条“军规”我给自己定了三条规矩可以说这几条帮我在多个项目里少熬了无数个夜。第一条动手前必须有baseline。不管DRC当前是几条还是上千条先跑一遍verify_drc把报告存好。这份baseline的作用不只是看个数更是为了在修完一轮之后对比——是变好了还是变差了。如果修完一轮short从50条变成了80条那说明手法有问题得停下来看是不是某个操作把线引到了更拥挤的区域而不是继续修下去。第二条按坐标分区不要全chip乱跑。我看到报告后第一件事是把violation的坐标拉出来在GUI里按区块高亮。通常DRC密集的区域就是绕线congestion严重的区域或者floorplan里面有硬核hard macro摆放不合理的地方。按区域处理可以更集中地观察问题根源而且修完一个区域后工具重新绕线不会影响远端的其他net。我一般在Innovus GUI里面把整块布局按block或者partition分开看哪边violation多就先处理哪边。第三条优先修“次级伤”而不是“硬骨头”。先把那些零散的min area、spacing类violation清理掉因为这些往往意味着某些区域绕线太挤。把这些小问题清掉之后short和antenna的数量往往也会跟着下降。原因很简单绕线空间变宽敞了工具在局部重新走线的时候就不会再东挤西挤。这三条“军规”听起来朴素但执行起来需要自律。尤其是看到报告一大堆、心里着急的时候最容易跳过分类直接开修。真出现这种情况通常修到后面会发现自己变成了“DRC消防员”——这边刚扑灭那边又着起来。2. Metal Short修复从定位三板斧到清理闭环2.1 定位Short三板斧报告坐标、DRC Marker、网络高亮Metal Short是所有DRC issue里最扎眼的存在因为它的数量往往最多而且一多起来整个chip的short列表能拉好几屏。定位short的方法我依赖三样东西。第一是DRC报告里的坐标信息。Innovus的verify_drc报告会给出每个violation所在层次、坐标以及涉及到的net名称。这一行信息包含了最基本的定位依据。比如一个M2层上的short坐标在某个区域报告里通常写着两个net的名字。先靠这个建立起第一印象。第二是GUI里的DRC Marker。在Innovus的GUI里打开DRC marker之后版图上会出现各种颜色的标记short一般有固定的marker颜色直接点击marker就可以看到violation的bounding box和具体层次。很多经验丰富的工程师习惯直接在GUI里圈选一片区域把short marker显示出来然后从视觉上判断短接发生在哪里。这个非常有直观感因为金属short的位置往往一眼就能看出来比如两条线本该平行走结果有一段靠得特别近甚至有了重叠区域。第三是网络高亮工具。用命令行或者GUI把涉及short的两个net分别高亮成不同颜色然后观察它们在哪里发生了物理接触。这一步是最终确认。我习惯用gui_highlight或类似命令将两个net分别标记出来同时把底层单元、power mesh等层次半透明化从而看到真正短接的细节位置。三板斧用完之后基本就能确定这个short是“哪根线碰到了哪根线”、“在哪个层次”、“大概是什么原因引起的”。2.2 高频Short成因与对应解法含Power/ground shortMetal Short的成因我在这几年项目里遇到过的主要有下面几种。每一种的修法其实不太一样。第一种同层信号线之间的short。这是最常见的典型场景是在congestion严重的区域两条信号net被工具挤到了一起M2或M3上贴得过近甚至直接碰上了。处理办法是删掉其中一根线的部分线段然后让工具重新绕。先判断哪根线更重要、哪根线较短或更不critical优先保留关键路径上的net。把不太重要的那根线删除或者往旁边推一个track再走线。第二种Power/ground与信号线的short。这个比信号线之间short更麻烦因为power/ground网络一般是整片mesh不能随意移动。如果一条信号线捅进了power ring里面或者某个via打在power stripe上常规办法是让信号线绕开power线走更远一圈的路径。如果绕不开可能需要调整power mesh的宽度或者局部轨道但这个动作牵扯比较大需要跟chip level的人确认。第三种Via相关的short。有时候问题不在trench metal上而在via上。打个比方一个M3到M2的via如果打在另一根M1线上就可能造成跨层short。这种问题用DRC marker看得很清楚修复时需要重点检查via位置是否真的合法必要时把via挪到一个没有冲突的位置或者把下面那层线稍微调整一下。前面那句“修完一根线另一根线又short”的情况也很常见。这是因为局部congestion太高工具在重新走线时为了绕开原来的short位置把线引到了另一个地方结果又碰到了新的net。所以修short不能只看单点要结合整块的绕线密度来判断。2.3 修Short的标准动作和避坑清单这里给出一套我在项目里反复使用的标准动作按顺序走下来大多数short都能被干净地清掉。第一步先用报告和GUI定位short涉及的net并确认是在哪个层次。第二步在GUI中高亮两个net看清楚短接的具体线段。第三步选中短接的wire通常是一段很短的水平或垂直走线用删除wire的命令删掉它。第四步把删除线段后原来net断开的两端接回去最直接的方式是选中该net在局部区域使用ECO路由工具重新绕线。绕线范围控制在short附近不要触发全chip重新绕线避免影响其他走线。第五步跑一轮增量DRC检查验证这个short是否消失然后继续处理下一个区域。说起来简单但实际执行中有几个坑我踩了很多次这里重点提醒一下。避坑一不要为了修short把线拉得特别长。曾经有个项目我为了绕开一个M4的short把时钟线绕了大半个blockshort是没了但timing瞬间差了几百ps。最后花了大半天才把线路调回来。现在我的原则是如果一条线绕行太远才能避开short那就应该考虑让另一根线让路或者直接看看有没有可能通过换层解决而不是硬绕。避坑二删线之后一定要确认相邻net完全断开不只是视觉上断开。Innovus里有时候会出现两个net仍然共享一段wire的情况。检查这种问题的方式是确认每个net的wire是否各自独立用高亮看到两个net同时在某个线段上有颜色就说明删除不彻底。需要进一步把那一段wire也清掉再重新走线。避坑三注意metal short修复和antenna修复之间的冲突。这两个问题是会互相打架的。比如某根长线你为了让信号线绕开short而把它换到更高层走结果这根线的天线面积变大了又报了antenna violation。所以修short的时候脑子里得同时想着antenna规则尽量让绕线后的走线分布合理不要单层拉出超长距离。3. 天线效应Antenna EMC的检查与修复3.1 天线效应到底怎么来的等离子刻蚀下的一场“静电事故”Antenna effect天线效应是芯片制造过程中的一个可靠性问题不是说芯片跑起来之后发生的而是在制造时就已经埋下隐患。芯片制造过程中金属层是通过等离子刻蚀等工艺形成的这个过程中金属线会像一根天线一样收集等离子体中的电荷。如果某根金属线直接连接到晶体管的栅极而电荷积累到一定程度又没有泄放通路就可能击穿栅极氧化层gate oxide导致晶体管失效或者性能退化。我在跟人解释antenna效应时喜欢用一个类比就像你在干燥的冬天穿毛衣手去碰金属门把手会被静电“啪”一下电到。如果静电足够强就可能把某个脆弱的电子元件打坏。芯片制造过程中的等离子体环境比毛衣摩擦环境的静电强得多金属线就是那根“放电的手指”栅极氧化物就是那个“脆弱的元件”。制程工艺里衡量天线效应风险有一个核心指标叫antenna ratio简单说就是连到栅极的金属面积和栅极氧化层面积的比值。antenna ratio超过工艺规定的阈值violation就成立了。阈值跟工艺节点、金属层都有关系先进工艺尤其严格。需要说明的是不同的DRC报告里天线效应的标识可能不太一样有的叫Antenna EMC有的叫ANT本质上都是同一类问题。用户在Innovus的DRC报告或者verify结果里看到这些词汇可以统一按antenna violation来处理。3.2 布线阶段预防与事后检查NanoRoute里的Antenna选项修天线效应最好的办法是在布线阶段就避免它产生。Innovus的NanoRoute引擎支持在绕线时做antenna-aware routing这是最省事的一道防线。我一般会在跑详细布线之前把antenna修复相关的选项打开让工具在绕线的时候自动考虑金属线连接方式和层次选择尽量避免在敏感栅极上堆积过大的金属面积。具体操作上可以通过setNanoRouteMode打开对应的antenna修复选项然后跑详细布线。这是一个很关键的前置动作因为它能在源头减少大量天线violation。如果项目比较早期最好在route之前就明确这些选项是否开启不要等到DRC报告出来了一堆天线问题才开始改。布线完成之后还需要做一次专门的天线检查。这个检查手段跟平时跑DRC不太一样它是基于天线规则文件来计算的关注的是每根金属线对栅极的charge收集情况。如果发现了违规net报告里会列出层次、坐标以及对应的天线比。对于自动修复没处理干净的violation就要靠下面三种手段来手动收尾。3.3 跳层、加二极管、插Buffer三种修复手法的选择逻辑天线效应的修复逻辑本质上是“要么减少电荷收集要么提供泄放路径要么断开长金属线上的连续天线结构”。基于这个逻辑我常用的修复手法有三种。第一种跳层断线。这是最理想、最干净的修复方式。具体做法是把一条连续的长金属走线在某一个位置换到其他层去走。因为antenna ratio是按单层金属面积来计算的如果这根线从M4跳到M3再跳回M4每一层上的连续金属长度都变短了每层对栅极贡献的电荷收集面积就会减小天线违规自然就解除了。跳层修复的好处是不增加任何cell不影响逻辑功能对时序的影响也比较可控代价是多加一两个via可能增加一点电阻电容。但要注意跳层点要选合理不要选在timing critical的线段上否则额外增加的via和层间耦合会带来延迟变化。第二种加antenna diode。如果某条线确实必须走高层长距离没有办法跳层那就在靠近驱动端的金属线末端也就是电荷最容易积累的地方插入一个反向连接的二极管cellantenna diode。这个二极管的作用是为积累的电荷提供一个低阻泄放通路相当于给静电装了一个“安全阀”。这种修复方法很直接几乎不影响时序但要付出面积和功耗的代价。diode cell本身有一定的泄漏电流如果数量太多对整个chip的静态功耗影响还是比较明显的。所以能用跳层解决的一般不用diode。第三种插buffer。把一根长线在中间插入一个buffer物理上这根长线就被分成了两段每一段对栅极的天线贡献都会被重新计算从而达到降低单段天线面积的效果。插buffer还能顺便改善信号完整性但同时也会带来延迟变化和cell面积增加。而且如果是clock tree上的net插入buffer之后会影响树的深度和skew修复完成后需要重新做clock tree相关检查。所以这类方案我一般放在前两种都不可行的备选位置。三种修复手法各有适用场景实际项目中经常是混合使用。我的选择优先级是跳层断线 加diode 插buffer。前两种对功能、时序影响小buffer则是最后手段。3.4 一次完整的Antenna违规修复记录说一个具体的案例。前几年一个项目里有一条APB总线的长走线从bridge module出来以后跨过一个大的memory block最后接到一个外设模块。布线完成之后天线检查报了一条M4层上的ANT violation天线比超过rule大概2.3倍。我当时的处理过程是第一步在GUI里定位到violation坐标高亮这根net确认它的走线路径。这根线从bridge的output pin出来后在M4层一直拉了大半个block到目的地路径上没有任何换层整段金属面积都计入了天线比。第二步评估是否可以跳层。我看了下这根线经过的区域M5层的congestion不算严重完全可以把M4层的一部分走线跳到M5层去走在贴近目的地附近再跳回M4进入pin。这样就打破了M4层上连续金属面积过大的问题。第三步在innovus里手动编辑wire。我先把M4长线从中间某个位置切断然后切换到M5层把后半段重新走了一遍最后再加一个M4-M5的via把两段连接起来。整个操作大概花了不到十分钟。第四步也是一定要做的跑一遍增量天线检查和DRC验证确认这个violation消失同时没有引入新的spacing/short问题。因为换层后新加的via和M5走线很可能会跟旁边的线产生新的间距问题特别是M5层如果已经很密。我那次运气不错新走线旁边没有其他net所以一次通过。整个过程下来没有增加任何cell也没有动逻辑连接这就是跳层方案的魅力。如果当时M5层太挤没法跳层我会直接评估在靠近驱动端的位置插一颗antenna diode而不是冒险把M4走线绕得更远。4. ECO路由技巧DRF修复的进阶手段4.1 哪些情况适合走ECO路由哪些情况要忍痛动大手术ECO路由说白了就是对已布线的design做局部修改而不是全量重新布线。它的核心好处是“小步快跑”对已有走线和时序的影响控制在尽量小的范围内。适合用ECO路由的情况至少包括改了RTL逻辑需要重新连接某几个netMRmetal-only fix阶段只能改metal层不能动cell修DRC的时候需要局部重新绕线以及某些performance fix需要插入或删除buffer但不想全chip重来。不适合用ECO的情况也很清楚如果DRC爆掉是因为floorplan本身布局不合理、电源网络短路、或者congestion整体过热那么单一的点修解决不了问题。这时候硬上ECO只是在局部打补丁治标不治本。我之前见过一个极端项目整个block的M2层short有上百条source原因其实是block中间摆了一个超大hard macro导致信号全部在macro周围挤压。这种情况下与其在ECO里面一条一条清short不如去重新评估macro的摆放位置或者加一条绕线channel。4.2 ECO Buffer Tree插入改树时的几个关键点热词里提到的“innovus eco buffer tree”实际是ECO过程中很常见的操作常见于功能修复或时序修复中需要往clock tree里插入buffer来调整skew的情况。但插入buffer tree这个动作如果处理不好会给DRC修复带来新的麻烦。我先说一下关键点。第一插入buffer之前要明确插入位置在clock tree中的层级。不能随便找一条net就切。第二插入buffer后这个buffer驱动的subtree长度会变化紧接着需要重新做CTS的局部平衡否则skew会变得很难看。第三新增buffer的input pin需要连到原netoutput pin的负载会改变必要时要补一部分dummy load来保持负载平衡。我曾经在修一个setup violation时往clock path里插入了一颗buffer结果因为位置太靠近sink pin导致后级几个flip-flop的clock skew瞬间偏了50ps。后来我把buffer的位置往前挪了几个cell的间距再手动补了一段short wire做负载匹配skew才回到可接受范围内。在修DRC的场景里插buffer tree一般是用在“长线驱动不足导致需要分段重走线”的情况。比如一根天线违规的线同时驱动能力不足这个时候与其单独加diode不如直接在中间插一个buffer既解决天线问题又改善驱动。但这种操作会有面积和功耗变化需要跟前端确认ECO的范围是否允许。4.3 ecoRoute和手动ECO的组合用法ECO路由的另一个巨大价值是在修short和spacing violation时可以只对局部区域重新布线。Innovus里的ecoRoute命令是完成这个动作的主力工具。实际用法我习惯分两步走先用TCL选中需要修改的区域或net然后在这个局部范围内执行ecoRoute让工具重新规划最短路径。举一个典型的修short场景。两条net在某个区域短接我删除短接线段之后不想手动一条条画线连接两个断点而是选中这两个net在short附近的bounding box里执行ecoRoute让工具自动把断掉的连接补回来。这样做的好处是走线结果仍然是工具原生的质量有保障不会出现手动绕线带来的不规则走线。不过这里有一个非常容易掉进去的坑如果对整个chip执行ecoRoute工具可能会把这些net在别的地方的正常走线也重新优化一遍导致大量非目标net被翻动时序和DRC都可能变差。所以我的经验是ecoRoute一定要限定明确的修改范围只选那些真正需要重绕的net区域也最好框定在修改点周边。这相当于告诉工具“只动这一片其他地方别碰。”进一步的话手动ECO和自动ecoRoute可以形成互补。手动删除一段wire、切换到另一个layer画一段线然后对断点周围的net做一次ecoRoute这种组合方式是修DRC时效率最高的手法。它能结合人类的直觉和工具的最优路径搜索能力。4.4 手动ECO修DRC的高频操作笔记在实际项目里有一些手动ECO操作是我几乎每天都用的这里做个简单的笔记。第一删除和重画wire。先选中要删除的线段然后从断点处拖拽新的wire到目标位置。整个过程需要保证新路径不跨越某些特殊层次比如不要走到hard macro的pin上方不要跟power stripe重叠。手动画线之后一定要跑DRC验证。第二利用体高亮做参照。手动ECO最怕的是画出来的线跟旁边的net靠得太近刚修完a short又制造了一个spacing violation。避免的办法是在画线前把相邻区域的net全部高亮显示以这些线为参照物留出足够的间距。第三更新antenna规则后的重绕。有些项目的antenna rule file在项目中期会更新导致原本干净的走线突然变成天线违规。这种情况不需要大动干戈只需要对这些net做一次跳层处理或者加diode然后跑增量验证。千万别因为这些新violation就把原来的走线全部推翻否则修复范围会失控。ECO这个名词看着高大上本质上就是“微创手术”。修DRC时如果能精准地做好每一次微创整个芯片的修复过程就会又快又稳。5. 常见问题与排查技巧实录5.1 “partial route conflicts: 1184 nets”到底在说什么很多人问过我在Innovus跑完或者ECO之后log里出现“[DRC RTSTAT-6] partial route conflicts: 1184 net(s) have a partial conflict.”是什么意思。这个信息本质上是在告诉你有1184个网络它们的physical走线形状和logical connectivity之间存在部分冲突。简单说就是工具的数据库里有一些wire并不是当前逻辑连接所需要的或者说某些wire之间“打架”了。这个问题的出现往往有几个原因。最常见的是在ECO过程中删除了某个net但对应的physical wire没有完全清理干净或者直接修改了逻辑连接却没有让工具重新走一遍线。另外一个常见场景是使用手动ECO时把一段wire接到另一个net上但原net的wire残骸还留着产生了partial conflict。处理方式也很直接对报出conflict的net先做一次ECO route让工具重新整理如果还是不行就把这些net的走线全部删掉再重新走一遍。我一般在跑macro placement之后的DRC cleanup阶段都会顺手把所有partial conflict的net清理干净因为这个东西如果不清后面verify DRC会产生一堆莫名其妙的假violation。至于具体命令不同版本略有差异在Innovus命令行里输入help ecoRoute看一下当前版本支持的选项就好核心思路就是让工具清理掉冲突的走线残骸。5.2 修天线却弄出新Short大概率是这几种情况天线修复过程中最容易闹出的事故就是本来修天线结果改线的时候搞出了新的short或spacing violation。我自己就踩过多次总结下来原因主要有三个。第一个原因跳层时via位置选得太随意。跳层的本质是在某一点改变金属层次没有一个via是解决不了的但这个via如果刚好落在旁边一条net的走线上那就直接short了。我现在的做法是在加上via之前先用高亮把邻近区域的金属层和net都显示出来确认via落点周围的空间足够再执行操作。第二个原因跳层后的走线层次选择不当。比如M4上的线跳到M5层但M5层在这个区域特别密你新画的一段M5线哪怕已经很规矩地沿着track走也会跟旁边的线产生spacing violation。解决的办法是看看同层两边的track是不是已经被占用如果占满了就考虑跳到更空的上层。第三个原因是跳到没有特殊规则保护的区域。有些block内部有antenna diode的专用摆放区域或者有power mesh密集的区域如果在这些区域里面手动穿线工具不会自动帮你避让。碰上这种情况修线之前要先把这些约束以route guide或keep-out的方式告诉工具再去做操作。5.3 DRC修好了时序却崩了三条止损经验修DRC最尴尬的事情莫过于修完DRC之后发现timing坏了。这里我有三条止损经验。第一条修线之前先把critical path上的net保护起来。在修DRC的时候如果知道有些net是setup或者hold的critical net就不要去动它们在关键路径上的走线段。如果short恰好发生在这些critical net上尽量选择改另一个net而不是让critical net去绕远路。很多后端工具支持设置net的weight或者critical range在ecoRoute的时候工具会自动优先照顾weight更高的net。第二条修完一轮DRC后立刻跑增量时序分析不要攒到最后。增量时序分析比全量signoff时序快很多它能帮你快速发现哪根线的RC因为走线变化而发生了明显改变。如果发现某根线延迟变大了就在这一轮立刻修正否则等到最后一起看根本不知道是哪个改动引起的。第三条如果DRC和timing打架先看violation的类型和数量。short类violation必须处理因为short在物理上就是错误的连接但一些non-critical的spacing或min area violation如果修起来会严重恶化timing可以考虑先放着在signoff前的最终DRC清理阶段再处理或者与工艺厂确认是否可以waive。总之不要为了追求DRC zero violation而让timing崩盘。最后再分享我个人的一个习惯。每个项目里我都会把修DRC的过程写成一个简单的TCL脚本脚本里记录每一轮修了哪些net、用了什么手法、verify DRC的结果是多少。这样做的价值在项目后期会体现出来——当你需要向别人解释为什么某根线被改成这样的时候这份记录就是最好的答案。修DRC这种看似重复的工作做到后面拼的其实不是手速而是系统性的判断力和对自己工具的熟悉程度。