FPGA设计的WNS太高怎么办？五个窍门帮你打赢FPGA优化战役！

FPGA

首先要指出的是，高 WNS 是指多于1ns 的失败时序的余量值。对于此类设计，我们有5个诀窍分享给大家！和一般认知相反的是，成功优化设计并不是很设计技巧关系很大，而是与下列原因息息相关：

计算资源的紧缺。很多 FPGA 团队只有几台服务器，甚至只有几台个人PC。而团队成员都在同时处理一个设计的不同版本。
设计从一台老的设备转移到一台新的设备。这时候，一些代码模式无法充分发挥新构架的优势或者编译器的特性，所以需要时间来修改。
由第三方或前任工程师写的IP区块。尤其是当这些工程师离开时没有留下足够的说明文档。
因为复杂的依赖性而无法修改的 IP区块。比如很多不同的变化版本都在其他设计中使用。
设计是一个用来提升时钟频率的 ASIC 原型。

这些原因导致的结果就是-1ns, -2ns 甚至更加糟糕的 WNS。我作为一只FPGA时序优化团队，尽管乐于帮助用户成功的达到性能目标（从低于-100ps 的失败余量到完全达到时序要求，更多详情），但是我们的方法并不能解决不良约束的问题或是弥补糟糕的设计架构。每一个在 Intime服务上运行良好的项目都是由经验丰富的工程师仔细雕琢过的。• 优化战役我们的一位美国合作伙伴在提升性能方面特别指出：

“优化战役的首仗是最重要的！”

换言之，整个流程中最重要的一环是综合。在这一步，时序，资源占用率和其他的设计参数的波动都很大，这些波动最终也会导致设计结果的变化。但当我们进行到布局并最终布线时，波动会越来越小。（见下图）

我们十分认同这个观点。如果您的设计最差余量有几纳秒，您应该首先满足某些中级的时序预（intermediate timing estimates）估然后再进行后续阶段的优化。否则提升性能是完全没有可能的。在理想状况下，在您的设计综合之后应该是布局，中级时序预估在减少失败路径的方面会越来越精确，越来越理想。如果稳定地发展下去，优化通道会越来越窄，布线之后时序收敛。然而，可怕的是通道有时会莫名地变宽，也就是说时序反而越来越差了，如下图所示。

好消息是，在 InTime服务运行的编译中，“通道变宽“并不经常出现。每个项目也许会需要最多200次编译来收敛时序（在多台机器上并行运行）。我们监控每一次时序预估。200次编译看上去很多，但和无穷无尽的设计空间的组合数目比起来，只不过是沧海一粟。下面就是针对高 WNS 的小窍门。前提是您的项目被合理地设计和约束过。下面窍门并不是关于如何写出更好的RTL代码，这应该是 FPGA 厂商的范畴。
窍门一：提早放弃较差的编译
正如前文所述，优化通道是有可能在快结束的时候“变宽“的。也许您有着良好的综合后时序预估，但是一切可能在布局或布线之后跑偏。实际上，真实的情况会复杂得多。时序预估在不同的编译阶段波动很大。利用好这些预估的一个重要方法就是根据布局后的预估来停止某些编译，可以节省最多一半的编译时间。这也意味着我们有两倍的时间来运行 InTime，并施展它的机器学习才华。

窍门二：打好综合+布局设置这场硬仗
布局后的时序预估和最终时序结果关联性很高。得到好的时序预估很重要。更具体地说，如果您的 WNS 不理想，最有效的“战斗”在综合就应该开始了。然而，我们仍无法从综合后时序预估推断出最终的结果。这是因为时许预估仍然不够精确（考虑到缺少实际的时序信息和尚未优化的硬件元素，这是情有可原的）。关键就在于找到综合和布局的优秀参数组合，这点 InTime 可以帮您。
一则 InTime 用户的轶闻：在一个设计中，InTime 发现 MAX_DSP* 综合选项的值“为了通过时序应该更高”。但用户看了结果之后，告诉我们他们的设计其实没有怎么用到 DSP，除了一个非常小的区块！MAX_DSP 的值本来不应该产生什么影响。这意味着两种可能，首先 MAX_DSP 也许已经发挥了一些切实的影响；第二，MAX_DSP 导致了编译算法的一些波动，而这些波动被 InTime 检测到了！*MAX_DSP 是 Vivado 工具中的综合设置。
窍门三： 不要把所有的设置都调成最大
在很多用户给我们的设计中，他们已经使用了最激进的设计，比如把 Effot Level 调成最高值。其中一个设计甚至使用 InTime 的”反向操作“，把所有的设置参数都调成最大值来看看是否会得出最佳结果。我们不建议这样做。运行时间和结果的质量很多时候并不是有着强烈的正相关。而且，假设真的有一个参数的”黄金组合“，您的 FAE 或是 FPGA 供应商肯定已经提供给您了。把所有设置都调成最大并不是“黄金组合”。每个设计都不尽相同，那么最佳组合肯定也会因设计而异。

窍门四： 种子仅适用于WNS较低时
这可能是最广为熟知的文档条目了。来自文档“AN 584：高级FPGA设计的时许收敛方法（Timing Closure Methodology forAdvanced FPGA Designs）”。

使用不同的种子值会导致同一个设计的 Fitter编译优化结果产生波动。例如种子值为2会使您的一个设计产生最佳结果，但是当您修改设计时，不管是源代码还是参数设置，这个值可能就不会产生最佳结果了。而且，在另一个不同的设计中，种子值为1可能会产生最好结果。一般来说，您会看到不同的种子值导致结果有±5%的偏差。

还记得这场优化战役吗？当种子在布局阶段发挥作用时，它们的波动范围会比较小。如果您的 WNS 本身十分糟糕，那么寻找完美的种子无异于大海捞针，并且也会浪费您很多宝贵的编译时间。
窍门五： 使用云计算和机器学习
我们都知道计算资源的不足会使得项目进展变慢。但如果我们为您提供无限的编译服务器呢？您会怎么最大限度地利用它们？这就是 InTime 方便的地方。InTime 使用机器学习，帮您生成并分析海量数据。在云端，我们可以将数以百计的服务器开启数小时，来从结果中学习，关闭它们然后再重启。这种迅捷的重复操作让我们可以用极快的速度探索和学习。通过 Plunify Cloud这个云平台，您拥有全部所需的许可证，软件和计算资源来进行流畅的优化流程。再也不用将编译放在缓慢的任务队列里（job queue），使用云计算可以实现更高的生产效率和更好的结果！

希望这些窍门对您有所帮助！Plunify 从您的设计中累计优化的方法经验，并且用这些经验来帮助后续的项目。通过机器学习，我们不断地减少同一个设计后续版本的总运行数。根据我们使用 InTime服务的经验，您不需要每次都用200台服务器来解决时序问题。您需要更加合理的方法来再次利用已经习得的经验。请查看这里。如果您有任何其他的优化编译流程的窍门，请与我们分享。让我们一起建设更加美好的 FPGA 用户社区！了解更多 InTime 的信息，或者直接申请免费试用。

关注Plunify公众号，关注FPGA设计优化。

所有产品的信息和相关使用申请亦在公众号主页的菜单中，我们期待与您的交流。