Felix

技术源于积累,成功始于执着! 个人邮箱:justlxy@mail.dhu.edu.cn QQ:1576109464

静态时序分析之——如何编写有效地时序约束(二)

0
阅读(3600)

静态时序相关博文连载目录篇:http://blog.chinaaet.com/justlxy/p/5100052092


如题,这篇仍然使用的是上一篇所介绍的那个例子,主要分析的是两种案例:

Insufficient FREQUENCY preference & Sufficient FREQUENCY preference,即不充分的频率约束和充分的频率约束。

首先,简单地聊一聊不充分的频率约束(Insufficient FREQUENCY preference)

上一篇博文中,我们说到,Diamond会在用户新建工程的时候自动创建一个LPF文件,并且其默认内容为两个“BLOCK”,现在我们在该LPF文件中添加上clk1时钟的FREQUENCY的约束:

image.png

此时,TRACE的报告内容如下:

image.png

对比一下,上一篇的报告:

image.png

我们可以发现,时钟clk1得到了约束,而clk2缺没有得到约束……这里反映了一个非常重要的信息——当我们的设计中含有多个时钟的时候,如果用户并没有对所有的时钟进行频率约束,那么Diamond并不会对那些没有被约束的时钟自动约束(而在Case1中,用户没有对任何一个时钟进行约束,Diamond会自动对每一个时钟进行约束)。为了时序能够闭合,很显然,用户需要对每一个时钟进行频率后者周期约束。


接下来,再来聊一聊充分的频率约束(Sufficient FREQUENCY preference)

我们进一步添加对clk2的频率约束:

image.png

此时TRACE的相关报告内容如下:

image.png

image.png

image.png

可以发现,两个时钟的频率都得到了响应的约束。但是同时,Clock Domain Analysis还提示用户,clk1和clk2还没有关联,建议用CLKSKEWDIFF进行约束(这个在后面的博文中会进行介绍)。

补充说明一下,实际上,并不是所有的跨时钟域路径(Cross-domian paths)都必须使用CLKSKEWDIFF进行约束,Diamond有能力分析某些特定的时钟源的跨时钟域路径,如PLL输出的时钟,分频器(Divider)输出时钟等。