极客工场

Appearance

共 2,221 字预计阅读约 7 分钟

Vivado 回归结果丢失：run 目录与产物不见了速查 ​

更新时间：2026-10-25。FAQ 速查页，属于 FPGA 工具排错系列。跑了一夜的回归，早上来看结果——run 目录空了、报告没了、比特流不知道去哪了。这类「结果丢失」问题八成不是文件真丢了，而是被清理脚本删了、被并发任务覆盖了、或者被写到了一个你没想到的相对路径下。它的破坏力在于不可复现：重新跑一遍要几个小时，而评审或签核就在今天上午。跨工具对照见 Quartus 回归结果丢失 与 nextpnr 回归结果丢失，工程组织见 设计流程。

本文要回答的问题 ​

  • run 目录被清了，是被谁清的、还能找回来吗？
  • 多人多任务共用一台回归机，怎么避免互相覆盖？
  • 产物到底写到了哪里，怎么让路径可预期？
  • 回归产物该按什么策略归档和留存？

一、报错原文与现象 ​

结果丢失通常没有报错，只有「找不到」：

text
# 预期位置是空的
$ ls runs/impl_1/
ls: cannot access 'runs/impl_1/': No such file or directory

# 或者 Vivado 里看 run 状态被重置
ERROR: [Runs 36-527] Run 'impl_1' results are out of date or missing. 
The run will be reset.
# launch_runs 前脚本里的一行 reset_run 把所有中间产物清了

典型场景三种：整个 run 目录消失（被清理）、目录在但状态被 reset（产物被判过期）、产物在一个陌生的路径下（相对路径跑偏）。先确认是哪一种，再谈找回。

二、可能原因总览 ​

报错/现象可能原因处置
run 目录整个没了清理脚本/cron 误删查清理规则与日志，从归档恢复
run 状态被 reset脚本调了 reset_run 或工程被改动产物已删，重跑；修脚本逻辑
产物在陌生路径脚本 cd 后相对路径跑偏产物路径一律绝对化
两份回归结果互相覆盖并发任务共用同一工程目录每任务独立工作区
比特流找不到只跑到了 route 没跑 write_bitstream检查 run 完成状态与脚本步骤
报告是上一轮的新 run 失败，旧产物没清产物带时间戳，看 mtime 别只看名字
磁盘满写入失败但没报错写盘失败被脚本吞掉查磁盘与脚本错误处理

三、逐条排查展开 ​

先回答「是被删了，还是根本没生成」。 两个方向证据不同。被删了：文件系统的其他快照（备份、ZFS/btrfs snapshot、版本库归档目录）里能找到影子，或清理脚本日志里有删除记录。没生成：回归脚本的日志末尾停在半路（磁盘满、license 失败、综合报错），所谓「丢失」其实是「从未产生」。先看回归主日志的最后十行，多数情况答案就在那里。

