【精品博文】4.9、静态时序分析之——如何编写有效地时序约束（四）

静态时序相关博文连载目录篇：

http://blog.chinaaet.com/justlxy/p/5100052092

这篇文章主要介绍三个内容，分别是：

|-7、Timing Exception 1 — MULTICYCLE

|-8、Clock over-constrained

|-9、Timing Exception 2 — False Paths

首先，Timing Exception 1 — MULTICYCLE

很多情况下，设计中都可能会包含有一些比较长的组合路径（Latency较大）。但是，在默认情况下，时序分析工具认为，所有的组合路径都应在一个时钟周期内完成。所以，TRACE会认为其为关键路径，导致分析报告中的时钟最高频率变得很低……。此外，为了尽量达成用于设定的时钟约束（频率或周期），PAR工具也会花费大量的时间对该组合路径进行优化（甚至是Pipelining、Retiming等，如果用户允许的话）。然而，实际情况是，用户并不需要该组合路径在一个时钟周期内完成，允许其可以在多个时钟周期之后在完成。这时，我们就需要用MULTICYCLE对该段路径进行约束。

具体来说，多周期约束一般可以分为两种：同一个时钟内的多周期问题和跨时钟域的多周期问题。后者由于过于复杂，对于初学者来说过于困难，本篇文章中不作介绍，只是简单地介绍一下同一个时钟域内的多周期问题。后期，（可能）会单独地写一篇关于跨时钟域的多周期时序约束的文章……如果需要的话……

对于同一个时钟域内的多周期约束很简单：

上面的语句会告知分析工具，从FF_S到FF_D这段路径需要两个时钟周期，而不是默认的一个时钟周期！具体，如下图所示：

跨时钟域的多周期约束，大家可以自行下载Lattice的Timing Closure文档进行阅读。此处不再介绍……

然后，简单聊一聊Clock over-constrained

时钟过约束有的时候会带来一些“神奇的”现象……举一个例子：

当采用上图所示的时钟约束时，对于从clk1到clk2的跨时钟域路径的默认延时要求为3.333ns。

当我们将clk1的频率约束改为303MHz呢？此时的默认延时要求多少呢？请看下图：

没错，你没有看错，就是0.066ns。具体的计算稍微有点复杂（其实也不是特别复杂，如果你能深刻理解时序问题的话），涉及到跨时钟域的周期计算问题，这里就不详细说了。有兴趣的可以自行去看Timing Closure的文档。那么，如何避免上面出现的问题呢？很简单，之前已经介绍过了，使用PAR_ADJ参数！！

最后，简单聊一下Timing Exception 2 — False Paths

所谓False Paths就是没有“意义”的路径，举一个简单的例子，如下：

上面的那条路径就是False Path。有的时候设计中的确存在着这样的路径，有的可以被优化掉，有的是有意而为之。因为对这样的路径进行时序约束，实际上是没有意义的，但是如果用户不对其进行约束，TRACE又会认为设计处于欠约束（Under-Constrained）状态。那怎么办呢？可以使用BLOCK约束命令，告知分析工具，忽略它就可以了。