01signal.com

Timing is everything

此页面是关于 timing的一系列页面中的第一页。

奖赏是安心

timing,尤其是 timing constraints 的话题,对 FPGA designer来说是一个巨大的挑战。不仅仅是 timing 难以理解。真正的挑战是克服在 FPGA design上工作时忽略整个主题的诱惑,因为一切正常。当没有明显的问题时,很容易陷入对 design 感到满意的陷阱。

经常听到 FPGA designers 说他们知道他们的 design 与 timing相比有所欠缺,但不管怎样,电子设备就像发条一样工作。事实上,确保 timing 正确完成在那一刻似乎是在浪费时间。渴望继续开发新功能的经理不太可能在几周内项目没有明显进展时感到高兴。事实上,对 design的 timing 进行适当的检查可以发现可能难以解决的问题。在旁人看来,这可能看起来像是在发明不存在的问题,然后浪费宝贵的时间去解决它们。

事实上,很多时候,忽略 timing 的策略在短期内是有回报的。但很多时候,对这个话题缺乏适当的关注会导致最烦人的问题,而且它们往往会在最烦人的时刻突然出现。例如,在最终验收测试期间,电子设备可能会在几个小时内发生一次故障,可能是在系统在整个温度范围内进行测试时。或者更糟的是: 产品发布几年后,客户开始抱怨。经过疯狂的努力找出这些投诉的原因后,发现这些产品中的 FPGAs 是分批生产的。因此,尽管所有 FPGAs 都满足 datasheet的要求,但它们的芯片差异导致新 FPGAs 的行为略有不同。

由于此类事件,FPGAs 为自己赢得了坏名声。但是,如果 timing 处理得当,您可以非常确定不会发生此类事情。当 design 正确完成时, FPGAs 非常可靠。

所以帮自己一个忙,花时间学习 timing的主题,然后一定要始终充分利用这些知识。这样做会让您不再担心如果您更改任何内容, design 会发生意外情况。您还将避免对出现和消失的 bugs 进行无休止的追逐。最重要的是,您会习惯于将 FPGA 视为可靠且坚如磐石的组件。

timing constraints的重要性

只有在 logic design中的每个 sequential element 上都满足 timing 要求时, FPGA 中的 logic 才能可靠地工作。为确保这一点,必须检查所有可能的 paths 。即使使用简单的 logic design,也不可能手动进行所有这些计算。

因此,工具有责任确保满足所有 timing 要求。为此,工具必须已接收到进行必要计算所需的所有信息。例如,工具需要了解所有 clocks 的频率以及外部组件对 timing的行为。这些信息会提供给带有 timing constraints的工具,这些工具通常包含一个具有特殊语法的文本文件。

如果 timing constraints 写错了,或者没有涵盖所有必要的信息,这些工具就无法确保 logic design的可靠运行。这些工具依赖于 timing constraints中提供给它们的信息,因此如果此信息不正确或不完整,那么这些工具进行的 timing 计算也是如此。 timing constraints 编写不当是 FPGA行为不可靠的常见原因。

所以与工具的不成文约定是这样的: 我们告诉工具他们需要知道的关于 timing的一切,工具确保 design中没有 timing violations 。

但有时工具无法避免 timing violations。发生这种情况时,工具中的 warning message 会这样说。这只是 warning 而不是 error,因此 FPGA 工具继续创建可以加载到 FPGA中的 bitstream 文件。因此,始终验证工具确认 timing constraints 已实现非常重要。这种确认通常采用类似“All timing constraints are met”的消息形式。

但这不仅仅是关于 timing constraints

您与 FPGA 软件之间的不成文约定其实更为广泛: 您将遵循关于 FPGA design 外观的几条规则,并且这些工具可确保 FPGA 不会出现故障。但如果你违反规则,工具就会报复。

正确使用 timing 是这些规则的重要组成部分。而 timing 不仅仅是写 timing constraints的事情。需要注意三个不同的方面。

第一个方面是 logic design 本身,即 Verilog (或 VHDL)代码。当然有一个明显的要求,即 logic 应该足够“快”(或者更准确地说, logic design 应该允许 clock 以所需的频率工作)。除此之外,还有其他几点需要牢记:

第二个方面是写 timing constraints。有时这部分真的很容易,有时则需要细心的工作。从不同的 design (尤其是一个 period constraint)复制 timing constraints 并认为工作已经完成是一个常见的错误。

第三个方面是生成和读取 timing reports ,以确保工具达到目的,从而保证 design 可靠工作。这是最难的部分,主要是因为这个任务需要了解 FPGA 内部的工作原理: timing reports 是根据 FPGA的最小构建块编写的。因此,如果不了解 FPGA,就很难从这些报告中得出任何有用的结论。

人们阅读 timing reports 通常是为了解决一个问题,尤其是当工具无法达到 timing constraints中的要求时。解决这样一个问题的过程称为 timing closure。最常见的问题是 clock的频率对于 logic design 来说太高了(同样可以说 logic 对于 clock来说太慢了)。

如前所述,强烈建议偶尔检查 FPGA design的 timing,即使已实现 timing constraints 并且一切正常。这意味着特别要检查 timing reports,还要验证 timing constraints 是否准确反映了 logic的需求。困难在于这样的检查在短期内不会有回报: 这种检查需要时间和精力,并且以无结果或发现问题而告终。因此,如果检查取得成果,实际上意味着更多的工作来解决一个没人能看到的问题。

这些关于 timing 的页面是如何组织的

这些页面着重于您与 FPGA 工具之间不成文协议的第二和第三方面: 写入 timing constraints 并读取 timing reports。这些技能需要理论知识和实用工具。

timing constraints 的实用方面比较好学。困难的部分是理解它们的确切含义和对 design的影响。本系列的下一页将介绍基本的理论概念。在接下来的几页中,将借助几个 timing reports示例继续讨论理论。整个故事都在 timing analysis的小细节中。

下一页之后的两页讨论了最重要和最有用的 timing constraint: period constraint。由于 timing reports 的重要性,这两页包含有关 timing reports 的详细讨论。

接下来的两页讨论 timing closure。这个主题可能有点早,但它解释了要遵循的主题的目的: 与 logic fabric相关的关于 timing constraints (在 SDC 语法中)的五页。接下来是关于 I/O timing constraints的两页。

本系列的最后一页专门介绍现有 design的检查。该页面中没有任何新内容。相反,它重复已经讨论过的主题。但这一次,作为要检查的事物的清单。

主题以允许从头到尾阅读本系列页面的顺序呈现。但是所有的主题都是相互关联的,所以页面之间有很多引用。

从此处继续的最佳位置是下一页。研究 timing 理论永远不会有坏处。

此页面由英文自动翻译。 如果有不清楚的地方,请参考原始页面
Copyright © 2021-2024. All rights reserved. (6f913017)