今天在跑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 思考题波形图
联系客服