一.概述
时序违例的解决可以分为几个阶段，布局前，布线前，布线后。我们从这几个阶段对时序违例进行分析以及提出解决方法。（参考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就正常，布线后的拥塞还分为全局，长，短拥塞，可以通过看关键路径是否通过拥塞区域进行判断违例是否受到拥塞影响，下图中不影响，而且拥塞等级低。
布局后拥塞
布线后拥塞
如果没有受到影响，需要减少控制集，例如：
（1）去掉复位/使能/置位的max_fanout属性，或者去掉不该用的复位
（2）使用opt_design –control_set_merge or –merge_equivalent_drivers 合并复制的控制信号
如果受到影响，需要：
（1）检查关键信号是否扇出>10 ,减少扇出。
对于c：
（1）选择时序路径，启用“Clock Path Visualization”工具栏按钮 ，打开原理图 (F4) 以复查时钟逻辑，如果是级联缓冲器，那么使用并行缓冲器代替级联缓冲器 ，在时钟路径中移除 LUT 或任何组合逻辑 ，缓冲器使用的合理性，在时序报告中也有体现。
（2）使用 CLOCK_DELAY_GROUP 。
（3）在异步时钟间添加时钟组 。
对于d：
MMCM或者PLL选择最小输出抖动。
对于e：
参考2.1中的f解决方法。
2.5report_qor_suggestions
通过report_qor_suggestions可以在分析关键路径的基础上给出优化建议，以xdc或tcl文件的形式给出来。上图是report_qor_suggestions给出的结果，该路径的时钟偏移太大，发现是由于异步时钟组没有约束的原因。
小结：文章来源：https://www.toymoban.com/news/detail-528591.html
本文介绍了VIVADO各个阶段所要注意的影响时序的因素，并根据时序报告的几个重要参数给出相应解决方法。文章来源地址https://www.toymoban.com/news/detail-528591.html
到了这里，关于时序违例在FPGA开发流程的分析及解决，结合实际工程的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
