01

SPYGLASS CDC 簡介

隨著技術的發(fā)展，數(shù)字電路的集成度越來越高，設計也越來越復雜。很少有系統(tǒng)會只工作在同一個時鐘頻率。一個系統(tǒng)中往往會存在多個時鐘，這些時鐘之間有可能是同步的，也有可能是異步的。如果一個系統(tǒng)中，異步時鐘之間存在信號通道，則就會存在CDC（clock domain crossing）問題。

如下圖中，CLKA和CLKB之間沒有固定的相位關系，是異步時鐘。前半部分設計屬于時鐘域CLKA，后半部分設計屬于時鐘域CLKB。DA信號從時鐘域CLKA進入到時鐘域CLKB，是一個跨時鐘域的信號，這條path也會被稱為CDC path。

CDC(Clock Domain Crossing)的前端設計中最常見的問題, 在RTL中要恰當?shù)奶幚砻總€異步的控制信號和數(shù)據(jù)信號, 否則就會出現(xiàn)亞穩(wěn)態(tài),造成嚴重的function false.

SpyGalss是目前業(yè)界唯一可靠的RTL Sign off解決方案，可以幫助客戶在設計早期發(fā)現(xiàn)潛在問題，保證產品質量，極大的減少設計風險，降低設計成本。

包含五大模塊：lint, CDC(跨時鐘域檢查), LP（低功耗)，Constraint(約束)，DFT(可測試性)。

SpyGlass CDC分析使你能夠識別設計中的CDC問題。SpyGlass CDC tool是一種 Formal Check Methodology工具, 相比寫case跑仿真來找CDC問題, 靠SpgGlass能更早,更全,更快的發(fā)現(xiàn)CDC問題. 它能夠:

1.管理是多時鐘域設計

2.系統(tǒng)地處理CDC問題

3.檢查和報告任何不同步的信號: 時鐘和復位

SpyGlass CDC與靜態(tài)時序分析相比:

1.STA對async interface不太好使,只適合sync模塊分析

2.CDC paths 總是需要設置成false paths

3.一般在design的后期在netlist level做才有意義

SpyGlass CDC與功能仿真相比:

1.黑盒測試很難窮舉(exhaust)

2.白盒測試需要assertions

3.需要覆蓋CDC的所有test branches

4.很難幸運的覆蓋所有,一般只能發(fā)現(xiàn)部分問題

5.一般在design后期才發(fā)現(xiàn)問題

當SOC design涉及的clock domain太多,用到很多第三方IP,及涉及人員水平參差不齊時, 用SpyGlass CDC來做檢查來保證RTL質量是十分必要的.

在工程的block-level和SOC 集成的兩個不同階段, 所適用的CDC Goal也是有所不同的. Block-Level關心的是模塊內部, 只有模塊內檢查沒問題后才能做deliver. 而SOC集成主要關心的是模塊間interface的CDC問題.

02

SpyGlass 的一些基本概念

一些基本的概率如下：

● Rule : 是SpyGlass 進行RTL分析的最小單位.

● Goal : 是一系列相關Rule的集合,組合起來完成RTL分析的某個特定任務. user可以用GuideWare定義好的Goal, 也可根據(jù)工程項目要求來選擇一系列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分析之前設定某些參數(shù), 對檢查過程進行一些約束

03

SpyGlass CDC流程簡介

SpyGlass的功能模型總結如下圖:

Figure3.1 SpyGlass Functional Model

3.1

設置階段(setup stage)

在設計的設置階段你可以:

●添加設計文件、SGDC文件、預編譯文件和技術文件。

●指定影響SpyGlass運行的各種設計讀取選項。例如，你可以在設計中指定頂層模塊、更改語言、指定宏等等。。

●運行design-read流程來執(zhí)行第一級的HDL分析。在進入下一階段之前，必須解決此階段報告的致命錯誤(FATAL)。

Spyglass 可以運行在BATCH 或者 GUI 模式。通常模式下是在batch模式下執(zhí)行分析，在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)設定和運行階段

在此階段，你將選擇并運行目標。目標是規(guī)則的集合。

你可以選擇規(guī)則，也可以指定規(guī)則執(zhí)行的順序。

在SpyGlass CDC分析期間，你可以在不同的階段運行不同的SpyGlass CDC目標。在每個階段中，修復所報告的違例并轉移到下一個階段。使用這種分步驟的方法可以幫助你了解一些需要考慮的CDC問題。

