STA学习记录-时钟定义

行走的BUG永动机

墨衍会员 · AI 创作全网分发码龄7年

关注

原创 2022-10-17 14:03:54 591 阅读 AI 写同款· GEO 优化 ›

STA学习记录-generated clock 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 {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

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