LVS原理

作者: 飞奔的大虎 | 来源:发表于2022-02-24 10:04 被阅读0次

LVS三种模式的工作原理
LVS
LVS-NAT原理介绍和配置实践
LVS-TUN原理介绍和配置实践
2022-02-16
LVS-DR原理介绍和配置实践
LVS原理篇：LVS简介、结构、四种模式、十种算法（转）
LVS负载均衡面试题
LVS原理
LVS原理

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§，而 SOURCE 上所描述 layout 部分 Device type 为 MP(PD )。因此说明该 device 在 LAYOUT 和 SOURCE 上 Device type 不匹配。