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都可以用时钟路径来分析

下面是一个基本的时钟定义:

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 {0 5} \
 [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

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:指的是从时钟源到时钟定义点的延迟

下图直观的展示了这两个延迟类型的位置

以下是一些指定源延迟和网络延迟的示例

# 没有给出 -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

posted @ 2022-10-10 21:56  行走的BUG永动机  阅读(210)  评论(0编辑  收藏  举报