Re: [問題] design compiler後counter(計數器)總是 …

看板Electronics作者 ( )時間14年前 (2010/08/19 21:42), 編輯推噓10(10056)
留言66則, 4人參與, 5年前最新討論串7/8 (看更多)
※ 引述《zxvc (眾生都是未來佛)》之銘言: : ※ 引述《zxvc (眾生都是未來佛)》之銘言: [恕刪] : 上面這一句話不正確。事實上DFT Compiler真的可以產生這種各clock domain : 各自串scan chain的方法。也就是這個指令: : set_scan_configuration -clock_mixing no_mix : (要配合這使用: : set_dft_configuration -fix_clock enable : ) : 然後DFT Compiler會幫不同的chain各自產生一個toplevel port, : 作為不同clock的輸入。 : 那些clock ports是要接到如測試機台的clock generator, : 也就是說在testing時,除頻的clock不是chip內部DFF除頻器產生的。 : 而這些clocks是用多工器接到原先 : functional mode circuit的clock pins上。 : 比如說有個DFF,在functional mode是用內部DFF除頻器作clock, : 在testing mode是用測試機台的clock,所以要用多工器去選。 : 所以說DFT Compiler並不是完全不能處理DFF除頻器。 您說的case是 Stuck at fault : 每條 scan 的 clk 是外灌的,當然不同chain就會有不同scan clk 而同一條 chain在 Shift In /Capture/Shift Out時, 都是用同一個外灌的 scan clk 基本上,這個case不會遇到太多麻煩... 但是at speed 的話 : 同一條 chain,在 shift in/shift out時,是用 scan clk (外灌的) 可是在launch/capture時,是用 normal clk 而一般 normal clk 大部份都用 PLL 除出來的 所以才會遇到麻煩... : : [1] Synopsys Inc., "DFT Compiler Scan User Guide," : : Version C-2009.06, July 2009. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.32.239.249

08/19 22:24, , 1F
之前我不太了解"at speed testing",現在再看一次Acme大的文
08/19 22:24, 1F

08/19 22:25, , 2F
章終於了解問題的所在。問題在funcational mode(也就是Acme大
08/19 22:25, 2F

08/19 22:28, , 3F
所謂的normal (mode)),internally generated clock可能會無
08/19 22:28, 3F

08/19 22:29, , 4F
法產生active edge,使得接到該generated clock的flip-flop
08/19 22:29, 4F

08/19 22:29, , 5F
無法capture。
08/19 22:29, 5F

08/19 22:32, , 6F
如果只給一個capture clock,頂多讓"除2 clock"會有active
08/19 22:32, 6F

08/19 22:32, , 7F
edge。
08/19 22:32, 7F

08/19 22:36, , 8F
雖然TetraMAX可以設定多個capture clocks,但上限只有10個。
08/19 22:36, 8F

08/19 22:41, , 9F
我前面有打錯字:funcational,應該是functional。
08/19 22:41, 9F

08/19 22:42, , 10F
謝謝Acme大。
08/19 22:42, 10F

08/19 22:51, , 11F
這一系列可以收精華區了
08/19 22:51, 11F

08/19 22:51, , 12F
不過,我剛才又想到,好像有解決的方法,只是我不知道
08/19 22:51, 12F

08/19 22:53, , 13F
DFT Compiler & TetraMAX支不支援。就是,在除頻clocks加Muxs
08/19 22:53, 13F

08/19 22:55, , 14F
。這些2-to-1 Mux一個source是接到functional mode的clocks,
08/19 22:55, 14F

08/19 22:55, , 15F
另一個source是接launch/capture訊號。
08/19 22:55, 15F

08/19 22:58, , 16F
抱歉,我上面忘了考量到scan clock。所以需要3-to-1 muxs。
08/19 22:58, 16F

08/19 22:59, , 17F
test_mode可能是兩個bits的port,比如00是functional mode,
08/19 22:59, 17F

08/19 23:00, , 18F
01是scan mode,10是launch/capture mode。
08/19 23:00, 18F

08/19 23:01, , 19F
不知這樣有沒有問題。
08/19 23:01, 19F

08/20 23:11, , 20F
不同chain可以有相同DFT clk,也可以同一chain混不同DFT
08/20 23:11, 20F

08/20 23:13, , 21F
clk,但要用 lockup latch之類的方式解決潛在的skew問題
08/20 23:13, 21F

08/20 23:14, , 22F
at-speed在capture時是用normal clock,此時並不限制
08/20 23:14, 22F

08/20 23:15, , 23F
normal clk 需為PLL,是generated clock 也不是不能作
08/20 23:15, 23F

08/20 23:17, , 24F
fixing clock 指的是讓它可 controllable
08/20 23:17, 24F

08/20 23:20, , 25F
以zxvc例子,10時,讓除頻clock能在capture_en時送出
08/20 23:20, 25F

08/20 23:21, , 26F
test procedure 能辨認的 clock pulse 即 可
08/20 23:21, 26F

08/20 23:23, , 27F
BTW,當clock tree fanouts 越大, generated clock 比起
08/20 23:23, 27F

