[Verilog] 10分鐘把Reset處理好健康沒煩惱

前篇內容提到說,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的干擾

..