验证 timing constraints 是否正确

本页是有关 timing的一系列页面中的最后一页。前几页解释了 timing 计算背后的理论，展示了如何编写多个 timing constraints 并讨论了 timing closure的原理。

介绍

很多时候， FPGA 开发策略是添加功能，修复任何不起作用的部分，然后重复。很容易忽略 design 中可能有问题但不会造成明显问题的部分。

了解 FPGA design 可能工作得非常好是至关重要的，即使 timing constraints 应用不正确并且即使它们没有实现： 正确使用 timing constraints 是保证 FPGA稳定正确运行的关键部件之一。然而，如果忽略这个话题，并不一定意味着立即失败。相反，不正确的 timing 可能会导致偶发的故障，这些故障可能会让人非常困惑。

本页总结并重申了这一系列关于 timing constraints的页面中的许多建议。目的是强调一些在查找因 timing不足而导致的问题时应牢记的主题。人们可能希望有智慧偶尔为此检查一下这些主题，但在现实生活中，我们大多数人这样做是为了解决一个看起来有点像巫术的问题。

阅读您的 timing report

所有 FPGA design 工具都会发出 timing reports。我们打开它们的最常见原因是工具无法实现 timing constraints时： 这就是人们可以找到失败的 paths的地方，并希望找出可以对它们做些什么。

但是，检查 timing reports有一个同样重要的原因： 验证 timing constraints 是否被工具按预期解释，因此它们被正确应用。偶尔做这个检查是个好习惯，尤其是在添加新的 timing constraints之后。

由于每个 FPGA design 工具都以不同的结构和格式生成这些报告，因此无法准确地关联每个报告中每个部分所说的内容。因此，本页概述了所有工具共有的原则。至于您自己的 timing reports的格式和功能，花点时间学习它们是个好主意。

timing report 检查的另一个可能的好处是它可能会发现 logic的错误使用。例如，如果 design 包含错误使用的异步 logic 或依赖于无法应用 timing constraints 的 clocks ，这在 timing report中会变得很明显： 因为无法将此 logic 应用 timing constraints ，所以它可能会在报告中显示为 unconstrained paths。

另一方面，值得一提的是，包含在 design 中的 IPs 通常会贡献自己的 timing constraints ，这些工具会添加到您提供的工具之上。通常没有必要检查与这些 constraints相关的 paths ，但它们可以为 timing report增加相当多的重量。

Unconstrained internal paths

为了便于讨论， synchronous element 是 flip-flop、 block RAM、 shift register 或任何其他 logic elements ，它们在 clock的 rising edge 或 falling edge 上对其 data input 进行采样和/或更改其 data output 。

所有从 synchronous element的 data output 到另一个 synchronous element的 data input 的 paths 都必须定时，即服从 timing constraints。唯一的例外是当 timing violation 的可能性在目的地的 synchronous element上得到正确处理时，就像 unrelated clock domains一样。

换句话说，必须对 path 到任何 synchronous element 进行计时，除非有明确的 resynchronization 机制来掩盖事实，即 design 工具不对以可预测的方式对 input signal 进行采样承担任何责任。

有时定义 reference clock的单排 timing constraint就足够了， FPGA tools 负责其余的工作。在其他情况下，它需要的不止于此。在非常糟糕的情况下，一些内部 paths 错误地保留为 unconstrained 。这有几个可能的原因，其中包括：

• 忘记添加 timing constraint。
• path 被错误地定义为false path 。
• path 在 related clocks之间穿过 clock domains ，但工具将它们视为 unrelated clocks （下文将详细介绍）。
• timing constraint 不通过 clock resource element传播。比如 reference clock 接 FPGA PLL， timing constraint 通常是给 FPGA的 input pin。这些工具随后有望为 PLL的 output clocks自动创建 timing constraints 。他们通常会这样做，但有时会有惊喜。
• clock 由 logic 生成（例如，使用在 logic fabric中实现的 frequency divider ）并且没有被 timing constraint明确覆盖。

