彻底理解Intel FPGA时序约束---解决方案篇（二）

 

 转载文章：https://blog.csdn.net/ciscomonkey/article/details/88199448

引言
本文在衔接上一讲的基础上，推出了，针对时序约束的解决方案，这些方案来源于本博主目前所掌握的一些工作经验。
不少人总说，好的时序都是设计出来的，不是约束出来的。什么叫好的设计？你觉得你的代码好，我还觉得我的比你更好呢？有什么评判标准呢？个人觉得应该是你正常的先完成RTL的设计，然后再做约束，如果发现EDA工具不能满足你的约束要求，然后再看能否修改你的逻辑代码。有必要从官网下手，从各方资料下手，来讲清楚这其中的来龙去脉。如果，你现在还是连steup 的slack和hold 的slack还没搞清楚，那我建议你好好看一下上一篇文章，特别是最后必备公式的图片。
作者：ciscomonkey
链接在此啦：https://blog.csdn.net/ciscomonkey/article/details/88046646

1、time-quest的GUI
首先，我们点进去都会叫我们选择一个模型，来建立网表，如果，我们选择slow，那么我们知道对setup slack自然会有影响更大，如果我们选择fast模型，就会对hold slack的模型影响更大。slow模型通常是针对综合完成后的环境的仿真，如果你选择fast模型，你综合后的FPGA未必能在恶劣的环境下正常使用，所以，根据经验，建议选择slow模型。

只有在编译filter（布线综合器）后，，然后再进行添加约束，最后再进行时序分析，如果你熟悉SDC的话，你可以自己手写脚本，如果不熟悉，你可以使用GUI的模式。另外，注意在时序分析时候，关掉signal tap, 有可能signal tap II会影响到时序约束，从而使得布线更加紧凑，违规更加严重。

1.1 时钟约束
时钟约束是必要的，你至少要先建立时钟再进行时序分析，因为所有的时序都是建立在时钟的基础上。

在添加或者更改约束后，请务必记得每次Write SDC File
如果要进行时序分析，请务必记得重新编译后，再进行时序分析，另外如果你有signal tap II，要关掉signal tap II.不然可能会影响到时序分析。

1.2 Fmax Summary最大时钟频率

在report 的datasheet当中有一个按钮Reoort Summary，此报告的意思是，按照这样的设计（你的verilog硬件电路设计），你在当前的环境下（比如80度低电压），你在当前时钟域下的设计最大的速度能够跑到多少，按照上面的最大的时钟速度只能跑到99.23M。

以上是官方的文档解释，我们来看一下
说了Restricted Fmax，这个值是因为保持时间的限制，也就是说，在这样的设计下，我们要，满足setup slack的要求，寄存器能正确的捕获到值，最大这个速度就只能是99.23M了。

1.3 Report timing 报告时序
custom Reports—》Report Timing…
这个功能可以说非常强大了，通过此功能，可以查看设计的所有时序问题，包括建立时间的余量和保持时间的余量都是很方面的可以看到的。

正如上图所示，From Clock \ To Clock可以指定时钟区域，要知道，我们的时序都是建立在时钟域的基础上的，没有时钟，何谈时序分析，这里，我们如果是全部设计只有一个sysclk的时钟域的话，我们把两个参数都选为sysclk即可。
Target的from、through、to这三者包含了我们要查看的时钟域里面的哪些节点部分。一般来说，我们都是查看整个时钟域。 Analysis type就是我们查看时序的哪一种slack，后面两种属于异步复位，我们暂时不去了解，但是在这里我建议，不要用太多的rst，写状态机，用一个即可了，甚至很多工程都不用rst的。我们指定1000条目录，足矣。
后面report pannel name是生成这个报告的名字。Fle name，我们可以把生成的另外保存下来。

1.3.1分析setup slack余量

data_arrival=0+2.597+10.004(注意：10.004就包括了utco、组合逻辑延时等)=12.601
data required time=20+2.522-0.020-0.021(注意：此处应该是减去0.021才对)=22.481
setup slack=data required time-data_arrival_time=22.481-12.601= 9.88
这才是真正的建立时间的余量，所以上图和下图的计算都是有误的，不过这关系不是很大，但是如果我们的setup slack很少的一部分就要注意了。但是实际上，我们的time是非常严格苛刻环境，已经是分析最坏情况了，所以，这一点计算误差，也影响不大。

我们可以根据上图来计算一下，其实算出来，我们就知道，会和报告的22.523的需求时间相差一点，为什么呢？那是因为Time quest算错了！按照波形图，它表示的正负关系都是对的，但是在上图红色圈圈处，它把tsu用的加法，而实际上与它的波形图，还有官方的文档，都是减法，所以，这里是他算错了的。我不知道在后续版本发现这个问题没，我是quartus13.1.

