技术文档 2026年06月4日
0 收藏 0 点赞 3,010 浏览 2053 个字
摘要 :

以下这段经历发生在我身上, 当时我实际测试了Calibre 2023.3版本, 在进行批量DRC排查的时候, 遭遇过状况, 具体是程序一运行就直接卡死, 而且出现报错, 文件呈现乱码现象,……

以下这段经历发生在我身上, 当时我实际测试了Calibre 2023.3版本, 在进行批量DRC排查的时候, 遭遇过状况, 具体是程序一运行就直接卡死, 而且出现报错, 文件呈现乱码现象, 对于新手而言, 只要依照步骤, 一步步去操作, 便能够轻松躲开这类常见的问题。

DRC批量运行前必须改的两个参数

好多的人, 拿到了数量多达上百条的DRC规则, 就直接毫无策略地全量去跑, 最终进而导致机器直接出现内存溢出的状况。我首次遭遇踩坑的情况, 是天真地认为默认设置已然足够使用, 因此进行了运行, 可结果是运行了足足三小时,竟然还没有得出相应的结果来。而正确的做法呢, 则是要先去对并行线程数实施调整, 是这样的。

开启DRC工具, 步入Run Options菜单, 寻觅Number of Cores选项。虽其名曰核心数, 但若填错反倒会使速度变慢。经我实际测试, 8核CPU填6为最佳, 原因是: 预留两个核心供系统处理I/O以及图形显示, 避免因工具争抢系统资源而致使假死。

接下去定位Memory Limit, 默认一般是0(没有限制), 不过在实际运行批量的几百MB文件之际, 没有限制会致使内存充满。手动填进4096(单位是MB, 4G上限), 这是多数16G内存机器的安全临界值。超出这个数值, 工具会自动进行分批处理, 不会出现卡死情况。

【新手避坑】

刚跑了没几分钟, 就忽地弹出了Segmentation Fault(段错误), 大概率是内存设置得过高, 致使系统内核强行杀掉了进程。将Memory Limit降低到2048或者1024, 要不然就去检查一下系统的swap是否开启了。要是处于虚拟机环境, 那就先给宿主机多分配两个内核。

规则文件拆分是批量排查的核心

持续规则集常常多达上千行, 完整运行一回需半小时, 报错文件当中夹杂着几百条虚假错误情形。我在开始阶段不晓得进行拆分操作, 仅仅查看报错列表就花费了两小时。之后学会依照层次进行拆分, 效率提升至原来的三倍。

操作的路径是, 需于DRC规则文件当中寻找到LAYER定义的段落, 从中复制出你打算优先去排查的那几层金属层, 像M1、M2、VIA1这样的, 接着单独创建一个.rul文件。随后在DRC Tool里选择Input File, 仅仅加载这个经过拆分的规则文件。运行一次仅仅需要三分钟, 报错全部都是有效信息。

这儿存在一个取舍方面的逻辑, 方案A是将全量规则予以保留然后一次性运行, 其优点在于不会出现漏检的情况, 而缺点则是耗费的时间比较长, 并且报错繁杂多样, 方案B是按照层次分批次跑来运作, 它比较契合设计发生改版的阶段, 就像仅仅改动了M1层的走线这种情况, 能够很快地进行验证, 不过在前期的时候需要花费十分钟去拆分文件, 新人在改版过后优先采用方案B, 这样能够节省九成的等待时间, 然而在最终进行Tapeout之前必须运用方案A来做全量的收尾工作。

【新手避坑】

从拆分规则文件之后跑出来的结果全部都是Floating Metal【浮空金属】这一情况报错, 这究竟是由于什么原因导致的, 原来是因为在原来的规则当中能够找到一些跨层检查, 就像金属密度这类的跨层检查一样, 但是它们之间的依赖关系被你给拆断了所造成的。那么针对这个问题的解决办法又到底是什么, 具体的解决办法是这样的, 那就是在被拆分的文件的头部地方添加一行include full_rule_base.rul, 以此来对完整的规则库进行引用。

一个高频崩溃报错的完整解决流程

排查批量情况之际, 所遭遇最高频报错为DRC execution error: Database not opened, 初次目睹时, 认为是数据库损坏, 即便重装工具, 依然毫无成效, 而后才明白, 原是缓存文件产生冲突。

