文章右侧广告为官方硬广告，与吾爱IC社区无关，用户勿点。点击进去后出现任何损失与社区无关。
今天吾爱 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 数据准备
ICC/ICC2 导出的 design.gds（不含标准单元），需要将 design 中用到的 cell（比如 IP ,IO 和 Memory 等）的 gds 全部 merge 进去，产生一个 design_merge.gds。gds merge 工作可以在 calibre 或者 virtuoso 中实现。
利用 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 错误案例
这种情况 LVS 报告提示 “NOT COMPARED”。通过查看 LVS 报告 lvs.rep 得知，因为 source 的 spice 网表存在错误，工具没有读取成功（比如某个 ip 的. spi 文件不存在或者路径不正确）。
这种情况可能是由于 TEXT 打的方式不正确，比如少打 TEXT，或者 TEXT name 不对。
很多时候我们是一边在做 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 部分）。
出现 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 错误。
利用 LVS RVE 寻找 bad component subtype error，可看到 RVE 所描述 layout 部分 Device type 为 MP§，而 SOURCE 上所描述 layout 部分 Device type 为 MP(PD )。因此说明该 device 在 LAYOUT 和 SOURCE 上 Device type 不匹配。
可利用 RVE 去 Trace Layout view 中 X3300/M1(12.860,64.820) 的位置做进一步 debug 。
利用 LVS RVE 寻找 Property Error 中 Discrepancy 的部分，可看到 RVE 所
描述 layout 部份 MP§ w:0.9u，而 source 部分 MP§ w:9u，说明 layout 和 source 在此 MP§ mos 的 width size unmatched。
这种 Property error，有时候是可以 waived 的，具体情况需要与 fab 或者 vendor 确认。
点击 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 错误能力
小编知识星球简介：
在这里，目前已经规划并正着手做的事情：
ICC/ICC2 lab 的编写
基于 ARM CPU 的后端实现流程
利用 ICC 中 CCD（Concurrent Clock Data）实现高性能模块的设计实现
其他内容待定
在这里，各位可以提问（支持匿名提问，提问从此不再害羞），小编会在 24 小时内给予解答（也可以发表你对某个知识点的看法，项目中遇到的难点，困惑或者职业发展规划等）。
反正它是一个缩减版的论坛，增强了大家的互动性。更为重要的是，微信有知识星球的小程序入口。星球二维码如下，可以扫描或者长按识别二维码进入。目前已经有十一位星球成员，感谢这十一位童鞋的支持！欢迎各位铁杆粉丝加入！
相关文章推荐（不看保证后悔）
PBA（Path Base Analysis）想说爱你不容易（静态时序分析基础篇）
【惊呆了！】你居然还在用 flatten 方式进行 timing signoff
合理的时钟结构能够加速 Timing 收敛（时钟树综合中级篇）
【机密】从此没有难做的 floorplan(数字后端设计实现 floorplan 篇)
听说 Latch 可以高效修 hold 违例（Timing borrowing 及其应用）
秒杀数字后端实现中 clock gating 使能端 setup violation 问题
教你轻松调 DCT 和 ICC 之间 Timing 与 Congestion 的一致性
Scan chain reordering 怎么用你知道吗？
数字后端实现时 congestion 比较严重，你 hold 得住吗？
Final netlist release 前，你应该做好哪些工作?
深入浅出讲透 set_multicycle_path，从此彻底掌握它
数字后端实现时 congestion 比较严重，你 hold 得住吗？
时钟树综合（clock tree synthesis）基础篇
好了，今天的码字就到这里了，原创不容易，喜欢的可以帮忙转发和赞赏，你的转发和赞赏是我不断更新文章的动力。小编在此先谢过！与此同时，吾爱 IC 社区（52-ic.com）也正式上线了。吾爱 IC 社区（52-ic.com）是一个专业交流和分享数字 IC 设计与实现技术与经验的 IC 社区。如果大家在学习和工作中有碰到技术问题，欢迎在微信公众号给小编留言或者添加以下几种联系方式进行提问交流。
打赏的朋友，请长按下方二维码，识别小程序进行打赏，欢迎砸钱过来！小编晚饭能不能加个鸡腿，全靠它了，呵呵！
作者微信：
