ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

sta工具是怎么进行setup/hold检查的

2026/8/13 13:07:17 拓冰建站 浏览量
sta工具是怎么进行setup/hold检查的

1.sta工具launch和capture沿配对

1.1配对规则

sta工具默认会做最严检查,就是保证launch clk的每个cycle都在launch不同的数据,capture能正确采样

sta工具在setup/hold检查时,要建立capture clk和launch clk的配对

在配对的过程中,是不考虑clk skew和jitter的【skew和jitter是在计算setup/hold slack时考虑】,配对的原则如下:

Setup检查的目的是:确保当前Launch沿(发起沿)发出的数据,能够“提前就位”并稳定足够长的时间,以便下一个Capture沿(捕获沿)能够正确无误地“读取”它。

那么工具在一个公共周期内,枚举每一个launch边沿和其后最近的capture边沿,并选择时间差最小的一对边沿做setup的配对

换句话说就是找所有launch clk之后最近的一个capture clk做检查

----每个launch clk之后都可以找到一个最近的capture 沿

----但是真正做配对的是 这些里面最小的那一组

Hold检查的目的:确保当前launch沿发出的数据,不会过快的到达,以至于干扰了前一个capture沿正在捕获的数据【落到了前一个capture沿的hold时间之内】

对于hold:工具在公共周期内,枚举所有可能的launch边沿和capture边沿,并选择时间小于等于launch clk边沿且最接近launch clk边沿的capture边沿的那一组做配对

----和setup沿配对一样,也是找间隔最小的那一组做配对

----为什么选择时间小于等于launch clk,而不能大于launch clk?

--------因为不考虑skew和jitter的ideal clk,capture clk大于launch clk的都用于寻找setup 配对沿

--------非ideal clk的情况下,实际hold check的capture 沿是可以比launch 沿晚的,工具会算上skew和jitter

上面两个规则对于同步时序检查都是ok的,无论是同频同向,同频不同向(常见是同频反向),快时钟到慢时钟;还是慢时钟到快时钟。

PT默认情况下完成了launch clk边沿和capture clk边沿的配对之后,如果使用set_multicycle_path -setup -start 改变launch沿,对应的hold检查的配对沿中launch沿也会相应的移动

使用 -setup -end改变capture 沿,对应的hold检查的配对沿中capture沿也会相应的移动

但是无论set_multicycle_path -hold -start还是 -end 只会影响改变hold自己的沿配对,不会影响到setup的沿配对

工具内部hold检查的边沿默认是基于setup检查的边沿派生出来的,所以改变setup的某一端,必然会导致hold的对应端也随之改变

1.2 几种常见的配对举例

1.2.1 同频反向的setup和hold

这种情况setup被称作半周期检查

hold是比较放松的,clk path给了0.5T的时间【不考虑skew和jitter】,这种ideal clk,hold检查是0.5T+Tco+Tdelay>T(hold)

1.2.2 慢时钟到快时钟

1.2.3 快时钟到慢时钟

2.setup检查的公式描述

setup检查的定义是capture到来之前,数据要稳定的最小时间

Setup检查的目的是:确保当前Launch沿(发起沿)发出的数据,能够“提前就位”并稳定足够长的时间,以便下一个Capture沿(捕获沿)能够正确无误地“读取”它。

T(launch)+T(co+comp)+T(setup) < T(capture)

T(setup)< T(capture)-T(launch)-T(co+comp)

sta工具pt会做最严的检查,就是要T(capture)-T(launch)最小,但是又不能为0【为0是物理不可实现的】

那么PT工具就会和T(launch)之后最近的一个T(capture)clk做setup检查

3.hold检查的公式描述

hold检查的定义是capture沿到来之后,数据要保持的最短时间

它的目的是确保当前launch沿发出的数据,不会过快的到达,以至于干扰了前一个capture沿正在捕获的数据【落到了前一个capture沿的hold时间之内】

----当前launch沿发出的数据,期望的capture沿是launch沿之后最近的那个capture沿,对应公式就是:

T(co+comp)) +T(launch_check_edge)-T(capture_ckeck_edge)>T(hold)

最严检查,就是要T(launch_check_edge)-T(capture_ckeck_edge)最小,也就是选择时间小于等于launch clk边沿且最接近launch clk边沿的capture边沿

这里的T(launch_check_edge)和T(capture_ckeck_edge)是已经配对的hold check检查沿

4.问题讨论

4.1 为什么不从一次完整的launch到capture过程来看,并用setup的配对沿来计算 hold check呢?

此时使用公式:

T(launch)+T(co+comp)+T(launch_clk_period) > T(capture)+T(hold)

T(hold)<T(launch)+T(launch_clk_period)-T(capture)+T(co+comp)

上面的公式在同频的同步电路或者快到慢时钟同步电路是没有问题的,结果和第3章的效果是一样的,但是在慢到快的hold检查就有问题,根源在于:

一条路径的数据流是L → C_setup → 等待下一个 L 周期再考虑 hold 风险。 相当于认为: 只需要保证:本次 L 发出的数据,至少维持有效直到本次 C_setup 沿。完全忽略中间存在其他 capture 采样沿的风险!

如上图所示,从setup的当前launch 沿向后推迟一个launch clk,然后和当前setup的capture clk沿做hold检查,这样就跳过了很多capture沿,导致找到的并不是符合hold check配对沿要求的沿。

4.2 hold检查的capture一定是setup的capture向前推一个时钟周期

需要注意有些人会认为,hold检查的capture一定是setup的capture向前推一个时钟周期

这种说法在同频的同步电路中是成立的,在launch和capture频率是倍数关系时不成立,如下图:

T0→T1是实际的setup检查配对沿

T1→T1是实际的hold检查配对沿

T1→T2不是setup的检查配对沿,只是普通的一对launch和capture沿,工具不会做T1->T2时刻的setup检查

那么T1→T1的hold检查配对沿的capture clk可以说是T2 captureclk前推一个周期,但不能说是setup的capture向前推一个时钟周期

但是对上图使用set_multicycle_path -setup改变setup的某一端,必然会导致hold的对应端也随之改变这个规则是适用的