企业官网建设流程全解析

第一次做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时间剧烈上升。你可以观察log，Flat流程最后几个小时往往就卡在同一段"comparing"上，进度条几乎不动。

1.3 Hierarchical Flow的核心思想：不重复验证重复结构

Hierarchical Flow的思路说起来很简单：既然一个标准单元出现了几万次，而且每次内部版图一模一样，那我只提取和验证一次，把结果保存下来，顶层只处理单元之间的连接关系就好。这个"一次验证，多次引用"的机制，就是hcell（hierarchical 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 connect

LVS里有个概念叫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. 跑完不是终点：结果可信度检查与日常Debug

5.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 metal），reduce也会出问题。这类问题没有捷径，只能通过报告里的cell名称列表，逐个对比差异层。

5.3 我的个人检查清单与调参建议

最后分享一份我每次跑Hierarchical LVS前都会过的检查清单，内容不复杂，但能挡掉大部分低级错误：

• 版图数据是最终版，时间戳是否一致，有没有人在我跑LVS时还在改版图。
• 网表版本和顶层名称是否匹配，有没有未接线的端口。
• hcell列表文件里没有拼写错误的单元名。
• rule file里的电源地名称和hcell端口名称一致。
• soft connect声明覆盖了所有电压域，数字地和模拟地没有无意识合并。
• 并行核数和内存匹配，日志里没有swap记录。
• 单元级和顶层级的缓存目录权限正常，修改hcell后旧缓存没有污染新结果。
• LVS报告里的HCELL状态与预期一致。
• 不要只看一个seed或一组参数就下结论，关键设计改为验证多跑一次确认稳定。

在我自己团队里，这条清单已经贴在工位上了。大数据量设计跑一轮LVS要几个小时甚至一天，任何一步低级错误都可能浪费整个batch窗口。宁可多花十分钟把清单过完，也不要对着一个跑了20小时的坏结果发愁。

调参方面也多说一句：Hierarchical Flow不是开箱即用的，每换一个工艺节点、每换一个PDK，hcell策略都可能要重新调。第一次切换时，不要一上来就追求全片最优性能，先用一个小模块完整跑通流程，确认每一份报告都符合预期，再逐步把规模放大。这套流程只要跑通一次，后面所有项目都可以站在这个基础之上继续走。