功能覆蓋率

功能驗證的目的是確定我們規範中定義的設計要求是否按預期執行。但是，您如何知道所有指定的功能是否都實際實現了呢？此外，我們如何知道是否所有指定的功能都經過了真正的測試？程式碼覆蓋率指標無法幫助我們回答這些問題。

在本節中，我們將介紹一種稱為功能覆蓋率的顯式覆蓋率指標，它可以與設計規範書或實現覆蓋率空間相關聯。測量功能覆蓋率的目的是測量與設計功能要求相關的驗證進度。也就是說，功能覆蓋幫助我們回答這個問題：是否所有指定的功能需求都已實現，然後在模擬過程中執行？關於如何建立功能覆蓋模型的詳細資訊將在功能覆蓋率測試計劃一章中單獨討論。

優點:

功能覆蓋的起源可以追溯到20世紀90年代，當時出現了受約束的隨機模擬。顯然，受約束的隨機激勵生成的價值主張之一是，模擬環境可以自動生成數千個測試，這些測試通常需要大量的手動工作來建立定向測試。然而，受約束的隨機激勵生成的一個問題是，如果沒有在模擬執行後冗長乏味地檢查波形的努力，你永遠無法確切知道測試了哪些功能。因此，功能覆蓋率被髮明為一種測量方法，以幫助準確確定模擬迴歸測試的功能，而無需對波形進行目視檢查。

如今，功能覆蓋的採用不僅限於受約束的隨機模擬環境。事實上，功能覆蓋率提供了一種在模擬期間執行需求跟蹤的自動方法，這通常是DO-254合規性檢查所需的關鍵步驟。例如，功能覆蓋可以通過連結到規範書中定義的特定需求的機制來實現。然後，在模擬執行之後，通過特定的定向或受約束的隨機測試檢查的需求，可以自動被測量，從未測試過的需求得到自動確定。

侷限:

由於功能覆蓋率不是一個隱含的覆蓋率指標，所以無法自動提取。因此，這需要使用者手動建立覆蓋率模型。從上層來看，建立功能覆蓋模型需要考慮兩個不同的步驟：

1. 確定您要測量的功能或設計意圖
2. 實現測量功能或設計意圖的機制

第一步是通過驗證計劃來解決，詳細內容將在從測試計劃到功能覆蓋的部分中介紹。

第二步涉及對驗證計劃步驟中確定的每個覆蓋專案的機制進行編碼（例如，為驗證計劃中確定的每個驗證目標編碼一組SystemVerilog CoverGroup）。在覆蓋模型實施階段，還需要考慮許多細節，例如：確定觸發測量的適當點，以及為了測量而定義的可控性（禁用/啟用）方面。這些和許多其他細節將在詳細的覆蓋率示例中解決。

由於功能覆蓋率必須手動建立，因此在覆蓋率模型中始終存在某些指定功能缺失的風險。

功能覆蓋率指標的型別

任何設計的功能行為，至少從驗證環境中的任何介面觀察到的，都由資料和時序元件組成。因此，從高上層來看，我們需要考慮兩種主要型別的功能覆蓋度量：覆蓋組和覆蓋屬性。

覆蓋組建模

關於功能覆蓋率，設計模型內或介面上狀態值的取樣可能是最容易理解的。我們將這種形式的功能覆蓋稱為覆蓋組建模。它由總線上觀察到的狀態值、介面控制訊號分組以及暫存器組成。關鍵是，被測量的值出現在一個單獨的顯式或隱式取樣的時間點上。SystemVerilog covergroups是我們通常用於構建功能資料覆蓋模型的機制的一部分，詳細資訊將在塊級設計示例以及相應covergroups實現的示例討論中討論。

覆蓋屬性建模

就功能覆蓋而言，在事件序列之間的時序關係可能是最難解釋的。然而，確保對這些事件序列進行適當測試是很重要的。我們使用覆蓋屬性建模來度量事件序列之間的時序關係。覆蓋屬性最流行的例子可能涉及匯流排協議上控制訊號之間的握手序列。其他示例包括與驗證低功耗設計相關的電源狀態轉換覆蓋率。斷言和覆蓋屬性是我們用來構建時序覆蓋模型的機制的一部分，它們在匯流排協議監視器示例中進行了說明。。

斷言覆蓋率

