跨異步本身呢是一種常見的信號處理，不過呢一旦處理不當就會引發多種電路危機，而這些電路危機大多與亞穩態有或多或少的關係。
亞穩態是我們老生常談的問題了，再來複習一下什麼是亞穩態呢。
在數字電路中信號處於非0非1、介於高低電平閾值之間未定義的狀態稱之爲亞穩態。由於數字電路的特點只有高低電平和高阻態能夠穩定存在，亞穩態會在0/1之間完全不確定的反覆震盪。理論上亞穩態可以在零噪聲場景下穩定維持，但是實際應用中不會存在零噪聲場景。
下圖來源百度百科侵刪。
在前端設計中我們主要關心的是觸發器亞穩態，當觸發器的輸入信號無法在亞穩態窗內保持穩定的可採樣的電平狀態時，那麼就進入了寄存器亞穩態，我們既無法預知最終的輸出電平也無法預知何時會穩定到最終的輸出電平上。亞穩態窗即由觸發器的建立時間和保持時間在時鐘上升沿左右定義的時間窗口，setup time + hold time即亞穩態窗的長度，亞穩態窗由器件本身物理屬性所決定一般來說工藝越新亞穩態窗會越短，但是更新的工藝並不意味着亞穩態的傳播會變短（這點我理解和電壓的關係更大，nm值越小越不能上高電壓否則會發生擊穿，電壓越低那麼穩定時間就會越長，這一點再問問後端大佬）。
亞穩態的危害是顯而易見的，在電路中直接使用可能存在亞穩態的信號可能會導致數字電路系統紊亂，比如計數器亂跳寄存器異常觸發等，而且亞穩態出發問題具有很大的概率性（概率公式就不列了，看着頭疼），這導致有限的測試時間內並不能保證發現問題，即使發現了問題也極難定位到亞穩態問題，只能說隱蔽性太高了（當然現在有了CDC工具，對於大部分跨異步亞穩態問題都能夠及時發現了）。
在這裏在順便說一下，我之前一直把亞穩態、X態和Z態混着記了。當然Z態最容易區分，是正常的高阻態（當然也不正常哈），一般只有在信號空接時候會出現。而X態呢主要是在驗證時候的概念，指的是信號的狀態未知但一定是某一確定的電平值或數值（對於多比特信號），比如說某一寄存器如果沒有寫入過數據也沒有進行過初始化操作，那麼在仿真時直接讀取出的就是X態，差態會在電路中蔓延造成不確定的結果，X態行爲是可以通過EDA驗證發現的關鍵信號也必須添加X態的檢查；亞穩態呢就是我們上面提到的那一大堆東西了，一般來說呢亞穩態問題或者其他的跨異步問題是無法通過功能仿真來發現的，因爲在功能仿真中時鐘是理想時鐘（當然可以設置隨機偏移一類屬性），時鐘採樣通過time-slot時間片的方式進行，setup time和hold time閾值均爲0即亞穩態窗不存在，那麼自然不可能觸發亞穩態問題。不過驗證技術始終在發展，現在是不是已經有能夠發現亞穩態問題的驗證方法可以提醒告知。
那麼要怎麼處理跨異步中的亞穩態，大家都知道要進行打拍。需要打幾拍呢？之前書上給的結論呢是打2拍就可以消除99%以上的亞穩態採樣概率，不過隨之工藝的進步尺寸減小電壓降低，2拍已經逐步管不住亞穩態傳播了；明確的說在7nm工藝時代，跨異步至少需要打3拍纔可以。
在跨異步打拍時如果處理不當，一樣會引發其他問題，比較突出的是誤採樣（毛刺）、漏採樣和過採樣。
毛刺誤採樣的典型場景是信號在跨異步前不進行寄存而是直接將組合邏輯的輸出作爲源端信號，舉例可見下面的波形。sig_a & sig_b進行跨異步，sig_a和sig_b本身是有傳播時間差的，因此sig_a & sig_b產生了一個微笑的毛刺，在同步電路中這不構成威脅因爲滿足了setup time和hold time的採樣要求。但是對於跨異步來說這就是災難性的毛刺了，因爲可能會被目的端時鐘捕獲，從而“無中生有”產生了一個週期的脈衝信號，直接影響了目的端的電路功能。
要避免毛刺被誤採樣，在信號處理中我們就要秉承一個原則，信號一律進行寄存器寄存後再進行跨異步，換句話說信號在跨異步之前不允許進行邏輯操作。
漏採樣多發生於慢時鐘採樣快時鐘信號場景下，在這種情況下快時鐘域的信號一般要進行信號拓展，拓展爲兩倍即sig_out = sig_a | sig_a_ff，那麼要拓展爲多少纔不會發生漏採樣呢？一般來講源端的跨異步信號需要維持目的端時鐘2個週期，當然這是一個穩妥值，具體還有詳細的計算方式我們後面再說。既然需要維持2個時鐘週期，那麼可見快時鐘採慢時鐘域信號也會發生漏採樣的，比如133M採樣100M信號，此時100M時鐘域內的信號也需要進行1拍的拓展。
過採樣的場景存在於快時鐘採樣慢時鐘域的場景下，典型的如uart中的過採樣場景。這種問題就無法避免了，需要跨異步兩端進行相關的約束和約定。
那麼如果信號順利的跨過了時鐘域，沒有誤採樣、漏採樣、過採樣的問題，就高枕無憂了麼？當然不是了，如果在目的時鐘域進行兩個跨異步信號的邏輯操作（也稱再收斂）或者多比特信號採用打拍跨異步，還是會引發問題，如下圖（我就用2拍來跨異步吧）。
問題出在哪裏呢？因爲你不知道信號在第幾拍恢復到正確的值，可能在第一拍也可能在第二拍。那麼sig_a和sig_b如果不是在同一拍收斂到正確值上去的，就會出現至少一拍的錯誤處理結果，這對目的端一般是不可接收的。怎麼避免這個問題呢？源端把該算的都算完再傳過來，儘量別讓我目的端進行什麼操作就好了。對於多比特信號呢？要麼方案中可以接受，要麼採用格雷碼一類的跨異步傳輸，或者採用握手或者異步FIFO之類更加複雜穩妥的傳輸方式，後面再聊。