数字IC时序约束的一些注意事项

问题1：一个时钟的上升和下降，用create_clock约束和用set_clock_latency约束有啥区别？

图1是两个时钟，clkA和clkB，系统要求两时钟同频不同相。clkA比clkB的相位晚20ns。

假设它们的周期都是100ns。用传统的create_clock表示两个时钟，如下：

如果用clock latency来说明相同的相位关系，代码如下：

上述两种表达有啥区别？

第一种表达，DC工具认为：如果clkB在0ns处的上升沿作为launch，则clkA在20ns处的上升沿就可以作为capture。工具不对两个时钟做时钟树平衡（PR视角），或者认为它们在理想情况下本来就是不对齐的（DC视角）。

第二种表达，DC工具认为：尽管clkA比clkB晚20ns，在线路内部，clkB会被额外插入20ns，使得clkA和clkB沿对齐。所以，如果clkB在第0ns处的上升沿作为launch，则clkA在20ns处的上升沿不能作为capture，因为工具认为它们是同一个沿。工具会对两个时钟做时钟树平衡（PR视角），或者单纯认为两者就是对齐的（DC视角）。

拓展知识：

如果RTL的时钟上人为插入了一个delay，请问在DC综合和STA分析时，这个delay会被考虑进去吗？

答：不会。因为在DC中，时钟被作为理想线，不进行时序分析，当然也不计算这个delay。所以要想让工具把该delay考虑进去，在create_clock时就要特意给它加个delay。但是，有一点。如果是工具自己分析的delay，它会考虑很多因素，比如输入的trans，输出的load，但你人为加delay，没有工具考虑得那么周全，所以并不准确，只能是凑合这么用，等到PR后再分析。

上述知识，不论是相位差，还是时钟树delay，都说明的同样的问题，即DC阶段不搞时钟树平衡，也不分析时钟网络延迟，所以你在时钟上插buffer，STA结果不显示效果。但是，DC会认为create_clock上对齐的时钟就是平衡的，即便后面有set_clock_latency，它也认为是平衡的。它认为，后续PR阶段一定会把它们搞平衡，它先按时钟平衡来分析。如果create_clock的两个时钟不对齐，那就是天然不平衡，DC不会认为它们平衡，PR时也不会将它们搞平衡，它会把有延迟的两个时钟沿当作一个是launch，另一个是capture。

--------------------------------------------------------------------------------------------------------

问题2：一个输入信号，既当普通信号，又当时钟，那它当普通信号线时，约束set_input_delay用什么驱动时钟？

如果在sdc中将信号A声明为时钟，又把它当普通信号，那么在片外，即set_input_delay声明时，可将A本身作为A的驱动时钟。

这与我们的习惯不符，因为我们习惯一个信号A的驱动时钟是另一个时钟，所以我们经常会声明一个频率更快的虚拟时钟来驱动A。但是，声明虚拟时钟存在一个问题，它分析A的时候，A上升和A下降它都分析，因为对于数据来说，上升和下降都有可能，无法确定。但实际上，对于一些情况，我们能确定A在某个时刻就是上升的，不需要讨论下降的情况，同样，我们确定某一时刻它就是下降的，不需要讨论它上升的情况。

如果用A本身来驱动A，就是你规定A时钟上升它就只分析上升，规定A时钟下降它就只分析下降。没有多余的分析。

而且，这样做甚至不需要加-clock_fall选项，也能分析A下降的情况。它是自动跟踪的，A时钟上升，A信号就上升，A时钟下降，A信号就下降，不用多几句-clock_fall是否方便。

代码如下。代码中max和min都设为0，意思是让A完全跟着设定的A走，中间没有延迟。当然不会有延迟，因为A就是A本身。

--------------------------------------------------------------------------------------------------------

问题3：set_input_delay和set_output_delay里，选项-clock_fall，说的是时钟下降沿采样。是指设计内部的DFF为下降沿采样，还是指设计外部的DFF为下降沿采样？

答：外部，即假想的在设计外面存在DFF情况下，它用什么沿来采。设计内部的情况不需要你告诉工具，工具自己清楚得很。