如果不遵循這個分步驟的方法，你可能會看到大量違反CDC的情況，其中大多數(shù)是由于不正確的設置或沒有修復前幾個階段的違例引起的。

SpyGlass CDC 的目標和規(guī)則如下圖所示

3.3

SpyGlass CDC 分析流程

SpyGlass CDC分析可以分為以下幾個階段:

1.創(chuàng)建SpyGlass CDC設置

2.修復時鐘和復位完整性問題

3.執(zhí)行CDC驗證

4.調試CDC問題

在執(zhí)行SpyGlass CDC 分析之前，請檢查必要的先決條件。

進行SpyGlass CDC分析的先決條件如下:

●成功運行design-read流程

●確保設計包含最少數(shù)量的非預期的black box

●在設計中為實例化的技術庫單元提供相應的技術庫(.lib)

●在設計中指定有關時鐘的信息，以及復位信息(如果可能的話)

建議在開始運行SpyGlass CDC之前，從設計規(guī)范、IPs或芯片引線收集這些信息。如果你沒有這些信息，SpyGlass CDC也能夠提供自動檢測時鐘和復位，但是會推斷出額外的時鐘和復位，最好是能夠預先明確所有的時鐘和復位信息。

04

創(chuàng)建SpyGlass CDC 設置

創(chuàng)建設置意味著在執(zhí)行CDC驗證之前指定設計信息，例如時鐘、重置和停止模塊。設置的質量決定了SpyGlass CDC分析的質量。錯誤或不完整的設置可能會導致許多違例或掩蓋一個真正的設計錯誤。

可以通過以下流程建立SpyGlass CDC設置：

●將時鐘生成模塊指定為black box

●為設計指定時鐘和復位

●為設計生成時鐘和復位

●使用設置管理器

4.1

將時鐘生成模塊指定為black box

對時鐘生成模塊(比如PLL)的內部執(zhí)行SpyGlass CDC分析非常復雜，而且對整體SpyGlass CDC分析幾乎沒有價值。

將這些塊標記為黑盒子，除非你有詳細的SGDC約束來定義這些模塊的時鐘特性。

標記PLL時鐘生成模塊為black boxes的方法是，在project file中設置如下命令：

set_option stop

一旦你設置這些模塊為black boxes:

●將時鐘約束定義在這些模塊的輸出pin上

●將輸出時鐘和輸入定義為同一個時鐘域，除非兩者之間沒有相位關系

如下面的列子所示：

FIGURE 1. Defining Clock Outputs as in the Same Domain

4.2

為設計指定時鐘和復位

如果知道設計中的時鐘和復位，可以執(zhí)行以下步驟來指定他們:

1.在SGDC中定義CLOCK和RESET的約束

clock -name “clk_sys”

reset -name “rst_n” –value 0

1.通過運行SpyGlass CDC 方法的Goals來分析設計

2.檢查The Clock-Reset-Summary Report.

3.在The Clock-Reset-Summary Report 的Section D: Cases not checked for clock domain crossings Section里面列出了unconstrained clocks.

4.修改SGDC來指定The Clock-Reset-Summary Report里列出的時鐘信號；

5.修改SGDC后重復步驟2；

4.3

為設計生成時鐘和復位

如果不知道設計中的時鐘和復位，可以執(zhí)行以下步驟來生成:

1.運行cdc_setup goal

這個步驟產生了autoclocks.sgdc和autoresets.sgdc兩個SGDC文件，包含了推斷的時鐘和復位。

2.檢查和修改生成的SGDC文件

這些文件可能包括一些除了真正的時鐘和復位的控制信號。因此，你必須檢查這些文件中的每個推斷的時鐘和復位，并刪除不是真正的時鐘和復位信號。

建議您查看Setup_clock01和Reset_info01規(guī)則信息，以查看這樣的推斷信號。

3.在SpyGlass中指定修改過的autoclocks.sgdc 和 autoresets.sgdc文件，并通過運行相應的Goal來分析你的設計。

4.3.1 在生成的SGDC 文件中修改時鐘域

默認情況下，autoclocks.sgdc文件中生成的clock 假定為一個單獨的時鐘域。在這種情況下，CDC Verification Rules 報告了對每對時鐘信號之間的時鐘域交叉的違例。

