流片前最后一轮LVSCalibre一口气报了四十多个错误其中六个short、十几个soft connect这种情况我遇到过不下十次。处理这类问题规律其实很固定从Innovus导出GDS和网表到Calibre跑LVS、读报告再回到Innovus定位修改这是一条需要反复走的闭环。这篇文章就把我在这条链路上踩过的坑、总结的排查方法和关键命令全部梳理一遍给正在被LVS折磨的兄弟们做个参考。1. 从Innovus到Calibre的第一公里GDS与CDL导出配置很多刚接触物理验证的人总觉得LVS报错就是版图画错了其实我这些年处理下来的经验是至少有三成以上的错误根本是导出环节造成的。数据从Innovus出来的那一刻就决定了Calibre到底是在帮你找bug还是在添乱。1.1 为什么LVS问题的源头常常在导出这一步先说明一个容易被忽略的逻辑Innovus里看到的版图数据和Calibre LVS真正吃进去的GDS数据并不是同一份东西。Innovus界面里显示的是内部数据库包含了你所有的布线、单元、电源网络以及一大堆对LVS没有意义的辅助多边形。当你执行导出GDS时工具会根据Stream Out的设置做层次映射、层名转换、text标签处理这一套下来任何一步设置不对出来就是污染过的数据。最典型的几个翻车现场GDS里缺了PG text导致Calibre无法识别某些电源地net的名字最后两个不同名字的net被软件合并报出一堆奇奇怪怪的short。层次映射表没写好本该是M1的图形被映射到了别的层Calibre读取时找不到对应的device terminal。网表导出时没带PG pin后端网表里的标准单元全都没有VDD/VSS端口LVS直接报missing pin或device mismatch。所以我的习惯是导出LVS用的GDS和CDL网表时遵循一套固定的参数不轻易改。接下来给出我常用的配置。1.2 exportGDS与exportNetlist命令级参数详解Innovus导出GDS不同版本命令有细微差异但最核心的参数基本一致。我现在的环境是Innovus 19.x命令是这样的exportGDS -design top -output ./lvs/top.gds -user_unit MICRON -compress_mode implicit -write_pg_text YES几个参数别乱动-compress_mode implicit生成的GDS自动压缩成gds.gz能省不少磁盘空间。Calibre能直接读gds.gz不需要手动解压。-write_pg_text YES这是我最强调的一个参数。它会把电源地网络对应的text标签写进GDSCalibre就能识别哪些图形属于VDD、哪些属于VSS否则电源地连接经常被当成浮空或soft connect处理。-user_unit MICRON保证坐标单位是微米跟Calibre里的坐标系对齐。导出CDL网表用下面这条exportNetlist -netlistFormat cdl -output ./lvs/top.cdl -pg -includePowerGround这里有个坑如果只写-netlistFormat cdl而漏了-pg或-includePowerGround导出的网表里标准单元的PG pin是打不出来的。Calibre拿到这种网表所有标准单元都缺电源地端口LVS基本没法看。我每次导出后都会先打开CDL文件搜一下有没有VDD和VSS作为子电路端口出现。另外如果项目里有多个电源域导出前最好在Innovus里确认globalNet连接是完整的。比如模拟模块的AVDD/AVSS如果没加到global net导出网表后这些pin就悬空LVS出来会报一堆open。1.3 导出CDL网表后必须先做三件事拿到top.cdl后别急着跑Calibre我建议花两分钟做三件小事检查.global声明。CDL网表开头应该有类似.global VDD VSS的声明。如果缺失说明导出时没有正确识别global net后面一切白搭。检查模型名。网表里每个器件都会引用模型名比如nch、pch这个模型名必须和Calibre rule文件里的DEVICE语句定义一致。经常有PDK版本更新后模型名变了规则文件没同步LVS一跑就是满屏unknown model。用文本编辑器搜一下是否有空的SUBCKT。有时候某些IP的行为级网表被当成黑盒导出了里面一个器件都没有Calibre读进去以后会认为这个模块是空的导致大量device mismatch。遇到这种情况需要在Verilog网表里为这个IP标注*.EQU或者用SPICE网表替换。1.4 先把工具自带的连接性检查跑干净我强力建议在导出GDS之前先在Innovus里跑一遍连接性检查verifyConnectivity -type all -error 1000 -warning 500这条命令会把设计里所有的open、short、floating pin等问题提前暴露出来。你想想如果Innovus自己都认为VDD和VSS某处短接了那你导出GDS再去跑Calibre结果一定是short等于白跑一轮。反过来如果verifyConnectivity全绿那Calibre报short的时候你就能比较确定是导出环节产生的数据问题而不是版图真实short排查方向一下子就清晰了。第一次接触这个流程的人往往skip掉这一步直接跑LVS。但说实话Calibre跑一个大芯片的LVS时间动辄几小时而Innovus里verifyConnectivity几分钟就出结果这时间账怎么算都划算。2. Runset里的关键开关soft connect、并联器件与报告阈值数据导出来之后下一步就是Calibre登场。但很多人拿到foundry提供的LVS rule文件直接双击就跑跑出来的报告里几百条错误仔细一看全是噪声。这里的问题往往出在runset的开关没调好。2.1 SVRF规则文件里必须确认的几条语句Calibre的LVS规则文件用的是SVRF语法foundry会在rule里定义一堆device和connectivity规则。我不建议新手去改foundry的rule本体——那是厂商维护的改动容易出事。但有几条LVS全局选项你可以在自己的runset里单独覆盖Calibre支持在rule后面追加选项覆盖默认值。下面这几条是我每次都要过一遍的语句作用我的常用设置LVS SOFT CONNECT SELECT控制是否把高阻路径衬底、N阱识别为连接按foundry默认但会在对比时关注LVS REDUCE PARALLEL YES合并并联器件减少器件数量差报错YESLVS REDUCE SERIES YES合并串联器件减少串管误报YESLVS COMPARE CASE NO网表和版图net名字大小写不敏感NOLVS REPORT MAXIMUM 1000单类错误最多列出多少条1000LVS PIN NAME CASE NOpin名大小写不敏感NO其中LVS SOFT CONNECT SELECT是我认为最重要的开关它直接决定衬底/N阱连接会不会被当回事。这个我会在第五部分专门展开这里先提醒一句别轻易把这个选项改成完全关闭否则版图里所有通过衬底连在一起的地都会被当成short来报报告瞬间爆炸。2.2 Calibre执行命令与并行设置Calibre跑LVS的命令行我通常这样写calibre -lvs -spice ./lvs/top.cdl -turbo 8 -hier ./lvs/lvs_rule.cal解释一下-spice指定源网表路径也就是Innovus导出的CDL文件。-turbo 8并行线程数具体设多少要看你机器核数和内存。我习惯设成CPU核数的一半到三分之二因为Calibre跑LVS时对内存的消耗也很猛线程全拉满容易OOM。-hier使用层次化比较模式。对顶层带大量重复单元的设计这个选项能大幅降低内存占用和运行时间。如果用的是flat模式一个大芯片很可能跑到一半机器就卡死了。跑完之后会在输出目录里生成几个关键文件top.lvs.report文本形式的LVS结果最常用。top.lvs.log运行日志报错信息在这里。top.lvs.resultsCalibre RVE显示用的数据库GUI界面高亮全靠它。我习惯在跑完之后立刻grep -i error top.lvs.log看一眼有没有ERROR级别的运行错误。如果log里就报错了那report大概率不可信先解决运行问题再说。2.3 先拿一个小模块验证规则文件再上全芯片这是我最想分享的一个习惯只要rule文件或PDK版本换过我一定会先用一个小模块把这个LVS流程完整跑通再拿全芯片打。小模块指的是那种几百个标准单元的block跑一轮LVS也就一两分钟。用它能快速检验CDL网表格式是否符合Calibre的读取要求。GDS层映射有没有问题。规则文件版本是否和PDK匹配。等你直接上全芯片跑了两三个小时最后发现是CDL网表第一行格式不对导致全流程白跑那才是最痛苦的。用最小模块做冒烟测试这个习惯帮我省下的时间足够我看好几部电影了。3. 读懂LVS报告错误类型、根因倾向与优先级排序Calibre LVS报告的结构对于一个不常看的人来说就像一堵墙。其实它的阅读顺序非常固定先看摘要再按错误类型逐个展开最后回到版图坐标去验证。掌握这个顺序你就能把几十页的报告压缩成一条清晰的行动清单。3.1 LVS报告的阅读顺序从摘要到详情典型的LVS报告开头会有一段摘要大意是LVS report: Cell top compares to cell top. * 2 short errors * 5 open errors * 7 device mismatches * 12 property errors INCORRECT看到INCORRECT就说明整体没过但别慌。接下来要做的是把错误分类然后按我下面的优先级去处理。Calibre的错误大致分这几类错误类型意思常见根因Short版图上两个不同net被物理连接金属桥接、via错打、单元内部短路Open本应连通的net断开缺少contact/via、线太细断裂Device mismatch版图器件和网表器件数量/类型对不上源网表不完整、单元类型不一致Property error器件参数如W/L与网表不一致尺寸变化、deivce定义错误Soft connect通过衬底或N阱产生的高阻连接多电源地域、缺少隔离环3.2 错误的处理优先级为什么short永远排第一我的排查顺序是固定的short → open → device mismatch → property error。为什么short排第一因为short会改变整片电路的连接关系。比如VDD和VSS之间短接Calibre在比较时会把原本独立的两个net当成一个net去比于是整个电路图全乱了后面报出来的device mismatch、open可能都是这条short引起的连锁反应。先把所有短路清干净很多后面的错误会自动消失。同理open会改变局部连接也可能导致器件匹配错误。所以short和open是大领导处理完它们再去看device mismatch这些基层员工。3.3 坐标语义为什么RVE里的点不能直接照搬到Innovus这是几乎所有新手都会卡住的地方。Calibre RVE里点开一个错误显示的坐标看起来很明确比如(123.45, 678.90)但你把这个坐标输入到Innovus里放大过去一看却发现什么都没有或者跟RVE里高亮的位置对不上。原因很简单Calibre的坐标是相对于GDS原点的物理坐标而Innovus界面里显示的坐标则基于它自己的数据库原点两者未必对齐。如果LVS导出的GDS经过了平移或cell origin变化坐标就会有一个固定的偏移。我处理这个问题的办法是在RVE里高亮错误时同时看它涉及的net名和cell名而不是只依赖坐标。回到Innovus先用一条明显的线比如VDD的走线做锚点把视野切到大致区域。再放大到坐标点附近配合highlight -net VDD -color red这类命令把整条net高亮出来Slowly找相交点。对于大芯片来说直接靠坐标硬找确实痛苦。所以我在下一章会专门演示一次完整的短路排查流程那是这段内容最实用的部分。3.4 一个容易忽略的错误来源text层与net名字LVS能正确识别net名字很大程度依靠GDS里的text标签。如果导出的GDS没有text信息或者text被映射到了错误的层Calibre会默认给这些图形分配一个自动名最后对比时就会报net name mismatch。我之前处理过一个case顶层有一个模块的VDD text丢了Calibre把这个模块的电源net自动命名为_1_123和网表里的VDD对不上一下子报出几十个open。排了半天最后发现是导出GDS时某些text层的Stream Out mapping没有配好。所以1.2节里我特别强调-write_pg_text YES就是为了避免这种低级但极其费时的错误。4. 短路错误实战从RVE坐标回Innovus定位到PG端子级理论讲完来一次完整的实战。这个案例是前阵子一个带BIST逻辑的模块Calibre在顶层report里报了6处short其中两处是VDD和VSS之间的短接。我带着你从头到尾走一遍。4.1 实战案例背景那份报告长这样ERROR: Short via CON between net VDD and net VSS at location (123.45, 678.90). Path is VDD - M1 - VIA1 - M2 - CON - terminal of instance biasnw - NWELL - VSS.看到没问题是这个biasnw标准单元的PG端子内部出了问题。这类单元是带衬底偏置的一般会有一个额外的端子比如BIASNW连接到N阱。如果这个端子的版图处理不当就可能把VDD和VSS通过N阱串起来。4.2 从RVE到Innovus的定位两步法第一步在RVE里双击错误查看高亮图形和完整的path信息。RVE会把这个short相关的所有多边形标成不同颜色我记录下涉及层M1、VIA1、M2、CON还有biasnw实例。第二步回到Innovus。先在命令行高亮两个有嫌疑的nethighlight -net VDD -color red highlight -net VSS -color blue然后在GUI的坐标输入框里输入123.45 678.90按回车。如果你的Innovus支持zoomToLocation也可以直接zoomToLocation 123.45 678.90需要提醒的是Innovus默认只显示当前显示的layer如果你只开了M3以上那M1/CON这些关键层根本看不见定位就会失败。所以我搜索前会先把层控制里M1、M2、VIA1、CON全部打开确保看到的是完整物理图形。4.3 在Innovus里按名字选中标准单元的PG端子这一步就是很多人问过的那个场景怎么选中名字为biasnw的标准单元的PG term。我说几种我用下来靠谱的方法。方法一命令行直接选中instanceselect_inst biasnw这样能选中这个实例但默认选中的是整个instance的边界框不是具体的PG pin。要查看它到底有哪些PG pin用dbGetdbGet [dbGet top.insts.name biasnw].pgPin.name输出可能是VDD VSS BIASNW。接下来单独选中某个PG端子editSelect -pin biasnw/VSS有些版本会要求指定类型用-type pg更保险。方法二如果你更喜欢GUI操作选择菜单里的Select by Name快捷键通常是F6在对象类型里勾选PG pin然后在名称框里输入biasnw/VSS点Apply。这样选中的就直接是PG pin本身能看它在版图里的具体位置和高亮。方法三也是最实用的我想知道某个PG pin到底连到了哪个net一条命令就搞定dbGet [dbGet top.insts.name biasnw].pgPin.net.name假设输出是VSS说明这个pin连到的net是VSS。如果发现BIASNW端子意外连到了VDD你就找到问题了。我在那次排查里就是用这条命令发现biasnw的BIASNW端子被connect到了VDD而内部结构上它应该和N阱一起接到VSS错误就很明确了。4.4 修复与一次回归从ECO到重新LVS找到问题后修复手段要看具体情况。如果是布线造成的可编辑连接比如某段M1走线贴着单元边界走了不该走的路径我一般先手动删掉错误连接再用ECO重新布线deleteRoute -net VDD -regexp .* # 注意范围别把整条VDD全删了 ecoRoute -modifyNet VDD但如果是标准单元内部短路没办法在PR工具里直接改layout就得换单元或者跟库厂商确认。那次问题出在单元内部的N阱连接上我的处理是把原来用的那个biasnw variant换成库中另一个经过修的版本然后重新place。改完之后重新导出GDS和CDL网表重跑一遍Calibre。增量模式可以用calibre -lvs -spice ./lvs/top.cdl -turbo 8 -hier -incremental ./lvs/lvs_rule.calCalibre会自动复用上一次运行中没变化的部分速度快很多。最终那6处short全部清掉VDD/VSS短路消失后面原本连带的open和mismatch也少了近一半。5. Soft Connect问题深挖为什么总在混合信号项目里爆雷soft connect这个词只要做过后端的人多少都见过。但很多人并没有真正理解它是什么于是一看到报告里成片的soft connect就慌了要么什么都不做要么乱改设计两种都容易出事。5.1 先理解本质地基相连的两栋楼用生活类比来解释soft connect想象两栋独立的楼房地面上各有各的电网、水管但它们共用同一片地基。你在地面上测这两栋楼的电路它们是绝缘的但如果你顺着地基往下挖会发现它们其实通过大地连在一起。芯片里的地基就是P型衬底和N阱。两个名字不同的地net比如数字地VSS和模拟地AVSS在地表面的金属层里是分开的但它们都连着同一个P衬底所以通过衬底是导通的。这种连接Calibre叫它就是soft connect。5.2 Calibre的soft connect报告到底在说什么Calibre在处理soft connect时取决于rule文件里的LVS SOFT CONNECT SELECT语句它有几种表现把这类路径作为soft error报出来报告里会写类似Soft connect by NWELL between net VDD and net VSS。在某些设置下直接当成short error处理因为从物理电阻角度看它确实形成了连接通道。如果开关设成完全忽略那这种连接就不报但也有可能把真正的隔离问题掩盖掉。我的建议是不要为了图省事把soft connect完全关掉。尤其是混合信号项目里你需要的不是不看问题而是判断这个问题到底严重不严重。5.3 真问题还是假问题三个判断标准判断soft connect是否要处理我一般问自己三个问题这两个net在网表里本来就是同一个电位的不同名字吗比如VSS和DVSS实际上在系统里就是同一个地只是IC设计时起了不同的名字那soft connect就是假问题。解决办法是在网表里做alias合并或者在rule里把这两个net按同一个net对待。设计上这两个net是不是需要物理隔离比如模拟地的噪声要求很高数字地又特别脏两者虽然都接P衬底但你要确保它们不会通过衬底互相干扰。如果guard ring和deep nwell布置足够soft connect的影响被控制住了LVS报告里的soft connect就可以接受。有没有latch-up风险在某些电源时序下N阱和P衬底之间的寄生二极管可能导通形成闩锁。如果soft connect路径上存在大尺寸的寄生PNPN结构那就必须处理。这种问题靠LVS一般查不出来要结合ERC和rule check一起看。5.4 预防从PR阶段就控制PG连接和隔离环与其在LVS报告里跟成片的soft connect搏斗不如在PR阶段就做好隔离设计。有几个操作是实打实有效的给模拟模块加double guard ring同时让数字地VSS和模拟地AVSS在物理上被guard ring隔开。如果工艺支持deep nwell把模拟模块包在deep nwell里从衬底上物理隔断。在Innovus里用PG规划工具检查不同power domain是否因为某个std cell的bulk连接而意外联通。有人问我那Innovus里有没有办法提前看soft connect说实话PR工具不是干这个的它不会去模拟N阱电阻路径。真正能提前发现这类问题的是foundry的ERC/LVS规则。所以更实际的做法是第一次LVS跑完后花半天时间把soft connect的分布摸清楚哪些区域是正常的、哪些是多余的然后一次性在rule或网表里处理掉不要每次跑LVS都被同一批soft connect干扰。6. 验证提效与高频翻车点我在流片前反复用的几招到了最后部分我想分享一些没法写在教科书里的习惯。这些东西不会让你解决某一个specific错误但能让你整体跑LVS的周期缩短一半。6.1 正式LVS前再跑一遍verifyConnectivity这次加-gui第一轮LVS之前我已经在1.4节建议跑过verifyConnectivity。但正式流片前我会再跑一次并且把结果有问题的部分直接高亮出来verifyConnectivity -type all -error 1000 -warning 500 gui_highlight -net VDD -color red为什么要做两次因为第一次是在早期版本上跑的中间改过布线、加过fill、换过单元第二次是确认最终版的状态。很多工程师在最后一版数据上忘了重新跑verifyConnectivity结果Calibre跑完一堆open/short一查发现全是可以提前发现的低级错误。6.2 用grep提炼报告摘要别翻几百页PDFCalibre的report动辄几百页人眼翻肯定不现实。我的习惯是跑完后立刻在终端里做几个grepgrep -iE error|incorrect|short|open top.lvs.report | head -80 grep -iE soft connect top.lvs.report | wc -l这样一分钟之内就能知道错误集中在哪几类、大概多少条。如果错误数目很大比如几百个short我会先用后文说的办法判断是不是规则文件或网表的问题而不是一头扎进RVE里一个一个看。6.3 并行与内存调优让大芯片的LVS跑得更快大芯片的LVS最怕的就是跑到一半OOM。我的组合拳是calibre -lvs -spice top.cdl -turbo 8 -cluster 4 -hier -hyper 2 top_rule.cal-turbo 8主并行线程数。-cluster 4集群式并行适合多die或超大设计。-hyper 2开启二分层次比较进一步降低内存占用。这三个参数不是越多越好得看你机器。我的经验是内存小于64G的机器-turbo开8就够了别贪多。6.4 版本对齐Innovus、Calibre、rule三者缺一不可老工程师一定见过这种灵异现象同一个GDS、同一个网表上周用Calibre 3.48跑全绿这周换成Calibre新版本再跑报了一百多个错你还没改任何东西。版本不一致是LVS稳定性的一大杀手。我强烈建议每次流片前记录下三个版本号Innovus版本Calibre版本LVS rule文件的版本通常PDK里会带日期如果中途换PDK或换rule版本一定要重新跑一次冒烟LVS确认结果和旧版本一致再继续全量跑。要不然你在新版rule下改了一堆问题最后发现是rule本身变了那就太亏了。6.5 先查设计再改规则别一开始就改rule最后提一个最容易踩的坑遇到错误不要急着去改LVS rule。很多人跑了几个错误第一反应是这个错误是rule误报然后在rule里加exclude、加waive。这种操作行云流水但往往掩盖了真实问题。我的原则是除非能明确解释这个连接为什么在物理上是合理的、在电学上不会造成影响否则不要动rule。宁可花多点时间在Innovus里把每一条short/soft connect都看一遍也不要图省事用exclude把这个错误从report里消掉。因为flow到流片阶段你多排除一个真实错误就有可能在硅片上多收到一个fail chip。用一句话总结我的做法LVS这件事三分靠工具七分靠流程。把导出、规则检查、报告分类、定位修复、回归验证这些流程固定成自己的习惯你会发现那些一开始看着吓人的错误列表其实根本没有那么难对付。