节省编译时间系列（二）：使用增量实现

引言：本文我们介绍使用增量编译节省编译时间以及如何在编译时间与 QoR 之间取得相应的折中。1.  概  述 自增量实现流程首次获得支持以来，它一直在不断演进，并且加入了大量针对性能和编译时间的增强优化。它能够满足实现阶段快速迭代的需求，大幅节省编译时间，同时还能确保结果和性能的可预测性。下图展示了在一组高难度设计上采用增量实现流程后，编译时间的节省趋势：

图1、2019.1 版本中，内部设计与外部设计采用增量实现流程后的编译时间节省情况图1显示，对于运行时间超过2小时的设计（设计改动量不超过 10%），采用该流程平均可节省 2.12 倍的编译时间。

图2、2019.1 版本中，采用增量实现流程后的 QoR（结果质量）可预测性图2展示的是小规模 RTL 改动下的 QoR 可预测性度量。ΔWNS 表示相对于参考运行（Reference Run）的 WNS 劣化程度。可以看到，相比默认运行方式，增量编译能够实现更好的 QoR 可预测性。有一点例外：对于规模较小的设计，编译时间的收益相对较小，因为初始化步骤在总编译时间中所占的比重更大。

2.  增量编译流程

该流程在工程模式（Project Mode）和非工程模式（Non-Project Mode）下均受支持。当你使用 read_checkpoint -incremental <dcp_file> 命令加载参考设计检查点，且 <dcp_file> 指向参考DCP的位置与文件名时，即会为后续的布局布线操作启用增量编译设计流程。

在非工程模式下，read_checkpoint -incremental 应位于 opt_design 之后、place_design 之前执行。

图3、增量编译流程目前，自动模式（Automatic Mode）和非自动模式均受支持。要启用自动模式，可以打开实现设置（Implementation Settings），勾选“Automatically use the checkpoint from the previous run（自动使用上一次运行的检查点）”选项。如果未勾选自动模式，也可以将用户指定的 DCP 作为参考检查点，用于指导后续的运行。图4、设计运行设置（Design Run Settings）

3.  何时使用该流程

当你的设计代码已趋于稳定、后续只做少量代码修改时，或者你正处于时序收敛的"最后一公里"且已接近目标时，该流程就非常有用。

增量实现流程会从参考检查点中读取布局布线信息，并与当前 opt_design 之后的网表进行匹配比对，匹配到的单元（cell）会被复用，而新增的逻辑则会按默认流程进行优化。同时，还会在匹配单元与未匹配单元之间执行跨域优化（crossing optimization）。

因此，当大部分逻辑都可以被复用、且设计已接近满足时序时，该流程对编译时间的收益最大。

另一个适用场景是：你的设计较难收敛、尚未接近时序闭合，但你希望在部分层级（例如 SLR / Block 类型 / 模块级）复用设计结果。此时可以将增量模式改为部分复用模式（partial reuse mode）。

例如，下面这行约束的效果，等同于将所有RAM的位置从网表反标（back-annotate）到 XDC 中，并在后续运行中应用这些约束：

read_checkpoint -incremental routed.dcp -reuse_objects [all_rams] -fix_objects [all_rams]

4.  影响增量实现编译时间的因素

在采用该流程之前，请注意以下几点，它们有助于你充分发挥增量流程的效能：

（1）选择正确的检查点。你需要确保参考检查点与被指导的设计使用的是同一器件（part），并且由与当前运行相同的 Vivado 版本实现。由不同版本生成的 DCP 会导致单元匹配率下降，编译时间的节省也将达不到预期。

（2）限制时序关键区域的改动量，以确保设计收敛的一致性和时序收敛。设计逻辑改动过多，可能导致指导效果不佳或编译时间反而变长。如果关键路径的布局布线无法被复用，就需要投入更多努力来保持时序。此外，如果小幅设计改动引入了参考设计中并不存在的新的时序问题，则可能需要更高的努力级别和更长的运行时间，甚至可能导致设计无法满足时序。同时务必保证 opt_design 的指令（directive）一致，因为 opt_design 的改动会引起更多单元名称的变化。

