（FPGA时序约束）set_multicycle_path详解

 1.定义

        和set_max_delay/set_min_delay一样属于时序例外的一种。

        时序例外在之前的文章中讲过，如果不去约束的话，可能会造成时序资源的浪费，不因该分析的分析了，不应该优化的优化了，不应该这么严格去分析的也这么严格的去分析了，跑这样的程序浪费电脑资源，同样也会增加运行时间。

        时序例外有几种：

        （1）set_false_path：直接设置不分析

        （2）set_max_delay/set_min_delay：直接覆盖默认requirement

        （3）set_case_analysis：设置pin或port为常数或特定跳变沿，相当于设置palse_path

        （4）set_multicycle_path：相对于源时钟或者目的时钟去调整requirement

        针对set_multicycle_path，其定义为：根据源时钟或目的时钟，通过修改路径requirement倍数，改变路径requirement，来放松该路径的setup或hold分析要求，以满足时序收敛。

        这里再解释一下什么是requirement，vivado工具默认进行的是单周期的时序分析，一般一条时序路径默认对应了一个requirement，是根据时钟周期来确定的，也就是一般情况下setup的requirement是一个时钟周期（默认单周期分析，当前时钟launch，下个时钟周期capture），hold的requirement就是0；

2.语法及说明

        set_multicycle_path <path_multiplier> [-setup|-hold] [-start|-end] [-from <start_point>] [-to <endpoint>] [-through <pins|cells|nets>]

        其中:

        [-setup|-hold]表明是调整建立时间的还是保持时间的；

        [-start|-end]表明是相对于源时钟还是相对于目的时钟来调整，setup默认对应-end，hold默认对应-start，如果要对应源时钟来调整setup，则使用-setup -start，hold同理，如果是两个时钟一致，则-end/-start没有区别，UG903里有一个官方的总结：

        上图中的Moves the launch edge和Moves the capture edge也正是set_multicycle_path的调整方式，就是挪动默认的发起沿和捕获沿， 无论是setup还是hold，requirement就是两个沿的时间差。

        但是这里需要注意的是，由于保持时间检查是在建立时间检查的基础上进行的，也就是说，得先确立一条路径的建立时间检查的发起沿和捕获沿，才能确认该路径的保持时间检查需求，这是因为，保持时间检查是为了确保两个事儿：

        （1）当前发起沿发送的数据，不被当前捕获沿之前的时钟沿所捕获

        （2）当前发起沿的下一个时钟沿发送的数据，不被当前捕获沿所捕获

        然后工具会去分析，以上两个关系中哪个情况比较恶劣，选最坏的哪个作为该路径的hold分析时钟沿基础，这是xilinx所有FPGA时序分析的基础，也比较关键。

        再回到主题，如果你只调了建立时间的multicycle，相当于发起沿或者捕获沿的位置变了，这时候，hold分析用的时钟沿关系就也变化了，所以，一般调整了setup的多周期路径，就得跟着调整hold的多周期路径。

3.举几个例子

        （1）相同时钟域下的多周期路径

        这种路径也是非常常见的一种多周期路径，默认情况下，静态时序分析工具（STA）会认定其建立与保持时间关系为：

        这也是在实际工程中比较常见的场景，此时可能由于DATAPATH过于复杂，导致数据无法在一个时钟周期内稳定下来，或者数据能在一个时钟周期内稳定下来，但是在几个时候周期后才会去使用它，这时候就需要用户去指示STA工具这是一条多周期的路径，需要以例外的方式处理它。

        0ns处为发起沿，4ns处为捕获沿，这是这条路径最差的建立时间关系，所以setup requirement就是4ns（一个时钟周期），在此基础上，衍生出两个hold关系（如前面所述），选其中最差的（两个一致），就是途中标hold的那个关系，两个时钟沿做差，结果为0，所以hold requirement就是0ns。 

        在上述基础上，给两个寄存器加上个CE（clock enable）信号，这个信号两个时钟周期拉高一次，也就是如下图所示的关系：

        这时候，如果还是按照上图中的关系去分析建立时间，会造成STA的资源浪费，应为没有必要让建立时间关系这么紧，实际上，建立时间关系可以放松到下一个时钟沿，也就可以如下设置多周期：

        set_multicycle_path -setup -end 2 -from <startpoint> -to <endpoint>

        其中2是path_multiplier，可以这么理解，setup是指定分析沿向指定方向移动path_multiplier-1个时钟周期，hold的path_multiplier是指定分析沿向指定方向移动path_multiplier个时钟周期。

        但是经过这么一调整，setup的requirement放松了，但是hold关系变了，变成下面的关系了：

        这样的hold关系是很难满足的，因为捕获沿后移，对应的捕获沿前一个时钟沿也相当于后移了，根据hold slack = data_arrive_time - require_time，而其中的require_time = capture_edge + clock_delay + hold_time，capture_edge变大了，slack为正的难度就变大了。

        所以这时候就需要再对hold的关系进行调整：

        set_multicycle_path 1 -hold -end -from <start_point> -to [end_point]

        这里的1代表，将hold分析中的目的时钟沿（由于使用了-end）向前移动1个时钟周期。

        这时候，setup和hold关系就变为：

        STA在以上的基础上去分析才是最优的。

        （2）同频不同相的两个不同时钟之间的多周期

        假设clk1和clk2周期相同为4ns，相位差0.3ns，如下所示：

        默认时序分析图如下：

        因为vivado会在两个时钟公共周期内取最差的一条来当作setup分析的基础，所里这里setup需求为0.3ns，这基本是不可能满足的，且在这种情况下hold分析的需求是-3.7ns，这个需求又是十分宽松的。所以需要通过多周期进行调整这些不合理：

        set_multicycle_path 2  -setup -from [get_clocks clk1] -to [get_clocks clk2]

        （3）慢时钟到快时钟

        假设clk1周期是clk2的三倍，默认关系如下：

        应调整为：

        set_multicycle_path 3 -setup -from <start_point> -to <end_point>

        set_multicycle_path 2 -hold -end -from <start_point> -to <end_point>

        调整之后：

        （4）快时钟到慢时钟

        假设clk2周期是clk1的3倍，默认关系如下：

        应调整为：

        set_multicycle_path -setup -start 3 -from <start_point> -to <end_point>

        set_multicycle_path -hold 2 -from <start_point> -to <end_point>

        调整之后：