FPGA design 工具支持创建列出 unconstrained paths的 timing reports ，即未应用 timing constraint 的 paths 。原则上，这个列表应该是空的： 不需要 constraints 的 paths 应该在 timing constraint 文件中明确定义为 false paths 。这样的 constraints 不会对 paths 的任何未计时的功能进行任何更改，但它们允许将 timing report 中的 unconstrained paths 列表保持为空。这使得很容易发现无意中遗漏的 paths 。此外，由于此列表中的 paths 数量有限，因此绝对不应该在此列表中的 paths 可能会被隐藏，因为无害的 paths 被列出了。

但遗憾的是，在某些 timing reports中， unconstrained paths 的部分可能还包括 paths 没有理由被 timing constraints覆盖。例如， path 从一个 clock buffer 的 output 到另一个 clock resource的 input 。因此， timing report 可能会将很多 paths 列为 unconstrained，但这完全没问题。这使得从 timing report推断情况稍微困难一些，但这并不是真正的问题，因为此类 paths 通常与以 flip-flop的 data input 或其他一些 synchronous element结尾的 paths 分开列出。所以归结为仔细阅读报告并注意每组列出的 paths 的含义。

默认创建的 timing report 有时不够详细，无法包含此信息。任何合理的 FPGA design 工具都允许创建列出 unconstrained paths的按需 timing report ，以及选择为每个组列出多少个这样的 paths （10 是一个合理的数字，即使相关列表应该完全为空）。

Paths 之间 clock domains

如果 clocks 是 related clocks （或者更准确地说，如果 logic 将它们视为相关），Timing constraints 必须用在内部 paths 上，这些 paths 在其源和目标处与不同的 clocks 同步。否则，他们不应该，因为这种不必要的限制可能会浪费高质量的 routing resources ，并可能导致无法实现 timing。请参阅有关 related clocks 与 unrelated clocks的页面。

每个工具集都有自己的方式来自动决定是否将一对 clocks 视为相关。在 timing constraint 文件（例如 Vivado 和 Quartus）中使用 SDC 语法的工具有一个set_clock_groups 命令，它允许定义 related clocks 和 unrelated clocks组。在这个问题上还有其他方法可以指导工具，特别是通过 false path timing constraints。

所以问题是如何检查工具是否将 clocks 视为 related clocks 。不幸的是，每个工具集都有不同的方式。以 Vivado为例，有一个 Clock Interaction Report，用彩图表示每对 clocks的情况：

• 从一个 clock 到另一个 paths 已经计时（即 clocks 被认为是 related clocks）。
• 从一个 clock 到另一个 paths 的 paths 尚未计时（“User Ignored Paths”）。
• 一些 paths 已经定时。

或者，可以使用仅限于某些 paths 组的自定义 timing reports 来调查此问题。 paths 可以根据涉及到的 clocks 来选择。这可以通过选择 paths来完成， paths开始于与一个 clock同步的 logic elements ，结束于另一个 clock。专门研究已知参与 clock domain 交叉的 paths 组也可能是有益的。

尽管这可能很困难，但全面审查工具将 constraints 应用于哪个 clock domain crossings 以及它们是否正确是至关重要的。同时，这是一个审查 logic design 是否在需要的地方有 resynchronization logic 的机会。由于对每个 signal使用哪个 clock 感到困惑，很容易以不安全的 clock domain crossing 告终。

重要的是要考虑到每个 clock的性质。例如，如果来自不同 oscillators 的两个 clocks 具有相同的预期频率，因此在 timing constraints 文件中具有相似的定义，则工具可能会错误地认为它们相关，并计算 paths 上的 timing ，这些 timing 介于这些 clocks之间。在这样的 paths 上应用 constraints 是没有意义的，因为不能保证两个 clocks之间的 phase 关系。就其本身而言，不必要的 timing constraints 只会让工具更难实现 timing，这可能是非常无害的。真正的问题是 timing report 可能会误导我们认为 clocks 实际上是 related clocks。因此，仅通过查看 constraints 和 timing reports，它们之间的 paths 可能看起来是安全的（即不需要针对 timing 违规的保护），而实际上它们并非如此： 两个 clocks 没有任何共同之处，只是频率大致相同。避免此类错误的唯一方法是了解每个 clock 是如何生成的。

Unconstrained external paths

