1. 天线效应违例到底在报什么错天线效应Antenna Effect这个词做数字后端的兄弟应该都不陌生。简单说就是在芯片制造过程中金属层或通孔在刻蚀时积累了电荷这些电荷如果找不到泄放路径就会击穿栅氧导致器件失效。工艺越先进栅氧越薄这个问题就越致命。我在最近一个项目里跑完route之后做verifyAntenna一口气报了60多个违例。这个数量不算特别夸张但也不少了。如果一个个手动去修加跳线、加buffer、改绕线没个两三天搞不定。而且手动修的过程中很容易引入新的DRC或者timing问题改完还得重新跑一遍验证来回折腾。天线效应的本质是什么Foundry在工艺规则里会定义一个“天线比率”通常是金属面积与栅极面积的比值。如果这个比值超过阈值就判定为天线违例。常见的修复思路有三种一是打断长金属线在中间加一个二极管把电荷泄放掉二是通过跳层layer hopping把长线分散到不同金属层三是插入buffer把一条长线拆成两段短线段。这三种方法各有适用场景。加二极管最直接但会占用面积而且有些工艺不允许在某些位置加二极管。跳层需要改绕线可能影响timing和congestion。插buffer则是最“温和”的方式因为它本质上是在逻辑上把一条net拆成两条天线比率自然就降下来了。我这次选择的是用ecoRoute来批量修复。为什么不用手工因为60多个违例分布在不同的模块和不同的金属层上手工修效率太低而且容易漏。ecoRoute的好处是它可以自动识别违例net自动插入buffer或者做跳层然后增量绕线不影响已经收敛的timing和DRC。注意ecoRoute修复天线效应之前一定要先确认你的design已经完成了route和post-route优化否则修完天线之后还要重新跑route前面的工作就白费了。2. 为什么选ecoRoute而不是手工修2.1 ecoRoute的核心机制ecoRoute是Innovus里专门用于增量绕线的引擎。它的工作方式是你给它一个eco place或者eco netlist的变更它只对受影响的net重新绕线其他区域保持不动。这个特性对于天线修复来说简直是量身定做的。天线修复的本质是什么就是在某条net的中间插入一个buffer把一条长线拆成两条短线。对于ecoRoute来说这就是一个标准的ECO操作你在netlist里加一个buffer实例连接好输入输出然后让ecoRoute去绕这两条新net。它不会动到其他任何东西。我试过用ecoPlace加ecoRoute的组合效果很稳。ecoPlace负责把新加的buffer摆到合理的位置ecoRoute负责绕线。整个过程是增量的不会触发全局reroute。2.2 和手工修相比的优势手工修天线最大的问题是效率。60多个违例每个都要看它的net走向、金属层分布、周围有没有空间加buffer或者做跳层。一个熟练的后端工程师修一个天线违例大概需要5到10分钟60个就是5到10个小时。这还不包括修完之后重新验证的时间。ecoRoute批量修复的话从写脚本到跑完大概30分钟到1小时就能搞定。而且脚本可以复用下次遇到类似问题直接改改参数就能用。另一个优势是一致性。手工修的时候不同的人可能有不同的修法有的人喜欢加buffer有的人喜欢跳层导致最终的netlist风格不统一。用脚本修的话所有违例都走同一套逻辑结果可预测、可复现。2.3 什么情况下不适合用ecoRouteecoRoute也不是万能的。如果天线违例集中在某个特别congested的区域ecoRoute可能找不到合法的绕线路径这时候就需要手工介入。还有一种情况是如果违例net上有时序特别紧的路径插buffer可能会引入额外的delay需要仔细评估。我一般会先跑一遍ecoRoute看看它能修掉多少。如果剩下几个实在修不掉的再手工处理。这样既保证了效率又保证了质量。3. 修复前的准备工作3.1 确认违例报告和net清单第一步肯定是拿到准确的天线违例报告。在Innovus里跑完verifyAntenna之后会生成一个antenna violation report。这个report里会列出所有违例的net名字、违例的pin、当前的antenna ratio、以及要求的threshold。我一般会把这个report解析一下提取出所有违例net的名字存到一个文件里。这个文件后面会作为ecoRoute的输入。# 提取天线违例net列表 set fp [open antenna_violations.rpt r] set net_list {} while {[gets $fp line] 0} { if {[regexp {Net:\s(\S)} $line match net_name]} { lappend net_list $net_name } } close $fp puts Total violation nets: [llength $net_list]这段脚本的逻辑很简单逐行读report用正则匹配出net名字存到list里。实际项目中report的格式可能不太一样你需要根据自己项目的report格式调整正则表达式。3.2 检查物理资源是否充足在跑ecoRoute之前一定要确认design里有足够的空间放buffer。如果congestion已经很严重了再往里塞buffer只会让情况更糟。我一般会看两个东西一是congestion map看看违例net所在的区域是不是已经爆了二是free space的报告看看还有多少可用的placement site。# 检查congestion情况 reportCongestion -hotSpot # 检查free site数量 checkFPlan -reportUtil如果发现某个区域特别congested可以考虑先把一些不关键的buffer挪走或者调整floorplan给这个区域多留点空间。3.3 备份当前design这一步千万别省。ecoRoute虽然说是增量的但万一脚本写错了或者ecoRoute的行为不符合预期你还能回退。我一般会用saveDesign存一个checkpoint命名上带上时间戳方便回溯。# 保存当前design状态 saveDesign ./checkpoints/before_antenna_fix_${timestamp}.enc提示备份的时候最好把当前的timing report和DRC report也一起存下来修完之后可以对比确认没有引入新的问题。4. 核心脚本拆解与实操4.1 脚本整体结构我写的这个脚本分四个部分第一部分是读取违例net列表第二部分是给每个违例net插入buffer第三部分是跑ecoPlace和ecoRoute第四部分是重新验证天线效应。整个脚本大概100行左右核心逻辑就是遍历net列表对每个net执行ecoAddRepeater或者ecoInsertBuffer然后统一跑ecoRoute。# antenna_fix.tcl # 读取违例net列表 set net_file antenna_violations.txt set fp [open $net_file r] set violation_nets {} while {[gets $fp line] 0} { if {[string trim $line] ne } { lappend violation_nets [string trim $line] } } close $fp puts INFO: Total [llength $violation_nets] nets to fix4.2 插入buffer的关键参数给每个违例net插buffer的时候有几个参数需要特别注意。第一个是buffer的类型。我一般会选驱动能力适中的buffer太小的驱动能力不够太大的面积浪费。具体选哪个要看你的library里有哪些可用的buffer。我通常会选一个中等驱动的比如BUF_X4或者BUF_X8。第二个是插入位置。ecoAddRepeater可以指定插入位置也可以让工具自动选。我一般会让工具自动选因为它会考虑congestion和timing。但如果某个net特别长我会手动指定一个大概的位置让工具在那个附近找。第三个是是否允许跳层。有些工艺里跳层比插buffer更有效。ecoRoute支持在绕线的时候自动做layer hopping你只需要在命令里加一个选项。# 对每个违例net插入buffer foreach net $violation_nets { # 获取net的driver和load set driver [get_db [get_db nets $net] driver] set loads [get_db [get_db nets $net] loads] if {$driver eq || [llength $loads] 0} { puts WARN: Net $net has no driver or load, skip continue } # 插入buffer ecoAddRepeater -net $net \ -cell BUF_X4 \ -location_aware \ -relative_location 0.5 puts INFO: Inserted buffer on net $net }这段脚本里-relative_location 0.5表示在net的中间位置插入buffer。这个值可以根据实际情况调整比如0.4或者0.6。-location_aware让工具考虑物理位置避免把buffer放到太远的地方。4.3 ecoPlace和ecoRoute的执行插完buffer之后需要先跑ecoPlace把buffer摆到合法位置再跑ecoRoute绕线。# 执行ecoPlace ecoPlace -buffer # 执行ecoRoute ecoRoute -target # 检查ecoRoute结果 set eco_route_status [get_db ecoRouteStatus] puts INFO: ecoRoute status: $eco_route_statusecoPlace -buffer是专门针对buffer的placement它会尽量把buffer放在net的附近减少绕线长度。ecoRoute -target会让ecoRoute只绕那些需要修的net不动其他net。跑完ecoRoute之后一定要检查一下status。如果status不是“completed”说明有些net没绕通需要进一步处理。4.4 重新验证天线效应修完之后重新跑一遍verifyAntenna看看还有没有违例。# 重新验证天线效应 verifyAntenna -report antenna_after_fix.rpt # 统计剩余违例数量 set fp [open antenna_after_fix.rpt r] set remaining 0 while {[gets $fp line] 0} { if {[regexp {Net:\s(\S)} $line match net_name]} { incr remaining } } close $fp puts INFO: Remaining antenna violations: $remaining如果remaining是0恭喜你收工。如果还有几个那就需要手工看看是什么原因。常见的原因包括buffer插不进去没空间、绕线绕不通congestion太严重、或者违例net本身有特殊约束。5. 实操中踩过的坑和排查技巧5.1 buffer插不进去怎么办最常见的问题是ecoPlace找不到合法的位置放buffer。这时候可以试试几个方法一是换一个更小的buffer比如从BUF_X4换成BUF_X2二是放宽placement的约束允许工具把buffer放得远一点三是手动指定一个位置让工具在那个附近找。# 换更小的buffer ecoAddRepeater -net $net -cell BUF_X2 -location_aware # 或者手动指定位置 ecoAddRepeater -net $net -cell BUF_X4 -location {100 200}如果还是不行那就只能手工在版图上找个空位手动摆一个buffer进去然后手动连上线。这种情况一般出现在特别congested的区域。5.2 ecoRoute绕不通怎么办ecoRoute绕不通的原因通常是congestion太严重。这时候可以试试调整绕线层让ecoRoute优先用上层金属因为上层一般比较空。# 设置ecoRoute的绕线层偏好 setEcoRouteMode -layer_preference {M5 M6 M7 M8}或者可以临时放宽DRC的约束让ecoRoute先绕通然后再手工修DRC。但这个方法要慎用因为放宽约束可能会导致后续DRC修不完。5.3 修完天线之后timing变差了插buffer会引入额外的delay这是不可避免的。如果修完天线之后发现某些路径的timing变差了可以考虑几个方法一是换驱动能力更大的buffer减少delay二是调整buffer的位置让它更靠近driver或者load三是在buffer后面再加一级buffer做timing的补偿。我一般会在修完天线之后跑一遍timing report看看有没有新的setup或者hold违例。如果有就针对性地修一下。5.4 常见问题速查表问题现象可能原因解决方法ecoPlace找不到位置congestion太严重换小buffer放宽约束手动指定位置ecoRoute绕不通绕线资源不足调整绕线层偏好放宽DRC约束修完timing变差buffer引入delay换大驱动buffer调整位置加补偿buffer天线违例没减少buffer没插对位置检查net的driver和load调整插入位置脚本跑一半报错net名字有特殊字符检查net名字加转义或者过滤提示脚本跑之前先用一两个net试一下确认流程没问题再批量跑。我吃过这个亏脚本写错了跑了一半发现不对回退又花了不少时间。6. 脚本的复用和扩展6.1 把脚本做成可配置的我现在的做法是把脚本里的关键参数抽出来放到一个配置文件里。这样下次遇到不同的项目只需要改配置文件不用改脚本本身。# config.tcl set BUFFER_CELL BUF_X4 set RELATIVE_LOCATION 0.5 set LAYER_PREFERENCE {M5 M6 M7 M8} set MAX_ITERATIONS 3然后在主脚本里source这个配置文件用变量替换硬编码的值。这样脚本的通用性就强多了。6.2 加入迭代修复的逻辑有些天线违例一次修不掉需要迭代几次。我一般会加一个循环每次修完之后检查剩余违例如果还有就再跑一遍最多跑三次。set max_iter 3 set iter 0 while {$iter $max_iter} { # 读取当前违例 # 插入buffer # ecoPlace和ecoRoute # 重新验证 # 如果违例为0break incr iter }这个逻辑对于那种违例分布比较分散的情况特别有用。第一遍可能只修掉80%第二遍再修掉剩下的15%第三遍基本就干净了。6.3 和其他ECO流程的整合天线修复只是ECO流程中的一环。实际项目中可能还有timing ECO、DRC ECO、IR-drop ECO等等。我一般会把这些ECO整合到一个统一的脚本里按优先级依次执行。天线修复的优先级通常比较高因为它直接影响芯片的可靠性。我一般会先修天线再修timing最后修DRC。这样顺序的好处是天线修复引入的buffer可以在后续的timing修复中被优化掉。7. 一些个人体会这个脚本我用了大概有两年了从28nm到7nm的项目都跑过整体来说稳定性还是不错的。但有几个点我想特别强调一下。第一不要迷信自动化。ecoRoute再智能它也只是个工具。有些违例就是需要人工判断比如那种特别敏感的模拟net或者有时序特紧的路径。脚本能修掉80%到90%的违例剩下的还是要靠人。第二脚本要经常更新。不同的工艺节点library不一样DRC规则不一样congestion的情况也不一样。我一般会在每个新项目开始的时候花半天时间把脚本调一遍确认它能正常工作。第三验证一定要做全。修完天线之后不仅要重新跑verifyAntenna还要跑DRC、LVS、timing。我见过有人修完天线之后DRC爆了结果又花了两天修DRC得不偿失。最后分享一个小技巧如果你发现某个net的天线违例特别顽固怎么修都修不掉可以试试把它拆成多条net每条net单独绕线。这个方法有点暴力但有时候确实管用。具体做法是在net的中间加一个buffer把一条net变成两条然后分别绕线。如果还不行就再加一个buffer变成三条。一般来说拆成三条之后天线比率肯定能降下来。