設計中的同步復位問題

　　1. 問題（I）

　　在許多地方，設計人員在時鐘方面喜歡同步復位設計。原因可能是為了節省一些芯片面積（帶有異步復位輸入的觸發器比任何不可復位觸發器都大）或讓系統與時鐘完全同步，也可能有一些其他原因。對于此類設計，當復位源被斷言時需要向設計的觸發器提供時鐘，否則，這些觸發器可能會在一段時間內都不進行初始化。但當該模塊被插入一個系統時，系統設計人員可能選擇在復位階段禁用其時鐘（如果在一開始不需要激活該模塊），以節省整個系統的動態功耗。因此，該模塊甚至在復位去斷言后一段時間內都不進行初始化。如果該模塊的任何輸出直接在系統中使用，那么將捕獲未初始化和未知的值（X），這可能會導致系統功能故障。

　　圖9：同步復位問題時序圖

　　2. 解決方案

　　在復位階段啟用該模塊的時鐘且持續最短的時間，使該模塊內的所有觸發器都在復位過程中被初始化。 當系統復位被去斷言時，模塊輸出不會有任何未初始化的值。

　　圖10：同步復位問題已解決

　　3. 問題（II）

　　在時鐘域交叉路徑使用兩個觸發同步器是常見做法。然而，有時設計人員對這些觸發器使用同步復位。相同的RTL代碼是

　　always @（posedge clk ）

　　if（！sync_rst_b） begin

　　sync1 <= 1‘b0; sync2 <= 1’b0 ;

　　end

　　else begin

　　sync1 <= async_in; sync2 <= sync1

　　end

　　在硬件中進行了RTL合成后，上面的代碼會在雙觸發器同步器的同步鏈中引入組合邏輯，這會帶來風險，并縮短sync2觸發器輸入進入亞穩態的時間。

　　圖11：同步復位問題2

　　4. 解決方案

　　可用以下方式編寫RTL代碼，以避免同步鏈的組合邏輯。

　　always @（posedge clk ）

　　if（！sync_rst_b） begin

　　sync1 <= 1‘b0;

　　end

　　else begin

　　sync1 <= async_in; sync2 <= sync1

　　end

　　在上面的代碼中，對sync2觸發器不使用復位，因此在同步鏈中不會實現組合信元。然而，需要注意sync2需要一個額外的周期才能復位，這不應導致設計出現任何問題。