★ FEATURED ARTICLE 从Innovus把最后一条ecoRoute跑完QoR看起来一切正常下一秒直接切到Calibre LVS打开log和report往往比跑线更让人心跳加速。我做数字后端这些年90%的“LVS卡住”都不是因为Calibre本身有多难而是出在Innovus和Calibre之间的数据传递、规则文件设置、以及一部分读报告的方法论上。这篇文章想把我从实际项目里沉淀下来的一套物理验证调试流程晒出来给正在做innovus数字后端、马上要签核或者刚入行要跑物理验证的同学当个参考。从Innovus导数据到Calibre收数据再到一份lvs.report里几百条错误里抽丝剥茧我都尽量讲得具体一些。其中会提到ECO buffer tree之后LVS突然爆错的案例也会详细讲soft connect这种让新手容易看懵的连接方式。最后补一些流程自动化、加速迭代的经验应用场景覆盖Block级验证和顶层集成验证希望能帮你少熬夜调flow。1. 从Innovus到底要交给Calibre什么一份干净的“交接物”清单1.1 版图导出GDS还是OASIS导多少东西出来很多同学第一次从Innovus里导GDS以为就是菜单上Export→GDS一步到位。实际没那么简单。签核要导出的物理数据不止一个“图形文件”还需要明确的层次关系、文本层、以及Power/Ground相关标记。我一般建议如果foundry的物理验证环境允许OASIS导出OASIS。Top-level下文件大小能差好几倍Calibre读OASIS也比读GDS快一些如果历史上一直用GDS没必要激进切换。GDS兼容性最好遇到下游脚本不认OASIS的情况很少但文件大了确实慢关键不是格式而是内容。Innovus里streamOut的时候通常用write_stream命令比如write_stream -format gds -lib library_name -file ./output/top.gds或者更常见的streamOut ./output/top.gds -mapFile ./runset/gds2.layermap -format gds -units 1000这里的-mapFile就是GDS层号映射。Innovus内部层跟你foundry给的标准层号不一定一致必须通过mapFile把Metal1、V1这些层“翻译”成GDS number。比如内部 M1对应GDS层 21文本层也有对应关系。少了map文件Calibre在提取时看到的是一片“层号错位”的几何图形LVS结果自然不可信。导出时还有一个容易忽略的参数是否包含sub-design blocks。顶层验证时一般希望把memory或IP保留成hierarchical cell其他标准单元打平。Calibre用h-cell机制可以做到既保留层次又不降低提取精度但如果你在GDS里把memory都打平后面想用h-cell加速也来不及。所以导出前先想清楚哪些cell要留层次。Text层也要带上。LVS报告最终能不能看着舒服关键就是top-level的net name和instance name是否进到GDS。Innovus里有些文本层不是默认streamOut的需要你自己在map文件里加。如果漏掉Calibre会将节点命名为“N12345”这类编号虽然也能debug但人脑处理起来累得多。1.2 输出给LVS的网表不是综合网表也不是仿真网表后端做完PlaceRoute之后你会得到很多种网表综合网表、仿真带寄生网表、时序signoff网表……但Calibre LVS要的是“版图对应关系最直接”的那个版本通常称为LVS网表或CDL网表。它的特点在于包含电源/地PG连接不像综合网表那样只关心逻辑连接标准单元库里的晶体管级描述要齐全或者至少顶层有明确的cell connection层次关系要和GDS一致能对上h-cell设置。在Innovus里我常用write_netlist ./output/top_lvs.v但纯粹用这个Verilog文件去做Calibre的晶体管级LVS通常不够。原因很简单标准单元库的晶体管级结构大多数不在这个门级Verilog里。所以实际项目里要么在Calibre规则里把库的CDL网表merge进来要么用foundry已经做好的“Simulation Program”先把门级网表展开成器件级。如果你有库里的CDL比如stdcell.cdl直接在Calibre中指定SOURCE PATH ./netlist/stdcell.cdl SOURCE PATH ./netlist/top_lvs.v这样顶层用门级底层器件结构用CDL补全。若没有CDL也可以让Calibre在比对时使用cell-to-cell的抽象方式——也就是把标准单元当成一个黑盒只比对端口连接关系但这样对很多签核要求来说不够严格尤其涉及ESD、IO结构时容易漏问题。这里要提醒一件事不同模式导出的网表可能不一致。有些工具在write_netlist时会根据你当前design的logical library自动生成但ECO之后Innovus内存里的网表可能和磁盘上的约束文件存在偏移。稳妥做法是ECO后直接导出不要用之前备份的netlist除非你非常确认没有改动。因为ECO改过connectivity后老网表会让LVS茶几上摆满假错。另外涉及IO cell和Power cell时普通Verilog网表往往缺少它们的电源地连接关系需要以“global power”的形式在Calibre规则里声明。很多人漏掉这一步导致所有IO buffer的VDD/VSS全部悬空LVS报告一大堆“missing port”。如果库里有物理验证用的CDL推荐优先使用CDL做LVS如果没有用Verilog门级网表配合rule中的device连接关系处理。两种方式都行但不要在同一次比对中混用两套来源不同的库容易产生诡异的匹配偏差。1.3 交接盲区layer map、电源文本、还有那点“运气”前面提过GDS导出的map文件但Calibre规则文件里也有自己的层映射。发生过这样的场景Innovus侧map文件是对的GDS layer 21是M1但Calibre规则文件里写的是layer 31于是所有M1图形都被识别成“未知层”LVS当然全是missing device。这不是Calibre的问题而是两个工具的“词典”不一致。为了避免这种事故最有效的做法是把layer map当作项目的正式交付物之一。统一用一个基准文件比如foundry提供的gds_mappingInnovus导出时基于它转成streamOut映射Calibre规则文件里的LAYER MAP语句也基于同一个文件。哪怕前端改了层号你也只改一个源头避免两边维护两个真相。还有一类交接盲区是文本层的归属。Power net名称、ground net名称、电源域标签通常以text形式存在于GDS中。Calibre LVS依赖这些文本做net naming和global net匹配。假如你在顶层将VDD text画成了VDDSCalibre把layout里这个net命名为VDDS而网表里叫VDD比对时就会产生net mismatch。处理方式是在规则文件里用TEXT语句和LVS COMPARE设置把VDDS统一成VDD。很多人忽略所以调了一个下午才发现根源是拼写不一致。“运气”这个词是开玩笑但确实有个习惯能提高命中率导完GDS和netlist后在Calibre里先跑一次不带hierarchy的“flat quick LVS”看看基础连接。如果这一步都稀碎后面调h-cell、调soft connect都是浪费时间。百分之八十的“LVS完全跑不通”都是这个阶段暴露出来的常见问题——层映射错、网表缺端口、电源域名称对不上。先把大头解决再推进到精细比对。2. Calibre LVS规则文件的门道层次映射与连接定义2.1 一份LVS规则文件到底在干什么很多人拿到Calibre的LVS规则文件看到上千行SVRF不寒而栗其实核心逻辑很清晰从GDS中提取出晶体管、电阻、电容、二极管的几何特征根据这些器件的连接关系生成一个layout netlist再用同样的网表比对引擎去跟参考netlist一一匹配。本质上是“从版图几何还原电路”的一个过程。规则文件里最核心的三个部分层定义把GDS层号赋给一个名字比如METAL1 L21组件定义通过逻辑运算得到实际使用的层比如有源区加注入区构成MOS管连接和器件定义CONNECT M1 V1 M2表示通孔V1连接M1和M2DEVICE NMOS(GATE,SOURCE,DRAIN)则告诉Calibre长什么样子的图形组合算是NMOS。有一回我们项目里抓到个很隐蔽的问题同一套GDS在旧版本Calibre上LVS clean换了新版本大概是3.48那代开始强制某些语法规范之后突然爆出几百个器件错误。后来发现规则文件里某个DEVICE语句依赖的层运算顺序变了需要重新定义。这种版本迁移的坑建议升级工具版本前把关键规则跑一遍golden deck并且留存版本对比报告。2.2 层次映射为什么Calibre里看不到层或者全部变成“空壳”新手遇到最多的是“所有MOS管都不认”。在RVE里打开extraction结果常见的表现是看到一堆“no electrical data”有图形但无器件instance上有warning说gate层缺失、或有源区没有注入层。这些问题90%出在层映射或层运算上。Calibre内部会把GDS层转为自己定义的内部层再通过运算生成derived layer。如果规则文件里写METAL1 L29而实际GDS第29层是注释那结果自然不对。另一个点极性positive/negative tone。有些层是负性光刻比如某些层在GDS里是挖掉一块规则文件要用MASK/REVERSE逻辑转换。streamOut时如果不注意正反版Calibre把整块芯片的衬底当成金属LVS会完全乱套。通常一旦出现整层全是反常连续图形的情况先怀疑负片层。调试时我习惯先用Calibre的RVE load提取结果配上Results视图把每一条导通的金属都显示出来。如果看到某层该连的地方没连多半是映射层号错了如果整片都连成一片极性是重点。2.3 器件定义和connect语句LVS真正在做“提取”时依赖的东西LVS提取不像人肉看版图它靠的是规则文件里一系列“几何推导”语句。比如MOS晶体管的识别基本的流程是由POLY和ACTIVE或DIFFUSION的交集画一个GATE检查注入层NIMP、PIMP来判断是NMOS还是PMOS分别把gate两边有源区标成source和drain。过孔则通过CONNECT声明把不同金属层连在一起CONNECT M1 V1 M2 CONNECT M2 V2 M3 CONNECT M1 P1 AA如果某个接触孔层没有connect那么M1到有源区的路径就断的器件source drain端口会悬空体现在report里就是“Port not connected”。很多时候打开net扫描会发现一个MOS管的drain是X并不是真的悬空而是接触孔层没被连接。所以调试到器件层面时不要只盯着gate图形也要检查OD/PO层附近有没有被“吞掉”的层。举个最常见的例子带dummy poly的MOS规则文件里如果没排除dummyCalibre会把dummy gate也当成一个多晶硅栅从而多提取出器件。但这种多提取的false device通常不会真正参与连接于是LVS报“extra instance”。看到这类错基本可以判断是规则文件对dummy的处理不完善而不是你layout画错了。2.4 软连接透过衬底和阱它也算一条路LVS里一个经典概念叫soft connect指的是两个本来应该隔离的信号通过PN结/衬底阱电阻形成了一条弱连接。数字芯片里到处都是衬底接触和阱接触VSS通过P扩散连到P衬底VDD通过N扩散连到N阱。若两个不同地之间共享同一块衬底就会形成一条从VSSA到VSSD的电阻路径。对于逻辑功能来说软连接往往不会影响时序但在物理验证里Calibre会在每个MOS的bulk端看到同一个衬底电位如果网表又把两个地的bulk连到一起Calibre就可能把它们短路。于是报告出现“Soft Connect / Short”之类的标注。处理软连接一般为两种情况在LVS中明确设计意图允许某些net通过衬底/阱互连使用LVS SOFT CONNECT语句或者利用LVS POWER NAME和LVS GROUND NAME把对标地先定住让Calibre在比对时忽略衬底上的软连接差异。项目里比较稳健的做法先看foundry给的参考deck里soft connect怎么写的不要自己乱删。乱删会让衬底每个接触点都断开导致有源区和衬底之间的“寄生二极管”全部报missing device写得太松又会把真正不该通的信号软连到一起。所以在你没有完全确认地分割策略比如有没有深N阱隔离之前尽量使用与foundry签核一致的设置而不是自己试出一份“自己的规矩”。3. LVS报告读法从“海量报错”里定位真实问题3.1 先看短路和开路其他先放一边真正跑完LVS报告可能上千行很多初学看到就头晕。我的习惯是按顺序看Short短路Open断路Net匹配错误Device失配Unmatched instance。短路的优先级最高因为它会导致大量相关的错误“群发”。比如一条SD网络和一条VDD短了Calibre可能会把整块区域内的几十个device都标记为wrongly connected如果你一开始就埋头改器件尺寸可能一晚上白干。短路的典型debug路径是在RVE里选中这条短路的net用“Trace”模式看高亮连通的几何形状。很多时候你会发现是两根相隔很近的金属线因为一条金属bridge或者一根“stray”的poly连到了一起。这时返回Innovus/布局界面看这两条net的坐标通常两分钟就能定位。开路相对好办一点report里会写明某个net的layout side缺失端口。最常见的是某个门级instance的电源端没连到电源轨上导致这个instance的VDD端口open。原因多半是标准单元放到了edge row没有翻转或没有水平电源轨穿过。也有少数情况是电源网用文本方式连接但文本拼写和网表不一致导致Calibre不认识算是“假open”。遇到“假open”我在RVE里直接看这个port周边有没有金属图形如果有但报open先检查电源文本层有没有被当作“空文本”过滤掉。这是一个非常典型的“层对不上”而不是“线没连”的案例。3.2 器件不匹配的三种常见形态器件不匹配普遍有三种instance数量对不上比如layout里比网表多出两个PMOS。常见于dummy cell被提取成真管器件类型不匹配网表里是NMOSlayout识别成PMOS。或者layout里是PMOS网表里是PMOS但bulk接法不同W/L尺寸不匹配最常见不代表你画错可能是某些source/drain区域被切掉一部分比如一根poly和ACTIVE交叠宽度偏了Calibre就把W计算得不同。再补充一个“不透明”的Latch-up相关结构、diode、电容也容易报。比如power-device区域里foundry为了让静电保护良好会在I/O边上放大量diode有些diode在网表里没有。如果你的规则文件没有加EXCLUDE语句排除这些允许器件LVS会一堆extra instance。协调办法是让规则文件更接近foundry的签核标准而不是在网表里硬加。匹配错误的修复不要一上来就改版图。先在RVE里看报错器件的extracted netlist和source netlist对照端口连接、宽长数值。如果两者端口连接完全相同仅W/L差异再回Innovus确认这条cell的尺寸是否被优化过。有一些差异是ECO时候替换了cell但网表没同步这种改网表就够。真正需要动版图的是那种“器件类型反过来”的错误通常是layer层定义反了不要轻易去改有源区注入层。3.3 在RVE里逐条核对的节奏感RVECalibre Results Viewing Environment是调试LVS的辅助利器它能加载lvs.report把每条错误列成表格并高亮到版图上。用的时候不必所有都看但至少要抓“代表性错误”。一个建议filter出error源。比如先按cell名过滤只显示Stdcell_layer相关的区域再按net名过滤只看错误最多的一条net。错误多不要紧关键是看最小的“误差别集合”。RVE里还可以用Cross-section功能切出剖面对判断衬底和阱连接极其有用。软连接问题在平面视图上看不出来切一刀看到N阱和P衬底的位置关系马上明白为什么会软连。调试节奏上我个人的习惯是先花15分钟粗扫Report把问题分类而不是立即逐条看。分类结果通常能给出一张表问题类型数量可能根因Soft connect3地分割/衬底接触过多Extra instance12dummy case未排除Gate short2文本层错误/金属桥接Missing port1电源文本拼写错误有了这表格再决定先处理哪类。因为很多错误之间是因果的处理完一个根因可能消除80个报错。4. 一次ECO buffer tree后LVS报错的完整排查链路4.1 改ECO后多出几十个“unmatched instance”先别改layoutECO是项目后期最常见的操作修时序、插buffer、换驱动每次付完款都以为万事大吉。但实际项目中innovus eco buffer tree之后最容易碰到的LVS问题之一是ECO插入的一组buffer没有正确连到电源地或者buffer chain中间某根金属段残留形成“半连接”。我遇到过一次印象很深的调试在28nm工艺上需求在某个data path里加4级buffer treeInnovus里ecoRoute后timing报告看起来没问题结果Calibre LVS一跑新增40多个unmatched instance。报告里明显多了一组相同类型的buffer都在同一坐标附近。我的第一反应不是去量版图而是把Innovus里ECO前后的网表做一次增量比较。因为ECO之后Innovus内存的网表应该已经带上了这批buffer。比较发现ECO确实在netlist里插了这4个buffer但LVS跑的时候因为顶层网表是从磁盘上的旧文件重新装载的根本没包含这次的ECO修改。也就是说版图多了buffer网表没有自然报unmatched。这不是版图问题是网表不同步。这种坑特别常见尤其在你用脚本批量跑LVS、但没有重新写netlist时。4.2 坐标回注把Calibre高亮导回Innovus真正需要动版图时最有效率的不是用眼睛在两端找。Calibre RVE里能看到错误实例的坐标在Innovus里也能通过坐标高亮同一位置。但更省事的方式是用Innovus的physical verification集成接口或者把报错坐标从RVE里导成文本再在Innovus里读进来。常规做法大致是在RVE里选中错误导出坐标列表可以保存成text在Innovus Tcl里读进来用highlight命令按坐标标记highlight -layer M2 -loc {x y}如果是单点问题直接打开layout editor在报错位置附近找一根短接的金属。也可以用Innovus自带的dbQuery -area按坐标查周围连线。我记得那次最后定位到的问题是ECO插入的buffer cell正好跨越了一根M3电源轨cell内部M1 VDD轨和旁边另一条信号线之间有残料。从Calibre report里看到是两条net之间的short坐标和这根M3轨完全对应。回到Innovus把那片区域放大确实看到ECO router留下的“dangling wire”搭到了信号线上。这个属于ECO后没有做area DRC的遗留问题。4.3 修复之后如何确保不是“假通过”修复通常有两种路径一是直接在版图里删除缺陷金属/重新连一根线二是回到Innovus里修正ECO再重新出GDS。我的建议是后者因为只有Innovus里修过后续netlist才不会和新GDS再次失配。修完后别急着直接开庆功先做到三点重新导GDS确保文本层和几何层都更新重新导出LVS网表绝对不要用上次那份跑完LVS之后再做一轮局部DRC重点看ECO区域。怎么确认不是“假通过”我的习惯是把LVS结果拿给做timing的同事再看一眼尤其是ECO相关的net。LVS clean不代表ECO效果达标如果buffer driving能力不足还是要回timing flow。但至少物理验证这边不再阻塞签核数据可以往下走。这个案例里最后的结果很简单重新ecoRoute删掉残料LVS clean全流程多花了一个下午。但如果你不会从报告分类出发而是一上来就改一堆instance width大概率会越改越花。5. 让Innovus与Calibre的往返不再折磨人自动化和脚本技巧5.1 一条命令跑完“导出、LVS、生成报告”全流程当你有block要反复迭代千万别一直手动点Calibre界面。手点不仅慢还容易点错选项。一般把流程拆成四步脚本Innovus里做streamOut和write_netlistsource ./scripts/export_for_lvs.tcl脚本内streamOut ./output/top.gds -mapFile ./runset/streamout.map -format gds -units 1000 write_netlist ./output/top_lvs.v用Calibre的命令行跑LVScalibre -lvs -hier -spice ./runset/lvs_rule.cal -design ./output/top.gds -netlist ./output/top_lvs.v -report ./output/lvs.report如果习惯foundry给出的图形界面也可以让Calibre在后台调一个runset模板再保存一个lvs_run.sh。关键是参数固定不要每次在GUI里手动选来选去。解析报告。你可以用一小段grep或者Tcl脚本把ERROR summary抓出来grep INCORRECT ./output/lvs.report | head -20这样每次迭代就能快速对比“错误数量是涨还是跌”。把lvs.report和生成的database导入RVEcalibre -rve ./output/lvs.report ./output/lvs.merge整个流程做成一个Makefile或bash脚本ECO之后一键跑效率高很多。自动化时有个小坑Calibre的临时目录和数据库文件需要按版本隔离多个任务并行时容易互相覆盖脚本里最好用##DSN_HOME##或者每轮生成独立时间戳目录。5.2 用h-cell和RAK做层级LVS时省时间做大规模SoC时flat LVS慢得离谱标准做法是设置h-cell。h-cell的意思是“保留这些cell的层次其余打平”。在Calibre规则文件里通常用LVS HCELL语句或命令行传入calibre -lvs -hier -hcell blockA -hcell memB ...h-cell设得好LVS提取速度能提升数倍且报告中还可以单独看每个block内部是否clean。h-cell的选择也有讲究不是越多越好。设得太多层次保留太多提取也没快多少设得太少memory和analog block会被过早打平结果出问题后很难判断是内部错误还是接口连接错误。我一般先把memory、analog、hard macro设成h-cell再根据报告里错误分布决定是否把某些标准单元block也提出来。RAKReference Application Kit是Innovus相关发行包里常见的一套脚本/流程框架很多客户会在其基础上改自己的implement flow。你在里面可以加一段“导出LVS netlist后自动调用Calibre”的hook。这样做的好处是你不用重新发明RAK已经帮你把环境变量、目录结构、标准单元库登记都处理好了。我通常顺手把h-cell列表放在项目config里每层project更新一次即可。5.3 更聪明的debug联动Calibre RVE与Innovus互操作不少团队希望点击RVE里的报错Innovus界面能跳到同一坐标。Calibre本身有“Layout VS Schematic debugging”功能可以和Virtuoso联动对Innovus通常用calibre -nocalibr去导出坐标再替换到Innovus里。有一个实用技巧利用Innovus的dbQuery -area按坐标查周围连线。我在调试时经常先把report坐标用简单脚本从lvs.report中抽出来转成一个包含net名和XY的CSV再写几行Tcl调highlight -loc。这样block级问题五分钟就能圈出范围不用反复用眼睛匹配。如果公司有自己的EDA辅助工具也可以把Calibre的MERGE文件直接解析把高亮和错误类别送进内部可视化工具。有了这种联动LVS debug才谈得上是“流程”而不是“手工作坊”。5.4 我个人的几个习惯最后给一些我自己总结的琐碎习惯希望对你有用。第一改任何规则文件前先备份并记录改动点。用git管理规则文件更好能对比这次跑LVS和上次到底改了什么很多“玄学”变成“这次规则文件里把某层极性写反了”。第二在Innovus里导出GDS时养成加-units 1000或foundry指定精度的习惯避免不同工具精度折算导致微小错位。特别是和模拟模块拼接时差一个database unit都可能让层次窗口对不齐。第三跑完LVS后建议顺手跑一下DRC不要等供应商/流片前才跑。ECO区域往往是DRC重灾区早发现早处理。LVS和DRC的数据基础完全一样一次导出的GDS可以同时喂给两边的runset不要为了省一次导出时间而用两份不一致的中间数据。第四如果报告里出现大量“unmatched”但layout图形一切合理先更新网表再怀疑版图。ECO流程中网表和GDS不同步是最高频根因之一。多团队协作时最好在每次ECO交付时把导出的netlist hash值附在邮件里避免有人拿到旧文件。第五遇到soft connect问题咨询功能时保留原始deck的默认设置不要通过硬删连接层去“解决问题”否则会掩盖真正的电源地隔离问题。真要调整也是在明确隔离方案后去改规则文件里的相关语句。这些都是我在多个项目里踩出来的不能保证每条都适用于所有foundry节点但在绝大多数数字后端物理验证流程里能帮你少走很多弯路。
阅读完成 · 觉得有帮助？
