执行命令定义时出错_深入浅出SDC clock定义（下）| 合理正确的定义clock

前情提要

前面两次分别和大家一起学习了SDC的整体框架组成和clock定义的一部分内容。(如果想要查看可以点击下方蓝色链接)，从中可以看出，所有SDC构成中最基本的就是clock的定义，它作为所有SDC的基础，贯穿到几乎所有SDC指令当中。并且一再证明了，Clock正确定义的关键是，约束要符合design，这样才是工具认知跟design行为完全切合的根本条件。今天会继续跟大家一起探讨下clock定义中create_clock和create_generated_clock的不同点以及如果generate clock定义不合理会导致的一些基本问题，最后还会简单的跟大家学习下clock group的定义。

深入浅出SDC - 前序

深入浅出SDC - clock定义(上) 

Clock Latency简介

要探讨今天的主题，首先需要跟大家一起学习下clock latency这个基本概念。Clock latency通俗意义上是指clock定义点到clock sink point(时序器件的clock Pin)之间的这段延迟时间。其分为两类，其中一类为，source latency，另外一类是network latency。

source latency ：也称作insertion delay，通常是指clock source端到clock定义点之间的这段时间延迟；通常有两种情况，其一：clock 直接来自于芯片外部，如crystal clock，此时，source latency指的是芯片外部crystal出口到芯片PAD(假如clock定义在此处)之间的时间延迟；其二：clock 来自于芯片内部的PLL，此时，source latency指的是芯片内部PLL输出点到芯片内部某个第一个clock定义点之间的这段时间。

network latency：其指的是clock定义点到clock sink point之间的这段时间。

这两种latency是每一个clock的固有属性，当CTS完成之后，每一个clock如果是在propagation状态下，其source latency和network latency都是确定的。当然，在前期(PR之前或者CTS之前)，通常情况下clock都处于ideal状态，为了能够模拟真实的情况，我们可以通过指令set_clock_latency去指定每个clock的source latency或者network latency，具体此指令的用法，我们这里不详细解释了，有兴趣，有需要的可以自己去查阅相关资料。

         图1 clock latency 示例

create_clock和create_generated_clock的不同点简介

通常定义clock的方式有两种，create_clock和create_generated_clock。再上次有具体介绍过，这两个指令的使用(可参考深入浅出SDC - clock定义(上))。那么他们之间有哪些使用上的区别以及各自都有什么特点呢？大体总结如下：

• create_generated_clock能够继承其master clock phase，换句话说：generate clock的边沿(rise or fall)是通过继承master clock得到的。

• create_generated_clock能够继承其master clock的source latency。

• 通常情况下，create_clock的source latency为0.(在不特殊指定的情况下)

• 每当设置一个create_clock，通常CTS时会构建一个新的clock domain。

Generate clock定义出错引入的clock edge识别出错

在上次，我们通过多个例子，分类说明了，如果generate clock定义不合理，会误导工具做出错误的timing分析的各种情形(可参考深入浅出SDC - clock定义(上))。但是具体工具timing分析会是什么样的呢？

图2 错误的定义generate clock示例

如图2所示，如果直接在u_ckdiv2/Q点上，使用-divide_by 2 –master_clock clk的方式定义generate clock，那么工具认为的Q点的波形会是图2中右图所示的情况。这其实是与实际design的情况不符合的(假如DFF复位状态为0)。这时工具会认为的timing path check情况会如图3所示。从u_ff1/CK到u_ff2/D，整个timing path周期只有半个clk cycle。

图3 错误的generate clock定义

如果我们能够正确的在Q-pin上定义generate clock，那么工具认为的Q-pin的波形会是图4中所示的情形。这时同样的timing path，从u_ff1/CK到u_ff2/D，工具做出的timing 分析会是图4中的情形。

图4 正确的generate clock定义

当然，通过上面这个例子，虽然clock定义不合理，但是错误的clock的定义，单从edge的传播来看，其实是加紧了对design的约束，可能会浪费一些PPA，但是不会让design最终因为timing出错。

Generate clock定义出错引入的latency计算出错

其实，除了上面分析提到的会影响工具正确的判断定义的generate clock的edge之外，还会可能影响到工具错误的计算clock的latency。

