今天吾爱IC社区小编为大家带来数字IC后端实现物理验证中关于LVS的主题分享。其实小编一直觉得这个主题没啥可讲的，考虑到一些新手没有太多的经验，还是做个简单的分享。经验都是来源于实际项目所积累的，所以建议多实践，毕竟实践出真知，实践是检验真理的唯一标准。后续还会简单做一个关于物理验证中DRC自动修复方法的分享。修DRC绝对不是你应该干的活，那绝对是Tool的任务。好了，下面直接进入今天的主题（想要加入微信技术交流群的，可以先加小编微信）。
LVS原理
LVS(Layout Versus Schematics)是物理验证中非常重要的一个步骤。它是用来检查设计的Layout是否和Netlist是否一致。其本质就是对比两个Netlist是否一致。工具将design的layout抽取出其对应的spice netlist，然后和source的netlist进行比对。因此，对于同一个GDS，做LVS时只需要第一次抽取一次netlist即可（无需每次都通过GDS抽取netlist）。物理验证LVS的流程图如下图所示。
从流程图中可以得知，在做LVS前，我们需要以下数据：
Post-layout的GDSII design.gds
Post-layout的PG Netlist design_pg.v
LVS RUNSET
在应用calibre跑LVS之前，应该先在ICC/ICC2中验证LVS，主要检查design中的short和open。同时也需要check pg是否有floating（floating pin需要fix，而floating shape则可以不用管）。
主要命令如下：
verify_pg_nets
verify_lvs -max_error 100 -check_short_locator -check_open_locator -ignore_floating_port -ignore_floating_net
check_lvs -checks {short open} -max_errors 100
如果ICC/ICC2中LVS都过不了（即可能存在short或者open），务必先在ICC/ICC2中将short，open全部清干净后，再进行物理signoff工具calibre的LVS check。
正常情况下，如果ICC/ICC2中均无short和open，则说明design的LVS基本上就没有太大问题。如果验证后calibre中仍然有错误，主要有以下几种情况
Text可能没打对或者没打全(比如某些PG可能是孤立的，并没有和其他连成一个整体power network)。此处提一个个人觉得比较重要的点，virtual connect 要慎用。
PG netlist中可能包含某些没有device的instance，比如普通filler cell，TCD等physical only cell。
LVS数据准备
Merge gds
ICC/ICC2导出的design.gds（不含标准单元），需要将design中用到的cell（比如IP ,IO和Memory等）的gds全部merge进去，产生一个design_merge.gds。gds merge工作可以在calibre或者virtuoso中实现。
产生spice格式的pg netlist
利用calibre自带的v2lvs命令，可以将设计的design_pg.v转换成工具识别的spice netlist。
v2lvs -v design_pg.v -o design_pg.spi
同时，还需要将design中用到的cell(比如IP, IO和 Memory等)的spice 网表，include到design_pg.spi中去。这些spice netlist通常是foundary或者vendor提供的，一般是spi或者cdl格式的文件。
常见LVS错误案例
Spice netlist file error
这种情况LVS报告提示 “NOT COMPARED”。通过查看LVS报告lvs.rep得知，因为source的spice网表存在错误，工具没有读取成功（比如某个ip的.spi文件不存在或者路径不正确）。
LVS Port name不一致
这种情况可能是由于TEXT打的方式不正确，比如少打TEXT，或者TEXT name不对。
LVS OPEN
很多时候我们是一边在做timing fixing，一边做DRC检查。在做timing fixing和DRC Fixing阶段，我们可能要做一些ECO或者要进行manual 的DRC Fixing。一旦有manual的操作，就存在出现错误的可能性，比如将某条net开路了。（正常情况下工具eco route后均不可能存在open的情况）。
通过RVE load LVS的SVDB文件，可以清晰看到LAYOUT上有两条NET，对应SOURCE上却只有一条NET。此时可以Highlight NET283 和NET504，进一步确认是否是这两条NETopen的情况。同时根据lvs.rep文件，我们也可以清楚看到LAYOUT上确实多了一条NET（只需查看AFTER TRANSFORMATION部分）。
LVS SHORT
出现short一方面是由于本身ICC/ICC2 route后本身就存在short而没有去fix掉。另外一方面可能是在fix DRC的过程中不小心导致的short。如果是实际layout上存在short，则表现为LAYOUT上的一条NET，对应到SOURCE则有两条NET。
通过RVE load LVS的SVDB文件和lvs.rep文件均验证了我们的猜测。同样我们可以Highlight出NET283，通过trace得知确实是LAYOUT上的两条NETshort在一起导致了LVS错误。
Device type mismatch
利用 LVS RVE 寻找bad component subtype error，可看到 RVE 所描述 layout部分Device type 为MP(P)，而SOURCE上所描述 layout部分Device type 为MP(PD )。因此说明该device在LAYOUT和SOURCE上Device type不匹配。
可利用 RVE去Trace Layout view 中 X3300/M1(12.860,64.820)的位置做进一步debug 。
Property ERROR
利用 LVS RVE 寻找Property Error中Discrepancy 的部分，可看到 RVE 所
描述 layout 部份 MP(P) w:0.9u，而 source 部分 MP(P) w:9u，说明layout 和 source 在此 MP(P) mos 的 width size unmatched。
这种Property error，有时候是可以waived的，具体情况需要与fab 或者vendor确认。
Power ground open and short
点击RVE界面左侧“Shorts Database”，选中short位置，进行Highlight cluster操作。通过定位发现是打Power 时VDD和VSS 短路了（VIa2多打了一部分导致short）。
LVS杀手锏
熟悉design中各个power domain划分和工作机理
Design中各个模块derive pg 正确
对需要打TEXT 的PG NET打上正确的TEXT
GDS Rename（比如Vendor 提供的IP）
对Netlist进行文本处理
Debug错误能力
联系客服
