数字IC设计实现hierarchical flow之物理验证篇

数字IC设计实现hierarchical flow之物理验证篇

文章右侧广告为官方硬广告，与吾爱IC社区无关，用户勿点。点击进去后出现任何损失与社区无关。

吾爱 IC 社区上周推出了七月份的第一波福利活动。整个活动共有 6 人参与（公众号后台看到共 20 人转发文章，可能是个别有看完文章默默转发的习惯吧，感谢！），虽然活动参与度不高，但是前 3 名点赞数还是特别高。因此本次活动中奖率高达75%。

一等奖：Hongki （点赞数 163，转发 12 个群）

二等奖：darry （点赞数为 44，转发 10 个群）

三等奖：Sinx （点赞数为 54，转发 5 个群）

祝贺以上这三位朋友，都是本社区的铁杆粉丝了。请中奖的朋友将地址和联系方式，私信小编。小编会在当天将礼品卡（美容卡和水果茶券）快递到各位手上。

没有中奖或者没有看到上次活动的朋友们，请继续关注公众号本月的第二波活动推送。听说将吾爱 IC 社区公众号置顶后就不会错过任何精彩干货分享和福利奖品活动。

最近小编在忙芯片 tapeout，也没空去打印书籍送给大家。又恰逢上海南汇水蜜桃上市季节，第二波活动打算先送出4 箱水蜜桃，每箱价值 100 元。活动细节过两天再推送（如果你是老铁，应该知道小编每年都会送水蜜桃的哦）。

2019 年数字 IC 后端校招笔试题目（附数字后端培训视频教程）

史上最全的数字 IC 后端设计实现培训教程（整理版）

好了，下面进入今天的主题分享。

吾爱 IC 社区之前分享了数字 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?

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 检查，你们可以将它理解成 GDS flatten level 的 input floating 检查。

ERC 的检查规则还是蛮复杂的，一般 foundary 提供的 rule file 比较通用，在实际项目中往往会报出很多假错，比如 tie high 和 tie low cell 上报 ERC 错误。因此为了更高效地 debug ERC 问题，需要按照自己的需求改 rule file，然后再去 RUN ERC，否则 ERC 假错太多，很难定位到真问题。

小编知识星球简介（如果你渴望进步，期望高薪，喜欢交流，欢迎加入 ****）：

在这里，目前已经规划并正着手做的事情：

• ICC/ICC2 lab 的编写

• 基于 ARM CPU 的后端实现流程

• 利用 ICC 中 CCD（Concurrent Clock Data）实现高性能模块的设计实现

• 基于 ARM 四核 CPU 数字后端 Hierarchical Flow 实现教程

• 时钟树结构分析

• 低功耗设计实现

• 定期将项目中碰到的问题以案例的形式做技术分享

吾爱 IC 社区知识星球星主为公众号” 吾爱 IC 社区” 号主，从事数字 ic 后端设计实现工作近八年，拥有55nm,40nm,28nm,22nm,14nm等先进工艺节点成功流片经验，成功tapeout 过三十多颗芯片。

这里是一个数字 IC 设计实现高度垂直细分领域的知识社群，聚集了无数数字 ic 前端设计，后端实现，模拟 layout 工程师们。

在这里大家可以多建立连接，多交流，多拓展人脉圈，甚至可以组织线下活动。在这里你可以就数字 ic 后端设计实现领域的相关问题进行提问，也可以就职业发展规划问题进行咨询，也可以把困扰你的问题拿出来一起讨论交流。对于提问的问题尽量做到有问必答，如遇到不懂的，也会通过查阅资料或者请教专家来解答问题。在这里鼓励大家积极发表主题，提问，从而促进整个知识社群的良性循环。每个月小编会针对活跃用户进行打赏。

最重要的是在这里，能够借助这个知识社群，短期内实现年薪百万的梦想！不管你信不信，反正已经进来的朋友肯定是相信的！相遇是一种缘分，相识更是一种难能可贵的情分！如若有缘你我一定会相遇相识！知识星球二维码如下，可以扫描或者长按识别二维码进入。目前已经有265 位星球成员，感谢这265 位童鞋的支持！欢迎各位渴望进步，期望高薪的铁杆粉丝加入！终极目标是打造实现本知识星球全员年薪百万的宏伟目标。

欢迎关注 “吾爱 IC 社区”

微信号：ic-backend2018

https://mp.weixin.qq.com/s/h9z2G7DRV69Ct2VZqJppBg