隨著數(shù)字化設(shè)計和SoC的日益復(fù)雜，復(fù)位架構(gòu)也變得非常復(fù)雜。在實施如此復(fù)雜的架構(gòu)時，設(shè)計人員往往會犯一些低級錯誤，這些錯誤可能會導(dǎo)致亞穩(wěn)態(tài)、干擾或其他系統(tǒng)功能故障。本文討論了一些復(fù)位設(shè)計的基本的結(jié)構(gòu)性問題。在每個問題的最后，都提出了一些解決方案。
設(shè)計中的同步復(fù)位問題
1. 問題(I)
在許多地方，設(shè)計人員在時鐘方面喜歡同步復(fù)位設(shè)計。原因可能是為了節(jié)省一些芯片面積(帶有異步復(fù)位輸入的觸發(fā)器比任何不可復(fù)位觸發(fā)器都大)或讓系統(tǒng)與時鐘完全同步，也可能有一些其他原因。對于此類設(shè)計，當(dāng)復(fù)位源被斷言時需要向設(shè)計的觸發(fā)器提供時鐘，否則，這些觸發(fā)器可能會在一段時間內(nèi)都不進行初始化。但當(dāng)該模塊被插入一個系統(tǒng)時，系統(tǒng)設(shè)計人員可能選擇在復(fù)位階段禁用其時鐘(如果在一開始不需要激活該模塊)，以節(jié)省整個系統(tǒng)的動態(tài)功耗。因此，該模塊甚至在復(fù)位去斷言后一段時間內(nèi)都不進行初始化。如果該模塊的任何輸出直接在系統(tǒng)中使用，那么將捕獲未初始化和未知的值(X)，這可能會導(dǎo)致系統(tǒng)功能故障。
圖9:同步復(fù)位問題時序圖
2. 解決方案
在復(fù)位階段啟用該模塊的時鐘且持續(xù)最短的時間，使該模塊內(nèi)的所有觸發(fā)器都在復(fù)位過程中被初始化。 當(dāng)系統(tǒng)復(fù)位被去斷言時，模塊輸出不會有任何未初始化的值。
圖10:同步復(fù)位問題已解決
3. 問題(II)
在時鐘域交叉路徑使用兩個觸發(fā)同步器是常見做法。然而，有時設(shè)計人員對這些觸發(fā)器使用同步復(fù)位。相同的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合成后，上面的代碼會在雙觸發(fā)器同步器的同步鏈中引入組合邏輯，這會帶來風(fēng)險，并縮短sync2觸發(fā)器輸入進入亞穩(wěn)態(tài)的時間。
圖11:同步復(fù)位問題2
2. 解決方案
可用以下方式編寫RTL代碼，以避免同步鏈的組合邏輯。
always @(posedge clk )
if(!sync_rst_b) begin
sync1 <= 1'b0;
end
else begin
sync1 <= async_in; sync2 <= sync1
end
在上面的代碼中，對sync2觸發(fā)器不使用復(fù)位，因此在同步鏈中不會實現(xiàn)組合信元。然而，需要注意sync2需要一個額外的周期才能復(fù)位，這不應(yīng)導(dǎo)致設(shè)計出現(xiàn)任何問題。
