Calibre 缓存陈旧速查：改了规则或版图结果没变与 svdb 旧产物复用处置
更新时间：2026-10-23。FAQ 速查页，面向在共享 Linux 服务器上跑 Calibre DRC/LVS 回归的同学。calibre 跑一次 rule deck 编译并不便宜，所以它到处留「上次跑的产物」：svdb 目录里躺着编译后的规则数据库与上一轮结果、Incremental 模式复用旧层次数据只重算改动区域、hcell 列表是上次手工挑的、版图 gds 从 NFS 共享卷读进来还带时间戳漂移——任何一环把旧产物喂回来，现象都是同一句话：rule deck 或版图明明改了，DRC/LVS 报告却和昨天一模一样。这类问题形式上「跑通了」，危害比报错更大：回归全绿但检查对象根本不是当前输入。版本切换引起的数据库格式不兼容交叉参考 Calibre 版本不匹配速查，清缓存后结果文件整体找不到的分诊见 Calibre 回归结果丢失速查。
本文要回答的问题
- 改了 rule deck 重跑 calibre，DRC 结果和上一轮完全相同，先怀疑哪一环？
- svdb 目录里哪些残留会让 calibre 复用旧编译产物与旧结果？
- Incremental 模式什么时候是提速、什么时候是「吃旧账」？
- NFS 时间戳漂移为什么会让 calibre 认为版图没变？
- 先删 svdb 全量重跑验证、再定位缓存来源，这套方法论怎么落地？
一、典型现象与现场描述
最常见的现场是回归连跑两轮，第二轮改了 rule file，报告违规数逐条一致：
$ calibre -drc -hier rules/calibre.drc | tee run2.log
...
TOTAL RESULTS = 1372 (1372)
$ diff run1.summary run2.summary
# 除了 header 时间戳，违规条目完全一致第二种现场在日志头部。calibre 发现 svdb 已存在且自认有效时给出提示，但回归脚本不检查这类 message，旧编译产物被悄悄用上：
// Calibre v2025.06
Note: Using existing SVDB database in ./svdb
Note: Rule file compilation skipped (up to date)第三种现场最隐蔽：hcell 列表文件还在，但它是上个版本 rule deck 配套挑的——新 deck 改了器件识别规则，旧 hcell 把层次对错了位置，LVS 比的根本不是你以为的那个层次组合。calibre 不会替你核对 hcell 的生日，照单全收。三种现场共同的判据是同一条：rule file 或版图的时间戳比 svdb 里所有产物都新，结果却没变——看到这个组合，先把「陈旧」列为头号嫌疑，再谈别的。
二、陈旧来源与病因处置表
| 陈旧来源 | 典型位置 | 现场特征 | 处置 |
|---|---|---|---|
| svdb 残留旧编译产物 | ./svdb 目录 | rule 改了但日志提示跳过编译 | 删 svdb 整目录全量重跑 |
| svdb 残留旧结果库 | svdb 下 results 子树 | 报告内容与上轮逐条一致 | 每轮独立 svdb 或跑前整目录清 |
| Incremental 复用旧层次 | 命令行 -incr 类开关 | 只重算局部，改动区外沿用旧结论 | 改 deck/hcell 后第一轮禁用增量 |
| hcell 列表过期 | -hcell 目标文件 | hcell 早于本次 deck 修改 | deck 变更后重生成 hcell 并校验时间戳 |
| layout/gds 时间戳漂移 | NFS 共享卷上的版图 | 内容变了、mtime 没变或倒退 | 全链路 NTP 对时，导出后 touch 刷新 |
| 换 rule deck 版本未清 svdb | 老 deck 编出的 svdb | 报怪错或静默用旧规则编译库 | 换 deck 版本先全量清 svdb |
| 依赖快照未更新 | 文件清单/manifest | 版图清单还是旧一批 gds | 每轮重生成依赖清单，跑前 diff |
| RVE 打开旧结果数据库 | 图形界面会话 | RVE 里看的是上一轮的 violation | 重跑后重开结果库，核对 run 时间戳 |
表中「现场特征」一列用来在不清缓存的情况下先判断嫌疑方向；确诊仍然靠删 svdb 全量重跑这一步。
三、排查决策图
陈旧问题的正确顺序是：先删 svdb 从零全量重跑一次确认「结果确实会变」，再回头逐环定位是谁喂了旧产物。顺序反了——先改这改那再重跑——会让多个变量混在一起，永远说不清哪个缓存是元凶。
读这张图抓住主线：红色入口先接蓝色「删 svdb 全量重跑」这一步判定实验——它是全图唯一的关键动作，把「是不是缓存问题」变成一个有结论的对照实验。判定分叉后，绿色分支确认存在陈旧来源才进入逐环定位（仍是蓝色排查动作），橙色是命中环的修复，紫色闭环把修复固化进回归脚本防复发；另一条红色分支「清了还一样」说明病根在输入本身（比如改的层次没被例化进本次 run 的顶层，或版图路径指到了旧导出），不在本篇范围。不要跳过判定实验直接逐环猜——七个嫌疑环挨个试一遍，比重跑一次贵得多。
四、逐条排查展开
第一刀：删 svdb 全量重跑，先做对照实验。 在 run 目录执行（路径以 /proj/drc 占位）：
rm -rf /proj/drc/svdb
# 回归脚本里去掉增量开关，本轮强制全量
calibre -drc -hier rules/calibre.drc | tee rerun.logsvdb 是 calibre 的持久化数据库：编译后的规则、层次化中间数据、上一轮结果都躺在里面。日志里出现 Using existing SVDB 且结果没变，第一嫌疑就是它。删库从零跑一轮：结果随 deck/版图变化，说明此前确有陈旧产物被喂进来，进入下一步定位；结果仍不变，先怀疑输入链路——版图路径、顶层单元名、-layout 指到的 gds 是不是旧导出，别再翻缓存。
第二刀：hcell 生日校验，LVS 回归必加的一行。 hcell 列表决定 LVS 比对的层次配对，必须是当前 deck 配套的产物。回归脚本里在启跑前加校验：
# hcell 必须不早于 rule file，否则说明是旧 deck 时代的产物
test lvs.hcell -nt rules/calibre.lvs || {
echo "ERROR: hcell older than rule file, regenerate first"; exit 1; }deck 改了器件识别规则而 hcell 没跟着换，calibre 不报错，但层次对错位置，结果要么假绿要么大面积 net mismatch——先核对时间戳再谈比对结论。
第三刀：Incremental 模式，回归和迭代分两套玩法。 交互迭代修版图时增量模式省时间，只重算改动区域；但改的是 rule deck、hcell 或全局设置时，增量的「改动检测」覆盖不到这类输入，层次化中间数据照旧复用。纪律很朴素：deck/hcell/设置有任何变更，第一轮一律禁增量全量跑；连续几轮只动版图才允许开增量。为了「提速」在 deck 变更轮也开增量，是负优化。
第四刀：NFS 时间戳与依赖快照，两条环境线。 版图 gds 通常从共享卷读，导出机与计算机时钟差几秒，会出现「gds 内容已更新、mtime 却比 svdb 产物旧」的假象，calibre 据此认为版图没变。处置：所有跑链路的机器对时（NTP），导出完成时 touch 一次 gds 强制刷新 mtime，跑前用 md5sum 而非时间戳确认文件确实变了。回归每轮同时重生成依赖清单（find 版图目录按时间排序落盘），跑前与上一轮 diff，清单没变而版图「改了」，直接暴露快照陈旧。
第五刀：换 deck 版本与 RVE 会话。 换用新版本 rule deck（如从老版本切到 2025.06 配套 deck）后第一轮必须全量清 svdb，旧 deck 编出的规则数据库不保证与新输入兼容，判据集中见 Calibre 版本不匹配速查。另外别忘了图形界面这一环：RVE 打开的是结果数据库文件，重跑后不重开会话，看到的还是上一轮的 violation——排查「结果没变」先确认自己看的报告是新跑出来的。
五、防复发与纪律
- 回归每轮独立 svdb：目录命名带时间戳，跑前不继承任何旧数据库；增量只在纯版图迭代轮用。
- hcell 与 deck 生日校验进脚本：启跑前断言 hcell 不早于 rule file，不满足直接 fail。
- deck 版本切换首轮全量：换 deck 或工具版本后第一轮删 svdb 从零跑，不继承旧编译产物。
- 全链路对时 + touch 刷新：NFS 环境下导出机、计算机统一 NTP；gds 导出完成 touch 刷新 mtime。
- 首轮改输入后必做对照实验：改 deck 或版图后第一轮手动删 svdb 全量重跑，确认结果会动，再交给回归。
- 结果一致性监控：回归收尾对比相邻两轮 summary，逐条一致且输入有变更时报警——这正是本篇开头的现场。
这一篇在知识体系里的位置
本篇是 EDA 工具排错速查簇的 FAQ 页，专管 Calibre 输入链路上的陈旧产物与 svdb 缓存复用一条线；换 deck 或工具版本导致的数据库格式不兼容在 Calibre 版本不匹配速查，清缓存后回归产物整体找不到的分诊见 Calibre 回归结果丢失速查，删 svdb 释放 run 目录占盘的方法见 Calibre 磁盘写满速查，同类方法论在形式验证工具上的对应篇见 Formality 缓存陈旧速查。
一句话总结
Calibre 改了 rule deck 或版图结果不变，先做对照实验——整目录删 svdb、禁增量从零全量重跑，结果随输入变化就确认存在陈旧来源，再逐环定位：svdb 残留旧编译产物与旧结果、Incremental 模式在 deck 变更轮偷吃旧层次数据、hcell 必须是当前 deck 配套产物（跑前校验时间戳）、NFS 全链路对时并用 touch 刷新 gds mtime、换 deck 版本首轮全量清库、RVE 会话重跑后要重开；长期靠「hcell 生日校验 + 相邻两轮 summary 一致性监控」两条脚本纪律，让陈旧产物在喂给 calibre 之前就被拦下。