set_multicycle_path语法说明【转载】

(转载）

（其实多看手册就知道原因了）

Q：多周期路径中的检查保持时间时刻,为什么默认是在建立时间检查的前一个cycle?请大家谈谈自己的理解。 如:Set_multicycle_path -setup 7 -to [whatever] 那么hold time 应该在7-1这个cycle检查,为什么?

A：

多周期路径中检查保持时间，如果你对建立时间设置多周期，那么保持时间检查就默认在前一建立时间，比如：
楼主所设定：
set_multicycle_path -setup 7 -to [whatever]
若一个周期为10ns，则此时数据到达触发器的时间范围应该是：[60+Th，70-Ts]
而至于为什么，一方面就是primetime等的默认，另外就是在检查单周期时，通常也是要求如此的，即要求数据在[Th，10-Ts]时间范围内到达。（Th表示保持时间，Ts表示建立时间）

但倘若你同时设定建立时间和保持时间都为多周期路径约束，那么延时范围就可以变大，如：
set_multicycle_path -setup 7 -to [clk]
set_multicycle_path -hold 6 -to [get_pins C_reg /D]
那么此时的保持时间检查就在Th时，而不是在60+Th时，而此时的arrival time的范围就变大了
是：[Th，70-Ts]
所以一般采用后者设定，这样多周期路径部分电路的优化范围就变大了。

重申一点：采用
set_multicycle_path -setup 7 -to [clk]
set_multicycle_path -hold 6 -to [get_pins C_reg/D]

这样多周期路径部分电路的优化范围确实变大了，但是会有亚稳态的潜在危险，所以要小心！

而只用：
set_multicycle_path -setup 7 -to [clk]
你又必须保证path_delay足够大，不会产生hold-time violation，DC几乎不可能做到这一点。

加register-enabling logic解决亚稳态

首先：
无论是单周期还是多周期，hold检查都默认为setup的前一个时钟。
你写了set_multicycle_path -setup 7 -to [clk]之后，dc何pt默认set_multicycle_path -hold 0 -to [get_pins C_reg/D]，如果你不写set_multicycle_path -hold 6 -to [get_pins C_reg/D]
其他的Harva 说得很详细了。
其次：
如richardhuang1 所说，加使能，在该采的时钟周期采数据。

Harva 和handsome说得很精彩,我帖一个synopsys的解释,大家共同学习.
set_multicycle_path and hold checks
-----------------------------------

Question:

I have a path that is set as multicycle path for the setup check. For some
reason, PrimeTime seems to be treating it as a multicycle path for hold time
checking as well. I'm using:

set_multicycle_path -setup 7 -to [whatever]

Why are the hold time checks multicycle?

Answer:

By default, if you specify 'set_multicycle_path -setup X', PrimeTime and
Design Compiler assume the datapath could change during any clock before
clock edge number X. To deal with this situation, PrimeTime and Design
Compiler implicitly add 'set_multicycle_path -hold 0 -to [whatever]'. This
positions the hold check one clock cycle before the setup check, effectively
constraining the path delay to be between X-1 and X clock cycles, or in
equation form:

X-1 cycles + T_hold < path delay (min)
                     path delay (max) < X cycles - T_setup

So by default the tools assume you want the path buffered up so that the
minimum change is > X-1 cycles.

This may not be the desired behavior. You can move the hold check back
towards the start of the multicycle period by specifying:

set_multicycle_path -hold X-1 -to [whatever]

In the above example, add

set_multicycle_path -hold 6 -to [whatever]

to the constraints and the hold check should occur on the desired edge. Note
that moving this check back requires the designer to handle possible
metastability. If the endpoint is a multi-bit signal, then you may need
to generate register-enabling logic to avoid clocking data before all of
it is valid.