时序违例在FPGA开发流程的分析及解决，结合实际工程

xsnl

已于 2023-04-03 17:07:51 修改

阅读量5.8k

点赞数 10

分类专栏： Xilinx 文章标签： fpga开发硬件工程 Powered by 金山文档

于 2023-03-25 00:08:34 首次发布

本文链接：https://blog.csdn.net/aaa23d1/article/details/129721352

版权

Xilinx 专栏收录该内容

6 篇文章 4 订阅

订阅专栏

一.概述

时序违例的解决可以分为几个阶段，布局前，布线前，布线后。我们从这几个阶段对时序违例进行分析以及提出解决方法。（参考ug1292和ug949）。时序违例包括建立时间违例和保持时间为例，主要关注建立时间违例，保持时间违例是由于组合逻辑太短和时钟偏移造成的，可以通过布线时绕线以及BUFG解决。但是布线时过多的绕线会影响布线时对拥塞的解决程度。可以通过在布线前插入LUT（布局后使用phys_opt_design -hold_fix ），使关键路径的保持时间符合要求，减少布线时的绕线，而专注解决拥塞。

二.分析

2.1布局前

布局前的时序分析可以打开综合后的dcp或者opt以后的dcp文件，然后控制台输入report_time_summary,即可看到列出了时序路径，该阶段时序报告反映的是以下情况下的设计性能：假定每条逻辑路径均达到最理想逻辑布局。如果出现不符合的路径，则关注扇出和资源利用率，进行设计的初步检查：

是否有太多阻碍逻辑优化的综合属性（mark_debug，keep，dont_touch）

是否扇出过大（report_high_fanout_nets）

关键路径的RTL代码设计是否合理

资源利用率是否符合要求（块 RAM 利用率较高，而 LUT/FF 利用率较低，那么设计仍可能出现布局问题，对于块 RAM 利用率达 70% 的设计，如果在 SLR 间未平衡块 RAM 资源并且其中 1 个 SLR 的块 RAM 利用率超过 85% ，也可能出现时序问题）

时序约束是否合理。

逻辑级数和延时是否太高（通常要求：逻辑级数<时钟周期（ns）* 2）

解决方法：

对于a，去除没有必要的综合属性。

对于b，可以使用max_fanout综合属性进行约束，或者手动复制寄存器，对于复位的高扇出，可以使用BUFG，以及少用复位，多用reg赋初值。

对于c：

1.用LUT实现大位宽数据存储，毕竟每个LUT只提供1bit输出，256的位宽意味着至少需要256个LUT，而这些LUT必然分布在不同列的SLICEM中，无论对布线还是时序都会带来负面影响。

博主在做双令牌桶算法时，就用LUT存储128位的数据，深度为32或64。需用RAM对此算法进行优化。

2.这一点，这个博主写得很不错。

（1）应该尽量保证每一个always块的判断条件简洁（判断条件中尽量只进行逻辑判断，尽量避免逻辑运算）

（2）应该尽量保证每一个always块的判断条件中的每一个变量都是直接来源于某个always块输出信号，尽量避免将组合逻辑的输出直接作为某个always块的判断条件的一部分，这样就可以保证每一个always块的输入信号的延时比较固定，有利于时序收敛。

（3）应该尽量保证每一个always块的赋值语句中的被赋值变量都是直接来源于某个always块输出信号，尽量避免将组合逻辑的输出直接作为某个always块的赋值语句中的一部分，这样就可以保证每一个always块的输入信号的延时比较固定，有利于时序收敛。

原文链接：https://blog.csdn.net/gemengxia/article/details/108442927

对于d：做一些资源优化

1.大ram分成小ram加小ram

2.分布式ram配置到集中式ram配置

3.LUT转RAM

4.平衡SRL间利用率

对于e:

1.设置伪路径

2.设置异步时钟组

3.设置多周期路径

对于f：

通常使用流水寄存器，重定时，操作数平衡，case代替if..else(vivado中if else会多用LUT)，关键信号后移,opt使用-remap（lut逻辑优化）等方式进行逻辑级数和延时的减少。

2.2布线前

布线前的时序分析可以打开布局后的dcp，然后控制台输入report_time_summary,即可看到列出了时序路径，该阶段时序报告反映的是假定每条单独信号线均达到最理想布线延迟，不考虑保持时间修复的造成的影响（信号线布线绕行）或拥塞。

器件或 SLR 利用率过高。

复杂逻辑导致的布局拥塞。

时钟间的时钟偏差或时钟不确定性过高。

解决方法：

对于a，如果资源总体利用率大于 70-80%，通过移除部分设计功能，或者将部分模块或内核迁移到另一个 SLR，可降低器件或 SLR 利用率。

对于b，逻辑是否可以优化

在 Explore 模式或 AggressiveExplore 模式下运行 phys_opt_design，尝试提升执行 place_design 后的 QoR 。

2.3布线后

打开布线后的dcp，布线后的严重的建立时间 (WNS) 或保持时间 (WHS) 违例是由拥塞过高导致的结果。

解决方法：

（1）可以通过在布线前插入LUT（布局后使用phys_opt_design -hold_fix），使关键路径的保持时间符合要求，减少布线时的绕线，而专注解决拥塞。

（2）如果资源总体利用率大于 70-80%，通过移除部分设计功能，或者将部分模块或内核迁移到另一个 SLR，可降低器件或 SLR 利用率。

（3）尝试使用不同的实现策略。

（4）执行 route_design 后，尝试运行 phys_opt_design 。

2.4vivado 时序表分析

打开每个阶段的timing，都能看到关键路径的时序违例情况，还可以看到每条路径的属性。

几个关键参数：

逻辑延迟，对于xilinx 7系列fpga，不超过25%

线延迟，对于xilinx 7系列fpga，不超过75%

时钟偏移，应大于-0.5（如果此值大，对于修复建立时间违例有利）

时钟不确定性，应小于0.1

逻辑级数 logic levels

解决方法：

对于a：逻辑延迟的减少可以由布线前的a解决方法解决。

对于b：线延迟需要看是否受到拥塞影响，report_design_analysis -congestion -name wx可以得到拥塞分布图，东西南北4个方向小于5就正常，布线后的拥塞还分为全局，长，短拥塞，可以通过看关键路径是否通过拥塞区域进行判断违例是否受到拥塞影响，下图中不影响，而且拥塞等级低。