极客工场

Appearance

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

PrimeTime 回归结果产物丢失：签收报告找不到速查 ​

更新时间：2026-10-22。FAQ 速查页，属于 EDA 工具排错系列。「PT 回归跑了一整夜，调度系统报成功，早上进结果目录一看签收报告是空的」——这是静态时序分析（STA，Static Timing Analysis）回归里最让人心虚的一刻。PrimeTime（简称 PT，Synopsys 的时序签收工具，交互壳是 pt_shell）绝大多数时候并没有偷懒：产物要么被并发作业互踩，要么写到了计算节点本地盘没回传，要么作业其实失败了却被 catch 或管道吞成了「成功」。本篇按「目录、路径、返回码、回传、清理、归档」六条线给三分钟定位法。姊妹篇讲综合侧同款事故，见 Design Compiler 回归结果产物丢失；作业是真的失败了（退出码非零）的分诊见 PrimeTime 命令返回非零，签收方法论背景见 静态时序分析与 PrimeTime 签收。

本文要回答的问题 ​

  • LSF 显示作业 Successfully completed，为什么收集脚本找不到 timing 报告？
  • pt_shell 日志里明明写了报告文件，为什么 run 目录是空的或缺文件？
  • 多个 corner、多个 block 并发回归时，为什么每次丢的结果都不是同一个？
  • 作业在计算节点上跑完了，产物为什么没回到提交节点和归档区？
  • 清理脚本和留存策略在什么情况下会把签收结论一起删掉？

一、报错原文与现象 ​

这类问题的共同特征是：pt_shell 自己往往没有 Error，惊吓发生在调度、收集和文件系统层。最典型的现场——作业报成功，收集报错：

bash
# LSF 邮件 / bhist 显示
Job <pt_signoff_top_mmmc> was successfully completed.

# 回归收集脚本输出
collect_results.sh: line 58: work/run_2026_10_22_0200/reports/top.setup.hold.rpt: No such file or directory
[REGRESS] run=2026_10_22_0200  total=16  collected=15  MISSING=1

第二种现场是日志里白纸黑字写着已产出，磁盘上却对不上：

bash
$ tail -5 logs/pt_top_ss0p72v_125c.log
Reporting constraint to 'reports/top.setup.ss0p72v_125c.rpt'.
PrimeTime V2023.03-SP5 -- Exiting at Tue Oct 22 04:18:02 2026
$ ls -l reports/
-rw-r--r-- 1 user group  18234 Oct 22 04:18 top.setup.tt0p90v_0c.rpt
# 唯独 ss corner 那份不在，时间戳全是别的 corner 的

第三种现场出现在农场环境：登录计算节点还能在本地临时盘上看到文件，提交节点和归档区却始终没有：

bash
# 提交节点
$ bjobs -l 7123045 | grep -E "Status|Started on"
Status <DONE>; Started on <node-a17>;
$ ls work/run_2026_10_22_0200/reports/ | wc -l
0
# node-a17 的本地盘（作业结束后短期保留）
$ ssh node-a17 ls /scratch/user/7123045/reports/
top.setup.ss0p72v_125c.rpt

记住这个反差：日志说写了、调度说成功、结果目录说没有——说明 PT 写完之后有「第二只手」动过目录，或者 PT 站立的工作目录根本不是收集脚本查找的目录。先别怀疑工具，先还原这批产物的一生。

二、可能原因速查表 ​

现象可能原因处置
作业成功、整个 run 目录消失定时清理 cron 或框架跑完即清查 crontab 与清理脚本条件
目录在、报告缺一部分且每次缺的不同并发 corner/block 共用同名 work 目录互踩每 run 每 corner 独立目录带 run id
日志写了报告、run 目录里没有相对输出路径相对了错误的启动目录作业脚本显式 cd 或全程绝对路径
退出码 0 但报告为空或缺关键段Tcl catch 吞掉前置命令错误后空跑前置命令失败即 exit 1，双校验
计算节点本地盘有、提交节点没有结果写到 /scratch 未回传输出落共享盘或收尾显式回传
收集脚本报 No such file，稍后再 ls 又有NFS 属性缓存延迟收集前 stat 重试，勿误判为丢失
Permission denied 或属主怪异umask/共享目录权限、作业换账号固定 umask 022，目录归提交者
昨天还能看、今天没了留存期到期被归档策略删结论产物分级保留、归档双份
重跑后连上次的部分结果都没了失败重跑先 rm -rf 整目录重跑开新目录，旧目录保留

三、逐条排查展开 ​

先按「日志站在哪、作业成没成、文件回没回」三件事做第一轮分诊，再进入对应支线：

eda/ts-primetime-regression-result-missing.md D2 示意图

读图抓住颜色：红色是入口现象，蓝色一步是分诊（日志 pwd、退出码、产物清单三样一起看），橙色三条支线互斥——日志有写入记录但收集目录没有，走向路径与回传；目录在但被清空、时间戳对不上，走向并发与清理；退出码 0 却连产出动作都没有，走向 catch 吞错。三条支线最后都收敛到紫色的封装纪律。

第一刀：确认 PT 到底站在哪个目录写文件。 pt_shell 里所有相对路径都相对「启动时所在工作目录」，而 LSF/SGE 作业的启动目录由提交命令和队列配置决定，不一定是你以为的 run 目录。在签收 Tcl 第一行和报告写出前各打一次锚点：

tcl
puts "PT_WORKDIR=[pwd]"
puts "PT_REPORT_DIR=$::env(RUN_DIR)/reports"

