极客工场

Appearance

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

Vivado 磁盘写满：No space left on device 速查 ​

更新时间：2026-10-22。FAQ 速查页，面向 FPGA 入门 阶段在笔记本或共享服务器上跑 Vivado 的同学。Vivado 是个典型的「磁盘吞吐型」工具：一个中等工程跑完布局布线，.runs/impl_1 下的检查点、日志、报告，加上 IP 生成物和仿真波形，工程目录涨到 GB 级甚至几十 GB 是常态（具体体量以工程规模与版本为准）。盘满的报错直白时是一句 No space left on device，阴损时 IP 生成中途断掉、.runs 里留下半截产物，下一轮运行报的却是文件损坏。本篇只讲磁盘容量与 inode 一条线；片上资源（LUT/BRAM 用超）与主机内存 OOM 的分诊见 Vivado 资源不足，写文件被拒的权限类原因见 Vivado 权限被拒。

本文要回答的问题 ​

  • write_bitstream / write_checkpoint 报 [Common 17-69] couldn't open file ... No space left on device，先救场还是先重跑？
  • df -h 看着还有空间，Vivado 为什么还是写不进文件？
  • 一个工程目录里到底是谁在吃盘，.runs、.gen、.cache、仿真波形分别能不能删？
  • xsim 仿真波形转储到一半失败，怎么让波形别再动辄几个 GB？
  • 服务器家目录报 quota 超限、Windows 弹「磁盘空间不足」，与本机盘满有什么不同？

一、报错原文与典型现象 ​

最常见的是写检查点或比特流的当口失败，工程路径以 /proj/demo 占位：

text
ERROR: [Common 17-69] Command failed: Write to file
"/proj/demo/project.runs/impl_1/top_routed.dcp" failed.
    No space left on device
ERROR: [Common 17-69] couldn't open file
"/proj/demo/project.runs/impl_1/top.bit": No space left on device

第二种现场在 IP 生成与仿真阶段。IP 输出产物写到一半失败，.gen、.runs 目录里留下不完整文件；xsim 全信号波形转储时 .wdb 写穿，仿真本身可能已跑完，但波形库不可用：

text
ERROR: [IP_Flow 19-xxxx] Failed to generate output products:
couldn't open "/proj/demo/project.gen/sources_1/ip/clk_wiz/...": No space left on device
ERROR: [Common 17-69] Write to waveform database
"/proj/demo/project.sim/sim_1/behav/xsim/test.wdb" failed.

还有两种容易误判的形态：journal 与 vivado.log 先写不进，随后工具出现按键无响应、Tcl 回显异常等古怪行为，根子仍是盘满；Windows 上则可能不弹 Vivado 错误框，而是操作系统先弹出「磁盘空间不足」提示，D 盘可用空间显示为 0。还要警惕「二次故障」：盘满当时没注意，下一轮运行读着上一轮写了半截的检查点或 IP 产物，报的是文件损坏、版本不匹配之类的新错误，排查方向容易被带偏到设计上——看到这类报错先回头查上一轮日志尾部有没有 No space left。读这类报错抓住一点：凡是路径落在工程目录、动词是 write/open/create 且带着 No space left 或 Disk quota exceeded，就是容量问题，不是设计错误也不是 license 问题。

二、占盘大户与病因处置表 ​

