做 FPGA 的人对下面这个场景应该都不陌生：一个 30 万 LUT 的工程，综合加实现一次要跑八个多小时，结果你只改了两行状态机代码，或者只是把某个计数器的位宽从 16 调到 17 位，整条流程又得从头再来一遍。等一晚上，早上打开电脑一看，时序还差 0.04ns，改一下再等一天。这种迭代节奏在大规模设计里基本上是不可接受的，而 vivado 的增量实现（Incremental Implementation）就是专门用来打破这个死循环的。它的核心思路很朴素：让工具记住上一次已经布局布线好的结果，这次只重做真正改了的那部分，没动的地方直接复用原来的物理信息。用得好，八小时的流程能压到一个半小时，而且时序结果往往比全跑还稳，因为大部分走线压根没被扰动过。这篇文章我会把增量实现的机制、参数配置、实操步骤和踩坑经验完整讲一遍，适合已经能跑通基本实现流程、正在被长编译周期折磨的中高级使用者，也适合刚接手大工程、还没搞清楚复用率是怎么回事的同行。
1. 先把时间账算清楚：增量实现到底省下的是什么
1.1 一次完整实现，时间都花在哪了
要理解增量实现的价值，得先知道实现阶段的耗时结构。Vivado 的 implementation 大致分四步：opt_design（逻辑优化）、place_design（布局）、phys_opt_design（物理优化）、route_design（布线），最后是 write_bitstream。对中等规模以上的设计，opt 通常只占 5% 到 10%，布局占 15% 到 25%，布线往往是大头，能吃掉 40% 到 60% 的总时间，phys_opt 视策略而定，可能再来 10% 到 20%。
关键在于，布局和布线都是全局性的问题求解过程。布局器要在整个芯片上给几十万个单元找位置，同时满足时钟、区域、拥塞等约束；布线器要在有限的金属资源里给几百万条网络找路径。这两个过程的算法复杂度跟设计规模高度非线性相关，逻辑量翻一倍，布线时间可能翻三倍。当你只改了 2% 的逻辑，理论上 98% 的解都是现成的，但传统全流程会把它们全部丢掉重算一遍，这就是纯粹的浪费。
增量实现做的事情，就是把上一次的布局布线结果作为"参考解"喂给工具，让它在保留绝大部分解的前提下，只对发生变化的那部分网表重新求解。所以省下的时间不是线性的一点点，而是把布线这个最大的时间消耗项整体砍掉大部分。
1.2 增量实现的两条前提
不过它不是什么魔法，得满足两个硬前提才有效果。
第一条是你必须有一份已经完成布局布线的参考检查点。这个检查点通常就是上一次 write_bitstream 之前的那个 routed dcp 文件，体积视设计规模从几十 MB 到一两 GB 不等。没有它，增量实现无从谈起——这是很多人第一次尝试时最容易忽略的地方，直接勾了增量选项却发现工具压根没复用，因为没有指定参考文件。
第二条是本次改动必须相对局部。改动越小，复用率越高，收益越大。行业里比较通行的经验阈值是：改动逻辑占总量 5% 以内，增量收益非常明显；5% 到 10% 之间，要看改动的分布位置；超过 10%，收益会快速衰减，甚至可能出现工具主动放弃复用、退回全跑的情况。这里的"改动"不只看 RTL 行数，还要看影响的网表节点数——改一个顶层参数导致的位宽连锁变化，影响面可能远大于你的直觉。
1.3 哪些场景值得上，哪些别硬凑
我的经验是，下面这几类场景用增量实现回报最高。
一是时序收敛的最后一公里。设计已经基本收敛，只差几条关键路径，你在做的是插流水线、调综合属性、改约束、微调逻辑层次。这种场景每轮改动都很小，但往往要迭代十几轮，增量实现能把每轮从数小时压到几十分钟，收敛周期直接缩短一半以上。
二是调试阶段加 ILA 探针。这里要提醒一句，插入或修改 ILA 会改变网表结构，探针本身还会占用布线资源，复用率会明显下降，一般只能维持 60% 到 80% 不等的复用水平。但即便如此，也比全跑快得多。所以调试期我通常会一次性把可能要看的信号探针都插上，尽量避免反复增删。
三是固件微调与寄存器改动。这类改动通常只影响地址译码和少量控制逻辑，网表变化极小，复用率能做到 95% 以上，是增量实现最舒服的用法。
而不适合硬上的场景也很清楚：时钟结构大改（换了 MMCM 配置、改了时钟域划分）、顶层端口或管脚约束大幅调整、器件型号或速度等级变化、从别的工具版本迁移过来的检查点。这些情况下增量复用率会掉到很低，工具还可能在复用的约束下做出比全跑更差的布局决策，得不偿失。
2. 拆开看机制：Vivado 靠什么"记住"上一次的结果
2.1 参考检查点里到底装了什么
一份 routed dcp（design checkpoint）本质上是一个压缩后的设计数据库快照，里面包含了网表结构、单元与网络的层次关系、物理约束、以及最关键的——每个 leaf cell 的绝对坐标和每条网络的详细走线路径（包含用了哪些布线资源、经过哪些 switch box）。
增量实现启动时，工具会做一轮比对：把当前新综合出来的网表跟参考 dcp 里的网表做结构对比，逐层判断哪些层次（hierarchy）的实例和网络没有变化。没有变化的那些，就被标记为"可复用"，它们的布局坐标和布线资源直接搬过来。变化的那些，会被打散成待重新求解的集合，交给布局器和布线器处理。
这里有个细节值得说：工具对比的颗粒度最终会落到 leaf cell 和 net 上，但判断的起点是层次结构。所以一个模块如果内部改了，整个模块的单元都会被视为"脏"的；而如果一个模块没改，但它的父层次改了端口连接，这个模块同样会被视为脏的。这就是为什么有时候你觉得自己只改了一个小地方，复用率却掉得厉害——连锁反应比想象中大。
2.2 复用的颗粒度：为什么改一个模块不等于只重做那个模块
复用分几个层次，理解它们对判断收益很关键。
逻辑复用（Instance/Net Reuse）：指网表层面有多少实例和网络跟参考设计一致。这个数字主要由综合结果决定。如果你开了增量综合，这个数字会很高；如果每次综合都从头跑，即使 RTL 没改，综合出来的命名和结构也可能有细微差异，导致逻辑复用率打折。
布局复用（Placement Reuse）：指有多少单元沿用了参考 dcp 里的物理坐标。这个数字通常低于逻辑复用率，因为新增或变化的逻辑会被塞进现有布局的缝隙里，可能挤动周边单元。
布线复用（Routing Reuse）：指有多少网络的走线路径原封不动保留。这是最"脆弱"的一层。一条网络只要有一个端点单元被挪动，整条网络就得重布。所以布线复用率一般是最低的那个数字，也是决定最终耗时的主要因素。
我在一个 20 万 LUT 的工程上实测过一组数据，可以参考：改动 3% 逻辑时，逻辑复用约 97%，布局复用约 92%，布线复用约 88%，整体实现时间从 6.5 小时降到 1.2 小时；改动扩大到 12% 逻辑后，布线复用掉到 61%，实现时间只降到 4.8 小时，性价比就很一般了。
2.3 增量综合和增量实现，是两套独立开关
很多人会把这两个概念混在一起，其实它们作用在不同阶段，需要分别开启。
**增量综合（Incremental Synthesis）**针对 synth_design 阶段，需要一份参考的 post-synthesis dcp。它复用未改动模块的综合结果，能省掉大部分综合时间。对综合本身就要跑一两个小时的超大工程，这个收益很可观。
**增量实现（Incremental Implementation）**针对 place 和 route 阶段，需要一份参考的 routed dcp。它复用物理实现结果，省的是布局布线时间。
理论上可以只开其中一个，也可以两个都开。实践中我倾向于两个都开——综合和实现都复用，端到端时间最短。但要注意，增量综合会引入一个约束：如果改动的模块跟未改动模块之间的接口发生变化，复用会失败，工具会退回全量综合。所以我会在改动涉及模块端口的时候，提前把相关层次的边界检查一遍。
3. 实操全流程：从拿到参考 dcp 到跑出增量结果
3.1 第一步：准备一份"干净"的参考实现
参考检查点的质量直接决定增量的效果，这一步千万别省事。
我的做法是：先把当前版本跑一次完整的实现流程直到时序收敛，确认没有未约束路径、没有严重的时序违例、DRC 干净，然后把这个版本的 routed dcp 单独归档出来，放在工程目录之外的固定位置，比如./ref_checkpoints/2024xx_v1_routed.dcp，并写一个简单的文本文件记录它的来源版本、工具版本、器件型号、时序余量（WNS/TNS/WHS/THS）等元信息。
为什么强调"干净"？因为如果你拿一份本身就有时序违例、布线拥塞或者大量未约束路径的 dcp 作为参考，增量实现会把这些缺陷一起继承下来，后续修改很难摆脱。参考解的质量就是增量结果的下限。
还有一点：参考 dcp 使用的 Vivado 版本，最好跟当前工程的版本一致。跨大版本使用虽然工具会尝试兼容，但网表结构、器件模型、算法参数都可能变化，复用率会明显下降，甚至出现奇怪的实现错误。我在 2020.x 和 2022.x 之间跨版本试过一次，复用率直接掉了 30 个百分点，后来就再也不这么干了。
注意：routed dcp 只有在 write_bitstream 之前或之后才会有，如果你在 route_design 完成后立刻中止了流程，需要确认 dcp 确实写出来了。另外，dcp 文件不要提交到 git 这类版本控制系统，动辄几百 MB，会把仓库撑爆，用独立存储或者制品库管理更合适。
3.2 第二步：设置增量参数，GUI 与 Tcl 两条路
GUI 方式：在 Flow Navigator 里选中 impl_1，右键打开 Implementation Settings，找到 Incremental Implementation 相关选项。你会看到两个关键设置：一个是 "Read Incremental Checkpoint"，用来勾选并指定参考 dcp 的路径；另一个是增量模式的下拉选项，一般有 off、auto、on 三档。auto 交给工具判断，on 强制尝试复用，off 关闭。
Tcl 方式（我个人更推荐，因为可以写进脚本、方便复现）：
# 指定参考检查点 set_property incremental_checkpoint {./ref_checkpoints/v1_routed.dcp} [get_runs impl_1] # 打开增量实现 set_property incremental_implementation on [get_runs impl_1] # 确认设置是否生效 report_property [get_runs impl_1]最后那行report_property是我强烈建议加的。不同版本 Vivado 的属性名偶尔会有差异，与其凭记忆硬写，不如让工具把所有属性打印出来，搜一下 incremental 关键字，确认属性名和写入的值都对得上。这个习惯帮我省过好几次排查时间——明明脚本跑完了，结果发现属性名写错，工具默默忽略了，白白跑了一次全量。
另外提一句auto和on的区别。auto 模式下，工具会先评估复用是否有意义，如果判断复用率会很低，它会主动放弃并全量跑，然后在 log 里留下说明。on 模式下则强制走增量路径，即使复用率很低也照样跑。我一般先用 auto 试一轮，看报告里的复用率，如果稳定在 70% 以上，后续迭代就改成 on 固定下来。
3.3 第三步：改设计、重跑综合、启动增量实现
完整的迭代流程是这样的，按顺序走：
- 修改 RTL 或约束，保存。
- 复位综合并重新跑：
reset_run synth_1然后launch_runs synth_1 -jobs 8。（如果开了增量综合，这一步会复用大部分综合结果，通常十几分钟就结束。） - 等综合完成，确认没有新增的严重告警。
- 启动实现：
launch_runs impl_1 -to_step write_bitstream -jobs 8。 - 等待完成，检查报告。
有个容易踩的坑：复位综合之后，impl_1 必须先复位才能重新启动。如果你只 reset 了 synth_1，impl_1 可能还停留在"完成"状态，直接 launch 会报错或者说没有需要跑的东西。正确做法是reset_run impl_1之后再 launch，或者干脆用launch_runs impl_1 -to_step write_bitstream让工具自己判断依赖关系，跑之前先用get_property STATUS [get_runs impl_1]看一眼状态。
还有一点关于 directive 的选择。增量实现的迭代过程中，我通常会把布局布线的 directive 调成偏"快速"的档位（比如 Quick 或 RuntimeOptimized），因为这时候目标不是榨出最后一纳秒时序，而是快速验证这一轮修改是否有效。等到逻辑稳定、要做最终签核版本时，再切回默认或 Explore 档，跑一次完整流程确认。这个"快跑验证 + 慢跑签核"的两段式节奏，是我在大工程里效率最高的用法。
3.4 第四步：读复用率报告，判断这次增量值不值
实现跑完后，Vivado 会生成一份增量实现报告（Incremental Implementation Report），在 GUI 的 Reports 菜单里能找到对应入口打开，同时 impl_1 的 runme.log 里也记录了关键统计。报告里最该关注的几个数字，我整理成表格：
| 指标 | 含义 | 健康区间参考 | 偏低时的常见原因 |
|---|---|---|---|
| Instance Reuse | 网表实例的复用比例 | 85% 以上 | 综合结果结构变化、开了全量综合但 RTL 改动连锁 |
| Net Reuse | 网络的复用比例 | 80% 以上 | 端口连接变化、逻辑优化把网络合并或拆分 |
| Placement Reuse | 布局坐标的复用比例 | 75% 以上 | 新增逻辑挤压、pblock 约束变化、时钟资源调整 |
| Routing Reuse | 走线路径的复用比例 | 65% 以上 | 大量网络端点偏移、布线拥塞、跨 SLR 网络变动 |
| Runtime 对比 | 相对全量的耗时比 | 30% 以下 | 复用率不够，固定开销占比过高 |
我自己的判断标准是：如果 Routing Reuse 低于 60%，那这次增量的性价比就很可疑了，我会去看具体是哪些层次被判定为脏的，通常能找到意料之外的连锁改动。如果连续几轮复用率都持续走低，说明改动已经积累了太多，是时候跑一次全量把基线刷新一下。
提示：增量实现不是"跑一次就能一直用"的。建议每迭代 5 到 10 轮，或者每次改动累积到一定量之后，跑一次全量实现，用新结果替换参考 dcp。长期不刷新基线，复用率会慢慢漂移，最后变成"名义上增量、实际上全跑"。
4. 复用率上不去：典型症状与排查实录
4.1 症状速查表
下面这张表是我这两年攒下来的，基本覆盖了增量实现里九成以上的异常情况。
| 症状 | 可能原因 | 排查动作 |
|---|---|---|
| log 里出现放弃增量的提示 | 工具判断复用无收益，或参考 dcp 不兼容 | 检查工具版本、器件型号是否一致，看复用评估的具体数字 |
| 复用率突然从 90% 掉到 40% | 顶层接口或时钟结构被改动 | 用网表对比工具看层次差异，重点查时钟和顶层端口 |
| 综合时间没变短 | 增量综合未启用，或接口不匹配导致退回全量 | 确认综合设置里的增量选项，检查模块边界接口 |
| 实现时间比全量还长 | 复用的硬约束拖累了布局器求解 | 关闭增量，改跑全量对照，确认是否存在拥塞 |
| 时序比全量差一截 | 新逻辑被塞进已有布局缝隙，走线绕远 | 检查关键路径的布线延迟，考虑局部 pblock 或 phys_opt |
| 报告里有新增 DRC 违例 | 复用布线产生新的拥塞点 | 查看违例类型和位置，评估是否需要局部重布 |
4.2 时序反而变差了怎么办
这是最常见的抱怨：明明增量省了时间，结果 WNS 比上一轮还差。原因通常是新逻辑被强行塞进现有布局的缝隙里，导致几条关键路径的走线比全量布局时长了不少。
我的处理顺序是这样的。
第一，先看是哪几条路径退化了。打开时序报告，对比增量前后的关键路径，重点看net delay而不是 logic delay。如果是布线延迟暴涨，基本可以确认是物理位置问题。
第二，如果退化的路径集中在一个小区域，可以考虑给这块逻辑加一个温和的 pblock，给它圈出足够的空间，避免被挤到边角。pblock 不要圈得太紧，留出 20% 到 30% 的余量，太紧反而会造成内部拥塞。
第三，如果退化是全局性的、分散在多条路径上，那说明这次改动的实际影响面比预估的大，硬做增量意义不大。这时候我会干脆跑一次全量，把基线刷新掉。
第四，也可以试试在增量实现之后追加一轮 phys_opt_design，让它做后布局的时序优化。这一步不会推翻复用结果，只是在现有布局基础上做局部微调，代价小、见效快，我在处理最后那零点几纳秒的违例时经常用。
4.3 资源占用和布线拥塞的漂移
增量实现还有一个容易被忽略的副作用：资源占用会缓慢漂移。因为每轮新增的逻辑都被塞进现有布局，工具为了塞得下，可能会把一些 LUT 合并、把一些寄存器挪到不那么理想的位置，几轮下来，LUT 利用率可能比全量高出好几个百分点，布线拥塞度也会上升。
对这种情况，我的建议是关注两个数字：整体 LUT/FF 利用率和各 SLR 或各时钟区域的拥塞指标。如果利用率在几轮迭代后涨了超过 3 个百分点，或者某个区域的拥塞度明显抬头，就说明该刷新基线了。带着膨胀的资源占用继续做增量，后面很容易撞墙——要么布线失败，要么时序怎么调都收敛不了。
另外，跨 SLR 的网络要特别留意。在堆叠硅片（SSI）器件上，跨 SLR 的走线资源本来就紧张，增量复用如果把这些网络端点的位置挪了，重布的时候很可能找不到跟原来一样好的路径，延迟会明显变差。所以对 SSI 器件，我倾向于在跨 SLR 的关键路径上加适当的布局约束，减少增量过程中的位置漂移。
5. 放进真实项目里：我的几条落地经验
5.1 参考检查点怎么管
前面提过不要把它提交到 git，这里再说说具体怎么管。
我的做法是在文件服务器或者制品库上建一个专门的目录，按"工程名 / 日期 / 版本号"三层组织，每个检查点旁边放一个同名的 .info 文本文件，记录以下内容：生成日期、Vivado 版本、器件与速度等级、这次实现用的是哪个 directive、最终 WNS/TNS/WHS/THS、这次对应的 RTL tag 或 commit hash、以及一句话说明"这个版本相对上一版改了什么"。
这些元信息看着琐碎，但在需要回溯的时候价值极高。有一次我们发现某一版增量结果异常，靠这个记录快速定位到那次用的参考 dcp 是从一个 directive 差异很大的实现里来的，换了检查点之后问题就消失了。没有记录的话，这种问题得排查半天。
保留策略上，我通常只保留最近 3 到 5 个版本的 routed dcp，更老的清理掉，否则存储成本会失控。但那个 .info 文本文件我会长期保留，做归档。
5.2 和团队协作、CI 流程怎么配合
增量实现放到多人协作或者自动化流程里，有几个特殊注意事项。
第一，检查点要跟代码版本绑定。不要让每个人各用各的参考 dcp，而是约定一个团队共享的"基线检查点"，跟某个明确的代码 tag 对应。谁需要迭代，都从这个基线出发。这样大家的时序结果才有可比性，也避免有人拿了个不匹配的检查点导致复用率异常。
第二，CI 上的实现任务默认应该跑全量。增量适合人做局部迭代，不适合做入库验证，因为增量结果的复用率跟当次改动强相关，不确定性太大。我通常会在 CI 里跑两套：一套全量作为签核基准，一套增量作为快速反馈；只有全量通过才算真正通过。
第三，自动化脚本里要加复用率的检查。跑完增量后，脚本从 log 里解析出 Routing Reuse，低于阈值就在日志里打个醒目的告警，提醒人去复查。这个小检查能拦住不少"看起来跑完了但结果不可信"的情况。
第四，如果团队里有人用的工具版本跟基线不一致，增量复用往往会失败甚至产出不可预期的结果。所以在工程配置里我会明确写死推荐的工具版本，并在脚本启动时校验，版本不符直接报错退出，不给人踩坑的机会。
5.3 常用配置与命令速查
把我日常最常用的几条整理在这里，方便直接抄。
# ---------- 生成参考检查点 ---------- # 全量跑完实现后，routed dcp 在 impl_1 的 run 目录下 # 复制并归档到固定位置 file copy -force [get_property DIRECTORY [get_runs impl_1]]/impl_1_routed.dcp \ ./ref_checkpoints/v3_routed.dcp # ---------- 配置增量实现 ---------- set_property incremental_checkpoint {./ref_checkpoints/v3_routed.dcp} [get_runs impl_1] set_property incremental_implementation on [get_runs impl_1] # 确认属性写入成功 report_property [get_runs impl_1] # ---------- 迭代流程 ---------- reset_run synth_1 launch_runs synth_1 -jobs 8 wait_on_run synth_1 reset_run impl_1 launch_runs impl_1 -to_step write_bitstream -jobs 8 wait_on_run impl_1 # ---------- 结果检查 ---------- # 从 runme.log 里抓复用率相关行 set logfile [get_property DIRECTORY [get_runs impl_1]]/runme.log关于incremental_implementation的取值，我一般这样用：第一轮验证用 auto，看看工具自己的判断；确认复用稳定在 70% 以上后改成 on，固定路径；只有在做对照实验、需要强制走增量的时候才用 on 配合手动指定检查点。off 基本只在排查"是不是增量导致的问题"时会临时切一下。
最后分享一个我觉得挺有用的小习惯：每次启动增量之前，先把本次改动的 RTL diff 大致过一遍，心里估一个"影响层次清单"，跑完之后拿这个清单跟报告里被判定为脏的层次对一下。绝大多数时候能对上，偶尔对不上——那多半就是发现了意料之外的连锁改动，早点发现总比等到时序崩了再回头找强。这个动作花不了两分钟，但帮我抓到过好几次隐蔽的顶层参数污染问题。
