功能覆蓋率應基於觀察

試驗平臺的激勵側應該用於驅動DUT，激勵側不應該用於覆蓋率，因為DUT或激勵可能無法正常工作，從而導致錯誤的覆蓋率。相反，功能覆蓋率應基於在測試平臺上DUT輸出處觀察到的情況。在UVM測試平臺中，功能覆蓋率將基於分析的事務內容。這對測試平臺的設計和分析的事務有影響。

功能覆蓋有效性

功能覆蓋率資料僅在通過檢查時有效。如果您沒有使用自動工具來合併來自不同模擬的覆蓋率，那麼您應該確保僅在測試通過時對覆蓋率模型進行取樣。

但是，如果您使用驗證管理工具從多個模擬中收集覆蓋率，則無需這樣做，因為失敗測試的覆蓋率結果不會與其他功能覆蓋率資料合併。

將負面檢測和正面檢查分開收集

如果驗證計劃要求對某個功能進行正面和負面測試，則分別設計並收集這兩種測試的功能覆蓋率。

設計用於分析的覆蓋模型

一個常見的錯誤是開發一個全面的功能覆蓋模型，但後來才意識到很難理解結果。使用可用的語言結構可以更容易地理解缺失的覆蓋範圍。換句話說，在建立功能覆蓋模型時，值得投入一些時間，以便在以後需要了解結果時節省時間。有關此主題的更多討論，請參見用於分析的覆蓋率設計頁面。

確定適當的忠於原設計的級別

需要與設計實現的細節有多接近？可以應用多少抽象？

在簡單的情況下，需要檢查的值相對較少，建立與設計細節密切相關的覆蓋率模型是一個可管理的問題。然而，當存在廣泛的值時，需要就在細節級別上做出謹慎的決定。例如，一個裝置具有大約20個可能值的配置可以很容易地直接建模，而像32位地址範圍這樣的東西需要拆分成一組有趣的值或值範圍，這需要一些抽象。

使用一致的編碼風格

使用一致的編碼風格來實現覆蓋組和斷言程式碼非常重要，因為這使它們更容易理解和解釋。它還使與驗證計劃和跟蹤工具的整合變得更容易。

有關覆蓋組編碼風格的示例，請參閱SystemVerilog編碼指南。請注意，實際使用的樣式並不重要，但使用一致的樣式很重要。

基於覆蓋組的覆蓋率注意事項

在設計基於覆蓋組的覆蓋率時，需要考慮許多基於設計的功能和特性的關鍵點。

哪個值是重要的？

通過簡單地指定由一個覆蓋點對一個變數進行取樣，可以很容易地以無知的方式收集資訊，這將導致自動生成2**n個bins，其中n是變數中的位數。對於窄寬度欄位，這可能是可以的，但對於更寬的欄位，這不太可能非常有用。在大多數情況下，將有許多重要的值或值範圍需要覆蓋，這些值或值範圍應從規範書中衍生出來，並作為一組bins編碼到coverpoint中。

資料變數之間的依賴關係是什麼?

在分析一個設計或資料包應該被配置為哪種方式時，不同變數之間是否存在關係？如果確實存在這種關係，則應在covergroup中指定變數之間的cross。

是否有需要檢查的邊界條件?

是否有特定值或值的組合需要檢查，因為它們處於操作極限或設計中的已知拐點？這必然需要一些規範書的“字裡行間的閱讀”，以及一些設計或實現知識。確定的任何邊界條件都應新增到覆蓋率模型中，以確保對其進行測試。

是否存在非法條件?

如果存在不應出現的情況，則covergroup可以使用一個術語來捕捉這些情況。該術語對功能覆蓋率沒有貢獻，但它可以幫助檢測設計或測試平臺錯誤。

是否有不重要的條件?

即使是最簡單的設計也可能有比實際使用更多的配置方式。如果有一種方法可以確定哪些模式最有可能被使用，那麼也有可能會有一些已知無用或不太可能被使用的模式，這些模式可以從收集的覆蓋率值排列中忽略。這裡也可能有一定程度的優先順序，某些配置必須進行測試，然後，如果有時間，可以檢查優先順序較低的配置。

