前篇內容提到說,async reset有著打出glitch的風險,
但除了glitch之外,
如果reset deassert的時間點不對的話可是造出大量metastable的data,
直接導致function fail,
至於assert的時間點因為是async reset,所以何時出發Reg收到時都會立即返應,
只要reset 觸發的時間不要太短,給reg足夠的時間回復到預設值,
基本上assert時沒什麼需要注意的,
因此實際上當觸統觸發reset時基本上都會有個數T的時間.
先講一下最好理解的glitch
glitch的發生是ic運作過程中無法避免的,glitch的形成可能因為外部noise,driving vlotage不穩..,都是glitch的成因
如果async reset的架構下沒有做好Reset處理,當reset path上出現glitch時就會直接讓reg當前的data被洗掉,因為不預期的reset trigger瞬間function fail
對於一般操作時的assert來說
rst觸發的時機點來說沒有規定要何時才能觸發,觸發後Reg就會回到預設值上,
觸發時間夠長都不會造成甚麼risk,觸發時間太短則會讓reg內的訊號來不及回覆至預設值
對於deassert來說
釋放的時間點格外重要,
如果釋放的時候剛好落於reg clk的valid edge會因為data沒有在setup time check point前達到stable的狀態導致setup time violation (matastable的成因),
簡單說,reset的釋放也像是data path一樣必須被check,
對於在約束reset釋放時間點的則是稱為recovery time和removal time
下一篇來介紹一下recovery time和removal time以及怎麼預防async reset的glitch
<note.>
reset assert -> reset功能被觸發,根據reset是high active或low active決定assert的vaule
reset deassert -> reset被放掉,電路從reset vaule回復到normal function
你知道,
除了noise造出的glitch外,chip運算過程中也會有大量的glitch產出嗎
我們一般reg在運作時要怎麼避免glitch的干擾
..