再对照收集脚本里的收集路径。写的人按 work/run_xxx/reports/ 收，PT 实际站在提交者家目录把报告写到了 ~/reports/——批量作业里这类漂移占「成功但没产物」的大头。作业脚本里显式 cd "$RUN_DIR" 或全部改用绝对路径，二选一固化进模板。

并发互踩是「每次丢的不一样」的唯一解释。 多 corner、多 block、多 seed 并发时若共用同名 work/pt_run/，后启动的作业重建目录、甚至先 rm -rf，就会带走先跑完作业的产物；丢失随机、单 corner 单独跑永远复现不了。判据是目录时间戳被重写、日志里混入别的 corner 名。处置是目录即契约：work/<run_id>/<block>_<corner>/ 一层到底，run id 含日期与作业号（LSF 可用 $LSB_JOBID），并发之间零共享；库、网表、SPEF 等公共输入只读挂载，不写共享目录。

退出码 0 不等于产物合格：返回码与产物存在性必须双校验。 这是 PT 签收场景最危险的一类「假成功」——前置命令被无条件 catch，后续报告命令对着残缺数据空跑：

tcl
# 危险写法：SPEF 没读到也继续，报告段缺失但作业退出 0
catch {read_parasitics inputs/top.ss.spef.gz}
report_constraint -all_violators -file reports/top.setup.rpt

收集脚本不能只看调度状态，要对预期产物做存在性与非空校验，缺一件就把该 run 判失败并保留现场：

bash
for f in "${EXPECTED_REPORTS[@]}"; do
  [ -s "$RUN_DIR/reports/$f" ] || { echo "MISSING:$f"; rc=1; }
done
[ $rc -ne 0 ] && exit $rc

退出码管「工具有没有跑完」，产物清单管「结论是不是真的产出了」，两道校验缺一不可。退出码本身怎么被 catch、管道和 LSF 语义吞掉，分诊细节在 PrimeTime 命令返回非零。

农场本地盘未回传是 PT 大回归的特有坑。 为降低共享盘压力，农场常让作业在计算节点 /scratch 上跑，结束时再回传；若收尾的 cp/rsync 步骤漏了、失败了，或作业被限时杀掉来不及回传，调度状态仍是 DONE，提交节点却一无所有。排查时按 bjobs -l 找到执行节点，登上去看本地盘还在不在；根治要么让输出直接写挂载的共享目录，要么在作业脚本尾部显式回传并校验回传结果，回传失败作业不许报成功。

NFS 延迟、权限与清理是另外三只手。 计算节点刚写完、收集节点立刻 ls 偶尔报缺失，过几秒又出现，是网络文件系统属性缓存延迟，收集前对目标做 stat 重试循环即可，别因此乱改路径。权限问题表现为 Permission denied 或文件属主异常——作业脚本固定 umask 022，共享 run 目录归提交者所有。清理误伤则用时间线还原：

bash
ls -ld work/run_2026_10_22_0200      # 目录还在但空=按文件 mtime 清；整目录消失=删目录
crontab -l | grep -iE "clean|rm -rf"
grep -rn "rm -rf" regression/*.sh

失败重跑若实现为 rm -rf <run目录> && 重跑，重跑再失败就连上次的部分报告一起没了，排查现场全失——重跑一律开 <run_id>_retry1 新目录。

四、预防与纪律（作业封装模板要点） ​

  • run 目录命名即契约：work/<run_id>/<block>_<corner>/，run id 带日期与作业号；清理白名单、收集脚本、归档脚本三处用同一个变量派生路径，不各自硬编码。
  • 作业脚本四段式：开头 source 环境、cd "$RUN_DIR"、umask 022；中段全程 tee -a 落日志；尾部先回传（本地盘场景）再做产物存在性与非空校验；最后以真实 PT 退出码与校验结果共同决定作业退出码，管道场景用 PIPESTATUS[0]。
  • 前置命令禁止裸 catch：read_verilog/read_sdc/read_parasitics/read_spef 失败一律 exit 1，不让残缺数据产出看似完整的签收报告。
  • 产物分级留存：签收报告（timing/DRC/constraint）是结论产物，保留到下次里程碑或不少于 14 天；临时 DBD、会话文件跑完 48 小时可清；里程碑报告跑完即同步一份到独立归档盘。
  • 清理脚本先 dry-run：输出「将删除清单」并留 24 小时缓冲；并发回归的任何两个进程不共享可写目录，这条写进框架模板而非靠自觉。
  • 汇总前完整性自检：收集器先列出全部预期产物与缺失清单，带着缺失不许出「全绿」汇总。

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

本篇是 EDA 排错速查簇中「PrimeTime 回归产物管理」节点的 FAQ 页：作业真失败（退出码非零）的分诊见 PrimeTime 命令返回非零，输入侧读不到文件见 静态时序分析与 PrimeTime 签收 的流程章节，综合侧同款事故见 Design Compiler 回归结果产物丢失，全簇索引见 开源/EDA 工具报错排查总览。

一句话总结 ​

PrimeTime 回归结果产物丢失，九成不是 PT 没写而是「同名 work 目录并发互踩、相对路径漂移、catch 吞错退出码 0 空跑、计算节点本地盘未回传、清理误删、归档缺失」六件事之一：先用日志头部 pwd 确认真实写入目录、用 bjobs -l 找执行节点查本地盘，再对调度状态做退出码与产物存在性双校验排除假成功，丢失随机查并发与 rm 式重跑，最后靠「run id 目录契约、四段式作业封装、前置命令不裸 catch、结论产物分级留存双份归档」四条纪律防复发。