深入浅出讲透set_multicycle_path，从此彻底掌握它

今天在跑 PR flow 后 debug timing 时，发现前端给的 constraint 中存在一点问题，若干地方的时序本可以设置 multicycle 的 path，给漏设了，直接影响工具对 design timing 的优化力度。因此，小编打算写一篇文章来介绍下 multicycle path 的概念和用法，同时也带领大家复习下 setup 和 hold 的时序检查机制。

通常情况下，两个同步的 reg 进行 timing check 时，组合逻辑的 delay 必须在一个时钟周期内到达，才能满足 setup 的时序。但在某些情况下，从一个寄存器输出到另外一个寄存器的 data 端需要不止一个 cycle 的时间，而且又不影响逻辑的功能。此时，我们可以将这样的 path 约束为 multicycle path。图 1 所示为一个 3cycle 的 multicycle path 的电路结构图和波形图。

因此，我们可以用下面的命令来定义约束：

create_clock -name CLKM -period 10 [get_ports CLKM]

set_multicycle_path 3 -setup -from [get_pins UFF0/Q] -to [get_pins UFF1/D]

setup 检查：

默认情况下，当 UFF0/CK 作为 launch clock 时（T=0ns 时），在 T=10ns 时 UFF1/CK 采集到前一级过来的数据。

图 1 multicycle path 下的 setup 时序检查

但是当我们通过以上的命令设置了 3 个 cycle 的 multicycle path 的约束之后，launch clk 的沿推到了 T=30ns。因此，两个寄存器之间那段组合逻辑的 delay 要求就放松到了近三个时间 cycle。这种情况下 setup 是比较容易满足的。对应的 setup 检查时序报告如下图 2 所示。

图 2 setup 检查时序报告

hold 检查：

默认情况下，hold 检查的沿应该是在 T=20ns 时刻（较 setup capture edge 早一个 cycle）。这种检查机制好不好呢？显然不好。为什么呢？（可以自己画波形，其实波形已经在图 3 中了）。从图中看到这样的 hold 检查方式，会导致 hold 可能过度悲观，很难满足 hold time 的要求。

图 3 multicycle path 下的 hold 时序检查

因此，我们需要像单 cycle check 的情况一样，即 hold 检查的沿应该和 launch clk 的 edge 一致（T=0 时刻）。这样我们的 hold time check 比较容易满足，也比较科学。那么如何实现这种想法呢？我们引进了如下约束命令：

set_multicycle_path 2 -hold -from [get_pins UFF0/Q] -to [get_pins UFF1/D]

这里面的数字 “2” 是指将默认的 hold check edge 往前推 2 个时钟周期，即从原来的 T=20ns 时刻往前移到 T=0ns 时刻。对应的 hold 时序检查报告如下图 4所示。

图 4 hold 检查时序报告

因此，在我们给设计写约束文件时（定义 multicycle path 时），需要同时定义如下命令：

set_multicycle_path N -setup -from [get_pins UFF0/Q] -to [get_pins UFF1/D]

set_multicycle_path N-1 -hold -from [get_pins UFF0/Q] -to [get_pins UFF1/D]

如果只定义了 - setup 3 而没有定义 - hold 时，工具 hold check 时， 默认的 clock edge 为 capture edge（setup timing check 时）前一个 cycle 的那个 edge。

到此小编已经介绍完了 set_multicycle_path 的概念，用法以及 setup hold time 的检查机制。本文用的例子是两个寄存器是被同一个 CLK 所驱动的。那如果两个寄存器是被不同的 clk 所驱动的，情况又是如何呢？这里我就不多啰嗦了，大家自己思考，必须学会举一反三。图 5 中的 setup check 和 hold check 对不对呢？

图 5 思考题波形图

原文链接：https://blog.csdn.net/weixin_37584728/article/details/117746704