清理脚本是最常见的「凶手」。 很多团队有磁盘清理 cron：「删除 7 天前的 run 目录」。规则写得糙一点（比如按目录名匹配 runs/*、没排除正在运行的任务），就会把昨夜刚跑完、还没来得及归档的结果清掉。排查：

bash
crontab -l                       # 本用户的清理任务
ls /etc/cron.d/                  # 系统级清理任务
grep -r "rm -rf" ~/scripts/      # 找带删除逻辑的脚本

找到后别急着改，先确认它的匹配规则与保留窗口，把「正在运行」与「未归档」两类目录加入排除清单。

reset_run 与工程改动会静默清空产物。 Vivado 的 run 有「状态」概念：源文件或约束的 mtime 比 run 产物新，run 就被标为 out-of-date；脚本里如果无脑调用 reset_run 或 reset_project，中间产物直接删除。常见触发：回归脚本开头「保险起见」先 reset 一遍；或有人改了约束文件（哪怕只是加了注释），所有 run 全部过期。纪律：reset 只在你明确要重跑时调用，脚本里每个 reset 都要打日志说明原因。

并发互踩：两个任务写同一工程目录。 回归机上两个会话同时打开同一工程、或两个批处理任务共用同一目录，Vivado 的 run 管理会互相覆盖——后启动的把先启动的产物判为过期清掉，或者两个 impl_1 目录轮流被写。判别：看产物的 mtime 是否在你任务运行期间被另一进程刷新；lsof +D runs/ 看谁还开着这个目录。根治：每个回归任务用独立工作区（按任务号建目录，如 ws/job_1024/），工程从模板脚本现场重建，永不共享活目录。

相对路径让产物「写到了别处」。 脚本里 launch_runs 之前 cd 到了别的目录，或者 Vivado batch 模式的启动目录与预期不同，产物就会落到「当时的目录」下。找回方法简单粗暴：

bash
find / -name "*.bit" -newermt "2026-10-25 00:00" 2>/dev/null
find ~ -name "timing_summary*.rpt" -mmin -720 2>/dev/null

按修改时间全盘找一遍，多数「丢失」的比特流都能找到。然后修脚本：所有产物路径写成绝对路径，回归根目录用一个变量统一定义。

「报告是旧的」是最阴的一种丢失。 新一轮回归失败了，但旧产物没清，目录里躺着的 timing 报告是三天前的——评审会上拿它汇报，事故级别比丢结果更高。防范：产物文件名带时间戳或 run id；看文件必看 mtime；回归脚本开始前先清空或移走旧产物，让「没跑成」表现为「目录是空的」而不是「目录里有旧数据」。

磁盘写满时写入会静默失败。 写比特流或报告时磁盘满，部分脚本配置下 Vivado 只报 WARNING 甚至静默跳过，日志埋在几百行中间。回归结束后目录里缺文件，看起来就像「丢了」。回归脚本收尾加一条产物存在性检查（bit/rpt/日志三类清点），缺了立刻标红，比事后翻日志快得多。

四、排查流程图 ​

fpga/beginner/ts-vivado-regression-result-missing.md D2 示意图

图的核心分叉在蓝色「定性」节点：被删与没生成是两条完全不同的路。被删走清理规则与快照恢复；没生成走日志找失败点。两路汇合后统一进入并发隔离与归档纪律——防止下一次丢失比找回这一次更重要。红色入口、蓝色排查、橙色修复、紫色沉淀。

五、预防与纪律 ​

  • 每任务独立工作区：回归任务按 job id 建目录，工程脚本化现场重建，永不共享活目录。
  • 产物路径全绝对化：回归根目录一个变量定义，bit/rpt/log 路径不许出现相对引用。
  • 收尾清点产物：脚本最后核对比特流、时序报告、日志三件套，缺一件回归判失败。
  • 清理规则保护未归档产物：清理脚本排除「近 N 天」与「未打归档标记」的目录，删除动作写日志。
  • 归档带指纹：产物连同工具版本、git commit、约束哈希一起归档，结果可追溯可复现。
  • 看文件看 mtime：任何评审用数据，先确认修改时间属于本轮回归。

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

本篇是 FPGA 排错速查簇中「回归与产物管理」节点的 Vivado 页：与 Quartus 回归结果丢失、nextpnr 回归结果丢失 互为跨工具对照；磁盘写满导致产物静默缺失的排查见 Design Compiler 磁盘写满；工程与回归组织背景见 设计流程，系列总览见 FPGA 知识版图。

一句话总结 ​

Vivado 回归结果丢失先定性「被删了还是没生成」：被删查清理脚本与 cron、从快照归档恢复，没生成看回归日志末尾找失败点（磁盘满、license、综合报错）；并发互踩用 lsof 判别、以每任务独立工作区根治；产物路径全部绝对化、文件名带时间戳、脚本收尾清点三件套；最终把「产物带指纹归档 + 清理规则保护未归档」写进回归脚本，让丢失从事故变成不可能。