斷言覆蓋率一詞在當今行業中有很多含義。例如，有些人將斷言覆蓋率定義為斷言數與RTL程式碼行數的比率。然而，斷言密度通常是一個用於此度量的更準確術語。在我們的討論中，我們使用術語斷言覆蓋率來描述使用斷言的覆蓋率屬性的實現。

覆蓋組和覆蓋屬性的不同之處

為了幫助說明使用覆蓋組和覆蓋屬性建模的覆蓋之間的區別，讓我們看一個簡單非流水線的匯流排示例，如圖1所示。

非流水線匯流排協議的一個寫和讀匯流排序列如圖2所示。

為了驗證我們的匯流排示例，測試地址匯流排的寫序列和讀序列的邊界條件（即addr中某些點位包含全零和全一）很重要。此外，在迴歸過程中，我們在地址總線上覆蓋了足夠多的非邊界條件，這一點也很重要。我們只感興趣的是在從機被選中且選通使能啟用時（即sel==1'b1&&en==1'b1）對地址匯流排進行取樣。最後，我們希望跟蹤這些覆蓋項的單獨寫入和讀取事件，以確保我們已經充分測試了這兩個操作。

這是使用覆蓋組對功能覆蓋建模的一個示例（例如SystemVerilog covergroup構建）。此外，我們可以使用相同的資料覆蓋率方法來測量讀寫資料匯流排。

現在，讓我們看看這個例子中的覆蓋屬性。寫入和讀取週期都遵循標準順序。例如，讓我們檢查一個寫週期。在時鐘1，由於從機選擇（sel）和匯流排啟用（en）訊號都被取消斷言，我們的匯流排處於INACTIVE狀態。寫入序列的第一個時鐘稱為匯流排START狀態，主機通過斷言一條從選擇線（sel==1'b1）來啟動匯流排初始化。在START狀態期間，主機在總線上放置有效地址和有效資料。資料傳輸（稱為匯流排ACTIVE狀態）實際上發生在主機斷言匯流排啟用選通訊號（en）時。在我們的例子中，它是在時鐘3的上升沿檢測到的。地址、資料和控制訊號在整個ACTIVE狀態下都保持有效。

當ACTIVE狀態完成時，匯流排使能選通訊號被匯流排主機取消斷言，從而完成當前的單次寫入操作。如果主裝置已完成將所有資料傳輸至從裝置（即，不再有寫入操作），則主裝置將取消斷言從裝置選擇訊號（sel）。否則，從機選擇訊號保持斷言狀態，匯流排返回到匯流排START狀態以啟動新的寫入操作。多個背對背寫入操作（不返回匯流排INACTIVE狀態）稱為突發寫入。

從時序覆蓋的角度來看，可以編寫一組斷言，以確保對總線上的狀態序列的正確。例如，圖3顯示了唯一合法的匯流排狀態轉換。此外，測試單個寫入和讀取週期以及寫入操作中的突發讀取非常重要。事實上，我們可能想要測量各種突發寫入和讀取週期。

通過組合覆蓋組和覆蓋屬性，我們能夠實現更高忠實原設計的覆蓋模型，從而更準確地測量設計的關鍵特徵。

APB3匯流排協議監視器示例中介紹瞭如何對時間覆蓋進行編碼的詳細資訊。

典型功能覆蓋率流程

在許多方面，典型的功能覆蓋率流程與典型的程式碼覆蓋率流程非常相似。收集和分析功能覆蓋率指標的目的是從規範書中識別當前驗證環境和在其上執行的測試用例尚未執行的特性和需求。從專案的角度來看，通常最好等到與覆蓋率相關的測試用例的實現接近完成，然後才開始認真地收集和分析功能覆蓋結果。否則，您可能會浪費大量的週期去試圖從不斷變化的激勵中理解移動的目標。話雖如此，我們建議您至少在專案週期的早期（即，在認真收集覆蓋指標之前）執行一些捕獲覆蓋率指標的模擬，以解決覆蓋流程中的任何潛在問題。

從高層次的角度來看，功能覆蓋率流程通常參與了四個主要步驟，包括：

1. 建立功能覆蓋模型Create a functional coverage model
2. 如果使用斷言，則測試RTL模型收集覆蓋率
3. 執行模擬以捕獲和記錄覆蓋率指標
4. 報告並分析覆蓋結果

分析步驟的一部分是識別覆蓋盲區，並確定覆蓋盲區是否由以下三種情況之一造成：

1. 缺少啟用未覆蓋功能所需的輸入激勵
2. 設計（或testbench）中的一個缺陷，阻止輸入激勵啟用未覆蓋的功能
3. 某些IP配置未使用的功能，或在正常執行條件下預期無法實現的相關功能