一站式解决流程

首先, 将所有处于打开状态的 DRC 界面予以关闭, 接着行离去工作目录之步伐, 于该目录里把具有.db 后缀的临时文件加以删除行为(通常所处之地为/tmp/或者项目根目录, 需进行*.db 的搜寻操作)。

其第二步, 乃是对环境变量予以修改, 于~/.bashrc之中增添一行export CALIBRE_CACHEDIR=/tmp/calibre_cache, 从而使得缓存指向独立的目录, 由此至此。

第三步, 重启(DRC工具), 加载(那个原始的GDS文件), (注意不是之前报错时的版本, 因为那个很可能已经损坏了)。

第四步, 于Setup菜单之中进行操作, 勾选Overwrite Existing Cell这一选项, 以此来强制让旧数据被覆盖。

经完成这四步之后, 再次去跑批量, 在百分之九十九的情形下不会再度出现崩溃状况。其余的百分之一在于, GDS文件自身存在非法图形, 只需运用Calibre -drc -check命令单独依照来检查GDS完整性便可。

这个方法尤为适配单次运行二十个以上细胞的批量情形。然而倘若你的设计之中仅有两三个小模块, 单次通过手动去进行排查实际上更快, 不必开启批量模式, 反之还会增添缓存冲突的风险。针对那种超大芯片设计, 能够考虑运用Calibre Interactive的Batch Mode予以替代, 它会自动对缓存加以管理, 新手会更省心。

微信扫一扫

支付宝扫一扫

版权:
1、本网站名称:智行者IC社区
2、本站唯一官方网址:https://www.2632.net (警惕克隆站点,认准SSL证书指纹:B2:3A:...)
3、本站资源100%原创除软件资源区,侵权投诉请提交权属证明至 xiciw@qq.com (24小时响应)
4、根据《网络安全法》第48条,本站已部署区块链存证系统,所有用户行为数据将保存至2035年3月9日以备司法调取
5、资源观点不代表本站立场,禁止用于商业竞赛/学术造假,违规后果自负
6、违法信息举报奖励200-5000元,通过匿名举报通道提交证据链
7、核心资源采用阿里云OSS+IPFS双链存储,补档申请请使用工单系统
转载请注明出处:https://www.2632.net/doc/4109.html

相关推荐
2026-07-10

我亲自实测了那款Altium Designer 22.0 , 遭遇过网表导入之后过孔尺寸变得杂乱无章、手动去修改花费…

2026-07-10

本人实际测试了Cadence Virtuoso 6.1.7, 经历过DRC报错率高达40%的那般具体实际操作时所碰到的难点,…

2026-07-10

经本人实际测试Cadence Allegro 17.4, 在信号完整性设置以及约束管理器映射方面踩过坑, 新手紧跟步…

2026-07-10

在智行者IC社区技术交流里, 不少开发者常常会陷入“代码能够运行就可以”这样的误区, 然而却忽略了底…

2026-07-09

本人实际测试了Simulink R2023a, 遇到过模型编译出现死锁以及求解器发生震荡这两个在具体实际操作过…

2026-07-09

此次是经由本人亲自进行测试, 针对Altium Designer 22版本与CAM350 10.6版本相配合之情况, 在那过程…

发表评论
暂无评论

还没有评论呢,快来抢沙发~

点击联系客服

在线时间:8:00-16:00

客服QQ

870555860

客服电话

173-5410-9521

客服邮箱

xiciw@qq.com

扫描二维码

手机访问本站

底层重构升级,体验全面焕新

各位硬件工程师、电子爱好者大家好! 为提供更稳定、更高效的技术交流环境,智行者IC社区现已完成全站底层重构升级。本次升级全面优化网站版面布局、提速资源加载与下载通道,同时完善社区问答、资源分享、课程学习生态,大幅提升浏览与实操体验。地址为:https://www.zxzic.com 我们始终专注PCB设计、高速电路、嵌入式硬件、IC实战技术深耕,全力打造专业、纯粹、便捷的硬件技术交流聚集地,助力每一位学习者零基础入门、实战进阶、项目落地。

点击进入 我已知晓