数字后端verication物理验证流程

数字后端verication物理验证流程

LVS原理

LVS（LayoutVersusSchematics）是物理验证中非常重要的一个步骤。它是用来检查设计的Layout

是否和Netlist是否一致。其本质就是对比两个Netlist是否一致。工具将design的layout抽取出

其对应的spicenetlistf然后和source的netlist进行比对。因此，对于同一个GDS,做LVS时

只需要第一次抽取一次netlist即可（无需每次都通过GDS抽取netlist）。物理验证LVS的流

程图如下图所示。

从流程图中可以得知，在做LVS前，我们需要以下数据：

Post-layout的GDSIIdesign.gds

Post-layout的PGNetlistdesign_pg.v

LVSRUNSET

在应用calibre跑LVS之前应该先在ICC/ICC2中验证LVS主要检查design中的short和openo

同时也需要checkpg是否有floating（floatingpin需要fix,而floatingshape则可以不用管）c

主要命令如下：

verify_pg_nets

verifyjvs-max_error

100-check_short_locator-check_open_locator-ignore_floating_port-ignore_floating_net

chcck_lvs-checks{shortopen}-max_crrors100

如果ICC/ICC2中LVS都过不了（即可能存在short或者open），务必先在ICC/ICC2中将short,

open全部清干净后，再进行物理signoff工具calibre的LVScheck。

正常情况下，如果ICC/TCC2中均无short和open,则说明design的LVS基本上就没有太大问

题。如果验证后calibre中仍然有错误，主要有以下几种情况

Text可能没打对或者没打全（比如某些PG可能是孤立的，并没有和其他连成一个整体

powernetwork）o此处提一个个人觉得比较重要的点，virtualconnect要慎用。

PGnetlist中可能包含某些没有device的instance比如普通fillercell,TCD等physicalonly

cello

LVS数据准备

Mergegds

ICC/ICC2导出的design.gdK不含标准单元），需要将design中用到的cell（比如IPJO和Memory

等的gds全部merge进去产生一design_merge.gdsogdsmerge工作可以在calibre或者virtuoso

中实现。

产生spice格式的pgnetlist

利用calibre自带的v21vs命令，可以将设计的design_pg.v转换成工具识别的spicenetlisto

v2lvs-vdesign_pg.v-odesign_pg.spi

同时,还需要将design中用到的cell（比如IP,IO和Memory等）的spice网表,include到

design_pg.spi中去。这些spicenetlist通常是foundary或者vendor提供的,一般是spi或者cdl

格式的文件。

常见LVS错误案例

Spicenetlistfileerror

这种情况LVS报告提示“NOTCOMPARED”。通过查看LVS报告Ivs.rep得知，因为source的

spice网表存在错误,工具没有读取成功（比如某个ip的.spi文件不存在或者路径不正确）。

LVSPortname不一致

这种情况可能是由于TEXT打的方式不正确，比如少打TEXT,或者TEXTname不对。

LVSOPEN

很多时候我们是一边在做timingfixing,一边做DRC检查。在做timingfixing和DRCFixing阶

段，我们可能要做一些ECO或者要进行manual的DRCFixing。一旦有manual的操作，就存

在出现错误的可能性，比如将某条net开路了。（正常情况下工具ecoroute后均不可能存在

open的情况）o

通过RVEloadLVS的SVDB文件，可以清晰看至（JLAYOUT上有两条NET,又寸应SOURCE上

却只有一条NET。此时可以HighlightNET283和NET504,进一步确认是否是这两条NETopcn

的情况。同时根据lvs.rep文件,我们也可以清楚看到LAYOUT上确实多了一条NET（只需查

看AFTERTRANSFORMATION部分）。

LVSSHORT

出现short一方面是由于本身ICC/ICC2route后本身就存在short而没有去fix掉。另外一方面

可能是在fixDRC的过程中不小心导致的short,如果是实际layout上存在short,则表现为

LAYOUT上的一条NET,又寸应至USOURCE贝I」有两条NET。

通过RVEloadLVS的SVDB文件和Ivs.rep文件均验证了我们的猜测。同样我们可以Highlight

出NET283,通过trace得知确实是LAYOUT上的两条NETshort在一起导致了LVS错误。

Devicetypemismatch

利用LVSRVE寻找badcomponentsubtypeerror，可看到RVE所描述layout部分Devicetype

为MP(P),而SOURCE上所描述layout部分Devicetype为MP(PD)0因此说明该device在

LAYOUT和SOURCE上Devicetype不匹配。

可利用RVE去TraceLayoutview中X3300/M1(12.860,64.820)的位置做进一步debug。

PropertyERROR

利用LVSRVE寻找PropertyError中Discrepancy的部分，可看到RVE所

描述layout部份MP(P)w:0.9u,而source部分MP(P)w:9u,说明layout和source在此

MP(P)mos的widthsizeunmatched。

这种Propertyerror,有时候是可以waived的，具体情况需要与fab或者vendor确认。

Powergroundopenandshort

点击RVE界面左侧“ShortsDatabase",选中shor(位置,进行Highlightcluster操作。通过定位

发现是打Power时VDD和VSS短路了(VIa2多打了一部分导致short)