第一個條件要求您要麼編寫額外的定向測試，要麼調整隨機約束，以生成針對未覆蓋功能的所需輸入激勵。第二個條件顯然要求工程師修復阻止未覆蓋功能執行的缺陷。第三種情況可以通過設定覆蓋工具在覆蓋記錄和報告步驟中排除未使用或無法訪問的功能來解決。

規格書到測試計劃

測試計劃建立方法

建立覆蓋率模型電子表格或測試計劃的目標是捕獲關於功能覆蓋率的設計意圖和行為的子集。這是一個耗時的手動過程，需要梳理各種設計規範檔案，並一次提取一個必要的需求。最好由一個由架構師、設計師、韌體和驗證工程師組成的跨職能團隊來完成，以獲得多個觀點和不同的輸入。如果沒有跨職能方面，設計意圖的各類子集很容易被忽略。建立測試計劃的最佳方式是召開多次會議，每次會議針對一個特定的設計區域（xyz區塊），並持續一段固定的時間（1小時，下週每天早上9點）和一個目標（50個要求）。一般來說，可以採取兩種方法：

1.自下而上：逐塊或逐介面檢查

2.自上而下：遵循晶片的使用模型或資料流。

兩種方法

在自下而上和自上而下的方法之間選擇

通常可以使用自上而下和自下而上的組合。你可以從一個自上而下的流程開始，繪製出主要的流程，自然地產生類別，然後對每個類別進行自下而上的操作。在專案開始時，一旦某種形式的設計規範書準備好，那這樣做是明智的。首先提取幾百個需求，將它們放入電子表格，然後隨著專案的進展新增更多需求。一些團隊在提取和細化每個需求時，會立即將每個需求和覆蓋元素相連結。其他人則將所有需求輸入電子表格，然後進行第二次檢查以新增隨後的覆蓋率連結。沒有哪一種方法比另一種好，重要的是在你對特定需求細節記憶猶新的時候完成覆蓋率連結。將連結留到專案的後期，意味著您必須重新檢視每個需求及其相關文件，這將花費更長的時間。

自下而上的例子

下面是帶有TX和RX路徑的乙太網晶片的框圖。每條路徑都有乙太網幀通過的塊管道。在各種配置下，其中一些塊可以被複用輸入或複用輸出。此外，還有各種時鐘配置，每個模組都有自己的配置設定細節。通過自下而上的方法，我們將檢查每個模組的設計規範，並提取出該模組的需求。我們還將檢查全域性塊和時鐘多路複用設定，並提取出每個設定的要求。關鍵是將工作劃分為小的、可消化的塊或子塊，以便在合理的時間內輕鬆提取詳細的需求和行為。

要開始自下而上的方法，你需要做的第一件事是儘可能多地聚集了解設計的人，包括架構師、設計師、驗證團隊、各種介面的專家等等。接下來，一個團隊需要將工作細分為一些邏輯上的、可管理的規模。這可以通過我的頭腦風暴圖來完成，也被稱為思維導圖。微軟的Visio和類似的軟體可以在團隊一起集思廣益時輕鬆捕獲這些型別的圖表。每個主題或子模組可以根據需要被進一步分解，它們都在頭腦風暴圖中相互關聯。下面的頭腦風暴圖顯示了乙太網晶片的一個簡單示例。對於更復雜的設計，頭腦風暴圖將有更多的子類別從每個塊分支出來，將需求提取工作劃分為可管理的數量。頭腦風暴圖中的每個分支可能最終成為乙太網測試計劃中相應的一個類別或子類別，或者如果很大，可能是它自己的分層電子表格。一些思維導圖軟體可以利用這些頭腦風暴圖，將資訊匯出到電子表格中，其中包含每個類別和子類別的章節號。這為您的測試計劃提供了一個很好的起點和現成的框架。

頭腦風暴圖是一個很好的開始。然後可以分解每個分組或分支，並召開測試計劃建立會議，以充實該特定主題的需求。在每次會議上，收集所有可用的設計和實現規範，以及該區塊或主題的任何行業規範，以便參考。

一旦你有了一個主題，你就可以使用黃色粘滯法[1]，給一個團隊提供便利貼，他們花20分鐘把需求提取到黃色的便利貼上，然後把便利貼都貼在白板上，以便進一步分類。規則和特徵被提取到詳細的需求中，然後每一個都作為一行輸入到一個帶有標題的電子表格中，以及一個描述該需求本質的簡要描述。請參閱下面關於需求的注意事項部分。

