#### 数字IC设计实现hierarchical flow物理验证Physical Verification 物理验证是芯片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?](https://link.zhihu.com/?target=http%3A//mp.weixin.qq.com/s%3F__biz%3DMzU5NzQ1NDI5Nw%3D%3D%26mid%3D2247484153%26idx%3D1%26sn%3D648f4ff1977f8eeb19ecb9bfc872238f%26chksm%3Dfe527e4fc925f7593fbdd4de792026c9ab0daf50e7cc84e7f674b686c8b8978b865f812d40a4%26scene%3D21%23wechat_redirect) **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)](https://link.zhihu.com/?target=http%3A//mp.weixin.qq.com/s%3F__biz%3DMzU5NzQ1NDI5Nw%3D%3D%26mid%3D2247484049%26idx%3D1%26sn%3D3fded05a51a3c43f1c5a2fca7e91960e%26chksm%3Dfe527e27c925f7313c879dbbd7ecbfc47f1ccde4abb3c4c862bc6a01da6f5e3dc8445ec191e7%26scene%3D21%23wechat_redirect)** **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检查，你们可以将它理解成GDS**flatten level的input floating检查**。 ERC的检查规则还是蛮复杂的，一般foundary提供的rule file比较通用，在实际项目中往往会报出很多假错，比如tie high和tie low cell上报ERC错误。因此为了更高效地debug ERC问题，需要按照自己的需求改rule file，然后再去RUN ERC，否则ERC假错太多，很难定位到真问题。