以下这段经历发生在我身上，当时我实际测试了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替代，它会自动对缓存加以管理，新手会更省心。