Timing constraints 应始终应用于以 I/O pins 开始或以 I/O pins结束的 paths 。有一个单独的页面解释了如何执行此操作。唯一的例外是 clock input pins 和 pins 有一个特殊的接口，例如 gigabit transceivers， pins 直接连接到 FPGA硅片上的 hardware processor 等。如果接口很慢，如果没有定义 timing constraints 也是可以原谅的。例如，使用 LEDs、按钮甚至 I²C 电线。但是最好为这样的 pins分配 false path constraints ，因为它使 timing report中的 unconstrained I/O pins 列表为空。

很多时候在 external paths上应用 timing constraints 似乎没有意义。例如，如果有多个 output pins 都与同一个 clock同步，则通过它们同时切换的事实来确保正确的 timing 。实现这种同时切换的常用方法是使用IOB register 。这款 flip-flop 提供了可能最好的 clock-to-output ，并且 skew 的 skew 介于 output pins之间，令人印象深刻。

然而，当 output pins 上的 timing constraints 很重要时，这是一个很好的例子： 通过保持 timing constraints 紧密，确保这些 pins 之间的低 skew 。当使用 IOB register 时，紧缩 timing constraints 可以成为强制工具使用此 flip-flop的一种方式，或者确保如果工具无法这样做，它不会被忽视： 如果工具未按要求放置 flip-flop ， timing 将失败。

出于类似的原因，也应该在 input pins 上应用紧 timing constraints 。

当为了多个 pins之间的低 skew 而使用 timing constraints 时，重要的是不仅要限制 I/O pins 直到报告的 slack 几乎为零，而且要验证需要更严格的 timing 会导致无法实现 constraint。这是因为 I/O signal path 可能包含可选的 delay lines，工具可能会以违反直觉的方式使用它。比如 Intel FPGA的 Quartus 如果 timing budget 有余量的话，可能会在 input path 上加一些 delay 。工具选择执行此操作可能既不希望也不期望。

不正确的 false paths 和其他 relaxed timing

有时会应用 timing constraints ，但它们过于宽松。这很难检测到，因为相关的 paths 是定时的，只是在错误的要求下。

此类事故有几个可能的原因，其中包括：

• False path constraints 不应该被意外地应用于 paths ，很可能是由于定义它所涵盖的 logic elements 的表达式中的错误。
• 其他特定 time constraints的问题相同，例如 multi-cycle paths的 timing 要求不正确。
• 指定所需时间量的值在 timing constraint中指定不正确。
• FPGA design 工具玩了一个肮脏的把戏。例如， Intel FPGA的 Quartus 可能会给 paths 分配错误的 clock 频率，除非 SDC 文件中出现“derive_pll_clocks”语句。

没有简单的方法可以发现此类问题。从上到下仔细阅读 timing report 绝对是一个好主意，但是即使报告显示每组 10 个 paths ，也不能保证有问题的 paths 会恰好出现在那里。或者在任何数量的显示 paths中，就此而言。

解决这个问题的另一种方法是查看 timing constraints 所写的内容。由于 SDC constraints 是用 Tcl编写的，因此可以评估在 constraints 文件中选择 logic elements （带有“from”和“to”）作为 Tcl 表达式的表达式，并通读端点列表。

因此，例如，如果此行出现在 Vivado .xdc 文件中：

set_false_path -to [ get_pins -hier -filter {name =~ */pclk_i1_bufgctrl.pclk_i1/S*} ]

可以打开 implemented design 并列出 false paths 适用的目的地：

puts [join [ get_pins -hier -filter {name =~ */pclk_i1_bufgctrl.pclk_i1/S*} ] "\n" ]

Tcl 命令“puts”和“join”确保每个 element 都列在单独的行中，因此很容易读取输出（可能很长）。

这种对 constraints 的审查很重要，但也很困难，因为它需要真正的脑力劳动。

概括

确保这些工具对各种 paths 实施正确的 timing 限制是一项棘手的任务。这是了解 timing constraint 语句的确切含义和知道如何检查 timing reports的组合，以增加发现错误的机会。

但最重要的是，它需要自律地检查和重新检查 design，尤其是当它看起来工作正常时。