企业官网建设流程全解析

相关阅读

SDC命令详解https://blog.csdn.net/weixin_45791458/category_12931432.html?spm=1001.2014.3001.5482

目录

定义不确定值

对象列表/集合

时序分析中的时钟不确定度

时钟间不确定度

建立/保持时间

Multicorner-Multimode支持

写在最后

set_clock_uncertainty命令用于指定设计中时钟周期的不确定性（设置了时钟对象的setup_uncertainty和hold_uncertainty属性），不确定性指的是对那些会对时钟周期造成的负面影响。这些不确定性可能来源于时钟抖动(clock jitter)、时钟偏差(clock skew)或是额外裕度(margin)等一切想要在时序分析中考虑的因素。如果想要移除不确定度，使用remove_clock_uncertainty命令。

对于时钟树综合前的理想时钟，set_clock_uncertainty命令模拟了时钟抖动、时钟偏差和额外裕度；对于时钟树综合后的传播时钟，set_clock_uncertainty命令模拟了时钟抖动和额外裕度，时钟偏差由时钟路径上的互连延迟和单元延迟真实计算出来的。

本文针对Design Compiler，但该命令同样存在于PrimeTime、IC Compiler等工具中，它们大致相同，略有差别。set_clock_uncertainty命令的BNF范式（有关BNF范式，可以参考以往文章）为：

set_clock_uncertainty uncertainty [object_list] //下面两行选项必须成对出现,每条命令最多一对 //**************************************************************************** [-from from_clock | -rise_from rise_from_clock | -fall_from fall_from_clock] [-to to_clock | -rise_to rise_to_clock | -fall_to fall_to_clock] //**************************************************************************** [-setup] [-hold] //注：该命令的uncertainty参数一定要放在object_list参数前（如有）

定义不确定值

uncertainty是不确定值的具体浮点数值，它的单位由工艺库给出。下面所有的实例，默认是以纳秒(ns)为单位的。典型的不确定值是正数，用以表示悲观估计；如果不确定值是负的，则代表乐观估计，只应该在一些极端条件下使用。

对象列表/集合

object_list指定了设置不确定度的时钟、端口和引脚，对于列表而言，如果有多于一个对象，需要使用引号或大括号包围（对使用集合无效），关于列表和集合的区别，可以参考下面的博客。

SDC命令详解：使用集合(Collection)而不是字符串(String)/列表(List)作为命令参数https://chenzhang.blog.csdn.net/article/details/147144571如果对象是时钟，则不确定度会直接被指定在时钟上；如果对象是端口，则所有经过该端口的时钟会被指定时钟不确定度；如果对象是引脚，则所有经过该引脚的所有时钟会被指定时钟不确定度。注意这三者是可以相互覆盖的，即如果如果一个时钟的时钟不确定度为0.5，但其定义在一个时钟不确定度为0.4端口上，则最终到达触发器的时钟引脚的时钟不确定度则为0.4；如果触发器的时钟引脚定义了一个0.3的时钟不确定度，则不论其他定义如何，这个触发器的时钟不确定度一定是0.3。

如果指定的对象是一个组合逻辑叶单元的引脚，则该引脚所属的叶单元会被设置size only属性，确保其不会在综合过程中被优化掉（需要注意的是，此时的size_only属性是隐式设置的，这与使用set_size_only命令显式设置不同，无法使用report_attribute命令或get_attribute命令直接查看，也无法使用查询命令的-filter选项过滤，而只能使用report_cell命令或report_size_only命令间接查看，隐式size_only属性的优先级高于显式size_only属性），使用list_size_only_types命令可以列出叶单元被设置size_only属性的原因（显式或隐式）。

下面是一些简单的使用示例。

#直接将时钟不确定度定义在时钟上 set_clock_uncertainty 0.2 [get_clocks clk1] #将时钟不确定度定义在时钟端口上 set_clock_uncertainty 0.3 [get_ports clk1] #将时钟不确定度定义在时钟引脚上 set_clock_uncertainty 0.4 [get_pins t_reg/CK]

在定义了时钟不确定度后，我们可以使用report_clock -skew命令查看所有定义了的时钟不确定度，如图1所示。

图1 时钟不确定度报告

可以从图中看出，定义了三个对象的时钟不确定度，t_reg/CK可以很明显看出是一个触发器的时钟引脚，而为什么会有两个clk1对象呢？其实答案很简单，这是两个同名的对象，但是其中一个是时钟本身，另一个是时钟端口。

最后顺带一提，如果重复对同一个对象定义了时钟不确定度，则最新定义会覆盖之前的定义。

时序分析中的时钟不确定度

目前为止，我们还没有接触时钟不确定度的具体作用，但我们已经可以定义简单的时钟不确定度了。时钟不确定度影响了所有使用此时钟的捕获触发器，使终点为该触发器的时序路径的时序裕度减少该不确定度值。下面我们通过一个简单的例子加深理解。

考虑两个触发器组成的简单结构，其中第一个触发器即发射触发器由clk1时钟控制，第二个触发器即捕获触发器由clk2时钟控制，有关发射触发器和捕获触发器的内容，可以看以往的文章静态时序分析：建立时间分析-CSDN博客，具体电路结构如图2所示。

图2 简单的例子

现在我们只研究从t_reg的时钟端到data_out_reg的数据输入端的时序路径。首先使用下面的命令在两个时钟端口上分别创建两个时钟对象。