1.3.2分析hold slack余量

计算：
data_arrval_time=0+2.542+0.746(这里面包括了utco)=3.288
data required time=0+2.625+0+0.212=2.837
这里是正确的，符合官方文档公式。图和数据也是符合的。
从图中，我们可以看出来launch沿其实是next launch沿，这再次说明了我们之前的理解是正确的。

总结
我们只需要掌握好了上一篇我们讲的公式，一共6个公式。实际上只用记住register to register之间的setup和hold的slack计算即可。
2、 constraints列表（约束列表选项的含义）
上面，我们介绍了如何分析时序的方法，并且验证了我们第一篇的公式，第一篇连接：https://blog.csdn.net/ciscomonkey/article/details/88046646
并且我重点介绍了report timing。下面，我们要开始正式来学习GUI界面下的约束命令了。

2.1、create clock\derive pll clocks\Derive clock uncertainty

2.1.1 create clock

以上默认是占空比50%，如果要指定占空比，请指定-waveform option.

2.1.2 derive pll clocks
The Derive PLL Clocks (derive_pll_clocks) constraint automatically creates
clocks for each output of any PLL in your design.

2.1.3 Derive clock uncertainty

Allows you to specify the expected clock setup or hold uncertainty associated with jitter, skew, and a guard band when performing setup and hold checks for clocks or clock-to-clock transfers. You can specify separate clock uncertainty for setup (-setup) and hold (-hold). The Timing Analyzer subtracts the setup uncertainty from the data required time Definition for each applicable path, and adds the hold uncertainty to the data required time for each applicable path.

从上面的官方文档，我们可以知道这个clock uncertainty正式时钟的不确定性的约束，其实也是我们建立时间余量和保持时间余量的不确定性的值。

2.2 set_clock_groups

设置时钟组允许你指定在设计中不相关的时钟，默认情况下，时需分析器件会假定所有的时钟都是通过共有的时钟而相关的，因此所有在时钟域间的传递对于时序分析来说都是有效的，你可以通过切分成时钟组来排除时钟域之间的传递。

比如说，如果有两个时钟8ns和10ns的时钟，即使时钟是完全异步的，这个时序分析器件仍然企图建立2ns的建立时间关系，除非你用时钟组来指定这两个时钟是不相互关联的。另外时钟组并不是只能设置两个，你也可以继续无限制的添加。

2.3 Create Generated Clocks

此约束用于内部生成的时钟约束，比如说PLL，或者分频生成的时钟，但是分频生成的时钟我们一般不建议用来作为时钟信号。source指的是时钟源，比如说将clk进行倍频，那么clk就是时钟源。

2.4 Set Clock Latency

2.5 set_input_delay

2.6 Output Constraints

2.7 set_false_path

set_false_path指的是不做时序检查，比如一些跨时钟域之间的数据传输可以不做时序检查，因此可以设置为set_false_path

3、调节时序的另类方法
方法1

更改分析和综合的设置选项，第一种为速度型，就会更加兼顾速度，第三种将更加兼顾布线的面积。更改这些值后，重新编译，如果时序伪劣较小，很可能，更改后，时序伪例就消失了。

方法2

综合种子，这个值默认是1，但是也可以更改为1~12等都可以尝试，不同的值可能会影响最后的布线，可能最后伪劣会消失。

方法3
更改布线的预计最坏slack，如果时序违规在在0.5ns左右，可以通过此方法，如果违规太严重，那可能用此方法也未必生效。

以上三种方法都属于工程经验，记住即可, 都是试出来的，有可能你三个方法都用了会适得其反。

4、增加Fmax的另类方法

设置为3，虽然编译时间会增加，但是可以以运行时间为代价寻找到更好的路由。

并且把router Timing optimization level 更改为max
更改前的fmax:

更改后：

实验结果发现也没提高，我们了解一下即可。

5、解决时序问题salck的正确办法
5.1 解决setup slack的正确方法
通过减少阻塞逻辑，减少rigister-to-register 的数据延时，所以最好就是if语句里面不要写太多的组合逻辑了，如果写了很多组合逻辑，我们可以输出flag标志的寄存器来处理，从而实现路径的分割。这也是插入pipeline的方法。

5.2 解决hold slack的正确方法
一般来说解决hold violation的情况是比较少见的，如果遇到，可以通过加一个lockup latch来解决。
————————————————
版权声明：本文为CSDN博主「ciscomonkey」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/ciscomonkey/article/details/88199448