但是，工具可能會將設計中的一些時鐘信號視為來自同一域。在這種情況下，工具會認為觸發(fā)器之間的數(shù)據(jù)傳輸沒有同步問題。

你可以通過約束中的clock 關鍵字來修改時鐘域的信息。通過修改clock的-domain參數(shù)為同一個值來指定所有相同時鐘域的clock到同一個時鐘域。注意-domain的參數(shù)可以是有效的字符串或者時鐘名。

例如，下面的例子中clk1和clk2是同一個時鐘域，clk3是不同的時鐘域。

current_design myDU

clock -name clk1 -domain A

clock -name clk2 -domain A

clock -name clk3 -domain B

選項 –domain的參數(shù)是可選的，如果沒有設定，那么時鐘域的名字就是時鐘自己。所以下面的例子clk1和clk2是同一個時鐘域(clk1)， clk3是不同的時鐘域(clk3):

current_design myDU

clock -name clk1

clock -name clk2 -domain clk1

clock -name clk3

05

修復時鐘和復位完整性問題

這個步驟必須確保時鐘和復位被正確定義，并且它們沒有glitches、競爭和其他故障。

你必須通過運行clock_reset_integrity goal來修復時鐘和復位的完整性。

Setup的主要目標是保證clock和reset被正確定義，必須保證所以error都被修復了，才能進行下一步，不然后續(xù)會有很多意想不到的錯誤。

06

執(zhí)行CDC驗證

CDC驗證是指在設計中檢測CDC問題。

要執(zhí)行CDC驗證，請執(zhí)行以下步驟:

1.設置所需的參數(shù)(parameters)

有關SpyGlass CDC解決方案的所有參數(shù)的詳細信息，請參閱Parameters in SpyGlass CDC.。

2.運行Goals，例如cdc_verify和cdc_verify_struct，以檢測大量的CDC問題。

最初你可能會發(fā)現(xiàn)大量違反CDC的情況。以一種系統(tǒng)的方式來處理它們是很重要的，這樣你就可以快速地處理一些需要考慮的問題。

下列列出了大多數(shù)重要的違例種類:

●Unsynchronized Crossings Issues

●Convergence Issues

●Reset Synchronization Issues

●Glitch Issues

●Signal Width Errors in Synchronized Control Crossings

●Data Hold Issues in Synchronized Data Crossings

對于所有其他違規(guī)行為，請搜索SpyGlass CDC文檔以查找其規(guī)則名稱的違例行為。

詳細的請參考 Rules in SpyGlass CDC.

6.1

未同步的跨時鐘域問題 （Unsynchronized Crossings Issues）

首先，通過查看Ac_unsync01 和Ac_unsync02來檢查未同步的跨時鐘域問題。

未同步就進行跨時鐘域設計會產生亞穩(wěn)態(tài)，這是最基本的CDC問題。

下面的例子是一種未同步信號直接跨時鐘域的情況：

FIGURE 3. Unsynchronized crossing causing metastability problem

6.2

聚合問題（Convergence Issues）

Convergence issues can occur when multiple signals cross from one domain to another but they are separately synchronized. For example, consider the following figures:

聚合問題發(fā)生在多個信號（可能是同一個時鐘域也可以是不同的時鐘域）從一個時鐘域跨到另一個相同的時鐘域，但是這些信號是分開同步的。這樣你在使用這些同步過的信號的時候，就不能確定他們是不是同時有效，這樣有可能就有問題。幾種情況如下：

FIGURE 4. Convergence Issues

此外，當將coherence _check_type參數(shù)設置為reset時，Ac_conv規(guī)則會執(zhí)行復位控制同步器的收斂性和一致性檢查，如下圖所示。

FIGURE 5. Convergence Issues of Reset Control Synchronizers

有關此類違規(guī)類型的信息，請參見Ac_conv01、Ac_conv02、Ac_conv03、Ac_conv04和Ac_conv05。

有關調試此類問題的信息，請參閱Debugging CDC Issues.

6.3

復位同步問題

對于此類問題，請檢查違反Ar_*規(guī)則的情況。這些rules報告同步異步復位信號的違規(guī)行為。

由于復位通常是單比特信號，你可能希望在Ac_sync01下報告它們。但是復位的同步往往不同，比如常見的異步復位同步釋放，輸入是拉高的。

