在一个芯片的最终tape-out时候，物理验证的一个重要的检查项当属LVS莫属。先来一张帅图镇贴。 ^_^
LVS 的目的
和功能类的一致性的比较formal相对而言，芯片里边的LVS可以视为物理版图（GDS）和原理图（Schematic）的已于比对规则文件（LVS）完成的一致性比较。所以LVS的全称即是：Layout Versus Schematic。
版图（Layout）是指：工具（Calibre）对二进制文件（GDS）进行到spice网表的转化，
原理图（Schematic）是指：工具（v2lvs）将verilog进行spice的网表转化，
规则文件（RSF）：是对GDS的操作，以及LVS比对是的常规配置
所以，用下表来对LVS和formal（LEC/formality）进行一个比较
类目/工具 | Golden | Revised |
formal RTL | RTL | syn-netlist |
formal gate | syn-netlist | layout-netlist |
LVS | layout-netlist | GDS |
可以看到，最终的用户会得到这样一个功能侧的恒等式
RTL = syn-netlsit = layout-nelist = GDS
最终的目标就是让流片的GDS功能恒等于RTL，确保功能，版本等等的正确。
PS：这里的等式标注了功能侧，这是因为GDS里边包含了除过功能侧意外的其他的组件（这些组件并不会影响对RTL功能的比对），包括但不限于：
- std-cell 版本
- 合规RSF版本：TO的GDS，必须是包含在某个合规RSF检查通过的数据。
- IP/phy的版本
- PG/UPF/PD/MV 信息
- physical-only cell： Clamp，process-cell，marker-cell etc.
LVS 的输入文件和使用
综上所述，开始一个LVS的比对，通常需要有下列三个文件，分别是：
- GDS
- PG netlist
- RSF
下面对这些输入文件的数据要求和使用分布做一下阐述。
GDS 导出和处理技巧
GDS导出和整合（merge）
这里的GDS的源头，就是从APR的layout数据库里边直接吐出来的GDS，但是通常这个GDS是无法直接给LVS去使用的，可能会有包含并不限于下列的因素：
- GDS不完整
- S家流程：ICC/ICC2的MW/NDM，的数据源是LEF，instance 的GDS的只有边框信息
- C家流程：enconter/innovus的数据源是LEF，instance 的GDS的只有边框信息
- GDS 的merge和版本问题
- 通过APR merge GDS
- S家的ICC：完全不支持GDS 导出时的 GDS merge
- S家的ICC2：使用命令
write_gds -merge_files $GDS_FILE LIST进行GDS导出时的GDS merge。这个是强制复写，无论NDM是否包含实际的instance的GDS信息，通过-merge_files选项，在导出GDS的时候强行merge-in 指定的GDS信息 - C家enconter/innovus：使用命令
streamOut -merge $GDS_FILE LIST进行GDS导出时的GDS merge。通过-merge选项，在导出GDS的时候merge-in 指定的GDS信息。
- 通过Calibre命令进行GDS merge：
layout filemerge -in $TOP_GDS -in $LIB1_GDS -in $LIB2_GDS [-mode append|overwrite|rename|forcerename] -out $FULL_GDS - 推荐和理由
- 上述多种方法的merge结果相同，这里依然推荐Calibre，理由如下：
- 从方便和版本控制的角度讲：首推Calibre。由于芯片在APR工具里边进行的修复，通常和IP/LIB的GDS没有直接关系，加之芯片流片前的：ROM_code/IP_update/parition_update等需求，在顶层人员手中，只需要控制好各个版本，而无需打开APR工具，既可以完成最终的合片，所以，使用Calibre的优势就比较明显。
- calibre的GDS merge，对于控制（模式/版层/深度/缩放/cell_name映射等）和rename的报告比较友好，对于大芯片的GDS merge质量控制是有一定优势的
PS：Calibre里边还有一个layout merge，这个命令的作用将两个GDS内容合并成一个新的GDS，这里不做赘述
GDS port信息的准备
由于LVS的比对方式很像formal，把实际的目标当作一个黑盒，所以无论是flatten（nmLVS）还是hierarchy（nmLVS-H：这个基本是现代LV的常用方式）的LVS，都需要将两个目标黑盒（GDS/netlist）的port先进行比对。所以GDS里的port信息，在用户导出GDS之前需要谨慎处理，但是calibre DRC通常对这个信息不敏感，这个也是LVS的特殊之处。
Calibre通常使用text（label）对芯片的port进行识别，通过查阅DRM手册，可以看到GDS里边的text版层定义
所以，用户在导出GDS的之前，需要在所有的port上定义好对于的port text（label），譬如：port：“A”对于的terminal 在M5，那么用户需要在M5 terminal的shape 范围上创建一个文本：“A”。通常建议放置到这个terminal的中心位置，并且要谨记port和terminal layer的不能错层，这个对于后期出bump坐标也是可以共用的坐标点。譬如这里的信号port：P11
对于所有的信号port，通常比较容易，因为常规的方法是一个信号 port通常只会有一个terminal，多terminal通常是被禁止的，不利于extraction和顶层连接。
PG的port会有一些特殊，这是因为PG通常是multi-terminal，这个会很方便连接PG，通过看IP的PG pin 就能感受到这个现象
主要是可以有效提高供电质量。
所以对于PG 的text，这里需要强调以下几点：
- 需要符合设计初衷：尽管设计中的PG是一张网络，用户需要严格定义PG text的位置，只能对真正会有PG输入的点进行定义，不能每个PG terminal 都定义一个text，这里分为block和top 两种情形
- 譬如这样一个block，有两层PG走线
现在很多项目为了保留更多的绕线资源给block，通常只连接最顶层的PG 网络，譬如这里的M5，所以用户如果需要在局部使用M4作为internal route，还是有操作余地的，所以在创建PG text的时候只能创建M5的text，这样在做后期block LVS （后续会详细展开）以及IR的时候才能算是尊重设计。 - 对于top设计，PG的text尤其重要：用户只能在bump/bonding out的PG terminal定义text，否则会给芯片的LVS带来真实的hole
这个例子里边，上部（upper）的PG shape和下部（lower）的PG shape在芯片内部是隔断的，这恶时候芯片也只会在下部的VDD bump point一个对外连接点，这个时候，如果用户错误的在上部定义了另一个
对于port还有一个有趣的事情，所有的IP都有自己的port text，也会放到比较高的层级，譬如IO上的port，VDD IO的通常会在M5层级创建一个text恰好也叫VDD，但是top-level的对于这恶VDD IO在顶层的应用是在VDD_MAIN net上，譬如下图
所以，最终的GDS在同样的M5 shape会有两个text：VDD和VDD_MAIN，遇到这种情形，通常需要在LVS的配置里边声明如下命令，来强制工具只识别top-level的text，来避免产生这种冲突：TEXT DEPTH PRIMARY 随着工艺复杂度不断提升，layer:datatype的应用也越来越普遍，APR工具在导出GDS的时候，都会应用一些类似map file的方式进行GDS stream-out的微控制，可以控制port/text的输出。就算用户创建了port text，也需要在mapfile里边，进行对应的配置，否则也会出现text没有被导出的情形，这样也会导致LVS的失败。具体操作细节，请参考各个EDA工具的配置手册
PS：由于C家和S家的一些策略区别，prboundary的处理也有一些不同：S家需要在工艺指定的prboundary层基于die boundary创建user_shape ，才可以导出；C家需要在mapfile 里边定义layerObjName/layerObjType 非别为DIEAREA/ALL，以及层号和数据类型（layer 和datatype），即可导出。
