这里有个小窍门，通过-name 指定一个名字，就可以在 Vivado IDE 中新开一个窗口显示这条命令的执行 结果，这个窗口还可以用来跟其他诸如 Device View 或是 Schematic View 等窗口之间 cross probing。这一点也同样适用于包括 report_timing 在内的绝大部分 Vivado 中的 report 命令。
在设置窗口中还有 Timer Settings 一栏（report_timing 中也有），可以用来改变报告时采用的具体 corner、速度等级以及计算布线延时的方式。很多时候我们可以借助 Timer 的设置来快速验证和调试设计需求。
举例来说，在实现后的报告中显示时序违例比较严重，我们可以直接在 Timer 设置中改变速度等级后重新 报告时序，来验证把当前这个已经布局布线完毕的设计切换到更快一档的芯片中是否可以满足时序要求。
另外，在布局布线后的设计上报告时序，往往不能更直观地发现那些扇出较大或是逻辑级数较高的路径。此时我们可以修改连线模型为 estimated，报告出布局后布线前的时序而无需另外打开对应阶段的 DCP 并重 新运行时序报告命令来操作，这么做节约时间的同时，也更容易找到那些高扇出路径以及由于布局不佳而导致的时序违例。我们也可以修改连线模型为 none，这样可以快速报告出那些逻辑延时较大以及逻辑级数较高的路径。以上这些改变 Timer 设置的方法可以帮助我们快速定位设计中可能存在的问题和缺陷。
report_timing_summary 实际上隐含了 report_timing、report_clocks 、check_timing 以及部分的 report_clock_interaction 命令，所以我们最终看到的报告中也包含了这几部分的内容。另外自 2014.3 版起，打开实现后的结果时会直接打开一个预先产生好的报告。
Timing Summary 报告把路径按照时钟域分类，每个组别下缺省会报告 Setup、Hold 以及 Pulse Width 检 查最差的各 10 条路径，还可以看到每条路径的具体延时报告，并支持与 Device View、Schematic View 等窗 口之间的交互。
每条路径具体的报告会分为 Summary、Source Clock Path、Data Path 和 Destination Clock Path 几部分，详细报告每部分的逻辑延时与连线延时。用户首先要关注的就是 Summary 中的几部分内容，发现问题后 再根据具体情况来检查详细的延时数据。其中，Slack 显示路径是否有时序违例，Source 和 Destination 显示 源驱动时钟和目的驱动时钟及其时钟频率， Requirement 显示这条路径的时序要求是多少，Data Path 显示数据路径上的延时，Logic Level 显示这条路径的逻辑级数，而 Clock Path Skew 和 Clock Uncertainty 则显示时钟路径上的不确定性。
以上图这条路径来举例，通过 Summary 我们可以得到这样的信息：这是一条 clk 时钟域内的路径，时钟周期为 3.125ns，这条路径有 0.268ns 的时序违例。违例的主要原因是逻辑级数较高导致的数据链路延时较大，但连线延时的比例也较高，所以可以仔细看看这条路径的数据路径上有没有可能改进布局、降低扇出或者是减少逻辑级数的优化方向。
report_timing
report_timing 是更具体的时序报告命令，经常用来报告某一条或是某些共享特定节点的路径。用户可以在设计的任何阶段使用 report_timing，甚至是一边设置 XDC，一边用其来验证约束的可行性与优先级。在 Vivado IDE 中可以由 Tools > Timing > Report Timing 调出其图形化设置窗口。
与 report_timing_summary 类似，调整选项后对应的Tcl 命令也会在 Command 栏生成，在 Targets 一栏 还可以设置需要报告路径的起始点/途经点/结束点，可以三个都设置或是仅设置其中任何一项，每一项都支持通配符匹配甚至是正则表达式查找。report_timing 报告出的路径延时与 report_timing_summary 中具体到每根 路径上的报告一致，可以以此为依据帮助我们定位时序失败的原因。
用 report_timing 来报告时序其实还有一些更常见的应用场景，用来帮助我们设置和验证约束，尤其是那些时 序例外约束。
举例来说，在设计过程中我们约束了一条或数条多周期约束，不同于 UCF 必须读入约束后重跑设计，我们可以直接在 Tcl Console 中输入这条 XDC，无需重跑设计，直接用 report_timing 来验证。在随之显示的时序报告 Summary 部分可以看到 Timing Exception 后列出这条路径被设置了怎样的时序例外约束（注意，不加额外 option 时，以下两条命令都仅针对 setup check） 。
单纯的一条多周期约束没有什么特别，但是如果使用了通配符后的时序例外有重叠的情况下，Vivado 会根据 优先级来决定对某条路径应用怎样的约束。当设计较大，XDC 较多时，一边设置 XDC 一边用 report_timing 来验 证就变得尤其重要。
另外，仅仅输入 report_timing 而不加任何 option，Vivado 便会报告出时序违例最严重的那条路径，方便我们快速了解当前设计的 WNS，找到最差的那条路径。在验证 I/O 约束时也常常用到 report_timing，只要指定-from 某个输入或是-to 某个输出便可以快速验证当前设计在接口上的时序。
get_timing_paths
除了上述两个大家比较熟悉的时序报告命令，Vivado 中还提供一个 get_timing_paths 的命令，可以根据指定 的条件找到一些特定的路径。我们可以利用其返回值中的一些属性来快速定位设计中的问题。
例如逻辑级数这个影响 FPGA 性能的一大因素，因为经常隐藏在时序报告后很难被发现。在 Vivado 中，除了借助综合后的报告来找到那些可能因为逻辑级数较高而导致的时序难满足的路径外，还有一个更直接的办法，可以一次性报告出设计中那些高逻辑级数的路径，方便我们有针对性的深入分析和优化。
下图这个例子报告了时序最差的 10 条路径的逻辑级数。需要注意的是，在综合后和在布局布线后用一样的脚本报告出的结果会稍有不同，对逻辑级数较为关注的情况，还是建议以综合后的结果为主要依据。
小结
本文可以视为对《XDC 约束技巧》系列文章的补充，希望可以帮助大家了解 FPGA 设计中的时序分析方法，学会使用 Vivado 中的静态时序分析工具来验证时序，定位问题，快速找到问题和解决方案。
楼主
标题置顶
标题高亮
