|
作者: Arjun Pal Chowdhury,Neha Agarwal 隨著數字化設計和SoC的日益復雜，復位架構也變得非常復雜。在實施如此復雜的架構時，設計人員往往會犯一些低級錯誤，這些錯誤可能會導致亞穩態、干擾或其他系統功能故障。本文討論了一些復位設計的基本的結構性問題。在每個問題的最后，都提出了一些解決方案。 復位域交叉問題 1. 問題 在一個連續設計中，如果源寄存器的異步復位不同于目標寄存器的復位，并且在起點寄存器的復位斷言過程中目標寄存器的數據輸入發生異步變化，那么該路徑將被視為異步路徑，盡管源寄存器和目標寄存器都位于同一個時鐘域，在源寄存器的復位斷言過程中可能導致目標寄存器出現亞穩態。這被稱為復位域交叉，其中啟動和捕捉觸發的復位是不同的。 在這種情況下，C寄存器和A寄存器的起點異步復位斷言是不同的。在C寄存器復位斷言過程中而A觸發器沒有復位，如果A寄存器的輸入端有一些有效數據交易，那么C寄存器的起點異步復位斷言引起的異步變更可能導致目標A寄存器發生時序違規，從而可能產生亞穩態。 
圖1：復位域交叉問題。 在上面的時序圖中，當有一些有效數據交易通過C1進行時，rst_c_b獲得斷言，導致C1發生異步改變，w.r.t clk從而使QC1進入亞穩態，這可能導致設計發生功能故障。 2. 解決方案 * 使用異步復位、不可復位觸發器或D1觸發器POR。 * 如果復位源rst_c_b是同步的，那么則認為來自C_CLR --> Q的用于從rst_c_b_reg -->C_CLR-->C_Q1-->C1-->A_D進行設置保持檢查的時序弧能夠避免設計亞穩態。然而，通常在默認情況下 C_CLR-->Q時序弧在庫中不啟用，需要在定時分析過程中明確啟用。 * 在目的地(A)使用雙觸發器同步器，以避免設計中發生亞穩態傳播。然而，設計人員應確保安裝兩個觸發器引入的延遲不會影響預期功能。 由于組合環路導致復位源干擾 1. 問題 在SoC 中，全局系統復位在設備中組合了軟件或硬件生成的各種復位源。LVD復位、看門狗復位、調試復位、軟件復位、時鐘丟失復位是導致全局系統復位斷言的一些示例。 然而，如果由于任何復位源導致的全局復位斷言是完全異步的，且復位發生源邏輯被全局復位清零，那么設計中會產生組合環路，這會在該復位源產生干擾。組合路徑的傳播延遲會根據不同的流程、電壓或溫度以及干擾范圍而不同。如果設計中使用了組合信元用于復位斷言和去斷言，那么也會導致模擬中出現紊亂情況。這被視為設計人員的非常低級的錯誤。
圖2：復位源干擾(基本問題)。 在上圖中，當復位源SW_Q斷言時，會導致rst_b斷言，這是全局復位。現在，如果全局復位本身被用于清除 “SW_Q” 復位斷言，那么會在設計中在SW_Q輸出和全局復位時產生干擾。此外，在模擬中，這會導致紊亂情況，因為復位源斷言試圖通過該組合邏輯去斷言。 然而，如果復位源(SW_Q)在復位狀態機(觸發器的SET/CLR輸入)為全局復位斷言被異步使用，那么復位干擾可能能夠復位整個系統(通過斷言全局復位)，因為全局系統復位去斷言不僅僅與復位源去斷言相關。當該復位源(有干擾)被同步使用或在觸發器D輸入使用的情況下可能依然有一個問題。干擾范圍可能無法在至少一個周期內保持穩定，因此這不會被目標觸發器捕獲。此外，該復位源不能被用作任何電路的時鐘(除了脈沖捕捉電路)，因為它可能違反時鐘寬度。
圖3：復位源干擾(問題2)。 在上圖中，復位源SW_Q將出現干擾。雖然如果復位源SW_Q的干擾在某個觸發器被捕捉作為復位事件狀態(在S)或用于其他目的，全局復位輸出(rst_b)都沒有干擾，但它將導致時序違反/亞穩態，或根本不可能被捕獲。 2. 解決方案 * 設計人員永遠都不應犯下上述(圖2)低級錯誤。 * 如果復位實現如圖3所示，那么設計人員應保證復位源(在該示例中為SW_Q)總是在觸發器的SET/CLR輸入使用，而不在D或CLK使用。 * 解決這個問題的最好的方法是在復位狀態機中使用之前注冊該復位源。 雖然它將導致時鐘依靠全局復位斷言，但是無論如何，如果沒有時鐘，該內部復位(SW_Q)都不會斷言。請參見圖4。
圖4：解決方案1。 此外，用戶也可以擴展SW_Q斷言，然后再在設計中使用它，復位斷言與時鐘無關。 請參見圖5。
圖5：解決方案2。 復位路徑的組合邏輯 1. 問題(I) 如果組合邏輯輸入大約在同一時間發生變化，那么使用復位路徑中的組合邏輯可能產生干擾，這可能在設計中觸發虛假復位。下面是一個RTL代碼，它會在設計中意外復位。 assign module_a_rstb = !((slave_addr[7:0]==8'h02 & write_enable & (wdata[7:0]==00)) always @(posedge clk or negedge module_rst_b) if(!module_rst_b) data_q <= 1'b0; else data_q <= data_d; 在上面的示例中，slave_addr,write_enable和wdata改變它們的值 w.r.t system clock，使用靜態時序分析，設計人員可以保證在目標觸發器的設置時間窗口之前這些信號在一個時鐘周期內的穩定性。然而，在該示例中，這些信號直接用作觸發器的異步清零輸入。 因此，即使在特定的時間slave_addr[7:0]在邏輯上將其值從“00000110”改為“01100000”，但由于組合邏輯的傳播延遲(凈延遲和信元延遲)它可以用一個序列“00000110 --> 00000010 --> 00000000 --> 01000000 --> 01100000”生成過渡。 在這段時間里，salve_addr為“00000010”，如果wdata[7:0]始終為零且“write_enable” 已經被斷言，那么它將在module_rst_b創建一個無用脈沖，從而導致虛假復位。
圖6：復位路徑的組合邏輯。 2. 解決方案 首先注冊組合輸出，然后再將其用作復位源(如圖7所示)。
圖7：復位路徑的組合邏輯解決方案。 3. 問題(II) 在上面的示例中，復位路徑的組合邏輯解決方案并不完善。如果組合邏輯輸入大約在同一時間發生變化，那么它可能在設計中觸發虛假復位。然而，如果組合邏輯的輸入信號變化相互排斥，那么它可能不會引起任何設計問題。例如，測試模式和功能模式相互排斥。因此復位路徑的測試復用是有效的設計實踐。 然而，對于某些情況，變化相互排斥的靜態信號或信號可能會導致設計出現虛假復位觸發。下面的示例描述了此類設計可能出現問題。
圖8：復位路徑的組合邏輯（問題 2）。 在上面的示例中，多路復用結構用于復位路徑，同時進行RTL編碼。其中“mode” 是一個控制信號，不頻繁改變，而mode0_rst_b和mode_1_rst_b是兩個復位事件，然而在合成RTL時，在門控級它被分解成不同的復雜的組合(And-Or-Invert[AOI])信元。雖然在邏輯上它相當于一個多路復用器，但由于不同的信元和凈延遲，每當信號“mode”從 1-->0變化時，final_rst_b都會產生干擾。 4. 解決方案 * 在合成過程中在復位路徑保留多路復用結構，因為多路復用結構與其他組合邏輯相比易于產生干擾。MUX Pragma可以在編碼RTL時使用，這將有助于合成工具在復位路徑中保留任何多路復用器。 設計中的同步復位問題 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。 2. 解決方案 可用以下方式編寫RTL代碼，以避免同步鏈的組合邏輯。 always @(posedge clk ) if(!sync_rst_b) begin sync1 <= 1'b0; end else begin sync1 <= async_in; sync2 <= sync1 end 在上面的代碼中，對sync2觸發器不使用復位，因此在同步鏈中不會實現組合信元。然而，需要注意sync2需要一個額外的周期才能復位，這不應導致設計出現任何問題。 冗余復位同步器引起的問題 1. 問題 在使用多個異步時鐘的設計中，設計人員需要確保在目標寄存器使用的時鐘方面，異步復位的同步去斷言，否則可能導致目標觸發器發生時序違反，從而產生亞穩態。復位同步器被用來復位去斷言，與目標時鐘域同步。然而，只有在系統復位去斷言過程中有目標時鐘時才會發生復位去斷言時序違反。如果在復位去斷言時沒有時鐘，那么便不會有任何時序違反。因此，在設計多時鐘域模塊時，設計人員可以讓編譯時間選項繞過該模塊中的那些復位同步器，并讓系統集成商根據對該模塊的時鐘可用性決定是否需要使用復位同步器。 此外，如果系統時鐘和異步時鐘比非常高，冗余同步器甚至會造成設計功能性問題。下面描述了這個問題。
圖12：冗余同步器的問題。 在上面的設計中，去斷言與sys clk同步的系統復位被饋送到(mod_clk域)的復位同步器，然后在mod_clk域邏輯中使用該復位。讓我們假定sys clk : mod_clk的時鐘頻率比大于6:1。默認不啟用mod_clk，以節省動態功率。當用戶想要啟用mod_clk域邏輯的功能時，便啟用該時鐘。在啟用了該時鐘后，有兩個mod_clk周期的延遲，其中，由于復位同步器導致整個mod_clk域邏輯都處于復位狀態。在該階段，如果一些數據交易從sys clk域開始，將在mod_clk域丟失。 2. 解決方案 雖然這不是大問題，但有時會在客戶一端造成混淆，因為該延遲對客戶不可見。 因此消除混淆的更好的方式是： * 如果在全局復位去斷言過程中沒有時鐘，則在設計中繞過/刪除冗余復位同步器。 這當然會節省一定的門控數。 * 如果動態功耗不是問題，用戶可以在mod_clk域邏輯開始運作之前很長時間在啟動代碼選擇啟用mod_clk。 因此，復位去斷言將有足夠的時間傳播。 * 這也可以在軟件中處理，在任何有效操作之前啟用了mod_clk后，設置兩三個mod_clk周期的延遲。 由于罕見的時鐘路徑導致復位去斷言時序問題 1. 問題 設計的復位架構根據系統而不同。在一些安全關鍵設備中，整個復位狀態機在安全時鐘上工作，安全時鐘默認啟用。 該時鐘也被用作設備的默認系統時鐘。
圖13：罕見時鐘路徑的問題。 在上圖中，復位狀態機(R觸發器)在default_clk上工作。此外，在復位去斷言過程中，default_clk是sys clk的源。因此，在邏輯上，這兩個時鐘(clk1和clk2)在復位去斷言過程中同步。但是，由于clk1和clk2之間存在巨大的罕見路徑，因此很難平衡這兩個時鐘并視其為同步。 因此，滿足A觸發器的復位去斷言變得具有挑戰性。 2. 解決方案 異步對待clk1和clk2，并在A觸發器中使用復位之前放置復位同步器。現在需要從S2-->A滿足復位去斷言時序(見圖14)。這不應是個問題。
圖14：解決方案。 結束語 這部分主要專注于復位設計中的故障以及克服這些問題的可能的解決方案。然而，上述解決方案并非唯一的解決方案，也不普遍適用于所有設計。這些是一些通用的解決方案和建議的指導方針，在特殊情況下可能需要進行修改。在這些情況下，此類問題不僅導致功能故障，還會增加一些額外的調試時間和工作，從而增加執行周期時間。因此，設計人員需要在設計的早期階段考慮此類問題。 |