例如，下圖顯示了一個復位同步釋放:

FIGURE 6. Reset that Deasserts Synchronously

有關這些違規(guī)的信息，請參見Ar_asyncdeassert01、Ar_syncdeassert01、Ar_sync01和Ar_unsync01。有關調試此類問題的信息，請參閱 Debugging CDC Issues。Ar_cross_analysis01規(guī)則執(zhí)行crossing檢測和同步檢查，并在設計中報告reset路徑中的所有時鐘域crossing。用戶不需要像Ar_sync規(guī)則所要求的那樣在約束文件中指定reset定義。

6.4

毛刺問題

檢查通過Ac_glitch或Clock_glitch規(guī)則報告的所有違例。

這些規(guī)則突出了容易出現(xiàn)毛刺的邏輯，這些邏輯可能導致與同步問題非常類似的問題。

例如，下圖顯示了容易出現(xiàn)毛刺的重新聚合的組合邏輯:

FIGURE 7. Glitch-prone reconverging combinational logic

關于這個違例更多的信息可以參考：Ac_glitch01, Ac_glitch03, Clock_glitch02, Clock_glitch03, Clock_glitch04, Clock_converge01, and Reset_sync01.

6.5

跨時鐘信號寬度錯誤（Signal Width Errors in Synchronized Control Crossings）

請檢查Ac_cdc01 rule 違例。

這種違例通常發(fā)生在信號從快時鐘穿越到慢時鐘，信號在慢時鐘還沒采樣到的時候已經發(fā)生變化。

下圖是信號寬度問題的例子:

FIGURE 8. Example of a signal width issue

6.6

數(shù)據(jù)跨時鐘的保持時間問題

請檢查Ac_datahold01a 違例。

在使用同步器，但功能不正確的情況下，會出現(xiàn)此類違規(guī)報告的信號。考慮如下的情況：

FIGURE 9. Incorrectly Synchronized Data Crossings

上圖是一種不正確的跨時鐘同步器的情況。這里，數(shù)據(jù)在enable有效的時候發(fā)生了變化。

07

調試CDC問題

在調試CDC問題之前，請保證setup是正確的。請參考Creating SpyGlass CDC Setup

在正常規(guī)模的設計上跑SpyGlass CDC，一般會有大量的違例。大部分違例是因為：

●錯誤或者不完備的setup

●配置信號，通常不應報告為CDC錯誤

你可以系統(tǒng)的，有條理的來移除這些違例，只留下一些你需要考慮的潛在的實際問題。

注意：千萬不要通過waiving的方式解決CDC的問題，這樣十分危險，可能wave掉了真正的CDC問題。每一條waver都必須反復check。

你可以通過以下方式來調試CDC問題：

●Using Spreadsheets

●Using Incremental Schematic

●Viewing Debug Data in Schematic

●Filtering Violations Based On Instances

●Solving CDC Issues Common to Multiple Violations

7.1

使用電子表（Using Spreadsheets）

當存在許多違規(guī)行為時，這些違規(guī)行為中的很大一部分是由一小部分的根本原因造成的。

分析它們的推薦方法是使用電子表格查看器。

執(zhí)行以下步驟來使用電子表格查看器調試大部分的違規(guī):

1. 打開電子表查看器

通過右鍵單擊違例標題（rule的大類，比如Ar_unsync01）并從快捷菜單中選擇電子表格查看器選項來打開電子表格。如下圖所示

2. 篩選和排序數(shù)據(jù)

在電子表格視圖中使用篩選和排序來區(qū)分共同因素和違例。要過濾或排序數(shù)據(jù)，右鍵單擊列標題并從快捷菜單中選擇一個適當?shù)倪x項，如下圖所示:

每一列單擊可以排序，右鍵可以過濾：

FIGURE 10. Filtering and Sorting in the Spreadsheet

3. 檢查常見原因或者來源

在電子表格中查找常見原因或常見來源。這些很可能指向一個單一的根本原因。

4. 根據(jù)源來進行過濾

如果您正在使用靜態(tài)信號的命名方法，請在電子表格中按源名稱進行篩選。比如篩選所有的配置寄存器。

例如，下圖顯示了如何為源指定過濾條件(_cfg):

FIGURE 11. The Custom Filter Dialo

查看過濾后的列表并解決根本原因，以消除大量違例。

7.2

