https://zhuanlan.zhihu.com/p/116888880
芯片設計進階之路——SpyGlass CDC流程深入理解(一)
SpyGlass CDC 流程深入理解(一）
------------------------------------------
版權聲明：
本文作者： 烓圍瑋未
首發於知乎專欄：芯片設計進階之路
轉發無需授，請保留這段聲明。
------------------------------------------
1. SPYGLASS CDC 簡介
隨着技術的發展，數字電路的集成度越來越高，設計也越來越復雜。很少有系統會只工作在同一個時鍾頻率。一個系統中往往會存在多個時鍾，這些時鍾之間有可能是同步的，也有可能是異步的。如果一個系統中，異步時鍾之間存在信號通道，則就會存在CDC（clock domain crossing）問題。
如下圖中，CLKA和CLKB之間沒有固定的相位關系，是異步時鍾。前半部分設計屬於時鍾域CLKA，后半部分設計屬於時鍾域CLKB。DA信號從時鍾域CLKA進入到時鍾域CLKB，是一個跨時鍾域的信號，這條path也會被稱為CDC path。
CDC(Clock Domain Crossing)的前端設計中最常見的問題, 在RTL中要恰當的處理每個異步的控制信號和數據信號, 否則就會出現亞穩態,造成嚴重的function false.
SpyGalss是目前業界唯一可靠的RTL Sign off解決方案，可以幫助客戶在設計早期發現潛在問題，保證產品質量，極大的減少設計風險，降低設計成本。
包含五大模塊： lint, CDC(跨時鍾域檢查), LP（低功耗)，Constraint(約束)，DFT(可測試性)。
SpyGlass CDC分析使你能夠識別設計中的CDC問題。SpyGlass CDC tool是一種 Formal Check Methodology工具, 相比寫case跑仿真來找CDC問題, 靠SpgGlass能更早,更全,更快的發現CDC問題. 它能夠:
- 管理是多時鍾域設計
- 系統地處理CDC問題
- 檢查和報告任何不同步的信號: 時鍾和復位
SpyGlass CDC與靜態時序分析相比:
- STA對async interface不太好使,只適合sync模塊分析
- CDC paths 總是需要設置成false paths
- 一般在design的后期在netlist level做才有意義
SpyGlass CDC與功能仿真相比:
- 黑盒測試很難窮舉(exhaust)
- 白盒測試需要assertions
- 需要覆蓋CDC的所有test branches
- 很難幸運的覆蓋所有,一般只能發現部分問題
- 一般在design后期才發現問題
當SOC design涉及的clock domain太多,用到很多第三方IP,及涉及人員水平參差不齊時, 用SpyGlass CDC來做檢查來保證RTL質量是十分必要的.
在工程的block-level和SOC 集成的兩個不同階段, 所適用的CDC Goal也是有所不同的. Block-Level關心的是模塊內部, 只有模塊內檢查沒問題后才能做deliver. 而SOC集成主要關心的是模塊間interface的CDC問題.
2. SpyGlass 的一些基本概念
一些基本的概率如下：
- Rule: 是SpyGlass 進行RTL分析的最小單位.
- Goal: 是一系列相關Rule的集合,組合起來完成RTL分析的某個特定任務. user可以用GuideWare定義好的Goal, 也可根據工程項目要求來選擇一系列rule的集合形成自定義Goal. GUI里面點Goal的button來選擇設定, 也可在Prj file 里定義.
- Sub-Methodology: 是一系列相關Goal的集合, 用以達成某方面特定目標, 如完成CDC check.
目前包括 SpyGlass CDC/Constraints/DFT/Power/TXV Methodology
其他術語 :
- SGDC : Constraints 文件, 主要包含clock和reset等約束信息.
- Waiver : 用以過濾一些結果的文件.
- Severity : report結果中分Fatal, Error, Warning和INFO四等級信息.
- Parameter: 可以在進行RTL分析之前設定某些參數, 對檢查過程進行一些約束
3. SpyGlass CDC流程簡介
SpyGlass的功能模型總結如下圖:
Figure3.1 SpyGlass Functional Model
3.1 設置階段(setup stage)
在設計的設置階段你可以:
- 添加設計文件、SGDC文件、預編譯文件和技術文件。
- 指定影響SpyGlass運行的各種設計讀取選項。例如，你可以在設計中指定頂層模塊、更改語言、指定宏等等。。
- 運行design-read流程來執行第一級的HDL分析。在進入下一階段之前，必須解決此階段報告的致命錯誤(FATAL)。
Spyglass 可以運行在BATCH 或者 GUI 模式。通常模式下是在batch模式下執行分析，在GUI模式下進行debug。
3.1.1 工程(Project)文件
采用BATCH模式，這些設置都會添加到工程(Project)文件中，Project一般定義了以下內容：
下面是一個Project文件 training.prj的列子：
需要讀入的文件及命令如下：
3.1.2 約束(SGDC)文件
SDC文件可以直接被SpyGlass讀取，自動轉換成SGDC，需要設置以下內容完成sdc2sgdc的轉換：
set_option sdc2sgdc yes
sdc_data –file “test.sdc”
下面是一個SGDC文件的例子
3.2目標(Goal)設定和運行階段
在此階段，你將選擇並運行目標。目標是規則的集合。
你可以選擇規則，也可以指定規則執行的順序。
在SpyGlass CDC分析期間，你可以在不同的階段運行不同的SpyGlass CDC目標。在每個階段中，修復所報告的違例並轉移到下一個階段。使用這種分步驟的方法可以幫助你了解一些需要考慮的CDC問題。
如果不遵循這個分步驟的方法，你可能會看到大量違反CDC的情況，其中大多數是由於不正確的設置或沒有修復前幾個階段的違例引起的。
SpyGlass CDC 的目標和規則如下圖所示
3.3 SpyGlass CDC 分析流程
SpyGlass CDC分析可以分為以下幾個階段:
- 創建SpyGlass CDC設置
- 修復時鍾和復位完整性問題
- 執行CDC驗證
- 調試CDC問題
在執行SpyGlass CDC 分析之前，請檢查必要的先決條件。
進行SpyGlass CDC分析的先決條件如下:
- 成功運行design-read流程
- 確保設計包含最少數量的非預期的black box
- 在設計中為實例化的技術庫單元提供相應的技術庫(.lib)
- 在設計中指定有關時鍾的信息，以及復位信息(如果可能的話)
建議在開始運行SpyGlass CDC之前，從設計規范、IPs或芯片引線收集這些信息。如果你沒有這些信息，SpyGlass CDC也能夠提供自動檢測時鍾和復位，但是會推斷出額外的時鍾和復位，最好是能夠預先明確所有的時鍾和復位信息。
4. 創建SpyGlass CDC 設置
創建設置意味着在執行CDC驗證之前指定設計信息，例如時鍾、重置和停止模塊。設置的質量決定了SpyGlass CDC分析的質量。錯誤或不完整的設置可能會導致許多違例或掩蓋一個真正的設計錯誤。
可以通過以下流程建立SpyGlass CDC設置：
- 將時鍾生成模塊指定為black box
- 為設計指定時鍾和復位
- 為設計生成時鍾和復位
- 使用設置管理器
4.1 將時鍾生成模塊指定為black box
對時鍾生成模塊(比如PLL)的內部執行SpyGlass CDC分析非常復雜，而且對整體SpyGlass CDC分析幾乎沒有價值。
將這些塊標記為黑盒子，除非你有詳細的SGDC約束來定義這些模塊的時鍾特性。
標記PLL時鍾生成模塊為black boxes的方法是，在project file中設置如下命令：
set_option stop <blocks>
一旦你設置這些模塊為black boxes:
- 將時鍾約束定義在這些模塊的輸出pin上
- 將輸出時鍾和輸入定義為同一個時鍾域，除非兩者之間沒有相位關系
如下面的列子所示：
FIGURE 1. Defining Clock Outputs as in the Same Domain
4.2 為設計指定時鍾和復位
如果知道設計中的時鍾和復位，可以執行以下步驟來指定他們:
- 在SGDC中定義CLOCK和RESET的約束
clock -name “clk_sys”
reset -name “rst_n” –value 0
- 通過運行SpyGlass CDC 方法的Goals來分析設計
- 檢查The Clock-Reset-Summary Report.
- 在The Clock-Reset-Summary Report 的Section D: Cases not checked for clock domain crossings Section里面列出了unconstrained clocks.
- 修改SGDC來指定The Clock-Reset-Summary Report里列出的時鍾信號；
- 修改SGDC后重復步驟2；
4.3為設計生成時鍾和復位
如果不知道設計中的時鍾和復位，可以執行以下步驟來生成:
1. 運行cdc_setup goal
這個步驟產生了autoclocks.sgdc和autoresets.sgdc兩個SGDC文件，包含了推斷的時鍾和復位。
2. 檢查和修改生成的SGDC文件
這些文件可能包括一些除了真正的時鍾和復位的控制信號。因此，你必須檢查這些文件中的每個推斷的時鍾和復位，並刪除不是真正的時鍾和復位信號。
建議您查看Setup_clock01和Reset_info01規則信息，以查看這樣的推斷信號。
3. 在SpyGlass中指定修改過的autoclocks.sgdc 和 autoresets.sgdc文件，並通過運行相應的Goal來分析你的設計。
4.3.1 在生成的SGDC 文件中修改時鍾域
默認情況下，autoclocks.sgdc文件中生成的clock 假定為一個單獨的時鍾域。在這種情況下，CDC Verification Rules 報告了對每對時鍾信號之間的時鍾域交叉的違例。
但是，工具可能會將設計中的一些時鍾信號視為來自同一域。在這種情況下，工具會認為觸發器之間的數據傳輸沒有同步問題。
你可以通過約束中的clock 關鍵字來修改時鍾域的信息。通過修改clock的-domain參數為同一個值來指定所有相同時鍾域的clock到同一個時鍾域。注意-domain的參數可以是有效的字符串或者時鍾名。
例如，下面的例子中clk1和clk2是同一個時鍾域，clk3是不同的時鍾域。
current_design myDU
clock -name clk1 -domain A
clock -name clk2 -domain A
clock -name clk3 -domain B
這樣，所有clk1和clk3或者clk2和clk3之間的信號都認為是跨時鍾域了，但是clk1和clk2之間不認為是跨時鍾域，不會報出來，因為clk1和clk2是同一個時鍾域。
選項 –domain的參數是可選的，如果沒有設定，那么時鍾域的名字就是時鍾自己。所以下面的例子clk1和clk2是同一個時鍾域(clk1)， clk3是不同的時鍾域(clk3):
current_design myDU
clock -name clk1
clock -name clk2 -domain clk1
clock -name clk3
5. 修復時鍾和復位完整性問題
這個步驟必須確保時鍾和復位被正確定義，並且它們沒有glitches、競爭和其他故障。
你必須通過運行clock_reset_integrity goal來修復時鍾和復位的完整性。
Setup的主要目標是保證clock和reset被正確定義，必須保證所以error都被修復了，才能進行下一步，不然后續會有很多意想不到的錯誤。
5. 后記
CDC檢查是SOC RTL freeze之前必須要做的檢查，也是最重要的檢查之一。CDC檢查能夠提前發現功能時序仿真中發現不了的跨時鍾問題，極大的減少了芯片失敗的風險。系統的學習SpyGlass CDC流程，深入的理解CDC的各種問題，熟練的使用SpyGlass工具是一個資深的SOC設計人員必須具備的。
文章主要參考SpyGlass官方文檔，加入自己的總結和工程經驗，希望能對看到本文的芯片設計人員有所幫助。這是SpyGlass CDC 流程深入理解的第一篇文章，還有后續，請關注知乎專欄《芯片設計進階之路》
贈人玫瑰，手有余香。原創不易，如果你有所得，麻煩花一秒時間幫我“點贊”吧，謝謝！
------------------------------------------
版權聲明：
本文作者： 烓圍瑋未
首發於知乎專欄：芯片設計進階之路
轉發無需授權，請保留這段聲明。
---------------------------------------