【STA】理解Timing Exception

理解Timing Exception

真的很好理解！😊

Exception即例外，顾名思义，在常规的计算方式外，允许用户根据实际情况，对某些timing path进行更加严格或者宽松的检查。

一、set_false_path

宽松的极限：取消检查

例1.1 Non-functional

正常情况下，两个触发器间会有一条timing path

但是由于两个MUX的选择信号相同，所以实际上不会发生同时经过第一个MUX的0端，和第二个MUX的1端的数据传输
我们可以告诉STA工具，不检查这条路径，给EDA减轻负担：
set_false_path -from [get_pins ff1/C] -to [get_pins ff2/D]
指名path的from pin 和 to pin，也就是timing report中所展示path的source以及destination
回忆下我们将其false_path掉的原因，本质上是因为先后穿过两个MUX端（下图红圈）的情况实际上不存在

所以还有另外一种更好的写法：
set_false_path -through [get_pins MUX1/A] -through [get_pins MUX2/B]
波及path可能会很多，写时需谨慎

例1.2 Cross clock

想象一下，一条FF-to-FF的path，两个触发器的clock是不同的，即跨时钟域
如果用户使用了同步器或者其他啥的方法（我不了解），反正用户认为不需要对这条path进行时序检查
如果只想false_path掉这一条，参照上例的第一种写法

如果是跨时钟域的全都不想要：
set_false_path -from [get_clocks clk1] -to [get_clocks clk2]
如果还想去掉从clk2到clk1的，还需要再写一条：
set_false_path -from [get_clocks clk2] -to [get_clocks clk1]
（-through不支持使用get_clocks）

这与上例使用set_false_path的原因不同，为此，有一种新的约束来处理这种情况：
set_clock_groups -asynchronous -group clk1 -group clk2
一个顶俩，表明对于这种跨时钟域的路径都无需检查了
（这里使用了-asynchronous来表明跨时钟域的状况，也就是说set_clock_groups还有其他参数，使用场景不仅于此，这里就先不展开啦）

例1.3 Protocol-based

书中提到这样一种情况，基于某种协议，slave和master可以双向传输数据（下图都是双箭头），而slave之间不进行传输。
然而实际电路上slave间存在通路，sta会产生slave-to-slave（through master）的path

例1.4 Combinational loop

这其实并不是set_false_path的应用，但是可以对比着理解，于是同列在此处。上个视频（STA/Timing Report/Slack计算/part2）提到过的，这里不再赘述。
STA工具必须断掉这个loop（绿圈）的任意一条边，才能做分析
不同的工具做法未必一致，重要的是未必符合用户预期，如果断掉BC路径上的任意一边（红线），会导致BC间没有path

如果用户希望保留BC路径，则需要断掉其余部分的某个边
若不改动器件间的连接关系（功能上用户需要这个环），用户希望仅使用sdc来调整sta，只有一个选择：断掉或门内部的连接（蓝线）
set_disable_timing from IN2 -to Z [get_cells I1]

与set_false_path相比，这样直接断破坏力更大

二、set_multicycle_path

在原本已经选定的最严格的边沿的基础上，移动边沿，改变Required Time，从而改变slack

例2.1

正常情况下，STA工具的setup check会选择的边沿，如下图所示

但是在这个例子中，由于clock enable只在每两个周期为1（红三角标注有效边沿），也就是说launch ff 每两个周期才发送一次数据，capture ff也只需要每两个周期接受一次数据

所以setup check比实际情况要严格（over constrained），hold check与实际相符。用户可以以周期为单位去调整边沿：
set_multicycle_path 2 -from [get_pins ff1/C] -to [get_pins ff2/D] -setup
其中， 2表示每两个周期接收一次数据。-setup可以省略，在不指定-hold时默认-setup
capture edge将会后移一个destination clock的周期（下图从2ns移动到4ns）

setup check与实际情况一致啦！

但是，此时hold的capture edge也会从0ns移动到了2ns，变得比实际情况更严格了
我们本意只想调整setup，但这条命令的效果是，hold的capture edge会跟着后移 n-1 个 destination clock的周期（n为setup后移周期数）

为什么会有这样的设计？
我认为是因为将setup后移只表示destination ff 每两个周期接收一次数据，工具默认你的launch ff没变，仍然是每个周期发送数据
那destination ff想要在4ns接收0ns发送的数据，那0ns发送的数据必须Hold到 2ns后，不然接收到的就是2ns时发送的数据了

现在我们需要将hold调回去，即将hold 的 capture edge 前移一个destination clock的周期：
set_multicycle_path 2 -from [get_pins ff1/C] -to [get_pins ff2/D] -hold -end
其中，当source clock和destination clock相同时，-end可以省略。-end的意思是指调整的是capture edge
放松hold，可以前移capture edge（-end），也可以后移launch edge（-start）。指定-hold时，默认是-start，其余默认-end。所以当source clock和destination clock不同时，必须加上-end，hold才能恢复原位

三、set_max_delay/set_min_delay

去除sdc中所定义clock的影响，直接定义data path的max/min delay。max delay 影响setup path，min delay影响hold path，完全对称，此处仅介绍max delay

例3.1

最简单的两个触发器相连的timing path，使用前后变化：
set_max_delay 3 -from [get_pins net0_reg/C] -to [get_pins net1_reg/D]

可以看到右图，slack已经不受时钟的影响了，即使改变时钟周期和波形，也不会影响最终的slack

例3.2 Combination

时钟变得可有可无了，所以对于纯组合逻辑，在无需定义虚拟时钟的情况下，可以直接加这个约束来进行时序检查

set_max_delay 3 -from [get_ports in] -to [get_ports out]

例3.3 Path segmentaion

只要讲述set_max/min_delay总是躲不开这个特性，前面提到的那些约束都没有的特性
允许from/to 不是正规的start/end point。很多工具会将用户指定的非常规的from作为一个新的start point，非常规的to作为新的end point
set_max_delay 3 -from [get_pins FD1/Q] -to [get_pins FD2/D]

Q端取代原本的C端成为了新的start point，注意是取代，而非增加，因为从start出发不可以再遇到start
还需注意的是，从clock point到Q端间的路径都不计入Arrival Time，将会导致clock skew更大
同理，to不是end point时，也会将to取代原本的end point

如何实现呢？建立新的start/end，必须解除其与原本start/end的连通关系，与断combinational loop类似，断掉任意一边就可实现，比如DFF/C变DFF/Q时，需断掉CQ间的连接

更多内容请参考Xilinx/ug903 Ch.5

四、参考资料

1.Xilinx/ug903-vivado-using-constraints
2.Constraining Designs for Synthesis and Timing Analysis