在每個需求中新增某種獨特的字母數字需求標籤號是一個好主意，尤其是當您有多個級別的需求時。然後可以使用這些標籤將更高級別的需求與更低級別的需求聯絡起來，反之亦然。需求跟蹤工具，比如ReqTracer，可以通過自動跟蹤所有需求來進一步控制需求標籤的命名和幫助。另一個好主意是新增其他有用的資訊，這將有助於指導每個需求的進一步工作。這些額外的有用資訊可能是需求來自規範中的位置、作者、註釋、優先順序、估計的工作量、稍後要回答的問題，等等。最後，每個需求都需要連結到一些特定的閉包元素，比如covergroup、coverpoint、cross、assertion、test、，等等。對每個被細化的需求進行第二次檢查，並確定優先順序是個好主意。有關推薦格式的描述和示例，請參見測試計劃格式頁面。

覆蓋率烹飪書中的apb監視器、uart和datapath示例使用自下而上的規劃方法。

[1] The Yellow Sticky Method is described in more detail in the book - Verification Plans: The Five-Day Verification Strategy for Modern Hardware Verification Languages by Peet James, Springer 2003.

關於編寫需求的指導原則可以在“需求編寫指南”一文中找到。在開始規劃過程之前，核查小組最好先編制一份這樣的清單，並將其分為規則（必須遵守）和建議（好主意）。實際上，這是為編寫需求定義需求。

自上而下的例子

自上而下的方法可用於和自下而上相同的通用乙太網設計。我們開發並遵循設計如何被用於實際應用的流程，而不是逐塊進行。我們遵循晶片的使用模式，或者有時候叫做晶片的“生命中的一天”。電源接通了。先發生什麼？然後呢？等等。對於這種乙太網晶片，高層次使用模型有以下流程：

1。設定/配置

-塊多路複用器配置

-時鐘多路複用器配置

-然後配置每個塊

2.資料路由

3.意外事件（LOS、錯誤等）

接下來，拓展這個基本的高階流程，展開更多細節。你可以一行一行地做，或者通過路徑或模式來做。例如，可能某些塊和時鐘組合被命名為模式，因此您可以按模式深入瞭解更多細節。你也可以遵循一條路徑，比如系統到線路，線路到系統。

這種方法的一個常見問題是，即使採用這種乙太網流水線的設計，其流程簡單，需求也很容易呈指數級爆炸，形成看起來太多的組合。這是很常見的，因此需要將爆炸重新處理為一些邏輯故障，如下圖所示：

當你看上圖中的兩個部分時，左邊的指數圖看起來像一個巨大的不可關閉的覆蓋組，而右邊的覆蓋組和覆蓋點則是每個表格或圖表的自然沉降物。因此，你取高層次使用模型流程的每個部分，然後你用任何表格或圖表來展開每個部分，這些表格或圖表對包含那些指數增長的特定的部分很有用。例如，在設定/配置的上述塊muxing部分中，您可以開發一個潛在有用的設定表，並對每個設定進行命名。在其他情況下，Y-樹、序列、氣泡圖或其他一些圖表會更有用。通常，最好將高層次的使用模型流程和所有這些圖表收集到一個新的使用模型文件中，並用最少的文字混合。

使用最能體現使用模型的每個領域指數性質的表格、圖表或圖表：

• 表格適用於小空間，如暫存器欄位的幾位或行為列表。
• 氣泡圖可以很好地顯示任務或專案之間的關係，如電源區域及其設定。
• Y樹圖有助於顯示選擇和決策、and和or、優先順序。
• 序列圖顯示了進展、因果、握手
• 始終可以將圖表組合在一起，如上面的一組表格，通過線連線

參見WB SOC設計示例，瞭解這些圖表在覆蓋率上下文中如何使用的使用模型。

一旦你將你的使用模型分解成一個有用的圖表和表格的漸進集合，最好將它們放在一個文件中，以便於檢視和傳播。有些團隊將它們組合成一個大的圖表;其他人將圖表放在一起，在圖之間用描述性的資訊幻燈片進行演示。這些圖表的其他格式包括文件（作為設計架構或實現規範的一章分割或新增）或作為專案網站的html檔案。演示格式是最常見、最有用的。收集檔案可以有許多名稱，例如：