--------------------------------------------------------------------------------------------------------

问题4：经常在set_input_delay和set_output_delay里见到-max选项，规定延迟的最大值，那是不是说，延迟的最小值不用规定了，默认是0？

答：不是。如果没有-min约束，工具不会自动认为-min为0，而是认为没有规定，不报错误。当你让它报告min的时序时，它说路径没约束。所以max和min都得写上，不知道写啥，那-min就写0，一定要写上。

--------------------------------------------------------------------------------------------------------

问题5：能否举个例子，证明set_clock_latency和set_clock_latency -source之间的不同？

答：可以。不加-source，说明是设计内部的时钟延迟，在PR之后，这个规定就没意义了，要去掉。而加-source时，说明延迟来自设计之外，PR工具也不知道延迟是多少，PR时以及PR后，这个-source的数值在STA当中也是有用的。PR工具会根据-source的值，来决定在时钟端口上加多少延迟，以便让时钟树能够平衡。

这里举个例子，当用-source声明时钟延迟为19.969ns后，这个时钟的路径是先延迟19.969ns，然后经过pad，pad又给它延迟了19.956ns。这与我设置source延迟的初衷不符，我设这个就是为了虚拟一个pad延迟，但是没虚拟成功，反倒经过了2次延迟。所以，source声明的值，工具会认为完全在设计之外，跟设计内部的延迟无关。分析时，先把source延迟做完，然后再做内部的延迟。

下面，我们将-source选项去掉，结果如图4所示。只在pad上进行了一次延迟，时间为19.969ns，那么我声明的clock_latency怎么没体现呢？本来就不应该体现，因为这里我的时钟是当数据用的，clock_latency只管时钟本身，不管数据。

总结：信号A既当时钟，又当数据，且A来自一个pad。设置A的clock_latency为x，用来模拟pad的延迟，不加source。pad本身并不是确切的x，我们定为y。则，当A作为数据分析时，经过的pad路径延迟是y。当A作为时钟分析时，经过的pad路径延迟为x。而如果设置A的clock_latency为x时加了-source选项，则，当A作为数据分析时，经过的pad路径延迟为（x+y），这是错误的，当A作为时钟分析时，经过的pad路径延迟为x。

--------------------------------------------------------------------------------------------------------

问题6：如何告诉工具一个复杂的时钟波形？

答：我们平时看到的都是些简单地重复时钟，一旦时钟形状复杂古怪，就不知道怎么约束了。

其实，在create_clock里用-waveform选项一直写下去，就能构建一个复杂时钟。比如下例，规定上升沿和下降沿交错成对出现，以上升沿为始，下降沿为终，即可构造出一个复杂的时钟。

--------------------------------------------------------------------------------------------------------

问题7：sdc约束是否能按照最终网表中对象的实际名称进行约束？

答：不行。工具吃sdc的时候，还没综合呢，所以它认目标，比如pins, nets, DFF的名称，都跟最后网表中呈现的名称不一定一致。sdc约束时写的是一个介于RTL和最终网表之间的名称。

比如，某个信号，在RTL里叫abc，声明为：reg [3:0] abc。

它的第0位在网表里叫：abc_reg_0_

你在sdc里写adc_reg_0_，工具就不认，你必须写成abc_reg[0]，工具才认。我们说，abc_reg[0]这个名字，是介乎于abc和abc_reg_0_之间的一个名字。

另外，pin脚的名称在sdc上也不要固定。比如，abc_reg_0_是一个DFF，它综合后是从QN端输出信号的。

那么，在sdc中，我们约束一条路径的起点，用abc_reg[0]/QN行吗？工具能认吗？

答：工具不认。因为工具吃sdc时还不知道它会用哪种DFF，是Q输出还是QN输出。所以，我们一般就写成：abc_reg[0]/*，通配符，让工具自己找路径。

--------------------------------------------------------------------------------------------------------

问题8：一些约束，在sdc上写就能起效，在综合后写就无效，还是按照sdc的约束来分析的。

比如，set_multicycle_path，如果是综合后，你在命令行上补写，然后再report_timing，结果不变。很多约束只能在sdc上写，后来补是没用的。