Quartus 回归结果缺失速查：批量回归跑完某几条 .rpt/结果不见了怎么办

更新时间：2026-10-23。FAQ 速查页，属于 FPGA 工具报错排错系列。批量回归（多 revision、多器件型号、多种子扫一遍）跑了一夜，早上打开汇总表：一百条里有三条没有 .rpt、没有时序数字，状态栏写着 not run 或干脆缺行——是这三条没跑、跑了没写盘，还是写了又被清掉？本篇把「Quartus 回归结果缺失」的六类真实病因排成速查表。如果单条编译本身就返回非零退出码，先走 Quartus 命令行退出码非零速查；如果结果都在但两次回归对不上，那是 Quartus 结果随机不一致速查 的地盘。

本文要回答的问题

• 汇总表里某几条显示 not run 或整行缺失，回归脚本到底跑没跑它们？
• 并行回归（xargs -P / make -j / LSF）跑完，个别任务没有任何输出，是谁杀了它？
• 单条手动复跑是好的，放回回归里就缺结果，差别在哪？
• 结果目录存在但 .rpt 是空的或不完整，磁盘和权限怎么查？
• 后处理脚本（汇总、清理）会不会把已经生成的结果误删或覆盖？

一、现象与报错原文

回归缺结果的现场有三层痕迹，从汇总层往编译层逐层看：

1. 回归汇总表：缺行或状态 not run。

revision      device          fit_status   fmax(MHz)   alm_util
base          10AX115S2F45    PASS         312.4       41%
seed_a        10AX115S2F45    PASS         298.7       41%
seed_b        10AX115S2F45    not run      -           -
seed_c        10AX115S2F45    PASS         305.1       41%

not run 多数是汇总脚本「在结果目录里没找到 .fit.rpt 或状态文件」的兜底措辞，不代表 Quartus 说过这句话。

2. 该条任务的编译日志尾部：要么戛然而止，要么有真 Error。

Info (293000): Quartus Prime Fitter was successful. 0 errors, 23 warnings
...
Error (293000): Quartus Prime Full Compilation was unsuccessful. 2 errors, 31 warnings

或者更干脆——日志停在某一行 Info 就再没有下文，连 unsuccessful 的汇总行都没有：

Info (170084): Router estimated total interconnect delay...

3. 结果目录里：缺文件、零字节、或时间戳对不上。

$ ls -l results/seed_b/output_files/
-rw-r--r-- 1 ci ci      0 Oct 23 03:12 seed_b.fit.rpt
-rw-r--r-- 1 ci ci  81234 Oct 23 03:11 seed_b.map.rpt

.fit.rpt 零字节说明进程在写报告阶段被终止；map.rpt 有而 fit.rpt 没有，说明死在 fit 中途。

二、现象 → 区分点 → 处置速查表

现象	区分点 / 最常见原因	处置
汇总表 not run，编译日志有真 Error	该 revision 编译失败，脚本跳过结果收集	按 Error 编号修该条；退出码分诊见 Quartus 命令行退出码非零速查
日志中途戛然而止，无任何汇总行	进程被杀：并行度太高内存耗尽，OOM killer 下手	dmesg | grep -i oom 石锤；降并行或加内存后补跑
日志完整成功但结果目录没有 .rpt	结果目录权限不够或磁盘写满，写盘失败	df -h 与目录写权限；Quartus 写失败通常在日志尾部有 Error (210000) 系列
网格回归（LSF/qsub）个别任务失踪	计算节点失联/被抢占，任务实际没执行完	调度器侧查任务状态（bjobs -a / qstat），失联节点任务重投
汇总表直接缺行（连 not run 都没有）	revision 名与脚本遍历列表不一致，该条从未进队列	对比 get_all_revisions 输出与脚本列表，统一一处定义
回归中途结果还在，收尾后消失	后处理脚本误删/同名覆盖：清理规则太宽或多任务共享输出目录	查清理脚本的匹配模式；每个任务独立输出目录
单条手动复跑成功，回归里就缺	资源竞争：只在高负载并发时触发 OOM 或 license 排队超时	固定复现条件（同并发数）再排；不是工程问题

三、排查决策树

分诊只问三个问题：编译日志尾部有没有真 Error？进程是自然结束还是被杀？文件是从来没写进去还是写了又没了？三个答案把现场切成三条通道：

读这张图抓住一条主线：先确定「没跑」「跑了被杀」「跑了没写进去」三选一，再进对应通道——日志有 Error 是「Quartus 自己拒绝」，日志截断是「外力终止」（红色病态态），无日志是「任务根本没执行」，文件曾存在后消失是「后处理闯祸」。蓝色是排查动作，绿色表示「原因通道已锁定」，橙色是修复补跑，紫色是收口防复发。最忌讳的是不翻日志直接整批重跑：一夜又一夜，缺的还是那几条。

四、逐条排查展开

该条编译失败被跳过，是最常见也最容易确认的一类。 回归脚本通常是 || exit_code=$? 记录后继续下一条，失败条目的 .rpt 不完整，汇总脚本解析不到时序数字就标 not run。确认只要一行：

