STA内容汇总
STA的准备工作包括：设定时钟、指定IO时序特性、指定false path和multicycle path
1 什么是STA环境
看下面这张图，假定Design Under Analysis（DUA）会与其他同步设计交互，这意味着DUA会从前一级触发器接收数据，并将数据发送到DUA后一级触发器
为了对这种设计执行STA，需要指定触发器的时钟、进入DUA和退出DUA的所有路径上的时序约束
2 指定时钟
定义时钟时需要提供以下信息：
* Clock source：可以是design的port，也可以是design内部的pin
* Period：时钟周期
* Duty cycle：高电平持续时间和低电平持续时间
* Edge time：上升沿和下降沿出现的时刻
通过时钟定义，所有内部的timing path都将受到约束，表明所有的internal path都可以用时钟路径来分析
下面是一个基本的时钟定义：
代码语言：text复制create_clock
-name SYSCLK
-period 20
-waveform {0 5}
[get_ports SCLK]在这个例子中，定义的时钟名称为SYSCLK，并且指定定义的时钟是在端口 SCLK上定义的
SYSCLK的时钟周期时20（如果没有明确指定时间的单位，默认是ns）
在-waveform中，第一个变量是上升沿出现的时刻，第二个变量是下降沿出现的时刻，因此在这个例子中，上升沿出现在0ns，下降沿出现在5ns
这个例子对应的波形图如下
-waveform中可以指定任意数量的边沿，但是**所有的边沿必须在一个周期之内**
边沿时刻从0时刻之后的第一个上升沿开始，然后依次是下降沿、上升沿、下降沿……
代码语言：text复制-waveform {time_rise time_fall time_rise time_fall ...}在-waveform中需要指定偶数个边沿，并且-waveform指定的是一个周期内的波形，在后续周期中不断重复
如果没有指定-waveform，默认是
-waveform {0, period/2}下面看一个不使用-waveform选项的时钟定义
create_clock -period 5 [get_ports SCAN_CLK]其对应的波形图如下：
在这个例子中，由于没有指定-name，因此定义时钟名称与端口名称相同
再来看另一个例子
代码语言：text复制 create_clock -name BDYCLK
-period 15
-waveform {5 12}
[get_ports GBLCLK]其对应的波形图如下：
在这个例子中，根据-waveform可以知道，第一个上升沿出现在5ns，第一下降沿出现在12ns
因为选项-waveform给出的上升沿和下降沿时刻会在每个cycle里重复，又因为-period指定周期是15ns，
所以在第二个cycle中，上升沿应该出现在15 5=20ns处
下降沿出现在15 12=27ns处
再来看另外两个例子：
代码语言：text复制 # Figure （a）
create_clock -period 10
-waveform {5 10}
[get_ports FCLK]
#Figure （b）
create_clock -period 125
-waveform {100 150}
[get_ports ARMCLK]对应的波形图如下：
对于图(a)，周期为10ns，上升沿出现在5ns，下降沿出现在10ns
在第二个cycle中，上升沿出现在10 5=15ns，下降沿出现在10 10=20ns
对于图(b)，周期为125ns，从选项-waveform {100 150}可以知道，上升沿出现在100ns处，并且 high duration = 150-100=50ns，那么low duration = period - high duration，即low duration = 75ns
因为150ns的时刻已经超出了第一个cycle的时间范围，并且low duration的时长小于上升沿出现的时刻，那么可以推断出 **在第一个cycle中有一个下降沿**，这个下降沿出现的时刻可以用100 - low duration得到（100 - 75 = 25ns）
出现这种情况的原因是：选项-waveform要从上升沿开始
根据下面的例子，再次理解一下选项-waveform
#Figure (a)
create_clock -period 1.0
-waveform {0.5 1.375}
[get_ports MAIN_CLK]
#Figure (b)
create_clock -period 1.2
-waveform {0.3 0.4 0.8 1.0}
[get_ports JTAG_CLK]对应的波形图如下：
在这个例子中，图(a)的分析方式与上一个例子相同
图(b)由于选项-waveform中给出的上升沿和下降沿时刻都在第一个cycle时间范围内，因此不需要进行额外的推断
在某些情况下，比如在顶层的输入端口或某些PLL的输出端口，工具无法自动计算出过渡时间，此时在clock source出显示指定过渡时间很有用，可以使用set_clock_transition来指定
set_clock_transition -rise 0.1 [get_clocks CLK_CONFIG]
set_clock_transition -fall 0.12 [get_clocks CLK_CONFIG]
# 这个约束仅适用于ideal clocks，一旦构建了时钟树就将其忽略3 时钟不确定度
可以用set_clock_uncertainty来指定时钟周期的timing uncertainty，用不确定度来建模那些**会降低有效时钟周期**的因素
set_clock_uncertainty -setup 0.2 [get_clocks CLK_CONFIG]
set_clock_uncertainty -hold 0.05 [get_clocks CLK_CONFIG]setup check会减少可用的有效时钟周期
对于hold check，clock uncertainty被用作需要满足的额外时序裕量
这里我的理解是，由于clock uncertainty的存在，减小了有效的时钟周期，并且在clock uncertainty范围内，我们无法预测clock是否有效，为了保证数据的正确性，在进行数据传输时，应当避开clock uncertainty的范围
下面几个command可以用来指定跨时钟边界path上的clock uncertainty，被称为 **inter-clock uncertainty**
代码语言：text复制set_clock_uncertainty -from VIRTUAL-SYS_CLK -to SYSCLK -hold 0.05
set_clock_uncertainty -from VIRTUAL-SYS_CLK -to SYSCLK -setup 0.3
set_clock_uncertainty -from SYS_CLK -to CFG_CLK -hold 0.05
set_clock_uncertainty -from SYS_CLK -to CFG_CLK -setup 0.1
从图中可以看到，该电路为两个不同的clock domain SYS_CLK和CFG_CLK之间的path，根据上面约束可知，setup check的uncertainty是100ps，hold check的uncertainty是50ps
4 时钟延迟
可以使用set_clock_latency来指定时钟的延迟，用法如下：
set_clock_latency 1.8 -rise [get_clocks MAIN_CLK]
# MIN_CLK的上升沿延迟是1.8ns
set_clock_latency 2.1 -fall [all_clocks]
# 所有时钟的下降沿延迟是2.1ns
# -rise和-fall指的是 时钟在DFF的clock pin上的延迟时钟延迟有两种：network latency和source latency
* network latency：从时钟定义点（creat_clock）到DFF的clock pin上的延迟
* source latency：指的是从时钟源到时钟定义点的延迟
下图直观的展示了这两个延迟类型的位置
以下是一些指定源延迟和网络延迟的示例
代码语言：text复制# 没有给出 -source 选项，表明是 network latency
# 没有给出 -fall和-rise选项，表明fall和rise是相同的
# 没有给出 -min和-max选项，表明min和max是相同的
set_clock_latency 0.8 [get_clocks CLK_CONFIG]
set_clock_latency 1.9 -source [get_clocks SYS_CLK]
set_clock_latency 0.851 -source -min [get_clocks CFG_CLK]
set_clock_latency 1.322 -source -max [get_clocks CFG_CLK]一个重要的区别：
当clock tree建立后，network latency可以忽略，source latency不可以忽略
这是因为network latency的作用是在clock tree综合之前用来估算clock tree上的latency，当clock tree综合之后，我们可以计算出clock tree上的实际的latency，因此不在需要network latency
当clock tree综合后，总的clock latency = source latency clock tree上的实际latency
参考
Static Timing Analysis for Nanometer Designs: A Practical Approach