占盘来源典型位置体量与特征处置
布局布线检查点project.runs/impl_1/*.dcpplace/route 后 .dcp 单个即 GB 级只留最新成功 run，旧 .dcp 确认不回溯后删
多轮 runs 历史project.runs/synth_1、多次 impl runVivado 不自动清历史 run，轮数线性堆积Tcl 里 reset_run 重置旧 run 后整目录清
IP 生成物project.gen/、各 IP 的 synth_ip每个 IP 独立综合，各留一份产物不用的 IP 从工程移除后清对应目录
IP 下载缓存project.cache/集中下载的 IP 包，随 IP 数量涨可整目录删，下次生成会重新下载
仿真波形project.sim/.../xsim/*.wdb全信号 dump 一波长仿真可达数 GB限定波形深度、按需 log_wave，不递归全加
handoff/bit/report 全套impl_1 与 *.runs 产物区bitstream、handoff、各级 report归档最新成功一套，旧 run 随清理带走
journal/日志vivado.log、vivado.jou 及 runs 日志长 run 日志可观但通常非头号大户跑完压缩归档，不与检查点抢盘
inode 耗尽小文件密集的 .gen/.cachedf -h 有余量、df -i 100%整目录清旧 IP 生成物，删大文件无效
服务器配额家目录或 NFS 共享盘报 Disk quota exceededquota -s 查限，归档或申请扩容
多版本 Vivado 本体安装目录每个版本各占几十 GB不用的旧版本从安装器卸载

表中体量均为典型量级，具体数字以本工程规模与所用 Vivado 版本为准。

三、排查决策图 ​

先判「容量满还是 inode/配额满」，再用 du 定位大头，最后才动手清理——顺序反了会白删文件。

fpga/beginner/ts-vivado-disk-full.md D2 示意图

读这张图抓住一次分叉：红色入口先经蓝色的 df 双判，切成「容量满」与「inode/配额满」两条互不相干的通道，再汇入蓝色的 du 下钻定位。红色只标现象与命中的根因，蓝色全是排查动作，橙色是这一次的救火动作，绿色闭环是重跑失败阶段确认产物完整。不要跳过双判直接删大文件——inode 耗尽时删几个 GB 的 .dcp 毫无作用，得清小文件密集的整棵目录。

四、逐条排查展开 ​

第一刀：容量、inode、配额三条线一起看。 Linux 上在工程根敲：

bash
df -h /proj/demo                 # 工程所在卷容量水位
df -i /proj/demo                 # 同一卷 inode 水位
du -h --max-depth=2 /proj/demo 2>/dev/null | sort -rh | head -20
du -sh project.runs project.gen project.cache project.sim 2>/dev/null

Use% 打到 100% 是容量写穿；df -h 还空着但 IUse% 100%，是 .gen、.cache 里海量小文件吃光了 inode，表现同样是写失败。共享服务器再敲 quota -s（具体命令随存储系统而异），报 Disk quota exceeded 时满的不是卷而是个人配额，看卷水位没有意义，删东西也要删自己账下的。

第二刀：按目录定位，分清哪些能删。 du 排序的常客通常是 impl_1 的路由检查点、历代 synth/impl run、IP 生成物与仿真波形。处置口径：确认不再需要回溯时序的旧 .dcp 直接删；历史 run 在 Vivado Tcl 控制台先 reset_run synth_1（或对应 run 名）重置，再清目录，避免工程数据库仍登记着半截产物；project.cache 可整目录删除，代价是下次生成 IP 重新下载；.gen 与 synth_ip 删后对工程执行 Report IP Status 并重新 Generate Output Products。常用的重置命令如下（run 名按工程实际替换）：

tcl
reset_run synth_1
reset_run impl_1
# 随后在操作系统侧删除对应 run 目录，再重新 launch

删之前看文件时间——正在跑的 run 目录误清比盘满更难收拾，多人共用机器时先确认属主；写穿当次的半截 .dcp、.bit 不可信，工具未必自查得出，「写入完成」的提示也可能照打，腾出空间后从失败阶段重跑，不要试图续用。IP 综合产物的共享策略随版本不同而变化，拿不准则统一走「重置后重新生成」这条保守路线。

第三刀：把波形的嘴管住。 xsim 占盘的头号原因是全信号、递归 dump：testbench 里 log_wave -r / 不加节制地跑长仿真，.wdb 涨到数 GB 很常见。改为只 log_wave 需要观察的层次与接口信号，或在仿真运行参数里限定采集深度与时间窗口；先用短波形定位大致区间，再对可疑区间加细粒度信号重跑一轮，比一上来全量录制省盘也省打开波形的时间。调试结束记得恢复精简配置再提交、再跑回归，别把调试波形脚本带进日常流程。工程目录组织与基本流程背景见 Vivado 快速上手。

第四刀：清不动就挪。 系统盘本身紧张时（笔记本上 Vivado 本体与多个版本已占几十 GB），把工程建到独立数据盘，Windows 下如 D:/proj/demo；旧版本 Vivado 从安装器卸载，不要手删安装目录。Windows 还要避开 OneDrive 等同步盘的虚拟占位——同步盘容量受云端配额约束，图标带云朵的文件未落地时批量写同样失败，工程目录应移出同步区或设为「始终保留在此设备上」。路径本身带空格或特殊字符引发的写入失败是另一类问题，见 Vivado 路径找不到。

五、预防与纪律 ​

  • 工程放独立大盘：远离系统盘与同步盘，经验上建议给工作卷预留约 20% 的空闲，容纳一轮 run 的突发峰值。
  • CI 与回归收尾即清：只归档最新成功 run 的 .dcp、.bit 与必要报告，历史 run 在脚本里 reset_run 后清理。
  • 波形按需开：日常回归不带全信号 dump，调试波形配置不进提交分支。
  • 定期 du 巡检：共享机器把工程目录大小纳入例行检查，水位超阈值先归档再跑新任务。
  • IP 与版本清点：移除不用的 IP 让 .gen、.cache 随之收缩，旧版 Vivado 及时卸载。

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

本篇是 FPGA 工具排错速查簇的 FAQ 页，专管磁盘容量与 inode 一条线；片上资源用超与主机内存/OOM 的分诊在 Vivado 资源不足，写文件被操作系统拒绝的权限问题在 Vivado 权限被拒，三者共同覆盖 Vivado「资源与文件」类高频报错。设计流程背景见 FPGA 设计流程，工程源码与产物的目录纪律见 RTL 版本控制。

一句话总结 ​

Vivado 磁盘写满先 df -h、df -i、quota -s 三线双判容量、inode 与配额，再用 du 下钻锁定 .runs 旧检查点、历代 run、.gen/.cache 与 xsim 大波形：能删的按「reset_run 重置、删旧 .dcp、清 IP 缓存、波形按需采集」处置，写穿当次的半截产物腾空间后重跑不续用，系统盘紧张就把工程挪到独立大盘并卸载旧版本；长期靠工程上大盘、回归收尾即归档清理、预留约 20% 空闲三条纪律防复发。