08/20 23:24, , 28F
gated clock 會顯得缺點較多,又當chip要作ATPG的話
08/20 23:24, 28F

08/20 23:25, , 29F
ripple counter的好處都不存在了,反而顯得麻煩
08/20 23:25, 29F

08/20 23:26, , 30F
沒事不要用 ripple counter,除非不作ATPG
08/20 23:26, 30F

08/20 23:26, , 31F
也不作FPGA
08/20 23:26, 31F

08/21 12:02, , 32F
ViewMoon大,為什麼clock tree fanout愈大,generated clock
08/21 12:02, 32F

08/21 12:02, , 33F
會比gated clock缺點多?
08/21 12:02, 33F

08/21 13:26, , 34F
gating clock可以選擇在 clock tree 靠近 source 端作
08/21 13:26, 34F

08/21 13:27, , 35F
或靠近FF作(ICG),但generated clock只能選靠近source
08/21 13:27, 35F

08/21 13:28, , 36F
另外是因為generated clock FF/CK 不是 sink pin
08/21 13:28, 36F

08/21 13:29, , 37F
當fanout 太大造成latency很大時,APR有時怪怪的
08/21 13:29, 37F

08/21 13:32, , 38F
說真的,若是single phase design,generated clock 都可以
08/21 13:32, 38F

08/21 13:33, , 39F
簡單用 gated clock 取代, double phase design 也行
08/21 13:33, 39F

08/21 13:34, , 40F
只是麻煩多了,不然 FPGA 怎麼作...還好 synplify pro
08/21 13:34, 40F

08/21 13:35, , 41F
新版都有 support 這類轉換
08/21 13:35, 41F

08/21 14:21, , 42F
ViewMoon大上面所說的"怪怪"的是什麼問題?
08/21 14:21, 42F

08/21 15:08, , 43F
timing 無法滿足,有點像是APR放棄那個CTS了
08/21 15:08, 43F

08/21 15:23, , 44F
我之前也聽過這種說法,似乎用sync counter(也就是我之前一直
08/21 15:23, 44F

08/21 15:25, , 45F
所說的DFF除頻器)在APR時處理skew有點困難,只是不知原因為何
08/21 15:25, 45F

08/21 15:26, , 46F
,也不知道是否是tool能力限制的問題。
08/21 15:26, 46F

08/21 15:28, , 47F
那若改用PLL作除頻器會比較容易CTS嗎?原因為何?
08/21 15:28, 47F

08/21 16:01, , 48F
和 source clock / generated clock 有關, 和 source
08/21 16:01, 48F

08/21 16:02, , 49F
是否為 PLL 無關
08/21 16:02, 49F

08/21 16:03, , 50F
skew 部分, 可以去看 ICG 的好處, 大概就可以知道不用
08/21 16:03, 50F

08/21 16:04, , 51F
ICG 的壞處了, 不過我覺得 fanout F/F 若只有兩三千個的
08/21 16:04, 51F

08/21 16:04, , 52F
話, 應還不致於要使用到 ICG
08/21 16:04, 52F

08/21 16:36, , 53F
PLL作除頻器如前面我推文說的,指的應不是IC
08/21 16:36, 53F

08/21 16:36, , 54F
generated clock 若要和 source clock 同一 clock group
08/21 16:36, 54F

08/21 16:37, , 55F
應是確認它在同一 global clock, FPGA 用 PLL 作除頻
08/21 16:37, 55F

08/21 16:38, , 56F
也是可以,但請考量FPGA上的PLL是有限的,我覺得會有這種
08/21 16:38, 56F

08/21 16:39, , 57F
說法應是未正確設定成同一 clock group, 導致 FPGA 有
08/21 16:39, 57F

08/21 16:40, , 58F
skew 問題, 又找不出原因, 最後發現用PLL除頻解決了skew
08/21 16:40, 58F

08/21 16:40, , 59F
問題,才會有除頻用PLL比FF好的說法
08/21 16:40, 59F

08/21 16:41, , 60F
至於IC上,若2^N除頻明明用幾個FF就兜得出來的東西
08/21 16:41, 60F

08/21 16:42, , 61F
就不會想要用PLL去除頻了,因為,PLL cost也很高,power也高
08/21 16:42, 61F

08/23 08:11, , 62F
謝謝ViewMoon的回答。
08/23 08:11, 62F

08/13 19:02, , 63F
ICG 的壞處了, 不 https://noxiv.com
08/13 19:02, 63F

09/17 22:57, , 64F
timing 無法滿足 https://daxiv.com
09/17 22:57, 64F

11/11 15:55, , 65F
所謂的normal ( https://daxiv.com
11/11 15:55, 65F

01/04 22:12, 5年前 , 66F
所謂的normal ( https://noxiv.com
01/04 22:12, 66F
文章代碼(AID): #1CRJIwSq (Electronics)
討論串 (同標題文章)
本文引述了以下文章的的內容:
以下文章回應了本文
完整討論串 (本文為第 7 之 8 篇):
文章代碼(AID): #1CRJIwSq (Electronics)