缩短Vivado编译时间（1）：一些通用方法

1年前更新

830

Vivado编译时间受多方面因素的影响，这些因素包括流程（例如：是否采用增量流程，是否采用OOC综合方式）、选项设置（例如综合阶段的选项、布局布线阶段的选项等）、RTL代码本身、约束文件、目标芯片本身（相同的资源利用率的情况下，芯片规模越大编译时间越长）以及布局布线阶段所遇到的关键问题（例如：布线拥塞）。

除此之外，运行Vivado的服务器本身也是一个重要因素。这里我们只关注设计本身和工具流程方面的因素。

测量编译时间

当设计发生改变时，如果我们要比较编译时间的变化，一个前提条件是必须保证Vivado运行在同一个或同类型（性能相近）的服务器上。对于一个完整的Vivado流程，我们可以很方便地在日志文件中找到编译时间相关信息，例如：

这条信息的开头是Tcl命令place_design。elapsed后面对应的值即为布局阶段所消耗的时间。注意这个时间与cpu后对应的时间（图中的03:21:34）的区别。cpu后对应的时间是指多线程所消耗的时间总和，这些线程用于执行place_design的子任务。这个时间不包含访问硬盘数据的时间。

我们在日志文件中也会看到类似如下图所示的信息，这条信息以Time打头而不是Tcl命令，所以它反映的是特定步骤下某个子阶段所消耗的时间。

因此，对于总的编译时间，无论是Project模式还是Non-Project模式，我们都可以通过如下方式计算获得：

需要注意的是，在Project模式下，Vivado会自动生成各种报告，计算编译时间时也要将生成报告的时间考虑在内，从而可以准备判断哪一步最耗时。下图显示的是report_drc命令所消耗的时间。

如果我们想获知某个单一命令所消耗的时间，可以借助Tcl命令进行追踪，如下图所示。可以看到get_cells命令共消耗10ms。

如果约束文件较大，包含成百上千条命令，我们可以采用上述方法来获取相关命令的执行时间。

对于增量流程，无论是增量综合还是增量布局布线，在日志文件中会有一个表格，用于显示增量前后的编译时间对比，如下图所示。需要注意的是增量流程需要从参考文件中读取一些信息，以达到设计复用的目的，因此，如果设计发生较大的改变，可复用的信息就会变少，相应的编译时间也会受到影响。

分析编译时间

获取了准确的编译时间之后，下一步我们就要对这些时间数据进行分析，确定哪一步最耗时，从而找到解决方案。

案例1：

假定我们最终发现布线阶段最耗时，通过日志文件我们发现设计资源利用率很高，导致发生了布线拥塞。鉴于此，我们可以借助命令report_design_analysis生成拥塞报告，找到拥塞区域，分析拥塞原因，判断哪些模块是拥塞的“罪魁祸首”。相应地，我们可以优化代码、尝试不同的综合策略、对关键模块采用模块化综合技术或者采用不同的布线策略以降低拥塞程度，从而达到降低编译时间的目的。

案例2：

设计中使用了大量的IP。在这种情形下，我们可以对这些IP采用OOC的综合方式，同时使用IP Cache功能，从而加速迭代过程。

影响编译时间的关键因素

约束

合理且完备的约束可以有效提高系统内存利用率，从而降低整体编译时间。我们需要分析约束所消耗的时间，理解这些时间是如何被消耗的，改善约束语法是行之有效降低编译时间的方式。

增量流程

无论是增量综合还是增量布局布线都是一种直接易操作的降低编译时间的方式。尤其是当设计改变率较低的情况下，例如低于5%，这种方式的带来的收益较为明显，同时这种方式也保证了结果的一致性，提升了结果的可预测性。

报告

通过一些报告我们可以发现设计存在的潜在问题，例如DRC问题、不合理的时序约束、布线拥塞等，这些问题会显著影响编译时间。例如：命令report_methodology生成的报告中，如果有Bad Practice，那么我们就要格外关注，并尝试修复这些Bad Practice。命令report_design_analysis可用于分析设计复杂度和布线拥塞问题。命令report_qor_suggestions可针对设计中的关键问题给出改善建议。命令report_exceptions可用于分析时序例外约束的覆盖率，这些都会影响编译时间。

OOC综合方式和模块化（Block-level）综合方式

OOC综合方式可提供运行的并行度，同时对于未改变的模块或IP，使用OOC之后，再迭代时可继承原有结果。模块化综合技术使得工程师可以对不同模块采用不同的综合设置或综合策略，也能达到降低编译时间的目的。

1人已评分