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

看板Electronics作者 ( )時間13年前 (2010/08/19 21:42), 編輯推噓10(10推 0噓 56→)
留言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
‣ 更多 Acme 的文章
文章代碼(AID): #1CRJIwSq (Electronics)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 7 之 8 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共8篇)
‣ 更多 Acme 的文章
文章代碼(AID): #1CRJIwSq (Electronics)