物理验证是芯片physical signoff必须做的一项工作，类似timing signoff阶段要用PrimeTime来进行时序收敛。目前业界公认采用Mentor Graphics公司出品的Calibre工具，它提供了高效的DRC，LVS和ERC的解决方案，同时支持层次化和Flatten模式的检查方式，大大提高了整个验证过程的效率。
DRC检查
DRC检查是指工具基于Foundary提供的rule file来检查当前design的GDS是否符合工艺生产需求，比如base layer的检查，metal之间的spacing检查，via之间的spacing check，via enclosure check和metal denstiy的检查等。
如果发现DRC，工具会把对应的错误标出来，同时还会指出该地方违法了哪条rule。用户在使用calibre检查完DRC后，可以将DRC结果导入到PR工具中，高亮显示，分析产生此类DRC的根本原因，进而fix掉。
如何用工具自动修复数字IC后端设计实现绕线后的Physical DRC?
Hierarchical 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 & Base layer DRC )
- 模块interface的天线效应
教你轻松玩转天线效应(Process Antenna Effect)
DRC Fixing的方法和手段
吾爱IC社区小编再次强调下，DRC Fixing千万不要去手工fix，这真的不应该是你们该干的活，它应属于tool的本职工作。能自动化的东西尽量要自动实现。特别是在22nm及以下工艺节点，由于底层有几层metal是属于double pattern的layer，手工修DRC也变得不太现实，往往手工修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 )
以上两大法宝请各位理解清楚并在工作中熟练使用。
Hierarchical 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的选项，即转换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 floating的golden脚本吗？那个脚本是检查gate level的input floating，比如与非门的一个输入端悬空问题，通过这个脚本可以直接报告出来。而ERC检查则是device level的input floating检查，你们可以将它理解成GDSflatten level的input floating检查。
ERC的检查规则还是蛮复杂的，一般foundary提供的rule file比较通用，在实际项目中往往会报出很多假错，比如tie high和tie low cell上报ERC错误。因此为了更高效地debug ERC问题，需要按照自己的需求改rule file，然后再去RUN ERC，否则ERC假错太多，很难定位到真问题。
