为什么在 cts 过程中 func clock 和 scan clock 经常长不齐?

在数字后端 CTS 过程中,有时候会碰到这样一种情况:

只开 function scenario 来做cts,可以得到很 balance 的 tree,

但是一旦带上 scan scenario 去做 cts,就容易出现不balance。

首先说说为什么会出现这种现象:

假设一个design 中只有两个 function clock: clk1、clk2,如下图所示:

clk1 的 sink 点是 R1~R3

clk2 的 sink 点是 R4~R6

那么在cts时,clk1 和 clk2 就会单独长tree,各自内部长齐,

假设 clk1 的 clock latency 比较短,而 clk2 的clock latency 比较长,

由于所有的reg 都要串起来做成一条 scan chain,所以scan_clk 的sink点就是图中的 R1~R6,

又因为 R1~R3 的 clock latency 比 R4~R6 的clock latency 小很多,

所以在 scan scenario 下必然会有较大的skew。

那么这个问题该如何解决?

1) 只开 scan scenario 去做 cts,让所有的sink点都长齐,这种方法显然得不偿失,白白增加了大量的clock buffer,不可取

2) 只开 func  scenario 去做 cts,此时 clk1 和 clk2 两组clock 各自内部单独长齐,比较合理;但是在 scan mode 下,R3 与 R4 之间可能会有较大的 hold violation,这个问题可以参考这篇博文来解决: 如何使用 lockup latch 来修 hold violation 

|-------------------------------------------|

猜你喜欢

转载自www.cnblogs.com/xiaoxie2014/p/12503228.html