批量DRC排查效率太低？手动点到手抽筋？试试这个一键脚本法

亲自进行测试的本人, 所测试的是Virtuoso IC618以及Calibre 2022.2_35.28, 所经历的最为糟糕的情况便是一个个、一条条单独地点开DRC结果之后转过头再去修改版图, 一张规模较大的芯片修改完成竟然需要两天时间。而对于新手而言, 只要依照着下述的步骤逐个进行操作, 便能够轻松地躲开这类较为常见的问题。

配置一个不会漏报的DRC Runset

做第一步行为时, 要将你的Calibre Interactive界面予以打开, 于输入文件栏之中, 需把Rule File指向由foundry所提供的完整.drc文件, 绝对不要去使用自己修改过的测试版本。我见识过非常多的人, 他们为了节省时间, 仅仅去跑最小rule set, 结果把密度检查以及天线检查给遗漏掉了, 最终在流片之前悲痛哭泣, 连后悔都来不及了。

第二步: 于Outputs选项卡里, 将Run Directory设置为一个固定路径, 像/project/DRC_BATCH/这般, 随后勾选对Export from layout以及包括Create DRC Database等的设定选项。然后勾上Export from layout和Create DRC Database两个选项。特别重要的是, 于SVDB选项之中去挑选Hierarchical模式, 借助如此这般的方式, 才能够在后续借助脚本以批量的形式提取所有cell的报错。

对于新手而言要注意避坑, 在此处最容易出现的报错情况是, 显示“SVDB database is too large”, 实际上并非数据库真的大得出奇, 而是你忘记了在Rules选项卡里, 勾上Abort on first 5000 errors旁边的那个Limit hierarchy depth, 其默认状态是无限层级, 要是处理小芯片的话跑起来不会出现问题, 然而处理大SoC时则会直接导致爆内存, 出现故障。

用Tcl脚本一键提取所有DRC违规

首先, 完成一回完整的DRC操作之后, 于CIW窗口当中键入drcListResults( “/project/DRC_BATCH/drc.db”?outputFile “./drc_all.txt” ), 此步骤产生了一份文本清单, 其中涵盖了所有cell里每一条DRC报错的位置, 含有该条报错的层次, 以及其所属的类型。这一回, 是那个我历经三次跌入陷阱方才寻觅到的API, 官方所给出的文档之中, 记述得知相当隐晦, 刚入门的新手压根就无从知道。

第二步: 进行如下操作, 先撰写一个简易的shell脚本, 该脚本要针对上面提及的文本去做两件事情, 一件事情是运用grep按照DRC error type进行分组并统计数量, 另一件事情是借助awk提取出每个cell里重复次数处于最高位次的前三个报错类型, 之后将其输出到一个全新的文件drc_summary.csv里。

第三步: 于Virtuoso Layout之中, 借助脚本达成自动高亮操作, 我时常运用的命令乃是geSelectByRegion( list( list( “M1” “0.18” ) ) ), 配合前文中所提取出来的坐标范围, 一次性选取全部同类错误, 接着通过右键点击选为相同一种颜色, 凭借视觉效果能够马上分辨出哪些区域为重灾区。

【新手需避坑】, 你极有可能碰到“Error drcListResults: database file not found”这种情况, 其缘由在于, Virtuoso的工作目录, 与你的Run Directory并不一致, 是另有情形的, 你可得留意了。处理途径颇简易: 于运行DRC之前, 先于CIW之中键入cd(“/project/DRC_BATCH/”), 将工作目录切换至Run Directory之下, 而后运行DRC, 如此脚本便能顺利寻得数据库了。

原因相当单纯 , 一种为GDSII此格式的数据库文件 , 尽管其体积稍微大一些 , 然而它同Virtuoso Layout的兼容性却是最为出色的 , 在后续借助脚本回标高亮之际 , 不会出现坐标偏移的状况 , 经过实际测试 , OASIS格式于IC618上会随机丢失大概5%的报错坐标 , 排查起来极为令人头疼。

对于两种实操方案进行对比, 一种是本文所提及的脚本批量提取以及自动高亮方案, 此方案适用于芯片规模较大, 且cell数量超过1000个的复杂设计, 另一种是Calibre RVE自带的Cell List面板手动点选方法, 这种方法适合仅有几十个标准单元的简单模块。若是你的设计已然步入顶层集成阶段, 那就务必采用脚本方案, 这是由于RVE的Cell List在顶层进行加载的时候速度极其缓慢, 每点击一个cell都会卡顿5秒钟, 要是有300个cell, 你点击一个小时, 手都会废掉。

一个呈现为高频且完整状态的报错: “Error dbComputeNode: failed to allocate memory” 所涉及的这种报错, 其出现一般是在你借助脚本运行完DRC结果之后, 还要尝试将所有 cell 的 highlight 一次性加载到版图这个行为发生之时。第一步, 先将Virtuoso关闭, 把临时文件通过命令rm -rf /tmp/cal*进行清理；第二步, 把版图重新打开, 于Layout Editor里选择Options这个选项, 接着选Display, 再将Dynamic Highlight改成Static；第三步, 仅加载前50个最为严重的错误类型, 不要全部选择, 如此内存便稳住了。

有一种方法, 说到底它仅仅是适宜于后端版图工程师, 在集成验证这个阶段去运用的。要是你仅仅是从事前仿真, 或者是进行单元库建库的工作, 那么跑单条的DRC就已经足够了, 根本没有必要去折腾脚本。替代的方案是极为简易的, 运用Assura自身所具备的Batch DRC功能, 在Runset当中配置一种仅针对Top Cell的模式, 运行完毕后直接去查看RVE的Summary, 虽说没办法进行批量高亮显示，不过好在配置速度相当快, 五分钟就能够完成。