• UMD: Use model document（使用模型文件）
• DITL: Day in the life document（生命文件中的日期）
• CAD: Coverage Architecture Document（覆蓋架構檔案）

無論您如何稱呼該文件，該文件通常都非常有用，可以將新的團隊成員引入到設計中，為他們提供清晰的概述。隨著驗證專案的進展，團隊通常會回到本文件和這些圖表，以充實更多細節。

一旦你有了UMD，你的驗證團隊就可以把它作為編寫測試計劃的指南。他們可以對其進行梳理，提取出需求，並將其放入測試計劃中。他們可以將流程圖、曲線圖和表格製作成電子表格中的一個部分或子部分，如果很大，也可以將其分解成自己的分層電子表格。關鍵是要劃分類別和子類別，以便每個電子表格行鍼對單個需求，並且可以有效地連結到某個覆蓋元素。另一個關鍵是在大致相同的級別編寫每個需求。氣泡圖中的每個氣泡可能是單個需求，也可能是整個需求的一個子部分。Y樹圖上的每個選項可能是一個或多個需求。每個表可以是一個覆蓋範圍組、每行或每列、一個覆蓋點。

從UMD中提取需求通常遵循與上述相同的自底向上提取過程。由於UMD及其圖表的固有流程，UMD通常使其更容易實現。通過實踐，驗證團隊將開始更容易地視覺化覆蓋組和覆蓋點，只需檢視其UMD中的所有圖表。就像自下而上的方法將連結和型別新增到覆蓋組一樣，coverpoint、cross、assertion或test最好在編寫需求時完成。

有關如何獲取UMD內容和建立測試計劃電子表格的更多詳細資訊，請參見Wishbone SOC示例部分。

測試計劃審查

驗證過程有許多重要方面，需要驗證小組投入時間和精力。testbench的構建、測試的執行、時間表等，往往優先於覆蓋模型測試計劃電子表格，其開發被推遲。通常，會建立一個初步的測試計劃，但忽略了與實際功能覆蓋要素的連結。結果是覆蓋率實施不佳，覆蓋率結果很低。團隊最終在黑暗中驗證，讓隨機生成發生，但不使用覆蓋率作為反饋指導驗證得出任何結論或關閉驗證。他們採用了一種“足夠好”的覆蓋率方法，而不是基於任何真實的覆蓋率指標資料。有一個良好的測試計劃，其中包含定義良好的需求，每個需求都與真實的覆蓋率元素連結是關鍵。花時間制定這個測試計劃從長遠來看會有回報。在編寫需求時新增連結是最好的方法。它還確保團隊不必重新檢視獲取靈感的每個需求的所有文件。為了避免這個問題，成熟的驗證團隊按照良好的文件或程式碼審查流程實現了一個測試計劃審查流程。三階段流程通常效果良好：

1. 初步審查：儘早制定測試計劃，並儘早進行第一次審查。這是一個快速的回顧，以確保測試計劃已經建立，有覆蓋率連結和型別，並且在正確的道路上。它不需要是完美的，但需要是當時能做到的最好的。它將在專案過程中不斷髮展。
2. 主要評審：在一個專案中大約三分之二的時間裡，真正的評審會發生。測試計劃是覆蓋模型，它定義了設計行為和意圖的一個優先子集。這裡的目標是確保優先順序和選擇的子集是正確的。你不能包羅永珍。你不可能核實每件事。團隊必須選擇他們的子集，並在分配的時間內進行最多的驗證和覆蓋。這項檢查需要一些時間，通常需要2-5天。對測試計劃進行了詳細審查，確保每一行的要求都是明確的，並通過覆蓋率連結得到滿足。所有問題都得到了解決，並輸入到錯誤跟蹤工具中。通常需要某種形式的需求重組來更新測試計劃。它可能需要新增內容以適應缺失的內容或設計更改，但通常必須減少，以便在剩餘的計劃時間內實際完成。通常會發生優先順序調整，一些工作會轉移到未來的流程中。審查的目標是發現並修復覆蓋率模型測試計劃電子表格中的任何重大問題或缺失部分。
3. 最終審查：該審查在專案的最後幾周進行，如果其他兩次審查都做得很好，則是對該計劃有效性的最終確認。所有重大問題都應該被發現並解決。在最終評審中，將新增異常細節，並在測試計劃結束前解決所有最終問題。

這個測試計劃評審過程通常與一個類似的三步程式碼評審過程結合在一起，在這個過程中，rtl和testbench程式碼被評審。