create_clock -period 10 -waveform {5 10} [get_ports clk1] create_clock -period 10 -waveform {5 10} [get_ports clk2]

然后我们使用下面的命令，分别设置这两个时钟对象的时钟不确定度，在这里为了区分，设置的数值是不同的。

set_clock_uncertainty 0.1 [get_clocks clk1] set_clock_uncertainty 0.5 [get_clocks clk2]

最后我们使用report_timing命令给出建立时间时序报告，如图3所示。

图3 建立时间时序报告

从图3中可以看出，只有捕获时钟的时钟不确定度会影响相应的时序路径，而发射时钟的时钟不确定度则不会。捕获时钟clk2的时钟不确定度体现在了clock uncertainty这一项中，导致data required time减少了0.5，也就导致了最后的裕度(slack)减少了0.5。

对于保持时间的分析也是类似的，在此不进行赘述。

时钟间不确定度

上小节中使用对象列表定义的是普通的时钟不确定度，还有一种时钟不确定度称为时钟间不确定度(interclock uncertainty)。它是由-from\-rise_from\-fall_from选项之一与-to\-rise_to\-fall_to选项之一指定的。从BNF范式中可以看出，每次使用命令时，普通的时钟不确定度和时钟间不确定度只能选择其一，但一个时钟可以同时拥有普通的时钟不确定度和时钟间不确定度。

时钟间不确定度，不仅使用-from\-rise_from\-fall_from指定了发射时钟，还使用-to\-rise_to\-fall_to指定了捕获时钟。-from指定了发射时钟的上升和下降沿，-rise_from\-fall_from指定了发射时钟的上升或下降沿；-to指定了捕获时钟的上升和下降沿，-rise_to\-fall_to指定了捕获时钟的上升或下降沿。两组选项之间可以任意搭配，比如-from与-fall_to，-fall_from与-rise_to等...

注意，这里的上升、下降沿指的是时钟对象本身的上升、下降沿，而不是到达各触发器时钟引脚的上升、下降沿（这里要考虑时钟在时钟路径上传播时可能因为单元的单调性出现翻转）。

下面来看一个实例，在图2例子的基础上，我们使用下面的命令创建一个从clk1到clk2的时钟间延迟。

set_clock_uncertainty 0.8 -from [get_clocks clk1] -to [get_clocks clk2]

使用report_clock -skew命令报告所有的时钟不确定度，如图4所示。

图4 时钟不确定度报告

我们会发现，普通的时钟不确定度和时钟间不确定度可能会发生冲突，比如图4中clk1到clk2的时钟间不确定度是0.8而clk2的普通时钟不确定度是0.5。在发生冲突时，以时钟间不确定度为准，即在分析从clk1到clk2的时序路径时，以0.8作为不确定度，如图5的时序报告所示。

图5 建立时间时序报告

在上例的基础上，如果再使用下面的命令，则会将已设置的时钟间不确定度分成四份（因为此时这四份不确定度不再统一），分别对应发射时钟的上升\下降沿到捕获时钟的上升\下降沿的时钟间不确定度，如图6所示，其中r代表上升沿，f代表下降沿。

set_clock_uncertainty 0.4 -fall_from [get_clocks clk1] -rise_to [get_clocks clk2]

图6 四份时钟间不确定度

建立/保持时间

到这里为止，我们讨论的不确定度的设置都是同时针对建立时间检查和保持时间检查，从上面的图中也可以看到这一点，即Plus\Hold Uncertainty和Setup\Minus Uncertainty被设置为相同的值。

使用-setup和-hold，可以指定时钟不确定度只设置给建立时间或保持时间（默认情况下，时钟不确定度同时设置给建立时间和保持时间）。顺带一提，这两个选项可以同时指定，此时和默认情况一致。

例如可以使用下面的命令，更改clk2的保持时间的时钟不确定度，如图7所示。

set_clock_uncertainty -hold 1.0 [get_clocks clk2]

图7 更改了clk2的保持时钟不确定度

对于建立时间检查来说，发射时钟和捕获时钟同时收到时钟抖动和时钟偏差影响；而对于保持时间检查，一般只受到时钟偏差的影响，因为保持时间检查在同一个时钟沿进行（前提是只有一个时钟域的简单情况），所以建议设置保持时间的不确定度小于建立时间的不确定度。

Multicorner-Multimode支持

该命令仅对当前场景生效，换句话说只能在当前场景指定时钟周期的不确定性。

关于场景的更多介绍，可以参考下面的博客。

Design Compiler：多工艺角和多工作模式(Multicorner-Multimode, MCMM)https://blog.csdn.net/weixin_45791458/article/details/149578771?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522e3267dcc7cc26380435f53994dc8b9b8%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=e3267dcc7cc26380435f53994dc8b9b8&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~rank_v31_ecpm-1-149578771-null-null.nonecase&utm_term=MCMM&spm=1018.2226.3001.4450

写在最后

传统流程中将时钟抖动包含在时钟不确定度之中，使用set_clock_uncertainty命令进行约束，但就像文章中说的那样进行较多人为干预，包括时钟树综合前/后以及建立/保持时间的区别。

更正确的方式是使用单独的set_clock_jitter命令进行更加精确的设置，它可以设置cycle clock jitter和duty-cycle clock jitter并且可以自动处理建立/保持时间的区别。