先前提到說,
對於reset如果沒有做好的話就有可能因為glitch造成function錯誤,
因此我們來談討一下reset相關的細節.
先複習一下對於reset來說總共有兩種type
- sync reset
- async reset
對於sync reset的架構來說先前文章有提到大致的差異
不過在這我們針對Reset出發對於這兩種不同類型的reg做另外一個層面的探討
sync reset : reset訊號作為data端的一部分
Din的訊號源 為input 和rst組成的Combination 電路,
所以在STA架構下, 我們reg是一級推一級的,
每兩個reg之間的timing path如果是為sync的 我們會利用STA的技術去保證
兩兩reg必須在1個cycle的clk內完成避免meta stable的問題
因此此時的Reset也作為data path的一環,
只要滿足了STA德check 我們就可以很肯定地說
所有reg 不會在reset 的assert或deassert的過程打出meta stable的問題
因為對於assert或Deassert來說
他會等到clk edge觸發時才把data抓近來 此時的Data作為combinational的一部分
早就被STA的sign off時保證了他必定滿足setup time和hold time.
因此不會看到reset 觸發所造成的meta stable
async reset : reset 訊號為獨立的port口 直接作用於reg的類比電路上
對於async reset的架構來說
data pin 和reset pin可以說是完全獨立的
因此data走data的 reset 走reset的
在我們reset assert時 data可以瞬間被設為預設值,
但在我們要把reset釋放時,如果剛好落在clk edge準備toggle的時候
因為data 端瞬間由於Reset釋放的變化回到了normal function的跳動
但並沒有完整的1個cycle讓他完成他的comb logic的運作
(我們STA所約束的都是1個cycle下)
此時由於可運作的時間單位變得更短更嚴苛了 就有可能沒辦法滿足我們STA給的限制
導致了meta stable的Data被打出,
因此 我們對於這種Data Reset 各自獨立運作的行為多給了他們一個約束
就是recovery time和removal time
recovery time : 對於clk edge 來之前 必須完成reset釋放, 避免logic在釋放後沒辦法達成setup time前的stable, 因此 recovery time 和sta的Setup time check其實是很像的東西只是目標改成check reset和clk的關係
removal time : 對於clk edge toggle後必須隔多久才能釋放, 避免logic在hold time check的時候就開始toggle, 因此Removal time和STA的hold time check很像, 也是改成在check reset 和clk
換句話說
recovery time 在保證reset deassert的時候 不能離clk trigger edge 前太近
removal time 在保證 reset deassert的時候 不能離clk trigger edge 後太近
在理解這個屬於reset 的timing check後
我們來想想一個問題
async reset的recovery time和removal time看起來相當重要
但是我們在synthesis的時候其實並不一定會去對他sign off
可能會拖到apr的階段才做check
但是這樣我們前面提了這麼多讓他融進STA的一環
以確保不會造成reg因為rst釋放又打出meta stable
但synthesis時又不考慮他
這樣我們synthesis的timing的check真的有效嗎?
...
..
這個問題其實相當有趣
實際上我們在做Synthesis的時候有個很常見的sdc