可執行測試計劃格式

測試計劃是一份文件，它捕獲了設計的重要特性，以及如何驗證這些特性。

建立測試計劃的目的

功能驗證被描述為SoC設計中的一個主要挑戰，許多人認為驗證過程的可見性不足是導致這一挑戰的主要因素。

這種可見性的缺乏會影響設計質量、進度可預測性和成本（資源/工具/基礎設施）。

驗證經理需要回答的典型問題是：我們什麼時候完成驗證？是否驗證了系統的所有關鍵要求？我們是否充分利用所有驗證資源來滿足專案進度？

通過制定一個可執行計劃，捕獲我們驗證意圖的優先列表，我們能夠做到以下幾點：

• 更好地組織自己。不可能完全驗證設計的所有狀態，但我們可以確定所有關鍵、重要和較好的特性，然後制定計劃，確保所有關鍵和一些重要特性在計劃內得到充分驗證。如果時間表允許，還可以驗證其他功能
• 在驗證專案的日常執行過程中，可執行計劃可以幫助您瞭解當前狀態。現在可以立即跟蹤進度，因為您可以確切地看到相對於您想要驗證的內容，您處於什麼位置。您可以根據里程碑、功能的優先順序，甚至資源來視覺化這個進度
• 在專案執行過程中，幫助管理功能覆蓋率關閉。驗證工程師可以將他們的覆蓋率關閉工作集中在已被確定為漏洞的關鍵特性上，然後是重要特性，然後是“較好的”特性

建立測試計劃

在許多情況下，功能將在模擬中驗證，並使用程式碼覆蓋率或功能覆蓋率記錄為已驗證。測試計劃還可以包括有關實驗室驗證和韌體/硬體整合測試的資訊。對於包含程式碼覆蓋率和功能覆蓋率的測試計劃，測試計劃和模擬之間的連線可以自動化。要使測試計劃可執行，必須遵循特定的文件格式。Questa的驗證管理解決方案使用的格式如下所述。

捕獲測試計劃

靈活性是將測試計劃連線到模擬器的關鍵。在Questa驗證管理的案例中，幾種不同的原始檔格式是有效的。唯一的要求是源文件必須能夠匯出為XML文件。例如，Microsoft Word、Microsoft Excel、OpenOffice Writer、OpenOffice Calc和Adobe FrameMaker都可以輕鬆輸出XML文件，這些文件可以進行處理並使其可執行。事實上，在Word和Excel中分別捕獲測試計劃的一部分是完全可以接受的。然後，這些不同的部分可以組合在一起，正如下面重用現有測試計劃部分所述。

在不同的輸入選項中，電子表格是最常用的，並且非常適合測試計劃中捕獲的資料型別。電子表格格式為視覺化驗證意圖提供了一種簡潔明瞭的方法。本文的其餘部分將描述電子表格中所需的資訊，以及如何靈活地新增額外的資訊，以便在整個測試計劃的生命週期中使用。

測試計劃的內容

將測試需求捕獲到計劃中是一個過程。這個過程在規範書到測試計劃一文中有定義。該過程包括對規範書的嚴格分析、架構、設計和驗證團隊之間的協作，以及確保不遺漏任何內容的評審。這個過程中產生的所有需求都需要在測試計劃中使用一些必需的結構進行捕獲。所需的結構允許測試計劃成為可執行的，併成為驗證週期的一部分。

所需的計劃結構

Questa的驗證管理解決方案需要為每個捕獲的需求提供四條不同的資訊。它們是章節、標題、連結和型別。此外，其他資訊是開箱即用的。每個需求的附加資訊包括描述、權重和目標。雖然這些附加欄位不是必需的，但它們大部分時間都在使用。Questa的驗證管理解決方案還具有允許使用者定義欄位的靈活性。

如果我們檢視電子表格格式中通常使用的欄位，每個欄位都由電子表格中的一列表示。

電子表格中的每一行對應於測試計劃建立過程中捕獲的需求。在Questa的驗證管理解決方案中，每一列都有特定的含義。

章節（Section）和標題（Title）

章節和標題列協同工作，在測試計劃中建立命名和層次結構。

章節

章節列通常是一個數字，用於在測試計劃中建立層次結構，並將相關的測試計劃項以父/子關係組合在一起。在電子表格中，使用者負責輸入這些資訊。通常，您將以數字“1”開始對節進行編號，然後按順序繼續。然後，該部分下的一個子部分將被編號為“1.1”，以此類推，其中每一個額外的層級將通過新增“.”來表示在分割槽號之間。

