解復位就是復位撤離，系統解復位就是復位結束了系統準備開始工作。

前文咱們提過，復位撤離比復位要復雜一些，因為復位了大家就是一起回到初始狀態去，寄存器也不采樣了，有什么毛刺啊亞穩態啊只要不影響其他系統（這個之后講）都沒關系的。這就相當于晚上回家上床準備上床睡覺，你愛穿啥衣服睡就穿啥衣服不穿也沒人管。但是解復位就不一樣了，這就是起床要出門上班了，怎么著也得準備好才能出去工作，不能穿著秋褲就往外跑。

所以的對于解復位（其實也不光是解復位，局部復位本身也很危險）就需要做跟多的額外工作了，上一篇說的同步撤離之后，還有什么問題需要解決呢？

主要是復位信號到達各個寄存器的時間不一致的問題。復位信號在系統內是有很大的扇出的，連接到所有需要復位的寄存器的復位端。這也就導致了復位在系統中的走線特別長，過長的走線又會導致工具在復位信號上增加buffer以提升驅動能力，那么如果時鐘頻率很高，復位信號最終到達各個寄存器的時間也就無法保證在同一拍。

復位走線到達各個寄存器不在同一拍會有什么后果呢？這個不能一概而論。對于一些復位解除后就開始工作的電路系統比如自動計數取指模塊，各個寄存器之間可能存在依賴關系，如果只部分寄存器被復位或解復位，可能會導致不一致的狀態，從而影響系統的正確運行。同時呢，如果復位方案做的不好，某系統進行復位時一部分復位了一部分沒有復位，也可能會產生毛刺被未復位的寄存器采樣，進而輸出使能影響到其他系統的正常工作。

總之呢，復位走線到各個寄存器不在同一拍，可能存在系統穩定性的風險。因此在對復位還需要對系統的復位做一些特殊的處理。特殊的處理有哪些呢，不同的團隊也有多種多樣的選擇，這里列舉一些我所聽聞過的方案吧。

降頻后復位。

先把時鐘降頻，再進行復位和解復位的操作，再提頻回正常工作時鐘頻率。你不是怕復位走線到各個寄存器的時間不一致導致不在同一拍復位嗎？那好，我把時鐘降頻總可以吧，1GHz太快了降到500M，500M還快降到100M，100M還快到10M總可以了吧，一個周期這么長時間足夠你復位信號慢慢溜達到各個寄存器的。所以采用這種方案時，會在復位前將工作時鐘32分頻或者64分頻（取決于系統的面積和工作時鐘，可以算的），然后進行復位和解復位，之后在將時鐘提頻至工作狀態。

這種方案下，可以在sdc中將復位信號設置為multicycle，檢查其在64個時鐘周期內能夠作用到所有的寄存器復位端。

關時鐘后復位。

這個方法更徹底，怕各個寄存器看到復位和解復位的時間不一致導致功能錯亂？那直接把工作時鐘給關斷不久好了，反正是異步復位不用擔心沒有時鐘復位信號作用不到寄存器端。時鐘一關所有寄存器相當于原地停工，這個時候別說復位信號了，啥信號過來都沒事，寄存器都不干了嘛。所以此時復位信號的走線也就不稱問題了，先復位再慢慢悠悠的解復位，都搞定了歇一會再把時鐘打開。

這種方案下，可以在sdc中將復位信號設置為false_path，畢竟相當于準靜態的信號，工作時復位信號不會跳變。

復位保護。

這個方法的思路是，不是擔心我這塊的復位影響其他系統工作嘛，那么不去處理復位和時鐘，而是把系統裹起來。怎么裹起來呢，把所有的對外輸出使能啊、握手啊這類信號都先和低電平與在一起，保證不管一會發生啥事，都不會有關鍵信號發生跳變。保護好之后，再去拉復位信號，過一會再解復位，再等會時間等系統穩定下來了，再把保護電路解除開始正常工作。

這種方案下，也可以在sdc中將復位信號設置為false_path。

復位之后等待一定時間再開始下任務。

這個方案更多的是在任務層面看，也就是說面對解復位后可能存在的系統不穩定性，先不要著急下任務下配置下指令，而是等待一定時間等系統中可能存在的不穩定狀態都結束了，再開始進入工作模式去下任務。

當然了不是說所有系統都適用以上的方法，比如某個系統確實是解復位后就立即開始工作，那用復位保護就沒效果，因為你內部狀態都亂了保護其他系統還有啥用呢。所以說還是具體問題具體分析吧，以上也只是經驗之談難免有所疏漏。