使用增量示意圖（Incremental Schematic）

示意圖使你能夠理解和隔離沖突的根本原因。

你可以查看電子表格中出現(xiàn)的多個相關違規(guī)的示意圖。為此，請執(zhí)行以下步驟:

1.通過按下鍵盤鍵在電子表格中選擇違規(guī)。

2.執(zhí)行下列操作之一，打開增量示意圖:

單擊電子表格中某一行的Schematic列中的鏈接。

單擊電子表格工具欄中的增量示意圖按鈕。

也可以右鍵直接選擇Incremental Schematic

下圖為增量示意圖:

FIGURE 12. The Incremental Schematic Window

使用增量示意圖的Tips：

●使用圖例了解用于標識域和限定符的顏色;

●總是運行Info_Case_Analysis規(guī)則來查看常量值(constant values)在示意圖中的傳播;

●右鍵單擊任何net(不是pin)并選擇Show Debug Data-> clock -reset選項來查看時鐘和域信息。

有關詳細信息，請參考Viewing Debug Data in Schematic.

●可以通過雙擊邊界邊來擴展層次結構邊界。

●通過雙擊需要traced的inout/output的對象來跟蹤輸入和輸出。

●通過使用示意圖中適當?shù)挠益I菜單選項來跟蹤輸入和輸出，從而跟蹤到觸發(fā)器、鎖存器、輸入、輸出和模塊。

7.3

在示意圖中查看調試數(shù)據(jù)

在示意圖中調試SpyGlass CDC解決違例時，以下信息非常有用:

●clock 路徑中的net的時鐘域信息

●reset 路徑中的net的復位域信息

●數(shù)據(jù)或者控制信號的時鐘域信息

●數(shù)據(jù)或者控制信息的準靜態(tài)信息

注意:必須將enable_debug_data參數(shù)的值設置為yes，才能查看SpyGlass CDC解決方案規(guī)則的上述調試數(shù)據(jù)。

要查看示意圖中的調試數(shù)據(jù)，右鍵單擊net并從快捷菜單中選擇Show debug data - >Clock-reset選項。當您選擇此選項時，將出現(xiàn)一個子菜單，顯示以下選項:

●Clock

選擇此選項可以查看時鐘路徑中出現(xiàn)的net上的時鐘信息，如下圖所示:

FIGURE 13. The Clock Domain Data Dialog

Propagate_Clocks rule計算上述信息。此選項僅對出現(xiàn)在設計的時鐘路徑中的net起作用。

●Reset

選擇此選項可以查看reset路徑中出現(xiàn)的net的reset信息，如下圖所示:

FIGURE 14. The Reset Domain Data Dialog

Propagate_Resets rule計算上述信息。在上圖中，Type表示復位類型，Active值表示復位源的初始值。此選項僅對在設計的reset路徑中出現(xiàn)的net起作用。

●Domain in data/control paths

選擇此選項，可以在設計的數(shù)據(jù)或控制路徑中查看net上的時鐘域信息，如下圖所示:

FIGURE 15. The Data/Control Path Domain Data Dialog

在上圖中，Internal Domain Tag是指在執(zhí)行時鐘傳播時計算的內部標記，而Quasi static是指具有準靜態(tài)屬性的路徑。數(shù)據(jù)/控制路徑可以有以下類型的時鐘域:

●用戶指定的時鐘域: 這個類別包括主時鐘、black box時鐘和派生時鐘。在這種情況下，SpyGlass會顯示用戶指定的時鐘名稱。

●合并時鐘域: 如果一個門上匯聚了多個時鐘，則在內部創(chuàng)建一個合并域。在這種情況下，SpyGlass會顯示用戶指定的時鐘列表。

●虛擬時鐘域: 如果一個虛擬時鐘與一個塊實例端口的主端口相關聯(lián)，則SpyGlass將顯示用戶指定的虛擬時鐘名。

●Quasi_static

選擇此選項以檢查net在數(shù)據(jù)或控制路徑中是否是準靜態(tài)的，如下圖所示:

FIGURE 16. The quasi_static Debug Data Dialog

7.4

基于實例來過濾違例

在處理大型設計時，設計師會被分配特定的設計實例。在這種情況下，設計師需要關注特定實例中報告的違規(guī)情況。為了幫助設計人員快速定位特定實例上的違規(guī)，SpyGlass CDC提供了基于實例的過濾機制。在此機制中，設計人員可以基于實例篩選違規(guī)。

