Vivado 资源/内存超限速查：器件放不下与机器扛不住怎么分
更新时间：2026-10-22。FAQ 速查页，属于 FPGA 工具报错排错系列。Vivado 报「超限」时，新手最容易走错方向的一步是没分清两件事：一类是 FPGA 芯片本身的片上资源不够（LUT、BRAM、URAM、DSP48、FF 放不下），另一类是跑 Vivado 的主机资源不够（内存、Java 堆、磁盘、文件句柄）。两者报错都带「failed / resource / memory」字样，处置却一个在 RTL、一个在机器。本篇负责把两类超限一次分流并给出处置主线；其中 LUT 单一类型打满的设计优化有专文深讲，见 Vivado 资源超限：LUT/BRAM 爆了怎么救，本篇不重复展开，只做全资源类型与主机侧的覆盖。
本文要回答的问题
place_design报[Place 30-...] failed to place与报Java heap space，分别是哪一侧不够？- 总利用率才 80%，为什么 BRAM 一栏 110% 也会直接失败？
- Linux 下 Vivado 退出码 137 和段错误 139 怎么区分？
- 不换器件、不换机器，各自有哪些立即可做的降载手段？
- 怎么提前发现资源峰值，而不是等作业半夜挂掉？
一、报错原文与现象
A 类：片上资源放不下。 综合能过，实现阶段布局器退出，路径与模块名为占位：
ERROR: [Place 30-...] Failed to place all RAMB36/RAMB18 cells.
ERROR: [Vivado Target ...] SLICEL / BRAM / DSP48 utilization exceeds available resources.
+ ----------------+------+-------+------------+
| Site Type | Used | Fixed | Prohibited |
| RAMB36E2 | 312 | 0 | 0 | Available: 288 (108%)
| DSP48E2 | 980 | 0 | 0 |
+ ----------------+------+-------+------------+典型迷惑点：Summary 总表看着只有 80%，但某一类硬核（常见是 BRAM 或 DSP）单独打满，布局照样失败。FPGA 资源不能跨类型拆借，LUT 再有富余也救不了 BRAM 110%。
B 类：主机资源不够。 工具自己在日志里喊内存，或者进程被系统杀掉、磁盘写满：
# vivado.log 内，工具自身的 JVM 分配失败：
Exception: java.lang.OutOfMemoryError: Java heap space
# Linux 终端，作业被内核 OOM-killer 杀掉（128+9=137）：
/proj/demo/run_impl.sh: line 40: 8231 Killed vivado -mode batch -source impl.tcl
# 磁盘或配额触顶，常出现在 write_bitstream / 导出报告阶段：
ERROR: ... write_bitstream: No space left on device
Disk quota exceeded: cannot write to /proj/demo/.runs退出码 137 是被杀（SIGKILL，多为 OOM），139 才是段错误（SIGSEGV）——两者病因完全不同，崩溃侧的判据见 Vivado 段错误崩溃速查。
二、分流决策图
先看报错关键字定通道，再谈处置，是这类问题唯一的正确顺序。
读这张图抓住一个分叉：红色是入口现象与命中的两类根因，蓝色是唯一的分诊动作——翻日志最后几十行找关键字，橙色是两条互不相通的处置通道，绿色是沉淀为基线。片上问题去调主机参数毫无用处，主机 OOM 去改 RTL 同样南辕北辙；进错通道，原命令重跑只会在同一堵墙上再死一次。
三、病因处置速查表
| 现象 / 报错锚点 | 超限一侧 | 一判据 | 处置方向 |
|---|---|---|---|
[Place 30-...] failed to place all RAMB | 片上 BRAM | 利用率表 RAMB 一栏 ≥100% | 查大 FIFO/数组是否进 BRAM、位宽对齐、考虑 URAM |
| DSP48 一栏打满，LUT 也异常高 | 片上 DSP | 乘法没被推断进 DSP48 | 核对推断条件与 use_dsp 属性，详见 DSP 算术资源用法 |
| 整体 80% 但单类型破百 | 片上单类型 | Summary 分类型读数 | 只追打满的那一类，不看总 LUT |
Java heap space | 主机 JVM 堆 | vivado.log 有 OutOfMemoryError | 按版本帮助调堆参数，见下节保守口径 |
| 终端 Killed，退出码 137 | 主机物理内存 | dmesg 有 OOM 行 | 降 -jobs、关 GUI、换大内存机 |
| route/write_bitstream 阶段几十 GB 峰值 | 主机内存峰值 | 峰值随并行度上涨 | 降并行、分阶段跑、batch 模式 |
No space left on device | 主机磁盘 | df -h 工程卷 100% | 清 .runs/.cache/IP 生成物，挪本地 SSD |
Too many open files | 主机文件句柄 | ulimit -n 仅四位数 | 调高 nofile 限额后重开 Vivado |
NFS/HDFS 配额报 Disk quota exceeded | 主机配额 | 本地盘有余、共享盘配额满 | 工程放本地盘，共享盘只归档 |
表中不写任何具体堆大小与机器内存数字——阈值随 Vivado 版本、器件规模和本机配置浮动，以所用版本的文档与实测峰值为准。
四、A 类处置：片上资源按类型回收
第一步永远是生成分层利用率报告，而不是盯着总表：
report_utilization -hierarchical -file /proj/demo/util_hier.rpt
report_utilization -slr # SSI 器件还要按 SLR 分区看Summary 表确认打满的是 RAMB、URAM、DSP48 还是 FF，再按层级树找到占用最大的模块，从大头砍起。常见三个推断坑：其一，大 FIFO/数组的异步读或带复位的写法让 BRAM 退化成分布式 RAM 甚至寄存器阵列，用 (* ram_style = "block" *) 显式指定，并检查复位是否让存储体无法映射进硬核；ROM 同理用 rom_style 引导。其二，UltraScale+ 的大缓冲没上 URAM（单块容量约为 BRAM 的八倍），「BRAM 超、LUT 有余」时优先评估 ram_style = "ultra"。其三，乘法器因位宽或流水线结构不匹配没进 DSP48，在 LUT 里搭出巨型乘法器。这三条推断坑的完整修法与位宽、深度对齐算法都在 Vivado 资源超限：LUT/BRAM 爆了怎么救 与 BRAM 存储器设计，本篇不重复。
确认不是推断错误、资源确实不够时，只剩三条架构路：降数据位宽与并行度、对运算单元做时分复用（参考 流水线与资源优化）、换大一号器件（part）。换型是最后手段，但也比在 98% 利用率下死磕布局布线便宜。
五、B 类处置：主机侧降峰值、调堆、清盘
内存：先砍并行度，再谈加内存。 route_design 与多个 IP 并行生成是内存峰值的主要来源，launch_runs/launch_simulation 的 -jobs 开得越大，各 run 各持一份数据，峰值近似随并行度上涨。大工程先把 jobs 压到物理核数以内；GUI 本身也占可观内存，CI 与长跑一律用 vivado -mode batch -source。峰值仍超物理内存时，进程会在毫无 Java 报错的情况下被 OOM-killer 杀掉留下 137——此时 dmesg | tail 能看到内核记录。
Java 堆：看版本帮助，不照搬固定值。 报 Java heap space 说明撞的是 Vivado 自身 JVM 的堆上限。先用 vivado -version 确认版本，再查该版本发行说明与 UG 文档（UG835《Tcl 命令参考》及安装目录下的内存调优说明）中关于启动参数（不同版本的 -jvm/Xmx 类参数名与默认值有差异）的章节，按文档指引调整；不要从网络帖子抄一个数字跨版本套用。加堆只是提高工具侧的天花板，机器物理内存不够时调再大也会被 OOM 兜回来。
磁盘：工程放本地 SSD，盯着 .runs 与 .cache。 排查三连：
df -h /proj/demo ; df -i /proj/demo
du -sh /proj/demo/*.runs /proj/demo/.cache
ulimit -ndf -h 有余量但写文件失败要看 df -i 的 inode；IP 生成物、增量 run 和综合缓存是磁盘大头，归档后清理旧 run 即可回收。工程目录放在 NFS/HDFS 等配额盘上还会撞配额与慢 IO，作业「卡住不动」类表现与 Vivado 运行卡死/超时速查 里的慢盘同源，规范做法是工程全程在本地 SSD，跑完只归档报告与比特流。
六、预防与纪律
- 利用率红线按单类型定（如各类硬核 80%），不看总表；每次综合归档分层报告，关注突增。
- CI 机器规格与设计规模匹配：新器件首跑先采样内存峰值（
top -p <pid>看 RES），按峰值定提交队列与并发上限。 - 分阶段跑综合/实现/写比特流并及时归档
.runs，不在一个超长作业里赌全程。 - 存储数组声明即写
ram_style、乘法对照 DSP 推断模板写，把 A 类问题消灭在综合评审。 - 提交脚本固定检查：工程在本地盘、
df -h有余量、ulimit -n已调高、batch 模式与 jobs 数显式指定。
这一篇在知识体系里的位置
本篇是 FPGA 工具排错速查簇中「资源触顶」的分流页：片上单类型（LUT 为主）打满的设计优化深读 Vivado 资源超限：LUT/BRAM 爆了怎么救；退出码 137 与 139 分不清时看 Vivado 段错误崩溃速查；进程不退出也不推进看 Vivado 运行卡死/超时速查；资源优化后引入的时序紧张与 Vivado 时序不收敛怎么办 互为因果，建议一起评审。底层资源形态见 BRAM 存储器设计 与 DSP 算术资源用法。
一句话总结
Vivado「超限」先按报错关键字分两条通道：Place 30、RAMB/DSP 放不下、单类型利用率破百是片上资源不够，用 report_utilization -hierarchical 定位大头、查 BRAM/URAM/DSP 推断形态再谈架构降载或换型；Java heap space、退出码 137、No space left 是主机扛不住，先降 -jobs 并行度、用 batch 模式、按版本文档调堆、工程放本地 SSD 并清理 .runs，最后把单类型利用率红线与内存峰值采样固化成 CI 纪律。