什麼時候是取樣覆蓋率的合適時間?

資料覆蓋率收集程式碼需要對其引用的資料值進行取樣。取樣點需要：

• 僅在相關檢查通過時發生
• 資料值有效時發生
• 資料值穩定時

如果取樣基於接收UVM分析事務，那麼如果它直接來自監視器，則可能需要有一種方法來區分有效的和無效的分析流量。如果功能覆蓋率收集器從記分板接收分析事務，則記分板應在傳送分析事務之前確認檢查已通過。

是否存在資料覆蓋率取樣無效的情況?

如果有，則必須將編寫的守衛放入功能覆蓋實施程式碼中。

分析事務中需要哪些資訊?

對於基於TLM方法學（如OVM或UVM）的測試平臺，功能覆蓋所需的資訊需要來自分析事務。這意味著分析事務必須具有將被取樣的所有資訊，這很可能會影響事務以及生成事務的監視器或記分板的設計。

總結

在考慮如何測試設計功能以及該功能應該基於covergroup的功能覆蓋模型的什麼部分時，請記住回答以下問題：

時序覆蓋率考慮

控制路徑和協議依賴於訊號之間的時序關係來實現握手和傳輸。使用時態sequences和properties最容易驗證這些型別的關係。功能覆蓋率資訊可以通過以下幾種方式從這些檢查中獲得：

• 如果一個property被斷言且從未失敗，但可以顯示為已完成，則可以假定該屬性中描述的功能已被涵蓋
• 如果一個sequence完成，然後該序列中編碼的功能行為已被觀察到，且可假設功能覆蓋率
• 如果一個sequence完成，則可以對覆蓋組進行取樣，以檢查其在什麼條件下完成（混合覆蓋率）
• 如果一個property斷言通過，則可以使用通過宣告觸發covergroup的取樣，以檢查在什麼情況下通過（混合覆蓋）

檢查應該是具體的

一個property或sequence應該只檢查一個條件，在一個屬性或序列中檢查多個條件會導致功能覆蓋範圍中的錯誤識別。

如果使用一個sequence和/或融合操作符來定義property，然後，為了收集通過屬性的每個潛在路徑上的特定功能覆蓋率，必須將屬性展開並實現為特定於每個路徑的序列。

混合覆蓋

有時可能需要混合使用資料覆蓋率和時序覆蓋率技術來收集特定型別的功能覆蓋。例如，檢查協議傳輸的所有模式是否都已發生，最好的方法是寫入一個property或sequence，標識傳輸何時成功完成，然後根據協議的感興趣訊號欄位對覆蓋組進行取樣，以檢查是否出現了所有相關條件。

APB匯流排協議監視器包含使用混合功能覆蓋的示例實現。

功能覆蓋示例Functional Coverage Examples

不同的設計風格需要不同的方法來構建功能覆蓋模型。以下是一些成熟的示例，說明了一些常見的設計類：

程式設計分析

關注covergroups的實現是一項時間上的投資，當您或其他人需要了解缺失的功能覆蓋率在哪裡時，這種投資會得到回報。

覆蓋組標記

在對covergroup程式設計時使用標籤的方式對理解覆蓋率結果有很大影響。可以為covergroup分配一個選項。名稱字串，有助於識別覆蓋範圍與測試平臺的哪個特定部分相關。在covergroup中，coverpoints可以被標記，bins可以被命名。使用所有這些技術，在分析過程中更容易理解覆蓋率結果。

覆蓋組命名

如果一個測試平臺中使用了相同covergroup的多個例項，則option.name引數可用於為每個例項分配標識字串。構造covergroup時，可以將名稱字串作為引數傳入。在UVM環境中，可以使用get_full_name()方法傳入名稱。請參見下面的程式碼示例。

covergroup還可以使用covergroup以程式設計方式命名的set_inst_name()內建方法。

Coverpoint和bins標籤

