今天在跑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时序检查报告如下图3所示。
图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 思考题波形图
联系客服