標題

標題列描述要驗證的需求或設計特徵的名稱。這是將出現在Questa中測試部分的名稱。此處選擇的名稱應有其含義，因為它將通過工具流程可見。

當Questa提取測試計劃時，它使用章節和標題列中的資訊為testplan的每一行建立層次名稱和唯一標記。例如，考慮到上面簡單的測試計劃示例，第1.1節將有一個分層名稱/testplan/Parent_1/Child_1。

描述

描述列允許向電子表格中新增更多詳細資訊。這可能包括對其他檔案的引用，以允許工程師收集更多資訊，也可能是對需求存在原因的簡單解釋。任何文字都可以在此列中引起注意。它在技術上是可選的，但在實踐中，測試計劃中需注意的需求應該在描述列中有一個條目。

連結和型別

連結和型別列用於明確指出和需求連結的程式碼或功能覆蓋率項。一個需求可以連結到多個不同的覆蓋率指標，包括不同型別的指標。Questa支援連結到CoverGroup、Coverpoints、Cross、Assertions、Cover指令、定向測試和程式碼覆蓋度量型別。這些列還允許像重用現有測試計劃一節中描述的那樣，匯入其他測試計劃。

連結

在該列中，您可以指定在覆蓋率資料庫中連結到相應測試計劃項的實際覆蓋率物件的名稱。這可能包括一個特定的covergroup例項、一個assertion等。

型別

在這個列中，您指定了連結列中指定的覆蓋率物件的型別。

連結和型別列資訊一起用於高效地在覆蓋率資料庫中找到相應的覆蓋率物件，並在測試計劃和指定的覆蓋率物件之間建立連結。這些列使測試計劃成為可執行的。

權重

權重列記錄一個整數，該整數反映當前測試計劃項在其同級中相對於其父測試計劃部分的相對重要性。如果未指定，則預設值為1。Questa使用“加權平均”計算演算法計算測試計劃的覆蓋率時，會考慮這些權重。有關Questa如何計算測試計劃覆蓋率的更多資訊，請參閱Questa關於驗證管理的文件。

此外，權重列可以通過為需要排除的測試計劃節/專案行指定0值來排除測試計劃的部分。

目標

此列指定特定測試計劃部分的驗證目標。合法值的範圍為1到100，如果未指定，預設值為100。Questa使用此資訊確定測試計劃部分/部件被視為涵蓋的點。它不會改變覆蓋率的計算方式。

使用Questa理解其它列

覆蓋率測試計劃中還可以使用其他特殊用途的列。這些列都是可選的，但是當它們出現時，Questa會利用它們的內容。

路徑

連結到covergroup的特定例項時，存在兩個選項。可選地，可以將覆蓋組的完整分層路徑新增到連結列中。如果在該設計層次結構的級別上只訪問一個coverge項，那麼這種方法非常有效。但是，如果多個覆蓋項被連結到同一層次的設計結構中，則“路徑”列允許指定設計路徑，該路徑將被新增到“連結”列中的條目之前，以建立完全限定的引用。

未實現的

隨著測試計劃的定義，在testbench或設計中還不存在相應的覆蓋項的情況，捕獲需求是很常見的。為了處理這種情況，可以通過在未實現的列中新增一個值“是”或一個大於零的數字，將一個需求設定為未實現。這將導致測試計劃覆蓋率計算準確地反映存在的需求，該需求的覆蓋率為零，而該需求尚未覆蓋。預設情況下，除非指定了此列，否則假定實現了需求的覆蓋範圍。

使用者定義的列

為了確保使用者能夠靈活地記錄與需求相關的其他重要資訊，Questa的驗證管理解決方案還允許建立使用者定義的列。這允許對任何需要跟蹤的內容進行規範。它還可以讓您更好地瞭解驗證過程。通常新增的一些列包括哪個工程師負責測試需求，以及需求或設計特徵的優先順序。

這些新增的列有助於回答以下問題：

• 我的高優先順序測試計劃專案進展如何？
• 在實現當前專案時間表方面，我在哪裡？
• 我的資源狀況如何？

系統級功能覆蓋示例中使用的電子表格添加了所有者和優先順序使用者定義列。

重用存在的測試計劃

通常，能夠在其他上下文中使用現有的測試計劃是很有用的。以下幾種常見情況下，這會變得有用：