如图5中的情形，如果采用图5中(左，中，右)所示的定义方式，由于在mux的Z-pin上已经定义了generate clock gclk1，而在定义generate clock clk_div时，如果其master clock还指向了gclk1前面的一个clock-clk1，那么此时clock其实定义是不合理的。因为从clk_div往前追，看到的第一个clock是gclk1，而clk1被其打断了，其clock属性不能再正确的往后传播。

图5 错误的clock定义

也即上面提到的generate clock可以继承其master clock的source latency这个特性就不能正确的保持了，从而导致工具认为此处定义的generate clock的source latency将从0开始计算。如果此处的generate clock替换为create clock会是怎样的呢？大家可以思考一下。而如果想正确的继承master clock的source latency，那么此处，可以按照图5中右所示的方式定义clock。

Clock Group定义简介

上面提到create clock定义时，会伴随新的clock domain的创建，此时所提到的clock domain即指clock group。当然，clock group并不仅存在于create clock定义时，在generate clock定义时，也可以指定clock group。其主要目的是，人为的告诉工具，我们所定义的所有的clock之间的关系，从而减少工具自动化分析的情形，降低runtime，得到更好的PPA的结果。但是具体clock group怎么划分，是需要按照design架构决定的。我们在此处，先不会深究为什么要区分不同的clock group以及clock group划分的依据(后面其它系列文章中再做分析)，而是跟大家详细的解释下定义clock group的方法以及注意点。

如图6所示，定义clock group我们SDC中右一条指令其为set_clock_group，详细的解释在图6中都已经给出，但是个人觉得还是有必要针对-logically_exclusive/-physically_exclusive/-asynchronous这三个option具体的分情况说明一下。

图6 clock group定义

-logically_exclusive/-physically_exclusive/-asynchronous简介

Logically_exclusive : 其含义是指两组clock逻辑上不会同时存在。如图7中第2框图所示，虽然，clk1a/clk1b/clk2/clk3/clk4同时存在于整个design中，但是由于clock mux的select信号是相同的，所以从图中可以看出，S=1，此时前后两个mux分别选通clk2和clk4;如果S=0，则此时两个MUX分别选通clk1a/clk1b和clk3，也就是clk1a/clk1b/clk3和clk2/clk4是逻辑上不会同时存在的。所以他们之间就是logically_exclusive。

Physically_exclusive : 其含义是指两组clock之间物理上不会同时存在。如图7中第1框图所示。第一个clock mux中的clk1a和clk1b，这两个clock是来自于相同的path，同一时间，这两个clock物理上只有一个存在，所以他们便是physically_exlusive。

Asynchronous : 其含义是指两组clock之间功能上异步的。如图7中第3框图所示，clk1和clk2，在功能设计时便是采用的异步方式设计的，即clk2跟clk1之间完全不需要关心相位或者frequency之间的关系，功能上也是正确的，这时候这两个clock便是aysnchronous。当然aysnchronous的前提条件是design功能上要保证正确性。

图7 clock group定义示例

图7中，如果换成第4框图中的定义方式，跟第3框图中的定义方式会有什么异同点？这个大家可以自己思考一下…

敲黑板，划重点

在此再重复一下上次提到的两条基本原则，有助于分析clock定义是否合理。采用create_generated_clock定义的clock，其一：继承的mater clock的edge一定要正确；其二：跟master clock之间的实际通路一定要物理上存在，并且要通。总结起来就是，clock定义要按照实际design来定义，不能想当然，如果在不清楚如何使用option时，可以先手画波形图，然后按照图再去选择option的使用。

今天就跟大家先讨论到此，到现在，基本SDC中的clock定义部分就差不多介绍完了，当然还有clock的一些DRC约束该如何实现？定义完clock之后，其它SDC指令如何使用定义的clock？比如I/O delay约束、uncertainty等，我会在接下来继续跟大家一起学习….

Agenda：

• Clock 定义

  • create_clock

  • create_generated_clock

  • set_clock_groups

  • set_clock_latency

  • …

• I/O delay约束

  • set_input_delay

  • set_output_delay

  • set_max_delay

  • …

• Exceptions 定义

  • set_multicycle_path

  • set_false_path

  • set_case_analysis

  • set_sense

  • …

• DRC中的clock constraints

  • set_clock_uncertainty

  • set_propagated_clock

  • …

• DRC中的基本约束

  • set_max_transition

  • set_max_capacitance

  • set_max_fanout

  • …

• DRC中IO相关约束

  • set_input_transition

  • set_load

  • …

走过路过不要错过

分享转发或点击在看是对笔者最大的鼓励