（3）若启用了自动模式，参考检查点只有在参考运行的时序优于 -0.250 ns 时才会被更新，这意味着你必须先得到一个时序足够好的参考检查点。

（4）质量较差的参考网表可能导致编译时间变长。在未更新参考检查点的情况下，如果此前的运行已存在检查点，Vivado 会尝试将其用作参考检查点；若不存在可用参考，则会回退到默认实现流程。

（5）当遵循默认运行行为时，Vivado 会尊重用户所选的运行策略（run strategy），编译时间与非增量运行相近。

（6）如果在运行开始后才出现检查点（无论是新更新的还是先前已存在的参考检查点），工具会再执行一次针对设计网表改动的检查算法，只有在满足相应判据时才会使用增量流程。当这些条件未被满足时，流程会自动回退到默认实现流程，并在 read_checkpoint -incremental 之后给出如下提示信息：

WARNING: [Project 1-964] Cell Matching is less than the threshold needed to run Incremental flow.                         Switching to default Implementation flow

（7）高复用模式（High Reuse Mode）：当单元复用率高于75%时进入高复用模式。在高复用模式下，布局布线算法会被优化，以尽可能多地复用现有的布局布线信息。高复用模式在参考检查点已实现时序收敛、且单元复用率达到 95% 以上的设计上效果最佳，例如参考设计与当前设计之间只有少量改动，或者向设计中添加调试核（debug core）的场景。place_design 和 route_design 提供三条可用的指令（directive）：

Default（默认）：获得尽可能接近参考运行的结果，以参考设计的 WNS 为目标。对典型场景而言，该模式的编译时间最优。

Explore（探索）：尽可能改善时序，以 WNS 达到 0.00 ns 为目标。这会耗费更多编译时间。

Quick（快速）：执行布局布线命令但不调用时序引擎。这是编译时间最优的选择，并且在复用率高于 99.5% 的部分设计中不会影响 QoR。

（8）低复用模式（Low Reuse Mode）：当设计相对参考检查点发生了较大改动，或者用户通过 read_checkpoint 命令的 -only_reuse 开关指定了仅复用参考检查点中的一部分单元时，进入低复用模式。在低复用模式下，所有 place_design 和 route_design 指令均受支持，工具将以 WNS 0.00 ns 为目标。相比高复用模式，这可能会耗费更长的编译时间。低复用模式在特定区域给布局布线带来挑战的设计上效果最佳，例如：复用一次良好运行中的块存储器（Block Memory）或 DSP 布局，或者复用某个时序时好时坏的特定层次结构。

（9）布局布线运行时间中的初始化部分。对于运行时间较短的布局布线，Vivado 布局器和布线器的初始化开销可能会抵消增量布局布线带来的全部收益。对于运行时间较长的设计，初始化所占比例变小，就能看到显著的编译时间收益。

（10）此外，还可以通过开启多线程进一步缩短实现阶段的编译时间。目前 Linux 系统上的上限为 8 线程。

set_param general.maxThreads 8

5.  生成增量编译时间节省报告

运行 report_incremental_reuse 命令，可生成一份展示增量复用情况的报告。报告的第 3 部分列出了编译时间（elapsed 与 cpu），显示了每个步骤所花费的编译时间。

由于增量指导（incremental guiding）是从 place_design 阶段才开始生效的，你需要注意：增量运行所统计的时间中会包含 read_checkpoint 步骤（即读入参考检查点）的耗时，因此增量编译时间的对比应当只从 place_design 开始算起。

下表列出了各阶段的耗时，其中包含 readcheckpoint 的时间。此外，新网表的改动量也可能对增量运行时间产生较大影响。

表1、运行参考比较

请注意，增量运行中的 phys_opt_design 步骤是可选步骤；当流程中调用它时，它会以默认模式运行，进一步对未被指导的路径或发生变化的路径进行优化，而不会影响已被复用的路径。

6.  结束语

在充分考虑上述各项因素的前提下运行增量实现流程，我们能够借助该流程实现实现运行的快速迭代，并在编译时间与 QoR 之间取得相应的折中。