极客工场

Appearance

共 2,709 字预计阅读约 9 分钟

Calibre 偶发不确定失败：同一条 DRC/LVS 重跑结果翻转速查 ​

更新时间：2026-10-22。FAQ 速查页，属于 EDA 工具排错系列，总入口见 开源 EDA 报错排错中心。先建立一个关键认知：Calibre（Mentor/Siemens 的物理验证工具，批处理入口 calibre -drc/-lvs/-pex）是确定性工具——给定同一份 GDS/OASIS 与同一份 rule deck，算法层面不存在随机种子，同输入必然同结果。所以「同一条命令昨天挂、今天过、明天又挂在另一条规则上」几乎不可能是校验本身算了不同的东西，答案全在工具之外：网络存储抖动、并发互踩、license 心跳、资源限额、输入被异步改写。这与 HDL 仿真的 flaky（随机种子、竞争冒险）根因完全不同，不要往「种子」方向排查。仿真侧的同款命题可对照 SpyGlass 结果不确定抖动速查，运行期挂死与回归产物丢失分别见 Calibre 运行卡死/超时速查、Calibre 回归结果或产物丢失速查，流程背景见 Calibre 物理验证实操。

本文要回答的问题 ​

  • 同一条 calibre -drc 回归夜里失败、早上原封不动重跑就过，是 Calibre 算错了吗？
  • transcript 报 SVDB 写入出错、RVE 打不开数据库，重跑一遍又完好，根因在哪一层？
  • license 日志里的退出码 -9、-96 一类心跳错误，怎么和真违例导致的失败区分？
  • 为什么失败位置每次都不同，一会儿死在层次展开，一会儿死在写网表？
  • 用什么判定性实验把「环境抖动」和「输入被改/并发互踩」两类原因一刀切开？

一、报错原文与现象 ​

不确定失败的共同特征是：退出码非零或产物残缺，但复现不了——原命令重跑就过，或死在完全不同的位置。以下三组占位日志覆盖最高频形态（路径、主机均为占位，各版本日志措辞以本单位安装版本为准）。

1. 网络存储抖动：SVDB 写到一半 stat 不到刚写出的文件，重跑即过：

bash
// Error: Unable to write to run database file
//        "/proj/demo/run_night/svdb/run_drc/<tmp>.db".
//        No such file or directory.
// EXITING due to error (exit code 1)
$ ls /proj/demo/run_night/svdb/run_drc/
# 目录此刻又存在且内容正常；同一命令立即重跑，退出码 0

上一行刚创建的文件下一行就 stat 不到，是 NFS/挂载盘元数据延迟或短暂断连的典型签名，不是 rule deck 的问题。

2. 高峰时段 license 心跳丢失，报 -9/-96 类退出，重连后成功：

bash
MGLS: Warning: heartbeat to license server timed out.
MGLS: Lost connection to the license server daemon.
       Feature: CALIBRE-VERIF  (-9) / server heartbeat timeout (-96)
// EXITING due to licensing error
$ # 几分钟后原命令重跑，license 正常签出，校验通过

3. 资源抖动或输入被异步覆盖：不同次死在不同阶段：

bash
# run A：层次展开阶段被杀（OOM）
Killed
$ dmesg | tail -2
Out of memory: Killed process 20481 (calibre) total-vm ...

# run B：死在读输入，hier cell 版本对不上
// Error: layout database cell "core/alu" modified timestamp changed
//        during hierarchy traversal; database is inconsistent.

二、原因速查表 ​

现象可能原因处置
报刚写出的文件 No such file、重跑即过NFS/挂载盘抖动，SVDB 写入中断或元数据延迟work 目录放计算节点本地盘，NFS 只归档；错峰跑大回归
高峰期 -9/-96 心跳退出，低谷正常license 服务器心跳超时或席位被抢占，非真违例按 license 故障处置，错峰/拆批次；不要把心跳退出记成 DRC fail
每次死在不同阶段，dmesg 有 OOM内存峰值被 OOM killer 杀，同机并发挤占降同机并发、按版图规模做内存预算、换大内存队列
报 too many open files 或写临时目录失败ulimit -n 句柄不够、磁盘配额/临时目录写满提高句柄与配额上限，临时目录指向大容量本地盘
单独跑永远过、回归里偶发挂多 job 共用同名 work 目录，临时文件互相覆盖每 run 独立目录加 run id，并发零共享可写目录
hier cell 时间戳变化/版图不一致P&R 还在写 GDS/OASIS 时校验已启动锁输入：校验前快照输入并对 checksum，未冻结不许启动
规则命中数回归窗口内漂移rule deck 或 INCLUDE 文件在回归期间被更新deck 版本打 tag，回归窗口内只读冻结，随报告记录版本
普通模式稳、开 -turbo/remote 才抖多线程/分布式归并阶段对网络与时序敏感对齐线程数与席位，先关 turbo 复现判定，慢盘改本地
重跑后连上次失败现场都没了重跑脚本先 rm -rf 旧 run 目录失败 run 原样保留 SVDB 与 log，重跑开 _retry 新目录

三、判定性实验与决策图 ​

