FPGA 入门 33：资源利用率报告——看懂 LUT/FF/BRAM/DSP 占用
更新时间：2026-09-12。本文是
fpga/入门层第 35 篇。资源原理见 LUT 与 FF 深入，存储落位见 BRAM vs 分布式 RAM，乘法落位见 DSP48 初认识。
本文要回答的问题
- 一个 slice 里 LUT、FF、进位链、多路选择器是怎么组织的？为什么报告里 LUT 数量和 FF 数量要分开看、不存在「一个 slice 用了一半」这种线性换算？
- LUT as Logic、LUT as Distributed RAM、LUT as Shift Register 三个子项分别说明设计里有什么结构？SRL 是什么、为什么一条长延迟线可能只占几个 LUT？
- 综合后、布局后、布线后三个阶段的利用率为什么会不一样？哪些数字在哪个阶段才可信（时钟资源、IO、布线后拥塞）？
- 利用率高到什么程度算危险？80%、90%、95% 各自带来的工程后果是什么？为什么「能放下」不等于「能交付」？
- 除了总百分比，报告里还有哪些必须逐模块看的信息（hierarchical utilization、按 IP/模块统计、时钟域分布）？
- BRAM 位宽/深度组合、DSP 打包率、URAM、Block Arithmetic 这些细节怎么影响真实可用容量？
- 资源和时序、功耗、成本之间怎么联动取舍？选型时除了四项主资源还要核对哪些「会一票否决」的资源？
读完本文，你应当能把一份 Utilization 报告从「总表」读到「每个模块的落点」，能在项目早期用量级估算判断器件档位，并能在资源紧张时按正确优先级做优化决策。
一、主要资源
| 资源 | 作用 | 报告关注点 |
|---|---|---|
| LUT | 组合逻辑/分布式 RAM/SRL | as Logic / as Distributed RAM / as Shift Reg |
| FF | 寄存器 | 数量；Latch 应为 0 |
| BRAM/URAM | 块存储（RAMB36/18） | 大数组/FIFO/帧存应落这里 |
| DSP48 | 乘法乘加 | 乘法应落这里 |
| IOB/IO | 管脚/Bank | 引脚数、电平 |
| BUFG/PLL/MMCM | 时钟资源 | 时钟树/时钟管理 tile |
二、两个阶段的报告
- 综合后：估计值，早期看量级、检查 BRAM/DSP 推断对不对；
- 实现后（P&R）：真实值，放不放得下以它为准，配合 Power/Timing 一起看。
三、用报告抓“资源落错地方”
| 现象 | 说明 | 回到哪篇修 |
|---|---|---|
| FF 暴涨、BRAM 没用 | 大数组被摊成触发器 | 29 BRAM：同步读/去复位/ram_style |
| LUT 暴涨、DSP=0 | 乘法用逻辑搭 | 30 DSP48：signed/打拍/去异步复位 |
| Latch 计数非零 | 组合逻辑推断了锁存器 | 18 锁存器坑 |
| 分布式 RAM 吃光 LUT | 浅存储挤占逻辑 | 部分改 BRAM |
| 长移位用一堆 FF | 没推断 SRL | 让工具用 SRL |
四、选型与余量
- 在目标/同系列器件上综合 → 读 Util%；
- 主要资源留 20%~30% 余量（太高布线拥塞、时序差、没扩展空间）；
- 同时核专用资源：DSP 数、BRAM 容量、SerDes 收发器、IO/Bank、PLL 数；
- 中等器件先开发、跑实现后再定最终档位。
五、资源到底长在芯片什么位置：从 slice 到列
利用率数字背后是真实的硅片版图。7 系 Xilinx 器件的主体是一排排 Configurable Logic Block（CLB），每个 CLB 含两个 slice，每个 slice 含 4 个 6 输入 LUT、8 个 FF、进位链和若干多路选择器。关键性质是：LUT 和 FF 虽然同居一个 slice，但它们是独立资源——一个只用 LUT 的组合设计可能 LUT 用了 80% 而 FF 几乎为零，反之大量寄存器设计 FF 高、LUT 低。报告里两者的百分比不能互相推导，也不存在「slice 利用率」一个数说了算，必须分开看。
LUT 本身还有三重身份，这正是报告里三个子项的由来：
- LUT as Logic：6 输入函数发生器，实现任意组合逻辑。一个 6 输入真值表就是 64bit 掩膜。
- LUT as Distributed RAM：一个 6 输入 LUT 可拆成 64×1 的分布式存储，同 slice 的四个 LUT 可拼成 256×1 等形态。浅 RAM/FIFO 落这里。
- LUT as Shift Register（SRL16/SRL32）：同一批存储位配置成移位寄存器，一个 LUT 顶 16/32 级延迟线。一个 256 级同步延迟链用 FF 要 256 个，用 SRL 只要 8 个 LUT 出头——所以长延迟线「凭空消失大量 FF」往往是推断成了 SRL，是好事。
再往上看，器件不是均匀的逻辑海：BRAM 是一根根固定容量（18Kb/36Kb）的存储列，DSP48 是一条条乘法列，时钟管理 tile（MMCM/PLL/BUFG）、高速收发器 Quad、PCIE 硬核、XADC 等都有固定位置和数量。这解释了两类反直觉现象：一是总 LUT 才 50% 但工具报放不下——你用的资源局部挤在一起（比如几百个 BRAM 集中在芯片一侧，配套逻辑布不过去）；二是换更大一档芯片有时频率反而提高——资源分散后关键路径更容易找到短走线。所以读报告除了总表，还要养成看 Device 视图里资源分布热力的习惯，局部拥塞看颜色比看百分比更早暴露问题。
Intel 平台词汇对照：ALM/LE（自适应逻辑模块，对应 slice 里的 LUT+FF 组合）、M9K/M20K/M144K（对应 RAMB18/36 等块存储）、MLAB（对应分布式 RAM）、DSP Block（对应 DSP48）、LAB（对应 CLB）。数字不通用，换算关系要查手册，但「组合、寄存器、存储、乘法、布线」五类资源的心智模型完全通用。
六、三个阶段的报告：什么时候该信哪个数
Vivado 流程里至少能看三次利用率，它们回答不同问题：
- 综合后（Post-synthesis）：RTL 被翻译成厂商原语（LUT/FF/RAMB/DSP），但没做布局，时钟树、部分 IO 逻辑、IP 包装的开销按模型估。用途：查推断是否正确、做早期量级判断。这一步 DSP=0 而 RTL 里有乘法，就不用等两小时布线再发现问题。误差通常在 10% 上下，复杂 IP 和存储组织可能偏得更多。
- 布局后（Post-placement）：每个原语有了物理坐标，逻辑优化（phys_opt）可能搬移/复制寄存器，数字小幅变化。用途：看时钟资源落地、IO 放置、初步拥塞。
- 布线后（Post-route）：所有连线接通，这是「真实账单」。能不能放下、最终频率、功耗计算都以这里为准。
经验做法：综合后扫三件事——推断正确性（BRAM/DSP/latch）、量级（离 100% 多远）、模块间资源比例是否符合预期（比如一个 FIFO 不该比主算法还大）；布线后确认总量和时序，必要时看每个 Pblock/区域的拥塞等级。不要拿综合报告做器件选型的唯一依据，也不要因为布线后数字比综合时大一点就以为工具出错——网表转换、时钟缓冲、IO 原语、调试核都是在后续阶段才完全计入的。
报告导出上，Vivado 有 utilization report（GUI）、report_utilization（Tcl，可导表格/文件）、checkpoint 里的层级展开；CI 里常用 Tcl 脚本 grep 关键行，资源超阈值就失败。团队协作时建议把「综合后推断对账」和「布线后总量红线」固化成两条自动检查。
七、逐模块对账：别只看全芯片总数
全芯片总数回答「放不放得下」，但资源优化靠的是层级视图（Hierarchical Utilization）。在 Utilization 报告里展开层次树，每个子模块占多少 LUT/FF/BRAM/DSP 一目了然。对账方法是「预算制」：设计前按模块估预算（FIR 滤波器几个 DSP、视频行缓存几行 BRAM、控制平面大概多少 FF），实现后逐模块比对，超预算 30% 以上的模块单独打开看，往往能直接定位「谁把资源吃掉了」。
几类典型的异常指纹：
- 某个小 FIFO 占了整块 BRAM：深度浅时本该分布式，要么深度参数填大了，要么复位风格导致 BRAM 推断失败。
- 控制模块 LUT 异常大：case 语句覆盖几百个状态但没并行化、或宽译码、或参数化展开生成大量重复逻辑。
- FF 数是总线宽的整数倍猛增：检查是不是把本该用 ROM/BRAM 的常量表写成了 case 初始化的寄存器阵列。
- DSP 数为零但有数学运算：综合策略可能全局禁用了 DSP，或运算位宽/符号风格不符（见 DSP48 初认识）。
- DSP 数恰好翻倍：累加器实现方式导致乘法被拆成两块，或位宽超过单块乘法宽度又没让工具级联。
做层级对账时要注意 IP 核经常以黑盒出现（OOC 综合），其资源要到它自己的综合产物或综合日志里看；多个相同 IP 例化时确认报告是「单个」还是「合计」，别误判十倍。
八、BRAM/DSP 的「名义容量」与真实可用量
新手按数据手册容量算存储预算时经常对不上报告，原因是块存储有组织方式开销：
- 一块 36Kb BRAM 配成 32K×1 就是 32K 深 1 位宽；配成 1K×32 时可用数据 32Kbit，但同一物理块不能同时被两种宽度瓜分；真双端口两端口宽度不同（如一端 32 写、另一端 8 读）会按较宽组织，深度相应变浅。
- FIFO 还要消耗块内空间存指针、空满比较和可选的首字直通逻辑，标称深度 1024 的 FIFO 通常要用 2K 深度的存储组织。
- ECC、校验位会再吃掉部分位宽；URAM（UltraScale 系列的 288Kb 大块）省面积但复位、端口模式受限，不能无脑替代 BRAM。
所以存储预算要按「每块能配出的最大深度 × 需要的块数 × 1.1~1.2 的 FIFO/对齐余量」来估，而不是总比特直接除。
DSP 同理：一块 DSP48E1 是 25×18 有符号乘法加 48 位累加；18×18 的乘法一块能放，35×35 要四块级联；常数乘、很小的乘法工具可能主动用 LUT（不一定错，要看全局 DSP 是否紧张）；累加位宽超过 48 会外溢到额外逻辑。做并行度规划时直接数「每拍多少个什么位宽的乘法」，再查手册块数，比看综合结果猜更快。
九、利用率红线：多少算太高
「能放下」和「能交付」之间隔着布线拥塞、时序收敛、迭代余量三件事。工程上常用的经验区间：
- 低于 60%：轻松，布线自由度大，时序通常不是资源造成的问题，还有大量空间加功能、加 ILA。
- 60%~80%：健康量产区间。工具仍有足够布线选择，拥塞风险低，留有版本迭代余量。
- 80%~90%：警戒区。要开始逐模块对账、规划优化；拥塞区域会出现在报告里，时序可能需要额外努力度才能收敛；调试核预算要精打细算。
- 90%~95%：高压区。布线时间明显变长，结果对约束和种子（implementation seed）敏感——「这次过、下次不过」开始出现；加任何功能都可能引发连锁返工；必须准备缩小功能或升档器件的预案。
- 超过 95%：基本不可交付。即使某次布线通过，量产一致性、温度电压角下的时序、后期任何需求变更都会失控。
注意这是对任何一种瓶颈资源而言：LUT 70% 但 BRAM 98%，设计已经没有空间加缓冲，瓶颈项单独决定档位。还要区分均匀占用和局部拥塞：数据路径天然集中在 BRAM/DSP 列附近，报告 Congestion 栏出现中等以上拥塞、布线延迟占比上升时，即使总百分比不高也要警惕，可用 Pblock 或修改模块布局改善（物理约束是进阶话题）。
十、资源 × 时序 × 功耗 × 成本的联动
资源决策从来不是单目标：
- 资源换时序：流水线复制乘法器、展开循环用更多并行硬件，频率上升但 LUT/DSP/FF 增加；反之时间复用（一个 DSP 轮流算多个抽头）省资源但吞吐下降。
- 资源换功耗：高密度器件静态功耗占大头，选更大芯片会显著增加漏电；利用率高的小芯片动态功耗集中、局部热点风险大。功耗报告要在布线后活动率信息较准时再读（供电散热见 供电与散热，功耗签核见进阶 FPGA 功耗估算）。
- 封装换 IO：有时资源逻辑上够，但管脚数或 Bank 电压组合不支持，被迫升一档封装；高速收发器数量、PLL 个数、支持的电平标准都可能成为一票否决项。
- 成本与生命周期：选器件要留供货周期和降档空间。同一封装内不同容量引脚兼容时，硬件按大容量设计、先贴小容量出货，是常见的产品策略。
选型核对清单（资源之外）：IO 总数与可用 GPIO（扣除配置/电源/时钟专用脚）；差分对数量；Bank 划分与 Vcco 组合是否支持你要的电平混用；GTP/GTX 收发器数量与支持的速率；PLL/MMCM 个数及所在 Bank；BRAM/DSP 总量；片内 RAM 是否要外接 DDR 及 DDR 控制器硬核支持；温度等级（商业/工业/汽车）；速度等级（-1/-2/-3）；封装尺寸与 PCB 难度；供货与价格。任何一项不满足都可能推翻「主资源够了」的结论。
十一、读报告的标准动作与自查清单
拿到一份新工程的利用率结果，建议固定按这个顺序读：
- 先看总表各项 Util%，圈出最高的两类资源和任何 100% 以上/Unconstrained 项；
- 看 LUT 三个子项比例，确认分布式 RAM/SRL 数量与设计预期一致；
- 看 FF 里 latch 计数——任何非零 latch 都先回到代码查清楚（见 锁存器坑）；
- BRAM 块数与自己估的 FIFO/缓冲表逐一对账；DSP 数与乘法器清单对账；
- 展开层次视图，找超预算模块，记录到资源表；
- 看时钟资源（BUFG/PLL）和 IO/Bank 使用，确认没有占用专用脚；
- 切到布线后报告复核，并扫 Congestion；
- 把关键数字（或自动导出的表格）与上一版 diff，资源突变就是回归信号。
自查清单：综合后和布线后的数都看了吗？瓶颈资源是哪一个、余量多少？该进 BRAM 的进了吗、该进 DSP 的进了吗？latch 清零了吗？预留了 ILA 和版本迭代的余量吗？选型核对清单逐项打勾了吗？资源变化进版本记录了吗？
最后记住一句话：资源报告是 RTL 风格的体检表——数字异常几乎总是代码结构问题的外在症状，而不是「工具不好」。学会对账，你的 RTL 质量会比单看仿真结果提升得更快（系统化优化方法见进阶 流水线与资源优化、资源优化）。
十二、两个完整的资源分析实例
光看规则不够，走两个从报告反推代码的完整例子，把本文方法串起来。
例子一：FF 异常暴涨的视频缓存。一个图像预处理模块，预期是两行 1920 像素、每像素 16bit 的行缓存，应该用两块 BRAM（约 60Kbit，两块 36Kb）。综合后报告：BRAM 只用了 IP 自带的一块，FF 却多了六万多个。按对账流程，先查行缓存的 RTL 写法：数组声明 reg [15:0] linebuf [0:1919]，读口是组合赋值 assign dout = linebuf[rdaddr]（异步读），而且复位块里写了 for 循环把数组清零。两个写法都在阻止 BRAM 推断：异步读要求存储像一张随时可查的表，BRAM 输出锁存一拍做不到，综合器只能把数组摊成 1920×16≈三万个 FF；复位循环更直接要求每个存储位都有可控的复位端，BRAM 不支持逐位复位，只能用 FF。修复：读口改成同步读（时钟沿里让 dout 取 linebuf[rdaddr]），去掉数组复位（初值用 initial 或上电不保证的策略，视频流本来靠 valid 控制），重综合后两块 BRAM、FF 回落。再补一个 ram_style 为 block 的属性锁死推断。这类问题的通用结论：凡是「应该在硬块里、却表现为海量分散资源」，八成是编码风格和硬件能力不匹配，而不是工具笨。
例子二：DSP 全空、LUT 爆表的滤波器。一个 16 抽头 FIR，预期 16 个乘法进 16 块 DSP。报告：DSP=0，LUT 利用率从预估的 40% 跳到 92%。排查：系数声明为整型常量没问题，但数据输入端口被声明成无符号 wire [15:0]，而系数含负值，综合时混合符号运算在部分工具策略下被推成纯 LUT 乘法；更关键的是乘法结果接了异步复位、且整个乘积在一个时钟里又乘又加又比较（三级运算没打拍），工具无法映射 DSP 的寄存器级联，只好用逻辑搭。修复三步：数据与系数统一为 signed，乘积/累加全程有符号；按 DSP 结构在乘法输入、乘积、累加输出各打一拍；去掉乘积寄存器的异步复位（或只在输入端复位）。重综合后 DSP=16，LUT 大幅回落，顺带时序也收敛了，因为寄存器级联走的是 DSP 列内专用走线。这个例子说明资源落位和时序往往是同一个问题的两面：顺着硬块的结构写，资源对了，频率也跟着对。
两个例子共用一套动作：先有「这段设计理应占什么资源」的预期（抽头数=乘法数、缓存容量=BRAM 数、延迟长度=SRL 数）；再拿报告数字对预期；对不上时，沿「存储看读写方式与复位、乘法看符号与打拍、宽逻辑看 case 与进位、延迟线看 SRL」四条线索回 RTL；修完重综合确认数字归位，并在布线后复核总量与时序。养成这套闭环后，资源报告就不再是验收时才看的表格，而是写 RTL 过程中随时照一照的镜子。
十三、资源估算怎么做在写代码之前
成熟团队不会等实现跑完才知道器件够不够，而是在架构阶段就有一张资源预算表。估算方法从粗到细分三档：
- 结构计数法（最常用）：数字信号处理和数据通路类设计，资源几乎可以从算图直接数出来。每个每拍执行一次的 N×M 有符号乘法约对应一块 DSP（位宽超界再乘倍数）；每个深度 D、宽 W 的 FIFO 或 RAM 占用的 BRAM 数按 D×W/块容量向上取整并留两成余量；每个数据通路寄存器位就是一个 FF；控制平面的状态机、译码逻辑按「状态数 × 输出宽」估 LUT，通常只占总量几个百分点，真正的大头永远是存储和运算。把模块清单逐行列出数量、位宽、并行度，乘出来就是 70% 可信度的预算。
- 参照工程法：团队做过的相似模块（视频 scaler、FFT、网络包处理）是最准的标尺，按参数比例缩放历史数据，比任何纸面公式都可靠。这也是为什么工程组织里会保留「资源参考库」。
- 快速综合法：架构有疑问时，把核心算法剥成最小工程，在候选器件上直接综合，一两小时就能消除最大的不确定性。IP 核直接看手册里的资源表，不必自己估。
预算表要分三列：算法必需、调试与软件可观测性预留（ILA、状态计数器、AXI 桥）、版本迭代余量（两到三成）。三列相加再对照器件总量，选型时心里就有底。项目中期每次大的结构变更都更新这张表，资源失控通常不是某一天突然发生的，而是十几个「就加一小块」的决定累积出来的，预算表能让每一次增加都看得见。
最后把资源意识和编码习惯连起来：写每一段 RTL 时顺手问自己三个问题——这个数组会进 BRAM 还是被摊成 FF？这个乘法会进 DSP 吗？这个信号扇出到多少地方？问得多了，代码天然就顺着 FPGA 的物理结构生长，资源报告从「事后体检」变成「写之前就知道答案」。这正是从「能写出可综合代码」到「能写出高质量 FPGA 设计」的分水岭之一。
再补一个常见误区：资源百分比和设计规模不能跨器件直接比较。同样一万个 LUT，在小型器件上是 80% 的高压区，在大型器件上可能不到 5%；更重要的是大器件里时钟树更长、绝对布线延迟更大，同一份代码在大器件上频率未必更高（工具需要把逻辑布得更紧凑才能保持时序）。所以「换大芯片频率就能上去」只在拥塞主导时成立，如果瓶颈是算法内部的组合深度，换再大的芯片也没用——路径长度取决于逻辑级数，不取决于硅片面积。反过来，在小器件里被迫贴近资源布局，有时内部走线更短、局部路径更快，但整体拥塞风险更高。频率、资源、器件档位三者要一起评估，没有单一公式。做架构评审时，资源表旁边最好同时写一列「目标频率下每类资源的实现依据」，让选型结论可以被追问和复核，而不是拍脑袋留一个百分比余量。
最后提醒一个工具使用细节：Vivado 报告里同一类资源有多个视图（Slice Logic、Memory、DSP 等分页），Block RAM 同时按 36Kb 和 18Kb 两种口径计数（一块 36Kb 可拆成两块 18Kb），看数字前先确认口径，否则容易自己吓自己——比如报告写用了 10 块 RAMB18 加 4 块 RAMB36，并不等于 14 块 36Kb，而是折合 9 块 36Kb。URAM、专用 FIFO 块也各有独立计数行。每次评审固定使用同一个导出模板，把口径、角点（典型/最差）、工具版本一起记录，跨版本比较才有意义。工具大版本升级后资源数字小幅变化是正常的（综合算法在变），但数量级突变必须查 changelog 和推断报告，不能默默接受。
还有一个实用习惯：在工程目录里保留一份「资源账本」电子表格或文本，每个版本一行，记录四类主资源、瓶颈资源百分比、最差路径裕量、器件型号、工具版本。半年后回看，你能清楚看到资源是怎么被功能需求一点点吃掉的、哪次提交引入了异常增长，比凭记忆判断靠谱得多。配合版本管理（见 RTL 版本管理），资源回归可以做成 CI 的自动门槛：合并后自动跑综合，任一资源较基线增加超过预设比例就标记警告。对学生作业这可能显得重，但一旦进入团队协作或产品迭代，这类基础设施的投入回报极快。养成每次实现后花两分钟记录资源数字的习惯，和写实验报告记录数据是同一个道理：趋势比单点更能说明问题。当资源变化能和代码提交一一对应时，「这个模块为什么占这么多」就从考古题变成了查日志。这正是把资源管理工程化的意义，也是一个 FPGA 工程师从「写完代码看报不报红」走向「对设计在硅片上的占地心中有数」的标志。
十四、和硬件团队对话时的资源语言
资源报告不只是给 RTL 工程师看的，它还是 FPGA 工程师和硬件、采购、项目经理沟通的共同语言。和硬件工程师讨论板卡设计时，对方关心的问题往往是：选哪颗封装才能放下这些 IO 引脚和高速收发器？Bank 电压怎么分？电源每路要供多少电流？散热按几瓦设计？这些问题的答案全部来自资源和功耗报告。一个常见的协作错误是 RTL 团队只报「大概够用」，硬件团队按最小器件选型，等功能增加 20% 时发现 BRAM 已经 98%，板子却已经投板，改芯片就要改封装和 PCB，代价是几周到几个月。反过来，硬件一开始选了过大的器件，BOM 成本每年多花几十万元。所以成熟团队在项目早期就会冻结一份「资源需求表」，列出每类资源的预测量、峰值量、调试预留，并标注哪些功能是确定的、哪些是可能增加的，硬件按「峰值加余量」选型，软件按表控制规模。
和项目经理沟通时，资源曲线是进度风险的早期指标。正常项目在开发中期资源快速上升，后期趋于平稳；如果临近交付资源还在陡增，说明需求仍在膨胀，要么砍功能，要么换器件，这个决策越早做成本越低。把资源数字纳入每周项目简报，和缺陷数、完成度并列，非技术管理者也能看懂「黄色区域在扩大」的含义。学会用报告里的数字支撑这些讨论，你就不再只是一个写 Verilog 的执行者，而是参与系统权衡的工程师。
常见坑对照
| 坑 | 后果 | 正确做法 |
|---|---|---|
| 只看综合估计 | 实际放不下 | 以实现后利用率为准 |
| 利用率 >95% | 布线失败/降频 | 换大芯片或优化 |
| 不看资源落位 | 推断错不自知 | 预期资源与报告对账 |
| 忽略专用资源 | 选型不够用 | 核 DSP/BRAM/SerDes |
| Latch 非零不管 | 行为异常 | 修组合逻辑完备性 |
相关与延伸
原理：LUT 与 FF 深入；落位：BRAM vs 分布式 RAM、DSP48 初认识。 深入：进阶 流水线与资源优化、资源优化；时序看 时序报告入门。
一句话总结
资源利用率报告告诉你设计用了多少 LUT（组合逻辑/分布式 RAM/SRL）、FF（寄存器，Latch 应为 0）、BRAM/URAM（块存储）、DSP48（乘法）、IO 和时钟资源，重点看 Used/Available/Util% 里接近 100% 的资源，以及功能有没有落到对的物理块。综合后报告是估计（早期看量级、查 BRAM/DSP 推断），实现后报告是真实值（放不放得下以它为准）。最有用的诊断是“对账”：FF 暴涨而 BRAM 没用=大数组被摊成触发器（去复位/同步读），LUT 暴涨而 DSP=0=乘法没用硬块（signed/打拍），Latch 非零=组合逻辑分支不全。选型时在同系列器件上综合、给主要资源留 20%~30% 余量，并核对 DSP/BRAM/SerDes/IO/PLL 等专用资源是否够用。
上一篇：35 比特流下载与 Flash 固化（JTAG/QSPI） ｜ 下一篇：37 时序报告入门（WNS/WHS/Slack） ｜ FPGA 系列目录