PV（physicalverification）
物理验证是芯⽚physical signoff必须做的⼀项⼯作，类似timing signoff阶段要⽤PrimeTime来进⾏时序收敛。⽬前业界公认采⽤Mentor Graphics公司出品的Calibre⼯具，它提供了⾼效的DRC，LVS和ERC的解决⽅案，同时⽀持层次化和Flatten模式的检查⽅式，⼤⼤提⾼了整个验证过程的效率。
DRC检查
DRC检查是指⼯具基于Foundary提供的rule file来检查当前design的GDS是否符合⼯艺⽣产需求，⽐如ba layer的检查，metal之间的spacing检查，via之间的spacing check，via enclosure check和metal denstiy的检查等。
如果发现DRC，⼯具会把对应的错误标出来，同时还会指出该地⽅违法了哪条rule。⽤户在使⽤calibre检查完DRC后，可以将DRC结果导⼊到PR⼯具中，⾼亮显⽰，分析产⽣此类DRC的根本原因，进⽽fix掉。
如何⽤⼯具⾃动修复数字IC后端设计实现绕线后的Physical DRC?
sleeptightHierarchical DRC
通过前⾯两个hierarchical flow的内容分享，我们知道现在的design基本上都是⾛的Hierarchical Flow（Chip规模⽐较⼤，Signoff周期可以缩短）。
仍然以之前分享的案例，Design A由⼦模块B，⼦模块C和Other Logic组成。当我们完成各个⼦模块和顶层的数字后端实现，我们需要将这些模块的GDS进⾏merge操作，合并成为⼀个Flatten A_merge.gds。最后再将这个merge好的GDS拿去跑DRC检查。腾飞教育
由于DRC检查并不是只检查，修改⼀次就可以马上收敛掉的。因此如果对于⼀个design每次都要通过将各个⼦模块merge成⼀个GDS再去跑DRC，那么整个DRC检查的周期可能增加⼀倍甚⾄更多。所以，我们在DRC检查前中期阶段，⼀般不采⽤这种⽅式。
那么，对于hierarchical设计实现的设计，我们应该如何⼤幅减少DRC检查周期呢?
DRC检查流程
各⾃模块的GDS Merge
俯瞰的拼音各⾃模块DRC Check & Fixing
顶层A only的GDS merge (这⾥可以不merge下⾯的⼦模块)
顶层A only DRC Check & Fixing
采⽤这种⽅式的DRC检查应该特别关注以下⼏点
模块拼接地⽅的PG (Metal的spacing & Ba layer DRC )
天线效应
模块interface的天线效应
教你轻松玩转天线效应(Process Antenna Effect)
DRC Fixing的⽅法和⼿段
tool的本职⼯作。能⾃动化的东西尽量吾爱IC社区⼩编再次强调下，DRC Fixing千万不要去⼿⼯fix，这真的不应该是你们该⼲的活，它应属于tool的本职⼯作
double pattern的layer，⼿⼯修DRC也变得不太现实，往往⼿要⾃动实现。特别是在22nm及以下⼯艺节点，由于底层有⼏层metal是属于double pattern的layer
⼯修DRC会越修越多。
添加route guide（route blockage）
调整cell的位置
换VIA的类型或者VIA数量
想彻底摆脱⼿⼯修复DRC的困境，可以前往⼩编知识星球上查阅。如果仍然有技术困惑，也可以在星球上提问。
LVS检查
LVS(Layout VS Schematic)检查主要是检查⾃动布局布线后的layout（Physical)是否Schematic（Logic）是⼀致的。很多初学者可能会觉得既然PR⼯具⾃⼰完成的布局布线，那么写出来的GDS理论上⼀定与逻辑功能是⼀致的。为何还要多此⼀举呢？
的确从APR⼯具本⾝来说，它确实不会改变原来的逻辑功能，仅仅只会做⼀些优化，但是跑APR的command是⼈为指定的，⽽且整个PR过程没有你们想象中的那么美好，还是有很多的⼈⼯⼲预步骤。⽐如你在ICC中为了修short删了⼀些线，为了修DRC的spacing问题，可能会将某些线open掉了。⽽⼀旦存在net open，那显然就是physical和logic是不match的，LVS检查结果⼀定是incorrect的。
中译英在线
不知道各位还记得⼩编之前分享过⼀个确保PR出去的GDS⼀定是LVS clean的⽅法吗？
Verify_pg_net (check_pg_connectivity)
Verify_lvs (check_lvs )
以上两⼤法宝请各位理解清楚并在⼯作中熟练使⽤。
服装促销sanicHierarchical LVS检查流程
PR⼯具吐GDS和Netlist
LVS数据准备阶段，PR完成⾃动布局布线后，需要通过写出设计的GDS和Netlist。写netlist需要特别留意，⽐如physical only cell是不需要写出来的。
整理Hcell list
环保英文⼀般情况下，为了LVS检查debug的便利性，我们强烈建议使⽤HCELL来进⾏LVS的⽐对。这个hcell list主要包含任何有device的cell，可以在PR⼯具中写个⼩脚本来获得。
Merge GDS
这⾥的Merge GDS需要将⼦模块A和B都merge进去，合并成⼀个整体的GDS，⽽不像跑Hierarchical
DRC时不需要merge下⾯的⼦模块。这点需要特别注意。
Create_text
在⽐LVS之前，还需要给design的GDS打上标签text，主要是给power net groud net打上对应的net名字。对于做power domain的设计，有时候还需要给local的power net打text，视情况⽽定。打text这步既可以在PR⼯具中完成，也可以在calibre中完成。
V2LVS
PR吐出的netlist是gate level的netlist，⽽calibre LVS所需要的数据输⼊netlist必须是spice格式的，因此需要通过calibre⼯具提供的v2lvs进⾏转换。
值得提出的是，在hierarchical设计中，模块接⼝处的信号可能会存在位宽顺序不⼀致，⽐如⼋位宽的信号，⼦模块可能是从0-7，⽽顶层调⽤可能是从1-7。碰到这种情况需要带上-l的选项
一般现在时练习题-l的选项，即转换spice netlist时读⼊⼦模块的netlist。
抽取GDS
LVS检查本质是将两个netlist进⾏对⽐，因此需要对design的GDS进⾏netlist抽取，这步往往需要消耗⼤量的时间。为了提⾼⼯作效率，同⼀个GDS只需要抽取⼀次netlist即可，后续LVS的⽐对只需要拿抽取后的netlist即可。
Netlist对⽐
将GDS抽取后的netlist与v2lvs转换后的spice netlist进⾏⽐对。对于hierarchical LVS⽐对中，还需要将⼦模块A和B设置bbox，这样⼯具在做LVS检查时，只检查⼦模块和顶层接⼝处，⽽不会trace到⼦模块内部中，⼤⼤节省了LVS的检查时间。
⽆论DRC检查还是LVS检查，建议⼤家养成使⽤脚本的⽅式来check，⽽不是还停留在使⽤gui界⾯来操作。每次⼩编看到不少⼈⽤gui来操作，我都替他着急。能⾃动化实现的东西为何要每次通过⿏标去点呢？本⽂中所⽤到的create text，Merge GDS，DRC和LVS检查的详细脚本可以移步知识星球查阅。
ERC检查
ERC检查主要是检查版图的电性能，⽐如衬底是否正确连接电源或地，有⽆栅极悬空等。说的再直⽩点就是检查电路中是否存在input floating的现象。⼤家还记得⼩编之前在知识星球上分享的检查input f
loating的golden脚本吗？那个脚本是检查gate level的input floating，⽐如与⾮门的⼀个输⼊端悬空问题，通过这个脚本可以直接报告出来。⽽ERC检查则是device level的input floating检查，你们可以将它理解成flatten level的input floating检查。滤波器英文
GDSflatten level的input floating检查
ibtERC的检查规则还是蛮复杂的，⼀般foundary提供的rule file⽐较通⽤，在实际项⽬中往往会报出很多假错，⽐如tie high和tie low cell上报ERC错误。因此为了更⾼效地debug ERC问题，需要按照⾃⼰的需求改rule file，然后再去RUN ERC，否则ERC假错太多，很难定位到真问题。
