第一次做5亿晶体管的SoC后端时我差点被LVS逼疯。Calibre LVS用平铺Flat方式整芯片比对跑了整整三天内存顶到256GB还在继续涨最后我在凌晨盯着log里不断跳动的提取进度决定切到Hierarchical Flow。这个决定最终把整个验证周期从一周压缩到一天半。那次之后我对亿级晶体管设计的LVS策略彻底改观不是工具不够强而是用Flat方式去啃亿级设计本身就是在拿核弹打蚊子资源全浪费在重复计算上。这篇东西不是说明书是我把这套Hierarchical Flow跑通之后把里面真正影响效率、影响结果可信度的关键节点整理出来尤其是5个必须卡死的阶段以及一个几乎每个大项目都会撞上、但官方文档里讲得特别含蓄的坑LVS soft connect软连接。如果你手里的设计超过1亿晶体管还在用Flat LVS硬扛或者切了Hierarchical但总报一些看不懂的错这篇应该能帮你少走不少弯路。1. 亿级晶体管设计里Flat LVS是怎么被拖垮的1.1 一版Flat LVS的真实资源账先算一笔账。一个5亿晶体管的SoC版图用GDS或者OASIS看全芯片数据量通常在20GB到50GB之间抽取出来的SPICE网表展开成Flat之后器件数量是几千万级节点数量轻松过亿。Flat LVS要做的是把整个版图网络和整个原理图网络分别摊平再做一次全局匹配。这个过程的存储开销不是线性的是超线性的网络合并、器件属性比较、节点对查找都会随着规模增长把内存和CPU时间推高。我当时那版设计纯提取阶段就吃了180GB内存后面LVS比较阶段又涨到240GB以上运行时间超过70小时。更要命的是中间只要改一个标准单元整片设计全部重跑。后端项目不可能不改版动一根金属线就要重来一次这种代价根本扛不住。1.2 Flat Flow的三个致命瓶颈第一个瓶颈是重复计算。标准单元库里一个INV_X1在芯片里可能出现了几十万次Flat流程下每一次出现都会被当成一个全新器件去抽取、去比对。同一个单元明明可以一次验证搞定却要重复算几十万次完全是无意义的资源浪费。第二个瓶颈是网络爆炸。平铺之后所有通过金属、过孔、衬底、阱连接在一起的图形会合并成一张巨大的连通图。电压域多、地平面多、guard ring多的时候网络数量会膨胀得非常快。有些网络在物理上跨了半个芯片在Flat网表里就是一个巨型网络后续任何跟这个网络相关的操作都奇慢无比。第三个瓶颈是全局比较。LVS比对阶段需要在版图器件和原理图器件之间建立对应关系。设计规模越大候选匹配空间越大很多启发式算法会退化表现为CPU时间剧烈上升。你可以观察logFlat流程最后几个小时往往就卡在同一段comparing上进度条几乎不动。1.3 Hierarchical Flow的核心思想不重复验证重复结构Hierarchical Flow的思路说起来很简单既然一个标准单元出现了几万次而且每次内部版图一模一样那我只提取和验证一次把结果保存下来顶层只处理单元之间的连接关系就好。这个一次验证多次引用的机制就是hcellhierarchical cell的意义。要注意的是Hierarchical Flow不是简单地把Flat LVS加个层次开关它涉及单元识别、接口抽象、边界连接、电源地网络处理、并行提取、结果增量更新等一系列环节。任何一个环节处理不当轻则报错重则结果完全错误。下面先讲清楚切换前的准备工作再逐步拆解5个关键阶段。2. 上Hierarchical Flow之前先判断设计够不够“层次化”2.1 数据体检GDS/OASIS、网表、层次深度不是所有设计都适合直接切Hierarchical。动手之前我会先做一轮数据体检看三个东西版图数据格式、原理图网表结构、层次深度。版图这边尽量用OASIS而不是GDS特别是数据量超过20GB的芯片。OASIS压缩率高层次信息保留完整Calibre读取速度也更快。GDS在超大规模设计下光是stream in就要耗费大量时间而且有些老流程导出的GDS会有重复多边形、破损层次后续hcell识别会出问题。网表这边要确认CDL或SPICE网表是结构化网表还是平滑网表。理想情况是网表里保留了与版图对应的层次化单元定义比如标准单元子电路、IP子电路、顶层模块。如果网表已经是打平的器件级网表后面做cell级比对会非常痛苦最好先让前端或数字实现团队提供保留层次的定义网表。层次深度方面我的经验是不是越深越好也不是越平越好。层次太碎hcell管理成本高层次太少又发挥不出Hierarchical优势。比较理想的状态是标准单元层、IP层、功能模块层、顶层这4到5级层次清晰而且同一子模块的重复实例数足够多。如果一个设计顶层下面挂了几百个完全不同的随机逻辑块每个逻辑块只出现一次那Hierarchical的收益主要来自标准单元和存储类IP而不是功能模块。2.2 hcell候选怎么圈定确定能不能分之后就要圈定哪些cell可以作为hcell。我习惯按三个维度筛实例数在版图和网表里重复出现次数最多的单元优先典型的就是标准单元、触发器、IO、存储器。单元面积面积大的单元即使实例数不多也值得作为hcell因为一次提取省下的资源很可观。内部一致性同一个单元名在版图里必须对应同一个版图结构。如果出现同名单元但内部图形不一致那必须处理否则hcell比对会失败。实际操作中我会导出版图和网表的instance count报告排序后取交集。一般标准单元库里排名前几十的单元就已经覆盖了芯片里70%以上的instance数量。把这些单元作为hcell候选性价比最高。2.3 规则文件里的层次化开关Calibre的SVRF规则文件里围绕层次化有一组专门的关键字和设置。我不打算把完整语法抄在这里因为在不同PDK和不同Calibre版本里写法会有一点差异但核心思路是一致的告诉工具哪些单元是hcell、用哪种方式做层次化约简reduce、是否允许并行提取。我会单独维护一个hcell列表文件每一行放一个单元名。规则文件里通过HCELL相关语句加载这个列表同时设置LVS REDUCE PARALLEL的模式。初步调试阶段先用串行reduce模式让工具输出完整的hcell判定报告确认没有奇怪的mismatch之后再切成树形或并行模式去追性能。这个顺序能省很多Debug时间。还有一个很容易忽略的点规则文件里有CELL的端口定义、电源地名称定义这些东西在Hierarchical Flow下必须覆盖到所有hcell。有些单元在Flat流程里端口识别不严谨也不影响最终结果但一旦做成hcell端口错了会被上层引用问题会放大。所以在正式切流程前先对hcell列表里的单元做一轮单单元LVS确认它们自己都能clean。3. 五个关键阶段实操拆解这套流程里我认为可以拆成五个必须卡死的阶段。每个阶段都有一个明确的交付物前一个阶段没过关不要急着进下一个。3.1 阶段一从网表和版图里圈定hcell清单第一个阶段是把候选单元变成确认单元。输入是第2节里筛出来的hcell候选列表输出是一份Calibre能够稳定识别的hcell清单。具体做法是先跑一版层次化LVS但设置成只报告hcell判定结果不做全芯片比对。Calibre会输出每个候选单元在版图和网表里分别被识别成什么类型、端口是否匹配、器件数量是否一致。我会重点看两个东西一个是同名单元在版图和网表里是否都能找到对方另一个是单元的尺寸device count / net count是否对得上。如果单元在版图里有但在网表里没有那就不能作为hcell。反过来网表里有但版图里没有也不行。只有两边都稳定识别的单元才允许进入hcell列表。这一步看起来繁琐但能省掉后面一大半莫名其妙的报错。3.2 阶段二用层次化提取把重复单元变成黑盒确认hcell之后进入提取阶段。这个阶段的本质是把hcell内部的版图和器件全部验证一遍然后把内部细节收敛成端口级行为对上层只暴露pin和instance。简单说就是把一个几万个器件的标准单元在顶层视角里看成一个带端口的黑盒。这个过程里我踩过最大的坑是abutment connection。标准单元左右相邻时很多电源、地、以及某些信号线是靠单元边界直接贴在一起实现连接的没有显式的金属线或过孔跨过边界。Flat流程里工具会通过图形连续性自动识别这种并接但Hierarchical流程里如果单元的边界形状、pin位置定义得不准确abutment connection就会丢失导致上层认为两个单元根本没连上。所以在这个阶段我会额外检查hcell的pin定义是否落在正确的层次和位置上特别是那些跨边界供电的pin。Calibre的LVS报告里会有abutted连接信息如果某个单元明明左右贴在一起报告里却完全没有abutted connectivity那基本就是pin定义错了。3.3 阶段三全局电源地识别与soft connect预处理第三阶段处理全局性的电源地网络。在Hierarchical Flow里VDD、VSS这类全局网络很特殊它们不是靠单个pin连起来而是大量单元各自的电源地端口在物理上通过金属平面、rail、guard ring、衬底、阱连成一大片。做层次化抽象的时候必须先把全局网络识别出来否则顶层合并时会出现海量pin-to-pin连接错误。我的做法是先单独列一份全局net名称清单包括所有电压域数字VDD、数字VSS、模拟VDD、模拟VSS、IO电源、PLL电源等。然后检查这些网络在hcell里是否被正确标记成全局网络。Calibre支持通过文本标签和逻辑连接关系来识别全局net所以版图上电源地的TEXT标签层次和文字必须规范。这个阶段同时要处理soft connect的预处理。简单说衬底和阱本身是半导体电阻不是理想金属连接但在LVS提取时同一个衬底区域里的两个substrate contact会被网络合并算法当成连通的。如果所有数字地和模拟地都通过同一个P衬底连着Flat LVS里工具还能靠算法去权衡Hierarchical Flow里这种合并会被封装进每个单元的抽象结果里导致顶层看到的地网络全部绑在一起。后面的第4节我会专门讲这个但阶段三就要开始动手声明哪些连接是soft connect该拆的拆、该忽略的忽略不要拖到顶层再处理。3.4 阶段四并行提取与断点恢复把跑批时间压下来前三个阶段把数据准备和规则检查做扎实之后才能开始追求速度。Hierarchical Flow的并行化主要体现在两个层面一是对多个hcell并行做单元级提取二是对顶层连接的reduce过程并行化。Calibre的LVS REDUCE PARALLEL支持不同的并行树结构。我这里建议先搞清楚瓶颈在哪如果CPU核数多、单核内存充足并行提取的收益明显如果内存紧张强行并行反而会触发swap速度更慢。实际项目里我一般先用四分之一的设计数据做一次短跑测出内存拐点再决定最终分配多少核跑全片。比如256核的机器我不会一把全塞进去而是先试32核、64核、128核看LVS runtime是否线性下降过了拐点就不再加核。另外要养成看中间日志的习惯。Hierarchical Flow通常是分阶段落盘的单元级结果会缓存。一旦某个环节失败断点恢复比Flat流程快得多。如果修改只涉及某个hcell内部版图理论上只需要重新验证这个cell和top level其他hcell的结果可以直接复用。这里要特别留意工具是否真的复用了旧结果别改了单元层次却因为时间戳没刷新导致全量重跑。3.5 阶段五Top Level比对与增量修正闭环最后一个阶段是做顶层比对。此时hcell内部已经验证通过顶层剩下的主要是单元实例之间的互联关系、IO、电源地框架、以及少量非层次化逻辑。顶层比对的运行时间一般只有全片Flat的十分之一甚至更少。跑完顶层后LVS报告会给出整个设计的比对结论。如果顶层报INCORRECT先不要急着全片重跑重点看错误落在哪个hcell里。如果错误集中在某个hcell说明这个单元自身有问题回过去修单元级数据然后只重跑这个cell和顶层如果错误分散在不同hcell之间的连接上那大概率是顶层连接抽象出了问题比如abutment、全局网络、soft connect。这个阶段的一个常见误区是只关注最后Pass/Fail。我会额外看一遍incorrect net的数量和分布。数量少但分布集中的错误通常是真实问题数量多且随机分布的反而可能是规则文件里某个全局设置坏了导致所有单元端口全部错位。这两种情况的修法完全不同。4. Soft Connect软连接最容易让Hierarchical结果崩掉的隐患4.1 到底什么是LVS soft connectLVS里有个概念叫soft connect国内做后端的人一般直接叫它软连接。它指的是两个本来应该电气隔离的网络通过一个高阻路径被连接起来了。最典型的例子就是P型衬底所有通过P衬底接触接地的区域在提取器眼里是连在一起的N阱同理所有N阱内的信号可能通过VDD电位点被连在一起。为什么叫soft而不是hard因为衬底、阱这类半导体区域本身是有电阻的它不是一根理想的金属线但在大规模LVS提取时如果你不做特殊处理工具的网络合并算法依然会把它们当成连通路径。这样一来数字地的电位和模拟地的电位就被软连接了明明两个地是不同电压域LVS却认为它们短路。小设计里这个坑不明显因为网络少、衬底接触数量有限提取器可能通过电阻模型自动识别出高阻路径。但亿级设计里整个芯片就是一个巨大的衬底网络所有substrate contact都在往同一个物理衬底上打如果规则文件不去声明soft connect的处理策略LVS的全局网络会变得极其臃肿跑出来的结果也不可信。4.2 在Hierarchical Flow里定位soft connect问题Hierarchical Flow下soft connect的破坏性是叠加的。原因在于每个hcell在提取阶段都会生成自己的内部网络连接关系如果这个hcell内部存在衬底到某个电源网络的软连接这个结果会被固化进hcell抽象后的端口和节点里。顶层在合并时会把几十万个hcell的内部软连接全部汇总本来在物理上分散的高阻路径在逻辑关系上全被当成直接连接导致顶层网络数量急剧膨胀甚至出现VDD和VSS短接的错误结论。我识别soft connect问题通常看两个信号。第一个信号是LVS报告里出现网络合并的警告比如某个网络的节点数量异常大明显超出了物理常识。第二个信号是电压域检查出错本来应该独立的模拟地AVSS和数字地DVSS在报告的net列表里被合并成一个。这种情况在Flat流程里可能还能通过器件属性区分但Hierarchical Flow下hcell内部的抽象往往掩盖了区分信息问题会变得更难查。还有一个容易被忽略的现象某个hcell单独跑LVS是clean的放到顶层就报错。这个单元单独clean、顶层即报错的典型原因就是soft connect在单元抽象时没有处理好。不是单元本身有问题是单元内部衬底连接和全局衬底网络在顶层被合并了。4.3 一套可落地的soft connect处理策略处理soft connect我有几个优先级不同的手段按顺序来。第一步先明确设计意图。哪些电源地之间是需要隔离的哪些通过衬底连接是可以接受的在混合信号芯片里数字地和模拟地通常要求隔离而数字域内部大量标准单元共用一个地这是正常的。所以不要一刀切把所有soft connect都取消那会把真正的连接关系也拆掉。第二步在rule file里显式声明soft connect关系。Calibre在这块有专门的soft connect控制机制可以通过声明关键字告诉工具哪些层、哪些net之间的高阻连接允许存在哪些不允许。比如声明衬底层可以连接所有标成DVSS的网络但禁止把DVSS和AVSS连在一起。具体语法在不同版本里略有差异但核心就是给soft connect划边界。第三步通过物理手段配合。光靠LVS规则去声明有时候不够工艺上常见的做法是加double guard ring把数字区域和模拟区域的衬底/阱隔开同时把guard ring接到对应的电位上。这样即使LVS规则文件不做很复杂的设置物理上连接路径也被切断了。在版图阶段就做好隔离永远比事后在LVS里补规则省事。第四步如果设计允许可以在LVS比较时屏蔽对某些soft connect的检查。这里要特别谨慎因为一旦屏蔽掉等于承认这两堆网络可以视为连通。如果设计里其实不允许这个屏蔽会把真实短路掩盖掉。所以屏蔽操作必须留下文档记录并且至少经过两个人确认。在Hierarchical Flow里我还建议对每个hcell单独检查soft connect的影响面。做法是把hcell单独提出来跑一遍LVS观察它内部是否存在因为衬底导致的软连接再决定这个单元应该用什么方式抽象。这个动作不能省很多顶层的大规模错误根源都在某个不起眼的IO单元里。5. 跑完不是终点结果可信度检查与日常Debug5.1 读懂LVS报告里的核心区块Hierarchical LVS跑完我先不急着看Pass/Fail先看报告里的CELL SUMMARY区块。这个区块会列出所有hcell的状态哪些cell被正确匹配、哪些cell在版图里有但网表里没有、哪些cell是reduced形式。如果这里出现异常即使顶层显示Pass我也认为结果是不可信的。第二个必看的是HCELL相关报告。正常情况下报告中会明确说明某个cell被识别为hcell并进行了一次性验证。如果说好了是hcell报告里却出现flattened或repeated processing字样说明规则文件没生效整个Hierarchical流程白跑了性能和结果可信度全部打折。第三个是INCORRECT DETAILS区块。在Hierarchical模式下错误信息会按照cell维度组织。我一般先把错误按cell分组观察分布规律。集中在某个cell里多半是cell内部问题分散在top level则优先查连接抽象和全局网络。5.2 HCELL不匹配与reduce错误怎么追HCELL不匹配是Hierarchical Flow里最让人头疼的问题之一。常见表现是版图里这个单元存在网表里也有同名子电路但二者匹配不上。原因通常有三类。第一类是端口名称或端口数量不一致。版图pin叫VDD网表端口叫AVDD虽然物理上可能连同一根线但LVS不认识这种别名必须把端口映射关系写清楚。第二类是内部器件类型不一致比如版图里用的是高阈值器件网表子电路里写的是普通阈值器件这种不匹配必须回设计源头修。第三类是单元内部的文本标签或边界层定义差异导致提取器看到的cell内容和预期不同。reduce错误则是另一种风格。工具在做层次化约简时会把等价单元合并成一种代表单元。如果两个版图单元图形完全相同但网表里是两个不同子电路名reduce之后会报mismatch。反过来网表里两个子电路完全相同版图单元却有细微差异比如多了一小段dummy metalreduce也会出问题。这类问题没有捷径只能通过报告里的cell名称列表逐个对比差异层。5.3 我的个人检查清单与调参建议最后分享一份我每次跑Hierarchical LVS前都会过的检查清单内容不复杂但能挡掉大部分低级错误版图数据是最终版时间戳是否一致有没有人在我跑LVS时还在改版图。网表版本和顶层名称是否匹配有没有未接线的端口。hcell列表文件里没有拼写错误的单元名。rule file里的电源地名称和hcell端口名称一致。soft connect声明覆盖了所有电压域数字地和模拟地没有无意识合并。并行核数和内存匹配日志里没有swap记录。单元级和顶层级的缓存目录权限正常修改hcell后旧缓存没有污染新结果。LVS报告里的HCELL状态与预期一致。不要只看一个seed或一组参数就下结论关键设计改为验证多跑一次确认稳定。在我自己团队里这条清单已经贴在工位上了。大数据量设计跑一轮LVS要几个小时甚至一天任何一步低级错误都可能浪费整个batch窗口。宁可多花十分钟把清单过完也不要对着一个跑了20小时的坏结果发愁。调参方面也多说一句Hierarchical Flow不是开箱即用的每换一个工艺节点、每换一个PDKhcell策略都可能要重新调。第一次切换时不要一上来就追求全片最优性能先用一个小模块完整跑通流程确认每一份报告都符合预期再逐步把规模放大。这套流程只要跑通一次后面所有项目都可以站在这个基础之上继续走。