時鐘域交叉分析方法

片上系統(tǒng)（SOC）設計的最大挑戰(zhàn)之一是不同的塊在獨立時鐘上運行。通過處理器總線，存儲器端口，外圍總線和其他接口集成這些塊可能很麻煩，因為當異步接口未正確同步時可能導致不可預測的行為。

檢查正確的同步通常是一個耗時的手動設計過程。通常，時鐘域交叉（CDC）的許多可能問題被忽視，導致主要的下游設計問題。

市場上出現(xiàn)了許多工具來識別CDC的問題。不幸的是，這些工具經(jīng)常報告數(shù)百個明顯的問題，其中許多通常是虛假的。這僅用于結(jié)構(gòu)性CDC分析。如果要更深入地檢查，必須在設計中添加斷言。此時，錯誤錯誤的數(shù)量會增加，通過它們所需的時間也會增加，并找到真正的問題點。

有一種方法可以減少這個過程的痛苦。它需要明確的同步規(guī)則和CDC分析方法，該方法可以與設計中不可避免的ECO（工程變更單）順利運行。此外，您的CDC工具必須支持輕松拒絕漏報的方法，并支持不需要在每個設計ECO上重新生成的豁免技術。

同步規(guī)程

同步中的挑戰(zhàn)是有很多方法可以做到這一點。雖然每種方法都有優(yōu)勢，但在設計中 - 以及在設計組織內(nèi) - 臨時使用不同技術會使審查過程復雜化。

今天沒有工具可以完全按下CDC驗證。總是需要一定程度的設計智慧來解釋結(jié)果并考慮系統(tǒng)級的含義。必須對各種同步技術做出這些判斷將不必要地使審查過程復雜化。

許多成功的公司已經(jīng)認識到這一點，并且只是強制要求必須通過預先設計的單元格或使用一小組預先批準的技術來執(zhí)行同步。雖然這可能會略微限制創(chuàng)作自由，但同步質(zhì)量的信心可以彌補這種損失。

應該預先批準的技術取決于他們必須支持的應用范圍。作為最嚴格的級別，可以強制要求所有同步通過預定義的同步單元進行。

最常見的同步單元支持單比特，通用總線和快速到慢速的數(shù)據(jù)同步。更輕松的方法允許手工制作這個邏輯，但仍然需要從一組有限的樣式中繪制插入的邏輯。在后一種情況下，通常需要添加變體 - 同步器的同步復位或半周期移位以降低元穩(wěn)定性或數(shù)據(jù)丟失的可能性。圖1a和1b顯示了兩種常見的同步技術。

圖1a - 單位亞穩(wěn)態(tài)同步

圖1b - 多位同步

在選擇CDC工具時，務必確保該工具支持設計中所需的所有技術。更復雜的工具允許設計人員基于各種同步樣式定義方法，包括最常用的技術，用戶命名的同步單元和用戶定義的結(jié)構(gòu)，這些結(jié)構(gòu)將與域交叉結(jié)構(gòu)進行模式匹配。

虛假域名交叉

許多時鐘域交叉通常是由復位或配置信號引起的（見圖2）。雖然技術上可以在這些準靜態(tài)信號上發(fā)生同步問題，但它將是一次性事件，并且由于此后信號是有效靜態(tài)的，因此可以在設備的大部分正常運行時間內(nèi)有效地忽略它們。

消除這些錯誤路徑的最佳方法是使用與合成或靜態(tài)時序分析相同的技術 - 聲明錯誤路徑。例如，您的CDC工具可能表明rst_n占交叉的50％以上，而配置[0]和配置[1]則占25％。如果您不想查看這些情況，可以通過錯誤路徑約束輕松地抑制它們：

cdc_false_path-from rst_n
cdc_false_path-from config [*]

錯誤交叉的另一個來源是功能錯誤的路徑。作者不知道今天會自動消除功能錯誤路徑的任何CDC工具，可能因為該分析可能非常昂貴并且可以說除了設計者通過一些簡單約束指定的值之外幾乎沒有增加價值。

例如，考慮使用CPU主機和多個I/O接口從機（如PCI或USB）驅(qū)動的總線?？偩€仲裁器的設計使得從機可以與CPU通信，反之亦然，但從機無法直接與從機通信。但是，CDC分析可能會顯示usb_ck和pci_ck等域之間的域交叉。同樣，使用錯誤路徑約束可以很容易地拒絕這些：

cdc_false_path-從use_ck到pci_ck
cdc_false_path-從pci_ck到usb_ck

在某些情況下，通過指定直通點可以進一步優(yōu)化錯誤路徑：

cdc_false_path-from（state）-through（thru-point）-to（end）

這是必要的改進，當確定從/到對在功能上是有效的，但只能通過某些路徑。

圖2 - 假時鐘域交叉的例子

FIFO同步

虛假域交叉的另一個有趣的來源可以是FIFO同步器中的推斷內(nèi)存。通常的做法是在將每個指針同步到相對的域之前對讀和寫指針進行灰度編碼，以便比較和生成滿標志和空標志。在讀數(shù)據(jù)信號周圍可能發(fā)生微妙且很少提到的錯誤交叉問題。想想如何在RTL中描述這一點：

