STA的准备工作包括:设定时钟、指定IO时序特性、指定false path和multicycle path
看下面这张图,假定Design Under Analysis(DUA)会与其他同步设计交互,这意味着DUA会从前一级触发器接收数据,并将数据发送到DUA后一级触发器
为了对这种设计执行STA,需要指定触发器的时钟、进入DUA和退出DUA的所有路径上的时序约束
定义时钟时需要提供以下信息:
* Clock source:可以是design的port,也可以是design内部的pin
* Period:时钟周期
* Duty cycle:高电平持续时间和低电平持续时间
* Edge time:上升沿和下降沿出现的时刻
通过时钟定义,所有内部的timing path都将受到约束,表明所有的internal path都可以用时钟路径来分析
下面是一个基本的时钟定义:
create\_clock \
-name SYSCLK \
-period 20 \
-waveform {0 5} \
[get\_ports SCLK]
在这个例子中,定义的时钟名称为SYSCLK,并且指定定义的时钟是在端口 SCLK上定义的
SYSCLK的时钟周期时20(如果没有明确指定时间的单位,默认是ns)
在-waveform
中,第一个变量是上升沿出现的时刻,第二个变量是下降沿出现的时刻,因此在这个例子中,上升沿出现在0ns,下降沿出现在5ns
这个例子对应的波形图如下
-waveform
中可以指定任意数量的边沿,但是**所有的边沿必须在一个周期之内**
边沿时刻从0时刻之后的第一个上升沿开始,然后依次是下降沿、上升沿、下降沿……
-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
,因此定义时钟名称与端口名称相同
再来看另一个例子
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处
再来看另外两个例子:
# 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,一旦构建了时钟树就将其忽略
可以用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**
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
可以使用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:指的是从时钟源到时钟定义点的延迟
下图直观的展示了这两个延迟类型的位置
以下是一些指定源延迟和网络延迟的示例
# 没有给出 -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
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。