grep -nE "^(Error|Critical Warning)" results/seed_b/compile.out | head -20

有 Error 就按编号修，这一条就变成了普通的编译失败问题，分诊路径与 Quartus 命令行退出码非零速查 完全一致。

并行度太高把内存耗尽，个别任务被 OOM killer 挑中。 xargs -P 8 起 8 个 quartus_fit，每个峰值 6-10GB，64GB 机器在 fit 重叠期轻松顶穿。被 SIGKILL 的进程连汇总行都来不及写，日志停在某个 Info 就结束。石锤方法：

dmesg -T | grep -i -A2 "out of memory"

看到 Killed process ... (quartus_fit) 就结案：把并行度降到内存能容纳的水平（粗略按 机器内存 ÷ 单任务峰值 × 0.7 估算），缺的条目单独补跑。注意这不是 Quartus 的 bug，排错方向是资源配额。

结果目录写不进去：磁盘满或权限问题。 结果目录挂在 NFS 上、配额打满、或者目录属主是别人，Quartus 写 .rpt 失败会在日志尾部报 Error (210000) 系列（文件无法打开/写入）。自查三件套：df -h 看磁盘、df -i 看 inode、touch results/seed_b/.w 试写权限。磁盘满导致的缺失有个特征：缺结果的往往是回归后段的任务（磁盘是逐渐被填满的）。

多机网格回归：个别节点失联，任务实际没跑完。 LSF/qsub 场景下，节点掉线、被抢占或 NFS 挂载超时，调度器可能把任务标成 EXIT 或一直 RUN。汇总脚本只看到「目录里没有结果」，但真相在调度器侧：

bjobs -a -o "jobid stat exit_reason" | grep seed_b

状态是 EXIT 且 reason 指向节点故障的，直接重投；网格任务务必配 bsub -e/-o 把 stdout 落共享盘，否则节点失联后连日志都拿不回。

revision 名与遍历列表不一致：该条从未进队列。 脚本里写死 revisions="base seed_a seed_b seed_c"，工程里实际只有 base seed_a seed_c（seed_b 上周改名成了 seed_b2），quartus_sh -c seed_b 会以「revision 不存在」快速失败，日志短得只有几行，汇总表里表现为整行缺失。统一口径：

quartus_sh --tcl_eval project_open demo; get_all_revisions

让脚本从这个命令动态取列表，而不是维护一份容易漂移的手写清单。

后处理脚本误删/覆盖：结果曾存在，收尾后没了。 两个高发形态：一是清理规则太宽，find results -name "*.rpt" -mtime +0 -delete 之类把当天结果也扫进去；二是多条任务共享同一个输出目录、同名工程互相覆盖（两个 revision 都用默认 output_files/ 且同名 .qpf 拷贝）。确认方法是看文件时间戳与回归时间轴对不对得上。根治是每任务独立输出目录 results/<rev>_<seed>/，清理只按目录级操作，不在共享目录里按文件名删。

「单跑好的、回归里就缺」一律先怀疑资源竞争。 手动单跑成功只证明工程没问题；回归环境特有的变量是并发——内存竞争触发 OOM、license 席位被占满排队超时、NFS 带宽打满写超时。复现要带上同等并发数，否则永远「无法重现」。结果忽有忽无、但每条单独都成立时，也要和结果漂移类问题区分开，后者见 Quartus 结果随机不一致速查。

五、预防与纪律

• 每任务独立目录 + 日志落盘：results/<rev>_<seed>/ 下编译输出 > compile.out 2>&1，缺结果时第一动作是翻这个文件。
• 汇总前校验：汇总脚本先数「预期条数 vs 实际结果数」，不等就报警并把缺失清单打出来，不静默标 not run 了事。
• 并行度按内存算：并发数 ≤ 机器内存 ÷ 单任务峰值 × 0.7；OOM 历史机器上同时开 dmesg 监控。
• revision 列表动态取：从 get_all_revisions 生成遍历清单，禁止手写硬编码。
• 网格任务日志落共享盘：bsub -o/-e 指向 NFS，节点失联也能拿回现场。
• 清理只按目录：回归目录按批次整体保留 N 天，不跑按文件名匹配的删除。

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

本篇是 FPGA 排错速查簇中「Quartus 批量回归缺结果」节点的 FAQ 页：缺的那条如果编译本身就是非零退出，分诊展开见 Quartus 命令行退出码非零速查；如果结果都在但两次回归对不上，属于结果漂移问题，见 Quartus 结果随机不一致速查。三篇合起来覆盖回归健康的三个维度：有没有跑成、失败为什么、跑成了稳不稳。

一句话总结

Quartus 回归结果缺失的分诊起点是把汇总表的 not run 还原成该条任务的真实现场：编译日志有 Error 就是编译失败被跳过，按编号修；日志中途截断是进程被杀，查 OOM 与并行度；日志报写文件失败查磁盘与权限；日志不存在查调度器任务状态与 revision 名一致性；结果曾存在后消失查后处理清理与同名覆盖。根治靠每任务独立目录、日志全量落盘、汇总前条数校验、revision 列表动态生成，让每一次回归缺结果都自带可回溯的现场。