设计规则检查总是报错？教你自定义DRC过检高级玩法

本人实际测试Cadence IC618和Calibre 2021时, 踩过好多令DRC跑飞以及假错到处都是的坑, 新手依照步骤一步步进行操作, 便能轻松躲开这类常见问题。

如何自定义DRC规则文件

当我才开始着手进行DRC自定义之际, 一下子就被那有着几千行的规则文件给吓得懵住了。实际上呢, 其核心逻辑是十分简单的: 规则文件从本质上来说, 是一个用于条件判断的脚本。

首先, 寻得你的PDK目录。于Terminal里先输入find / -name”*.drc” 2>/dev/null, 进而定位至诸如SMIC_018_MM/Rule/这般的文件夹。接着, 将一份原始规则复制至你的工作目录, 千万不要在原文件之上进行直接修改。

新手要避开的坑: 复制之际, 务必要让后缀名全然保持一致。好多人本就直接复制txt后缀, 致使Calibre没办法识别, 报出“Cannot open rule file”。正确的做法是维持.drc或者.rul后缀, 抑或是在用cp命令之时加入–preserve参数。

第二步, 借助文本编辑器将规则文件打开, 寻找到DRC CHECK MAP区域, 此区域对全部的检查项予以了定义。把你打算屏蔽的规则前面添加上//进行注释处理, 诸如// DRC CHECK POLY1 POLY2这种形式；每次仅注释三至五条规则, 之后开展一次DRC验证效果的操作。

新手请注意避开这个坑: 一次对过多规则添加注释, 会致使DRC逻辑出现错乱。最为常见的现象是, 报出“Undefined parameter in DRC engine”这样的提示, 在这种时候, 并不能说明是规则文件坏掉了, 而是当你在对规则进行注释操作时, 把变量定义也一并给注释掉了。解决的办法是: 在进行注释之前, 使用grep -n”define” your.drc去查找一遍变量定义行, 以此来避免出现误删的情况。

规则检查跑不过怎么办

当你把规则自定义给完成了以后, 运行DRC的时候, 总是会出现各种各样稀奇古怪的报错情况。在我这里, 会分享一个高频且完整的报错, 以及一套一站式解决流程。

报错的信息是这样呈现的: 一种错误情况出现了, 具体是: 在DRC运行期间导致了严重的错误, 而其中的错误内涵是: 在第2345行存在SVRF语法方面的错误。

此报错的关键缘由大概八成之多在于括号并非相称情况, 新手于自行定义期间常常会因手部不小心而多删除或者少删除了一个括号 , 解决办法分成三步来进行:

1. 使用awk ‘{print NR”:t”$0}’ your.drc, 将其通过管道符传递给head -2350, 接着把head -2350的输出再通过管道符传递给tail -20, 以此来显示报错行附近20行内容, 然后通过肉眼去检查括号所处的位置, 有标点符号。

2. 通过使用grep -o ‘{‘,你的.drc来统计左括号数量将其作为一项操作, 接着运用grep -o ‘}’你的.drc来统计右括号数量当作另一项操作, 而这两项操作所得到的结果必须是完全相等的。

3. 要是数量并非保持一致的状态, 那就去寻觅缺失括号的规则块, 而后补上与之对应的括号便可实现。

针对于金属线宽检查而言的关键参数最优推荐数值是,推荐把WIDTH METAL1设置为大于等于0.18u而非0.15u的值。尽管0.15u同样能够通过物理验证, 然而从制造良率的方面进行考量, 0.18u能够为光刻工艺留出充足的冗余量, 能够有效地降低短路的风险。

两种实操方案展开对比: 方案A是于原始规则基础之上, 逐一进行注释, 此情形是适合那种仅仅修改少数几项规则的场景；方案B则是创建一个空的规则文件, 借助INCLUDE语句去引用PDK规则进而对参数予以覆盖。方案A有着上手较快的特点, 然而规则文件会变脏, 方案B较为干净, 不过需要首先看懂INCLUDE语法。若你仅仅去改动三至五条规则, 那就挑选方案A；要是你打算进行长期的一套自定义规则库的维护工作, 强烈地推荐方案B, 这便于版本的管理以及回退操作。

这个方法于纯数字标准单元库设计里不太适用, 因为标准单元库的DRC规则 normally由foundry严格锁定, 不被允许自定义改动, 不然流片时会直接翻车。替代方案是运用Calibre RVE的DRC Waiver功能, 直接于GUI界面中标记假错为豁免, 不修改底层规则文件, 安全且高效。