hold多周期约束如下,约束含义为hold分析时发起时钟边沿往后移动2个周期(hold多周期约束时钟默认为start,即发起时钟) set_multicycle_path -hold -from [get_clocks clk1] 2 setup分析结果不受hold多周期的影响,requirement和slack不变。 hold分析结果,分析边沿对中clk1已移动了2个周期变为4ns,clk2的边沿不变,此...
hold分析在setup分析边沿变化,发起时钟clk1也同步向后移动2个周期,从0ns变为-4ns,又有自身的约束start向前移动2个周期,因为分析边沿还是0ns 4.3 慢时钟域到快时钟域 clk1和clk2的周期分别为6ns,23ns,占空比都是50%,都在0ns处有第一个上升沿,默认情况下setup/hold分析的边沿对如下,setup分析边沿对为0ns:2...
set_multicycle_path1-hold-from CLK1 -to CLK2 这样hold检查向后(左)移动(延迟)1个period,由于-hold默认移动launch_clk,也就是launch_clk向前(向右)移动了1个时钟周期(也可看做capture_clk向左移动了1个时钟周期),如下图(这种情景设置只适用于多周期采样,例如存在图中的使能信号Clock Enable): 补充:对于多...
简介:【芯片前端】所以说,一直以来我理解的set_multicycle_path -hold都是错的? 在前端设计中,对于放宽到多拍产生逻辑结果的运算路径,需要设置set_multicycle_path来放宽时序检查,加入要放宽到4拍检查的话,一般就是这样写(具体格式记不清了,大概是这个意思): set_multicycle_path -setup 4 -from xxx -to xxx...
总结:setup multicycle设成2,hold multicycle设成1,会让setup timing放宽1个周期(launch clock周期)的时序要求,而hold要求并没有放宽,也没有收紧,而是原地不动。 为了证明上文我说的,hold分析点如果不另加约束的话,它会跟着setup的约束而运动。我再增加一个实验。约束如下:我把对hold的约束注释掉,咱看看效果。
对于上述clk的周期为T=4ns,现在若只设置set_multicycle_path 2 -setup -from CLK1 -to CLK2后,由于hold检查比setup检查往左一个时钟周期,则要求数据到达触发器的时间范围为:[4ns+Th,8ns-Ts],此时由于数据采集每2个时钟周期一次,这样对于保持关系过于苛刻,实际数据可到达的时间范围是[0ns+Th,8ns-Ts]。所...
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检查时序报告 ...
总结:setup multicycle设成2,hold multicycle设成1,会让setup timing放宽1个周期(launch clock周期)的时序要求,而hold要求并没有放宽,也没有收紧,而是原地不动。 为了证明上文所说的:hold分析点如果不另加约束的话,它会跟着setup的约束而运动。我再增加一个实验。约束如下(图 10):我把对hold的约束注释掉,咱...
set_multicycle_path –from $from_list –to $to_list –hold <N-1> 深入讲解set_multicycle_path多周期约束---理论篇-CSDN博客 【皮特派聊硬件设计_4】set_multicycle_path约束方法_哔哩哔哩_bilibili setup不特别声明-start时 默认搭配end, 一定要记得设置参考的时钟(端点),比较明确!
图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...