作為一個例子，考慮下面來自於UART例子的功能覆蓋問題。在本例中，UART字格式由線路控制暫存器（Line Control Register, LCR）的內容決定：

更低的分析潛力

更高的分析潛力

為了檢查所有可能的文字格式是否都已傳輸，我們可以通過為LCR[5:0]建立覆蓋點來實現覆蓋組，而不指定任何bins。這將建立一組預設bins，每個bins對應於暫存器的每個可能值，如左側程式碼示例所示。如果功能覆蓋率收集的這些位至少採樣一次，則沒有問題，但如果沒有，則很難確定哪個箱子對應於哪個條件——請參閱Questa 覆蓋組瀏覽器中的“之前”螢幕截圖。在這裡，不使用標籤導致模擬器使用自動bins，這意味著需要將缺少的箱子值轉換為二進位制，然後對映到暫存器欄位以識別缺少的配置。

實現covergroup的更好方法是為每個暫存器欄位使用帶標籤的coverpoint，然後為暫存器真值表中的每個值使用bins語法。當進行模擬時，建立的向量積反映了不同的bins標籤，這使得確定哪些功能覆蓋條件沒有被取樣變得更加容易。它還可以更容易地檢視是否存在遺漏的總覆蓋條件。請參閱Questa 覆蓋組GUI中重構的“之後”螢幕截圖。

Covergroup選項如何影響覆蓋率的報告和計算

實現選項

功能覆蓋率資訊的分析受覆蓋結果報告方式的影響。covergroup有三個選項會影響覆蓋率報告，並可能造成相當大的混亂，它們是：

• option.per_instance
• option.get_inst_coverage
• type_option.merge_instances

如果在實現covergroup的程式碼中未指定這些選項，則預設情況下不會啟用這些選項。換句話說，它們被設定為0。

這三個選項應在covergroup中明確宣告，以確保覆蓋率計算和報告一致且符合要求。

Covergroup型別和例項

當一個covergroup被宣告時，它就變成了一種可以在測試平臺中多次例項化的型別——例如，在一個設計中，同一型別的介面用於多個埠，因此同一covergroup用於測量協議覆蓋率。預設的覆蓋率報告方法是將covergroup型別的覆蓋率報告為該型別所有covergroup覆蓋率的加權平均值。這意味著，如果其中一個埠已經實現了100%的覆蓋率，而其他埠沒有，那麼報告的覆蓋率將不低於100%，並且無法分析哪些介面尚未實現。

per_instance選項

如果covergroup中option.per_instance設定為1，則covergroup報告將按每個例項進行細分，但報告的總體覆蓋率仍然是加權平均值。在引用的示例中，這將使每個埠的覆蓋範圍都能被檢查，可能會導致檢測到設計缺陷或激勵生成中的缺陷。

merge_instances 選項

如果covergroup中的type_option.merge_instances設定為1，則covergroup的所有例項報告的總體覆蓋率是所有覆蓋率的合併或邏輯or，而不是加權平均值。如果您有相同設計IP的多個例項，並且測試平臺的不同部分以不同的方式使用它，那麼這可能很有用。使用merge_instances選項的一個結果是，一個covergroup例項達到100%覆蓋率，而另一個例項達到0%覆蓋率，此後總體覆蓋率將報告為100%。

get_inst_coverage選項

要做到使能merge_instances選項的情況，option.get_inst_coverage的值設定為1，以啟用SystemVerilog的$get_inst_coverage()系統呼叫返回covergroup例項的覆蓋率，從而允許檢查所有單個例項的覆蓋率。如果merge_instances選項設定為0，則get_inst_coverage變數無效。

總結Summary

per_instance和merge_instances設定之間的互動：

merge_instances 和 get_inst_coverage之間的互動

特定於模擬器的執行時選項

所描述的選項是SystemVerilog LRM中定義的covergroup選項，因此可以新增到covergroup程式碼中。模擬器還添加了命令列選項，允許使用者更改報告覆蓋率的方式，儘管這些選項往往是全域性性的，會影響被模擬測試平臺中的所有覆蓋組。