• 測試計劃是在塊級開發的，需要納入晶片或系統級測試計劃。
• 測試計劃隨IP或驗證IP一起交付。例如，特定於協議的驗證IP應包含完整的協議測試計劃，以確保協議得到完全驗證。
• 將自動生成的測試計劃納入我們的子系統或SoC級計劃。例如，對於電源感知模擬，模擬器應該能夠建立測試計劃，以確保電源場景完全可用。
• 將不同編輯工具捕獲的測試計劃合併到一個主測試計劃中。

在這些情況下，現有的測試計劃可以分層匯入到正在建立的頂級測試計劃中，從而可以視覺化整個驗證工作的深度。

當建立這樣一個測試計劃時，Type列將被賦予一個值“XML”，以通知Questa該部分不引用覆蓋率物件，而是引用另一個測試計劃文件。“連結”列將用於指定包含被匯入的測試計劃的實際測試計劃檔案（通過檔案的相對路徑或完整路徑）。

測試計劃到功能覆蓋率

到達功能覆蓋關閉是一個從設計功能規範書開始的過程，並通過分析確定：

匯出功能覆蓋模型並不是一個自動過程，它需要對可用規範進行解釋，模型的實現需要仔細考慮。

• 需要測試哪些功能
• 在什麼條件下需要測試功能
• 驅動和監控設計介面需要什麼樣的testbench基礎設施
• testbench將如何檢查功能是否正常工作

匯出功能覆蓋模型並不是一個自動過程，它需要對可用規範進行解釋，模型的實現需要仔細考慮。

過程

生成功能率覆蓋模型的過程通常是迭代的，隨著測試平臺的每個部分和刺激的構建，模型會隨著時間的推移而建立。每次迭代都從相關的和可用的功能規範文件開始，這些文件被分析，以識別需要在測試平臺中通過配置和激勵生成的一些組合檢查的特性。

一般來說，測試平臺有兩個方面，一條控制路徑用來刺激被測試的設計，使其進入不同的狀態，以便檢查其特性；還有一個分析面，用來觀察設計對激勵的反應。應在測試平臺中實現自檢機制，以確保設計正確執行，這通常被稱為記分板。功能覆蓋率模型的作用是確保DUT通過的測試檢查了所有相關條件下的設計特徵。功能覆蓋率模型應基於對設計行為的觀察，而不是它被要求如何行為，因此應該在分析路徑中實現。考慮這一點最簡單的方法是，在測試平臺上，必須開發執行在其上的激勵和記分板來測試設計的所有特性，並使用功能覆蓋模型來確保這些測試的所有預期變化都已成功完成。

驗證是一個不完整的過程，即使是“簡單”的設計，也很難及時驗證所有可用的內容。對於大小合理的設計，在可驗證的內容和可用於實現、執行和除錯測試用例的時間之間存在權衡，這導致基於專案的技術和商業背景進行優先順序排序。明智的驗證策略是從最高優先順序的專案開始，並確定優先順序順序，同時準備隨著專案的進展重新確定列表的優先順序。功能覆蓋模型應隨著每個設計特徵的測試而發展，功能覆蓋模型的每個附加部分應在激勵之前就位。

過程指南

功能覆蓋模型基於功能需求

測試平臺用於測試設計的特徵。功能覆蓋模型的作用是檢查這些不同變體的特徵是否正常工作。特徵也可以被稱為需求，或者在某些情況下被稱為故事。

例如，DUT生成帶有CRC欄位的資料包。CRC基於資料包的內容，比如說有10個變體。測試平臺產生刺激，使DUT產生資料包，記分板檢查CRC欄位，確保DUT正確計算。在這種情況下，功能覆蓋率監視器的作用是確保所有10個數據包變體都已通過檢驗。

選擇最合適的實現

在決定如何實現功能覆蓋模型時，可以選擇如何實現功能覆蓋。SystemVerilog語言支援兩種主要型別的功能覆蓋：

Covergroup 功能覆蓋率依賴於對一個或多個數據欄位的值進行取樣，以統計這些值出現的不同排列的次數。

Cover Property或基於時序的覆蓋率，是基於計算測試期間特定狀態和/或條件序列發生的次數。時間覆蓋通常用於獲得控制路徑或協議上的覆蓋，其中時間關係可能會發生變化。例如：

• FIFO是否已進入溢位或下溢狀態
• 是否觀察到特定型別的匯流排迴圈完成

開發功能覆蓋模型的第一步是決定針對每個關注領域應採取這兩種方法中的哪一種。