芯片设计批量DRC排查技巧 快速定位修改错误根源的方法

芯片设计后端工作里，批量DRC排查属于是最耗费时间的环节当中的一个，好多工程师都碰到过运行一回DRC，也就是设计规则检查后，耗费时间达到十几个小时，结果出来后，满眼都是报错信息，修改的时候却根本不知道从哪里开始下手，这种困境，要想对批量DRC展开高效排查，核心之处不在于“修”，而是在于“防”以及“拆”。

批量DRC怎么快速定位错误根源

看见几十乃至上百页的DRC报告之际，别被吓到。我一般会先瞅报告末尾的汇总，找见面积最大或者重复次数最多的那类错误。像金属密度不足这种情况，常常会在芯片的空白区域大量出现。借助脚本对错误类型进行分类统计，将同类错误归拢到一块儿处理，比起一条一条去翻阅版图效率要高好多。

DRC批量错误怎么修改最快

修改批量错误得有那种类似“擒贼先擒王”的思路，就拿最短路径错误来说，要是察觉到一大片区域都在报这个错，那极有可能是顶层绕线策略出现了问题，并非底层单元的问题，在这个时候应当先去调整绕线方向或者阻挡层设置，接着重新跑一小块区域进行验证，确认有效之后再进行全局应用，千万要忌讳手工去拉扯每一根线。

DRC分步检查的实用方法

将DRC排查，我习惯于分成三步来进行。首先第一步要看基础单元，像是标准单元库自身有无问题就关注的是这一点，此步骤通常于项目起始之前便予以确认妥当；紧跟着第二步查看于模块内部，比如数字模块与模拟模块二者相交接之处，这个地方极易出现层次之间连接方面的错误情况；然后第三步聚焦于芯片顶层，主要涉及的是电源地网络以及密封环周边的规则问题。采取分步走的益处在于能够赶紧把问题已然发生的阶段予以确定，极力防止把本不需要投入和浪费时间在此错误的地方。

批量DRC的预防比修复更重要

于实际项目里，我发觉要是将检查节点予以提前，便可省却后期百分之八十的批量修改时间。举例而言，在Place阶段之时加入初步的DRC检查脚本，于绕线关键层之际开启实时规则检查。这些预防性举措尽管会使前期运行得稍慢一些，然而却能够避免在最后关头因一个批量错误致使整个芯片Tape – out延迟。

当你着手去处理那一批量的DRC之际，所碰到的最为棘手的那一类错误究竟是什么东西，欢迎于评论区域分享讲述你的踩坑方面的经历，要是觉得这篇文章存在有用之处的话可千万不要忘记点一下赞去给予支持一番。