覆蓋率例子 (實踐)

匯流排協議覆蓋率

匯流排協議定義了總線上主裝置和從裝置之間的資料傳輸方式。協議規定了當主裝置發出請求時，以及當從裝置準備好響應該請求時，使用哪些訊號來確認。驗證匯流排協議的一種方法是將協議監視器實現為SystemVerilog介面，該介面使用SVA併發斷言和CoverGroup的混合，以檢查它觀察到的匯流排通訊量是否符合協議，並收集關於總線上發生的傳輸型別的功能覆蓋資訊。協議監控器是一種被動驗證元件，用於監控協議訊號，它可以連線到測試臺頂層的外部訊號，也可以繫結到設計內部的內部匯流排訊號。匯流排協議監視器是可重用驗證元件的一個很好的例子。

APB3 協議概述

ARM AMBA APB3協議是一個簡單的外圍匯流排協議的示例，可用於說明與實現協議監視器相關的要點，並說明如何使用它來收集功能覆蓋資訊。

使用APB3協議，一個主裝置可以與多個從裝置進行介面。主裝置為所有從裝置通用的地址、寫入和寫入資料生成一組控制欄位。每個從機由一個單獨的外圍選擇線（PSEL）選擇，然後由一個通用的PENABLE訊號啟用。每個從機生成響應訊號、就緒、讀取資料和狀態，這些訊號被多路複用地傳輸回主機。方框圖顯示了典型的APB3外圍模組。

APB3訊號之間的時序關係如下圖所示。

Deriving The Protocol Properties

開始定義屬性的最簡單方法是用英語為每個協議規則編寫簡單明確的描述。一旦定義並達成一致，那麼實現斷言程式碼通常是相對簡單的。

以下概述的屬性也總結為測試計劃。

對於APB協議，我們可以定義以下內容：

未知的(X, Z) 訊號

如果協議訊號處於未定義狀態，則在某些情況下會導致問題。檢查未知訊號狀態的屬性在除錯設計的早期階段很有用，但在驗證的後期階段不太有用。然而，它們確實說明了功能覆蓋率集合的第一種型別——成功且永不失敗的屬性證明了該屬性的功能覆蓋率。

對於APB3協議，以下未知訊號規則為真：

• PSEL應始終處於已知狀態
• 如果至少有一條PSEL線處於邏輯1，則以下控制場訊號也應處於已知狀態
• PADDR
• PENABLE
• PWRITE
• 如果至少有一條PSEL線位於邏輯1，且PWRITE位於邏輯1，則PWDATA應處於已知狀態
• 如果PSEL和PENABLE均為邏輯1，則PREADY應處於已知狀態
• 如果PREADY處於邏輯1，則PSLVERR應處於已知狀態
• 如果PWRITE處於邏輯0，且PREADY處於邏輯1，則PRDATA應處於已知狀態

另一種方法是要求所有匯流排訊號必須始終處於已知狀態，但這可能並不總是可行的，而定義的屬性是協議在所有條件下正常工作的最低要求。

有關示例實現，請參見示例的未知訊號屬性部分。

時間關係

協議中的訊號之間的定時關係可以使用sequences和properties來描述。如果一個被覆蓋的sequence完成，或者一個斷言和被覆蓋的覆蓋屬性通過，那麼可以為相關函式假定功能覆蓋率。對於APB3協議，可以定義以下時序關係：

• 一旦在邏輯1處對PREADY進行取樣，PENABLE將在下一個時鐘邊緣處變低
• 當PSEL線進入邏輯1時，以下訊號應保持穩定，直到在邏輯1處對PREADY進行取樣時迴圈結束
• PSEL
• PWRITE
• PADDR
• PWDATA (iff PWRITE處於邏輯1)
• 匯流排傳輸之間至少應有一個時鐘週期，其中PENABLE為邏輯0
• 當PSEL線路連線到邏輯1時，PENABLE應連線到以下時鐘邊緣上的邏輯1。有關這些屬性的實現，請參見示例頁面上的時序關係部分