节省编译时间系列（三）：使用增量综合

引言：本文介绍增量综合，通过采用增量综合流程，我们可以实现综合运行的快速迭代。该流程配置简便，并且有助于保持设计一致性、缩短编译时间。

1.  增量综合流程

增量综合的工作方式与增量实现流程类似，但它只作用于综合阶段，不会指导其后的实现阶段。该流程需要一个独立的综合参考文件（综合后的 DCP），因此你必须先完成一次初始综合运行，以得到第一个综合后DCP文件。

在后续的增量运行中，设计中未改动的部分会被复用，只有发生变化的部分才会被重新综合。被复用的部分以分区（partition）为粒度予以保留。

下图展示的是一个使用脚本的非工程模式流程：

图1、增量流程图

在图形界面（GUI）中，指定参考检查点支持以下两种方式：

（1）使用自动增量参考检查点（目前仅 GUI 支持）

（2）使用用户指定的参考检查点

要在工程模式下启用自动模式，请打开综合设置（Synthesis Settings），勾选“Automatically use the checkpoint from the previous run（自动使用上一次运行的检查点）”选项。

在该模式下，综合运行会自动将最近一次的综合后网表复制到工程目录下的<project directory>/project.srcs/utils_1/import/design 本地路径中。

流程完成后，新的布线后检查点即可作为下一次运行的参考；并在运行被重置（reset）时更新。如果未勾选自动模式，也可以输入用户指定的 DCP 作为参考检查点，用以指导后续运行。

图2、设计运行设置

2.  何时采用该流程

当设计规模大于5万个实例（instances）时，始终建议启用该流程。如果设计过小，增量模式会被忽略，设计将按常规流程运行，因为潜在的收益不足以体现出来。

对于运行时间超过20分钟的综合，采用增量综合流程平均可获得 2.06 倍的提升。下图展示了26个大型设计上的加速趋势：在设计改动量有限的情况下，编译时间最多可节省至原来的1/4（约4倍加速）。

图2、若干示例设计上的编译时间加速比

表中所列各设计的耗时同样说明：在设计改动较小的前提下，参考运行耗时越长，增量运行节省的时间就越可观。因此该流程对大型设计尤为有益。建议在大型设计上始终开启增量综合的自动模式。不过，想要立即使用增量综合，必须先有综合数据写入参考检查点——这通过write_checkpoint -incremental_synth 开关来实现。

附带的getSynStepsRunTime.sh脚本可用于生成一份性能分析表，列出 synth_design各阶段所耗的时间。运行该脚本时，可按下例中的命令执行，并分别为初始运行与增量运行各生成一张表。表中的actual列与phase列分别列出每个阶段所花费的时间以及累计时间。

在增量综合运行过程中，RTL优化（RTL Optimization）、面积优化（Area Optimization）、时序优化（Timing Optimization）以及技术映射（Technology Mapping）这几个步骤，相比参考运行会具有更短的编译时间。下表展示了一个用户设计的示例。请注意对比参考运行与增量运行中各个综合阶段所花费的时间。由于这些阶段在参考运行的编译时间中占了绝大部分，它们对整体运行时间的影响尤为显著。

像RTL展开（RTL Elaboration）、约束验证（Constraint Validation）、应用XDC时序约束（Applying XDC Timing Constraints）、I/O 插入（I/O Insertion）、全局优化（Global Opt）、网表生成（Netlist Generation）以及其他拼接（stitching）阶段，在增量综合过程中的时间改善则相对有限。

注意：OOC流程（out-of-context flow，脱离上下文流程）的工作方式有所不同——它让子模块像独立的IP一样运作，因此需要更多人工干预，例如创建模块包装文件（module wrapper）以及约束作用域划分（constraints scoping）。它同样有助于缩短编译时间；对于体积庞大且保持静态、不发生改变的模块而言，该方式尤其适用，可省去优化该特定模块所花费的时间。

3.  影响增量综合的因素

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

（1）选择正确的检查点。你需要确保参考检查点与被指导的设计使用的是同一器件（part），并且由与当前运行相同的Vivado版本综合生成。不同版本生成的 DCP 不受支持。 最重要的一点是：参考DCP必须在本次综合运行所在的同一个会话（session）中生成，并且是在 write_checkpoint 时加上 -incremental_synth 开关创建出来的。

（2）synth_design 的设置应始终保持一致，时序约束也应保持一致。限制你所影响的模块数量以及跨边界优化（cross-boundary optimization）的范围，以确保设计收敛的一致性和时序收敛。设计逻辑改动过多（>50%）会导致更多模块需要被重新综合，从而造成编译时间变长或指导效果不佳。

（3）此外，如果小幅设计改动引入了参考设计中并不存在的新的时序问题，则可能需要更高的努力级别和更长的运行时间，甚至可能导致设计无法满足时序。下图展示了：若因跨边界优化导致模块间的路径发生变化，M1 和 M3 模块将被重新综合。

（4）尽可能把改动限制在单个独立模块内，否则任何发生改动或被拆解（dissolve）的分区都需要重新综合。同时，若要阻止跨边界优化发生，可以在已对模块的输入/输出端口做过寄存的前提下，对该层次模块名使用 PRESERVE_BOUNDARY 属性。例如：

set_property BLOCK_SYNTH.PRESERVE_BOUNDARY 1 [get_cells [list {M1 M3}]]

图3、综合参考运行与增量运行对比（含跨模块优化）

（5）如果某个设计模块在设计中有多处例化，那么该模块中的任何微小改动，都可能因其例化次数而被成倍放大影响。因此在这种情况下，必须按改动总量（而非源文件改动的"处数"）来衡量设计变化。

（6）在潜在的编译时间缩减方面，大型设计相较于小型设计总能从增量综合中获益更多。

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

综合运行日志中会包含网表复用率（netlist reuse percentage）的详细信息。在本例中，仅修改了一个较小的实例；如果改动发生在某个子模块中，那么该模块的名称也会一并列在表格里。

5.  结束语

通过采用增量综合流程，我们可以实现综合运行的快速迭代。该流程配置简便，并且有助于保持设计一致性、缩短编译时间。