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

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

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

前面的几篇讲了静态时序分析一些基本概念等内容，接下来将以一个实际的例子来简单地介绍一下使用Lattice Diamond IDE进行静态时序分析的几种基本案例。此部分博文主要翻译自Lattice的一篇叫做Timing Closure的文章（在Diamond的Start Page的页面中就可以找到），有兴趣的可以自己去下载阅读。

接下来要介绍的主要一下几种基本案例（Case）：

|-1、No user-defined timing constraint

|-2、Insufficient FREQUENCY preference

|-3、Sufficient FREQUENCY preference

|-4、INPUT_SETUP

|-5、CLOCK_TO_OUT

|-6、CLKSKEWDIFF

|-7、Timing Exception 1 — MULTICYCLE

|-8、Clock over-constrained

|-9、Timing Exception 2 — False Paths

由于内容比较多，所以分开为多篇文章……

首先来介绍第一种情况：No user-defined timing constraint

默认情况下，当我们新建一个Diamond工程的时候，Diamond都会自动地创建一个LPF文件，文件里面包含以下内容：

其中，BLOCK RESETPATHS是一个全局约束（global preference）。主要用于禁止TRACE分析异步复位和异步置位路径的时序信息。

BLOCK ASYNCPATHS也是一个全局约束，主要用于禁止TRACE分析输入到寄存器路径的时序信息。因为很多情况下，我们的设计往往只是一个内部的模块，并不用连接到IO上，所以此时对输入到寄存器的时序分析是没有必要的。

如果用户没有在LPF文件中添加任何时序约束条件的话（不管有没有默认产生的两个BLOCK），同时也没有在HDL源码中进行时序约束，MAP TRACE根据你的设计会自动的生成一个FREQUENCY的约束（preference），但这个设置并不会被写入到LPF文件中。时钟的FREQUENCY数值是根据特定器件的逻辑层和硬件布线延时预测算法计算得到的（based on the logic levels and the hardware recommended routing delay estimation algorithm for the target device）。

为了更好地说明这些，下面（包括接下来的几篇博文）将以这个HDL设计为例分析：

使用Synplify Pro综合后可以得到（ChinaAET压缩的太厉害了，有点看不清了……）：

这个例子中，一共有两个外部时钟输入，clk1和clk2，并且两者之间并未建立相关的时序约束，我们可以在MAP TRACE和PAR TRACE中的Clock Domains Analysis部分找到相关信息：

前面也说了，如果用户没有指定时钟的FREQUENCY或者PERIOD约束，MAP TRACE根据你的设计会自动的生成一个FREQUENCY的约束（preference）。但是这个是不准确的，所以在报告中往往会有一些错误和警告，同时报告类型（Report Type）也会提示用户，当前的约束是MAP TRACE自动产生的。如下图所示：

那么，如果用户已经指定了时钟的FREQUENCY或者PERIOD约束，TRACE却任然报告错误，怎么办呢？这就说明用户当前的HDL设计结构可能存在问题，需要优化（Pipelining & Retiming等）。如果HDL已经无法优化了，用户还可考虑选择速度等级更高的器件。