精选推荐
彻底理解Intel FPGA时序约束—解决方案篇(一)
2021-04-10
解决方案篇(一)
本文在衔接上一讲(基础概念篇1-2)的基础上,推出了针对时序约束的解决方案,这些方案来源于我目前所掌握的一些工作经验。
不少人总说,好的时序都是设计出来的,不是约束出来的,想必,这种话你一定听过无数次。那你告诉我,什么叫好的设计?你觉得你的代码好,我还觉得我的比你更好呢?有什么评判标准呢?个人觉得应该是你正常的先完成RTL的设计,然后再做约束,如果发现EDA工具不能满足你的约束要求,然后再看能否修改你的逻辑代码。有必要从官网下手,从各方资料下手,来讲清楚这其中的来龙去脉。如果,你现在还是连steup 的slack和hold 的slack还没搞清楚,那我建议你好好看一下《彻底理解Intel FPGA时序约束—基础概念篇》,特别是最后必备公式的图片。
首先,我们点进去都会叫我们选择一个模型,来建立网表。如果,我们选择slow,那么我们知道对setup slack自然会影响更大,如果我们选择fast模型,就会对hold slack的模型影响更大。slow模型通常是针对综合完成后的环境的仿真,如果你选择fast模型,你综合后的FPGA未必能在恶劣的环境下正常使用,所以,根据经验建议选择slow模型。
只有在编译filter(布线综合器)后,然后再进行添加约束,最后再进行时序分析,如果你熟悉SDC的话,你可以自己手写脚本,如果不熟悉,你可以使用GUI的模式。另外,注意在时序分析时候,关掉signal tap, 有可能signal tap II会影响到时序约束,从而使得布线更加紧凑,违规更加严重。
时钟约束是必要的,你至少要先建立时钟再进行时序分析,因为所有的时序都是建立在时钟的基础上。
在添加或者更改约束后,请务必记得每次Write SDC File。
如果要进行时序分析,请务必记得重新编译后,再进行时序分析,另外如果你有signal tap II,要关掉signal tap II.不然可能会影响到时序分析。
在report 的datasheet当中有一个按钮Reoort Summary,此报告的意思是,按照这样的设计(你的verilog硬件电路设计),你在当前的环境下(比如80度低电压),你在当前时钟域下的设计最大的速度能够跑到多少,按照上面的最大的时钟速度只能跑到99.23M。
以上是官方的文档解释,我们来看一下
说了Restricted Fmax,这个值是因为保持时间的限制,也就是说,在这样的设计下,我们要,满足setup slack的要求,寄存器能正确的捕获到值,最大这个速度就只能是99.23M了。
Custom Reports—》Report Timing…
这个功能可以说非常强大了,通过此功能,可以查看设计的所有时序问题,包括建立时间的余量和保持时间的余量都是很方面的可以看到的。
正如上图所示,From Clock To Clock可以指定时钟区域,要知道,我们的时序都是建立在时钟域的基础上的,没有时钟,何谈时序分析,这里,我们如果是全部设计只有一个sysclk的时钟域的话,我们把两个参数都选为sysclk即可。
Target的from、through、to这三者包含了我们要查看的时钟域里面的哪些节点部分。一般来说,我们都是查看整个时钟域。Analysis type就是我们查看时序的哪一种slack,后面两种属于异步复位,我们暂时不去了解,但是在这里我建议,不要用太多的rst,写状态机,用一个即可了,甚至很多工程都不用rst的。我们指定1000条目录,足矣。
后面report pannel name是生成这个报告的名字。File name,我们可以把生成的另外保存下来。
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.
计算:
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计算即可。
未完待续……
来源于CSDN,内容仅代表作者观点,文章有删减。作者:李瑞锋,中国电科电子科学研究院硕士毕业生,苏州瑞晟微电子(realtek半导体集团)芯片工程师。