要基于實例過濾違規(guī)，請執(zhí)行以下步驟:

1.在項目文件中指定以下命令:

set_option enable_module_based_reporting yes

2.從“視圖”菜單中選擇“樹查看器”選項。下圖展示了樹查看器:

FIGURE 17. The tree viewer

確保在樹查看器中選擇了實例選項。

3.在instance視圖中右鍵單擊一個實例(如圖17中的F3)，并從快捷菜單中選擇instance選項的Show Messages。

執(zhí)行此步驟后，將根據(jù)F3實例過濾違規(guī)。如下圖所示:

FIGURE 18. GUI view before filtering violations based on instances

注意 :可以使用msg_inst_mod_report參數(shù)根據(jù)目標實例或根據(jù)公共模塊過濾違規(guī)。

除了實例層次結構視圖外，違例行為還可以在Msg樹視圖下進行過濾，如下圖所示:

清理過濾器

要清除過濾器并恢復出現(xiàn)所有違例，即頂層設計的完整視圖，右鍵單擊消息樹并從快捷菜單中選擇clear Message filter選項，如下圖所示:

FIGURE 20. Clearing the filter

保存信息

要保存違反消息，請右鍵單擊“消息樹”窗格并選擇“保存消息列表”選項。

注意 :在SpyGlass Explorer中，您可以為選擇的層次結構保存消息。更多信息，見SpyGlass Explorer用戶指南。

7.5

解決多種CDC共同的違例問題

在大量的SpyGlass CDC違例中，大多數(shù)是以下情況:

●不正確的設置

●可以安全忽略的明顯問題

本節(jié)描述了以下很多違例行為常見的根本原因:

●Crossing發(fā)生或者結束于black box

●錯誤的Case Analysis設置

●源Flip-Flops產生靜態(tài)信號

●噪聲

在關注rule相關的問題之前，應該首先考慮解決上述問題。解決了上述問題并重新運行SpyGlass CDC之后，您應該會看到更小、更易于管理的問題集。

注意:處理CDC問題時，千萬不要通過waving。如果你采用這種方法，就有可能掩蓋一個真正的問題。

7.5.1 Crossing發(fā)生或者結束于black box

SpyGlass CDC分析依據(jù)如下:

●能夠通過路徑進行跟蹤

●一定程度的功能性理解

在black box的上游和下游都無法實現(xiàn)上述目標。

要消除這個問題，特定的約束為SpyGlass CDC提供一個部分模型，如下所述:

●使用以下方法為black box的輸入輸出分配一個域:

●對black box輸出使用abstract_port約束

●對black box輸入使用signal_in_domain約束

●使用assume_path約束對從black box輸入到輸出建模為直通路徑。

7.5.2 錯誤的Case Analysis設置

檢查否正確地設置了set_case_analysis約束。

例如，你可能會看到錯誤的原因是，所有的功能模式和所有的測試模式都是同時激活的，而實際上這些模式中的許多模式永遠不會同時激活。要把test相關的信號用set_case_analysis約束。

7.5.3 源Flip-Flops產生靜態(tài)信號

如果源觸發(fā)器產生一個靜態(tài)信號，可能不需要同步。比如說配置信號，這些信號通常在開機/啟動時設置，然后不再更改。可以從芯片架構師獲得關于哪些信號屬于這種情況，并使用準靜態(tài)約束quasi_static 來約束這些信號。

7.5.4 噪聲(Noise)

在SpyGlass CDC驗證的主要挑戰(zhàn)之一是管理大量的違規(guī)。你可以通過特定的設置和設置檢查步驟來降低這些“噪聲”的干擾。

08

后記

CDC檢查是SOC RTL freeze之前必須要做的檢查，也是最重要的檢查之一。CDC檢查能夠提前發(fā)現(xiàn)功能時序仿真中發(fā)現(xiàn)不了的跨時鐘問題，極大的減少了芯片失敗的風險。系統(tǒng)的學習SpyGlass CDC流程，深入的理解CDC的各種問題，熟練的使用SpyGlass工具是一個資深的SOC設計人員必須具備的。

版權聲明：

本文作者：烓圍瑋未

首發(fā)于知乎專欄：芯片設計進階之路

轉發(fā)無需授權，請保留這段聲明。