總是@（posedge read_clk）
如果（read_en == 1'b1）read_data <=> =>

always @（posedge write_clk）
如果（write_en == 1'b1）mem [write_addr] <=> =>

這是一個非常合理的FIFO核心描述除了CDC分析將檢測寫入和讀取時鐘之間的域交叉和“read_data”之外。

事實上，這個域名交叉是虛假的，這是一個有趣的原因。雖然理論上可以從與寫入相同的地址進行讀?。ㄍ瑫r），但大多數(shù)同步器設計會在讀取和寫入之間強制執(zhí)行一些延遲，從而確保在同一地址中不會發(fā)生寫入和讀取。相同的周期（任何一個時鐘）。這種延遲確保讀取數(shù)據(jù)至少在幾個周期內(nèi)有效地準靜態(tài)，因此不能成為域交叉。

一個好的CDC工具可以自動檢測和拒絕這些情況。

握手同步

一種非常常見且穩(wěn)健的同步多個數(shù)據(jù)信號的方法是握手技術，如圖3所示。這很受歡迎，因為握手技術可以輕松管理時鐘頻率的變化，同時最大限度地減少交叉口的延遲。但是，握手邏輯比標準同步結(jié)構(gòu)復雜得多，大多數(shù)工具都不會自動識別。在這些情況下，傳統(tǒng)的隱式CDC分析將報告所有交叉數(shù)據(jù)信號的非同步域交叉。

圖3 - 握手同步是時鐘域交叉中常用的技術

各種正式工具都有屬性（斷言）檢查握手結(jié)構(gòu)的特性 - 例如，在目標寄存器完成數(shù)據(jù)捕獲之前，不得取消置位REQ。但是所有這些技術都要求設計人員手動識別握手并為每個這樣的結(jié)構(gòu)插入這些斷言。

雖然檢查這些屬性有好處，但這仍然給設計人員帶來了確保所有握手確實已被分析的主要負擔。同樣，這些結(jié)構(gòu)將導致錯誤的CC報告，只能通過手動檢查來消除。

一些最新的CDC工具可以自動檢測一大類握手結(jié)構(gòu)，大大減少了CDC報告中的漏報。這也允許工具對握手結(jié)構(gòu)進行功能分析和隱式檢查，完全不需要設計人員定義和插入這些檢查。

第三方IP

今天幾乎所有的設計都包含一些外部知識產(chǎn)權（IP），無論是內(nèi)部開發(fā)還是商業(yè)收購。對于如圖4所示的IP，除了進入的檢查檢查之外，重復檢查內(nèi)部域交叉和同步技術幾乎沒有價值。在大多數(shù)情況下，您無法更改IP的內(nèi)部，因此任何報告的問題都只是額外的噪音。更重要的是分析圍繞該IP和其他設計的CDC，其中IP域和設計域之間的交互可能導致新問題。

某些CDC工具提供約束來屏蔽指定IP內(nèi)部的所有域交叉報告，同時仍報告其他邏輯與這些IP之間的交叉。這使得檢查更容易，更有效。

圖4 - 與IP塊相關的時鐘域交叉點

評論和ECO分析

即使已經(jīng)消除了所有這些雜散源，也可能需要檢查大量可能不同步的域交叉。這些可能來自在復位或配置信號意義上不是準靜態(tài)的信號，但已知在使用之前“足夠長時間”是穩(wěn)定的。

一旦審查并批準此類案件，除非您選擇，否則無需再次查看。處理這些案件的一種實用方法是放棄，在RTL代碼內(nèi)部或外部應用，以標記案件已經(jīng)過審查和批準。

易于使用和靈活的點 - 和如圖5所示，單擊豁免方法優(yōu)于“正式放棄”一種或多種違反任何類型的行為。應該智能地應用這些豁免，適應RTL代碼的更改，因此很少需要更新它們。如果需要，這些豁免和他們壓制的CDC仍然可以進行設計審查或最終通過，以重新驗證所有域名交叉點。

圖5 - 豁免違規(guī)的點擊式方法

功能分析

CDC的功能分析是自然延伸到結(jié)構(gòu)分析。每個識別的同步結(jié)構(gòu)帶有一個或多個功能要求。例如，考慮一個常見的多路復用循環(huán)同步器，如圖6所示。

圖6 常用的多路復用再循環(huán)同步器

多路復用器驅(qū)動目標域中的寄存器，并且僅在選擇時允許數(shù)據(jù)從源域傳遞，否則多路復用器將寄存器輸出值再循環(huán)。選擇“sel”必須與指定域同步。

到目前為止，這是一項結(jié)構(gòu)性檢查。在這種情況下所需的功能檢查是當選擇“sel”變高時源數(shù)據(jù)信號“data”是穩(wěn)定的。由于選擇和數(shù)據(jù)信號是自動識別的，因此應該是自動檢查。

此類中的其他檢查包括快速到慢速域跨越保持時間，灰色編碼檢查，握手檢查等等。這些檢查不會減少，也可能增加報告的問題數(shù)量，但在準確的結(jié)構(gòu)識別基礎上這樣做，大大降低了誤報的可能性。