作者：Txu，来源：AMD Xilinx开发者社区
这篇博文介绍了多种自动生成报告的有效途径，以便您在尝试对设计中特定阶段所耗用的编译时间进行调试时使用，例如，自动报告加载设计约束的时间、每条命令的持续时间，甚至是跨多个设计的运行时间差异。
此外还提供了关于如何解读这些结果的建议。
其中涵盖了 3 个强大的脚本，用于应对这些用例。
report_constraints：
对约束分析时间进行剖析之前，您应知晓写入约束时建议的顺序要求。这些要求是根据每种类型的约束的优先级来决定的。
时序约束的最优排序如下所述：
1. set_disable_timing
2. set_case_analysis
3. create_clock
4. set_clock_sense
5. create_generated_clock
6. set_input_delay / set_output_delay
7. set_min_delay / set_max_delay
8. set_false_path
9. set_multicycle_path
10. set_bus_skew
除了 set_bus_skew 之外，其他约束类型的优先级随编号而递增，并且覆盖先前约束类型的可能性也越高。因此，仅限更高优先级的约束才会对所涵盖的路径进行分析。
为减少约束解析所用的时间，约束应尽可能精确无误并且限定到目标范围内。如需了解更多信息，请参考 UG949 中的“建议的约束顺序”部分。
在复杂设计中，总是需要添加许多约束文件，包括 IP 约束和用户添加的约束。
要获取这些约束的汇总表，可在 Tcl shell 中调用 report_constraints 脚本，以报告 XDC 或 DCP 文件中使用的约束 Tcl 命令（时序和非时序）数量。
它还可以根据约束排序，对生成的时序更新数量进行粗略估计。
您需使用下列语法找到此脚本：
语法：
% report_constraints -help
用法：report_constraints
[
[-dcp
[-all][-property][-no_src_info]
[-file
[-append]
[-csv]
[-details][-full_details]
[-timing_graph]
[-verbose|-v]
[-help|-h]
示例：
1. 按 XDC 文件名报告时序约束数量。
此示例演示了 4 个独立 XDC 文件中每一种约束类型的数量：
2. 利用 -all 选项报告时序约束和非时序约束。
非时序命令包括当前使用的所有 Vivado 命令，例如，get_pins、get_clocks 等。
3. 报告详细的约束信息和各项约束的详情：
4. 报告时序计算图 (graph)：
此脚本可以估算各命令对于时序计算图的影响，它还能通过报告估算的时序更新数量（部分更新或完整更新）来帮助您了解这些约束是否采用了最优排序，其报告结果为“Estimated updates: xxx”。
当命令流从“Invalidate timing”（使时序失效）转变为“Require valid timing”（需有效时序）时，即可检测到时序更新。
通过使用此脚本，您应该能够看到这些约束的更新和加载次数，并确定约束是否具有重复的定义或有效的状态。
注释：报告的时序更新次数只是估算总数。但它确实能够呈现时序约束是否采用了最优排序。
剖析器：
在 Vivado shell 中根据执行目标操作来调试特定设计的运行时间问题时，可以在 Vivado Tcl shell 中找到剖析器文件“profiler.tcl”，用于执行以下操作：
1. 剖析 Vivado 命令或用户进程
2. 执行运行时间分析，帮助了解运行时方面的瓶颈
3. 分析特定命令或进程的调用次数（以改善脚本效率）
剖析器报告的输出 log 日志文件中包含 4 个部分：
1. 汇总表
2. 排名前 50 的运行时间
3. 排名前 10 的集合
4. 剖析的所有命令的详细运行时间
注释：输出格式可采用表格（默认）格式或 CSV (profiler summary -csv) 格式。
语法：
% profiler
用法：profiler
其中
? - 此帮助消息
add - 将 Vivado 命令添加到剖析器中 (-help)
configure - 配置剖析器 (-help)
remove - 从剖析器中移除 Vivado 命令
reset - 复位剖析器
start - 启动剖析器 (-help)
status - 剖析器状态
stop - 停止剖析器
summary - 返回剖析器汇总信息 (-help)
time - 剖析内联 Tcl 代码 (-help)
version - 剖析器版本
使用示例：
% source profiler.tcl
% profiler add *
% profiler start
% open_checkpoint design.dcp
% profiler stop
% profiler summary
% profiler summary -log profiler.log
% profiler summary -log profiler.csv -csv
报告部分详情：
第 1 部分：汇总表
通过对表格列进行计数，得到耗用的总体时间的统计结果。
每个列的含义如下：
命令 收集的命令/阶段的名称
min 最短运行时间
max 最长运行时间
avg 平均运行时间
total 累计运行时间
ncalls 命令调用次数
%runtime 该命令占用的运行时间占总运行时间的百分比
这样即可轻松确定哪些命令占用的运行时间最长。
如下图所示，get_clocks 和 get_nets 命令均多次调用，占用了大部分的运行时间。
第 2 部分：排名前 50 的运行时间
此处报告了前 50 个最差的运行时间，按最差到最好进行排序。它提供了对运行时间影响最严重的命令的快速汇总信息。
其中包含以下列：
• ID（可用于查找 log 日志文件内的命令）：匹配 Vivado 已处理的命令的顺序。ID 1 是运行的第一条命令，ID 2 是第二条，以此类推。
• runtime：以 ms 为单位的运行时间
• command：Vivado 运行的命令
以下截屏显示了 50 行列表中的一部分：
第 3 部分：排名前 10 的集合
这部分包括由任意剖析的命令返回的 10 个最大的对象集合。其中对于每个集合都包含：
• size：集合大小
• count：大小相同的集合数量
• total：对象总数 (size * count)
• commands：返回该集合的命令列表
第 4 部分：详情报告
这部分包含已剖析的每条命令的全部详细信息，按第一条到最后一条命令排序。
其中包含命令 ID、运行时间、命令以及每条命令对象数量：
用例：
1. 改善约束效率
对 Tcl 脚本进行剖析有助于了解运行时间的使用方式以及 Vivado 命令或用户进程的调用次数。
它有助于重构对运行时至关重要的 Tcl 代码，显著改善运行时间。
以下示例对两个等效版本的 Tcl 循环之间的运行时间差异和 Vivado 命令的调用次数进行了比较：
构造前：
结果显示，有 75216 次调用用于 get_property 命令，这占用了大部分的运行时间。
因此，我们可以把“get_property”命令移至循环外部以节省时间。
构造代码后，耗费的总时间减少了 95%：
2. 跨多个设计比较运行时间：
在跨不同 Vivado 版本进行网表加载或约束解析时，您可能会遇到时间差异。
以下示例演示了 2 轮不同的 Vivado 运行之间耗用运行时间的方式。
此方法有助于对不同版本间耗用的每条命令的调用次数进行调试。
在此情况下，有问题的版本运行针对每个命令的调用次数都增加了一倍。
正常版本：
问题版本：
vivadoRuntime：
如需对多个设计上跨多个阶段的 Vivado 命令的运行时间进行比较，可使用 vivadoRuntime 脚本从 Vivado log 日志文件内的 runtime/memory/checksum/timing/congestion/command 行提取部分调试信息
。
它还可用于比较多个 Vivado log 日志文件之间的信息。
此脚本可用于提取定制运行时间，前提是这些运行时间的格式正确。
它会从文本 log 日志文件中提取信息，并可在 shell 提示符下执行。
语法：
% vivadoRuntime -h
用法：vivadoRuntime
[
[-file
[-append]
[-csv]
[-cpu][-elapsed][-checksum][-peakmem][-gainmem][-wns][-tns][-whs][-ths][-congestion][-cmdline]
[-runtime][-timing][-memory][-all]
[-split]
[-reference
[-seconds][-duration]
[-loose_match]
[-diff]
[-show_unreported]
[-hide_steps]
[-transpose]
[-vivado_only][-custom_only]
[-verbose|-v]
[-help|-h]
示例：
在此示例所示表格中，对 Vivado 流程中每个阶段的多个 log 日志文件进行了比较。
% source vivadoRuntime
% vivadoRuntime ./*/*.log
总结：
通过使用这 3 个强大的脚本，您即可快速识别约束和运行阶段的瓶颈，从而最终帮助您节省运行时间。