先做一次判定性实验：锁定输入快照，每 run 用独立 work 目录，同一条命令连跑三次，记录每次退出码、失败位置与环境指纹。一次实验把原因切成两大类——三次都过或只在高负载时挂，根因在环境/IO/license 侧（外部抖动，工具结果本身可信）；三次中有失败且位置漂移或报输入不一致，根因在并发互踩或输入被异步改写（流程缺陷，必须修）。

eda/ts-calibre-flaky-nondeterministic.md D2 示意图

读这张图抓住唯一的分水岭：连跑三次这一步。红色是问题入口与仍未排除的输入侧分支，蓝色是排查动作，绿色分支表示工具结果本身可信、问题在外部环境，橙色是两类分支汇合后的修复与固化。不要跳过这一步直接怀疑 rule deck 或重提 license 申请——确定性工具的 flaky，先审环境与流程。

环境侧第一嫌疑：网络存储。 Calibre 的 SVDB 是大量小文件的高频读写，对 NFS 元数据延迟极敏感：挂载盘短暂断连时，刚写出的临时文件下一行就打不开，RVE 事后也可能打不开结果库；网络恢复后原命令重跑一切正常。判据是错误路径都在挂载点下、单独登录计算节点用本地盘跑不复现。处置是 work 与 SVDB 写本地盘（如 /scratch/<run_id>/），结束只归档最终报告与结果库，慢盘诊断手法见 Calibre 运行卡死/超时速查。

第二嫌疑：license 心跳与系统资源，二者都表现为「时间相关」。 高峰时段 MGLS 心跳丢失会报 -9/-96 一类退出码并整进程终止——这是许可证事故，不是 DRC 结论，回归系统必须把这类退出码单列为「环境失败待重跑」，严禁计入违例或签收结论；签不到证的启动期硬错误见 Calibre license checkout failed 排错速查。资源侧同理：内存峰值被 OOM killer 杀、ulimit -n 文件句柄不够、磁盘配额或 /tmp 写满，死点随当时内存/句柄压力漂移，每次位置不同正是特征。跑批前固定记录环境指纹：

bash
{ date; hostname; echo "MGC_HOME=$MGC_HOME"; df -h "$PWD" /tmp; \
  ulimit -a; lmstat -a -c 27000@<server> | head -30; } > env_fingerprint.txt

输入侧：并发互踩与输入被异步覆盖。 多个 regression job 共用一个 work 目录（未用 run id 隔离）时，临时文件互相覆盖、后启动的 job 重建目录，表现为单跑永远过、并发偶发挂且现场互相毁灭；目录隔离纪律见 Calibre 回归结果或产物丢失速查。另一类是上游还在写：P&R 未交付就启动校验，GDS/OASIS 遍历中途被改，hier cell 版本对不上；rule deck 或 INCLUDE 文件在回归窗口内被更新，会让两次校验的规则集合本身不同。修法是校验前对 GDS、deck 做只读快照并记 checksum，未冻结不许启动。最后注意 -turbo/remote/split jobs 的归并阶段对网络更敏感：普通模式稳定、开多线程才抖时，先对齐线程数与席位、确认分布式工作目录在本地盘，再谈调优。磁盘写满导致的写库失败与本篇症状重叠，按 Calibre 磁盘空间不足速查 先排除容量；进程段错误类硬崩溃见 Calibre 段错误崩溃速查。

四、预防与纪律 ​

  • 先认确定性：同输入同结果是 Calibre 的承诺，flaky 一律先审环境与流程，不怀疑算法、不找「随机种子」。
  • run id 目录隔离：work/<run_id>/<block>_<check>/ 一层到底，并发零共享可写目录；失败 run 的 SVDB 与 log 原样保留，重跑开 _retry 新目录。
  • 输入冻结再启动：校验前快照 GDS/OASIS 与 rule deck 并记 checksum，deck 打 tag 在回归窗口内只读，上游未交付不启动。
  • 数据近节点：SVDB 写计算节点本地盘，NFS 只做归档；资源按版图规模做内存与句柄预算，license 心跳退出单列环境失败。
  • 环境指纹随报告落盘：host、MGC_HOME、df、ulimit、license 服务器时刻、输入 checksum 一起归档，让下一次抖动可对拍而非靠回忆。

这一篇在知识体系里的位置 ​

本篇是 EDA 排错速查簇中「确定性与复现」节点的 Calibre FAQ 页，总入口见 开源 EDA 报错排错中心；运行期挂死分诊见 Calibre 运行卡死/超时速查，产物与 SVDB 丢失见 Calibre 回归结果或产物丢失速查，容量、license、段错误分别见 Calibre 磁盘空间不足速查、Calibre license checkout failed 排错速查、Calibre 段错误崩溃速查，正常 runset 与流程背景见 Calibre 物理验证实操，跨工具同款命题对照 SpyGlass 结果不确定抖动速查。

一句话总结 ​

Calibre 偶发不确定失败先记住它是确定性工具、没有随机种子，flaky 几乎全来自环境与流程：用「锁定输入快照、独立 work 目录、同命令连跑三次」做判定性实验——重跑通过或仅高负载挂是 NFS 抖动、license 心跳超时（-9/-96）、OOM/句柄/配额等环境侧问题，仍失败且位置漂移则是并发同名 work 目录互踩或 GDS/deck 被异步覆盖；根治靠 run id 隔离、输入 checksum 冻结、SVDB 写本地盘、资源预算与环境指纹随报告归档、失败现场不覆盖六条纪律。