走近Timing Exception
1. 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
由于用户使用了同步器或者其他啥的方法（我不懂），反正用户认为不需要对这条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
一个顶俩，表明对于这种跨时钟域的路径都无需检查了
p.s. 这里使用了-asynchronous来表明跨时钟域的状况，也就是说set_clock_groups还有其他参数，使用场景不仅于此，这里就先不展开啦
例1.3 Protocol-based
书中提到这样一种情况，基于某种协议，slave和master可以双向传输数据（下图都是双箭头），而slave之间不进行传输。然而实际电路上slave间存在通路，sta会产生slave-to-slave（through master）的例子
例1.4 Combinational loop
这其实并不是set_false_path的应用，但是可以对比着理解，于是同列在此处
上个视频提到过的，这里不再赘述
STA工具必须这个loop（绿圈）的任意一条边，才能做分析。
不同的工具做法未必一致，重要的是未必符合用户预期，如果断掉BC路径上的任意一边（红线），会导致BC间没有path
如果用户希望保留BC路径，则需要断掉其余部分的某个边
若不改动器件间的连接关系，仅使用sdc完成，只有一个选择：断掉或门内部的连接（蓝线）
set_disable_timing from IN2 -to Z [get_cells I1]
与set_false_path不同，直接断的破坏力更大
2. set_multicycle_path
例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
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才能恢复原位。
一句话总结：在原本已经选择好的最严格的边沿的基础上，移动边沿，对slack的影响仅在于此
3. set_max_delay/set_min_delay
明天接着写，累死了
