《SystemVerilog驗證-測試平臺編寫指南》學習 - 第1章 驗證導論
測試平臺（testbench）的功能
- 產生激勵（Generate stimulus）；
- 把激勵輸入到待測設計上（DUV，Design Under Verification）；
- 產生預期（Generate Expectation）；
- 捕捉響應（Capture response）；
- 檢驗響應的正確性（Check the response for correctness）；
- 根據驗證目標評估驗證進度（Measure the progress against the overall verification goals）；
驗證四要素：
- 灌激勵：（產生輸入信號）
- 做預期：（產生預期結果）
- 集響應：（收集輸出信號）
- 作比較：（比較響應和預期結果）
方法學基礎
本書採用如下原則：
- 受約束的隨機激勵；
- 功能覆蓋率；
- 使用事務處理器的分層測試平臺；
- 對所有測試通用的測試平臺；
- 獨立於測試平臺之外的個性化測試代碼；
這些原則是相關聯的。隨機激勵對測試複雜設計十分關鍵。
定向測試：找出設計中預期的漏洞；
隨機測試：找出預料不到的漏洞；
當使用隨機激勵時，需要用功能覆蓋率來評估驗證進度。一旦開始使用自動生成的激勵，就需要一種能夠自動預測結果的方式 -- 通常是計分板或參考模型。
1. 受約束的隨機激勵
爲什麼要約束？
答：
雖然你希望仿真器能產生隨機激勵，但同時有不希望這些激勵數值完全隨機。
你的隨機化對象是什麼？
需要廣泛地考慮所有的設計輸入，而不是僅僅是數據字段，如下所列：
- 設備和環境配置；
你應該對整個環境的配置進行隨機化，包括仿真的時長、設備的數量，以及它們的配置方式。當然，你需要創建約束以確保配置的合法性。- 輸入數據；
你需要事先估計好所有的分層協議和錯誤注入，以及計分板的內容和功能覆蓋率。- 協議異常、錯誤和違例；
應該儘量嘗試去仿真在實際的硬件中可能出現的錯誤，而且應該針對所有可能出現的錯誤。- 時延和同步；
嘗試協調各個驅動器使他們能夠在不同的速率下進行通信。
2. 功能覆蓋率
你需要知道哪些部分已經被驗證過，這樣才能對驗證計劃中的項目進行覈對。
功能覆蓋率的測量和使用：
- 添加代碼用於監控進入設備中的激勵，以及設備對激勵的反應，並據此確定哪些功能已經被驗證過；
- 運行幾次仿真，每次使用不同的種子，合併報告；
- 分析結果，採用新的激勵測試未被測試到的條件和邏輯；
隨機測試需要使用反饋。最初的測試會被運行很多次，使用不同的種子，創建很多互異的輸入序列。但是到了最後，即時使用新的種子，所產生的激勵也很可能無法在設計空間中探測到新區域。
隨着功能覆蓋率逐漸接近極限，你需要改變測試，以期望能找出新的方法去達到那些尚未被覆蓋的區域。這被稱爲“ 覆蓋率驅動的驗證 ”
在受約束的隨機激勵中很少採用動態反饋。相反地，需要手工分析覆蓋率報告，然後調整隨機約束。
3. 分層的測試平臺
不分層的的測試平臺或者低層次的Verilog測試就是初學Verilog時寫的簡單testbench那種形式。
如下圖所示是帶着所有層次的完整測試平臺：
- 信號層：把待測設計和測試平臺相連；
- 命令層：驅動器驅動待測設計的輸入和監視器檢測待測設計的輸出變化，並把這些變化按照命令分組。斷言也穿過命令層和信號層，負責監視獨立的信號以尋找穿越整個命令的信號變化；
- 功能層：代理（在VMM中稱爲事務處理器）接收到來自上層的事務，例如DMA讀或者寫，把它們分解成獨立的命令。這些命令也被送往用於預測事務結果的計分板。檢測器則負責比較來自監視器和計分板的命令；
- 場景層：功能層被位於場景層中的發生器所驅動。所謂的場景就是操作步驟，場景層就是負責組織協調這些步驟的；
- 測試層和功能覆蓋率：測試平臺的最頂層 -- 測試層，就像一個指揮官，不演奏任何樂器卻引領者其他人的表演。測試包含了用於創建激勵的約束。功能覆蓋率可以衡量所有測試在滿足驗證計劃要求方面的進展。隨着各項測量標準的完成，功能覆蓋率代碼在整個項目過程中會經常變化。由於代碼經常被修改，所以它不作爲測試環境的組成部分。
建立一個分層的測試平臺
1. 創建一個簡單的驅動器
如之前所說，驅動器接收來自代理的命令。驅動器可能會注入錯誤或增加時延，然後再把命令分解成一些信號的變化，例如總線請求或者握手。這樣的一個測試平臺模塊通常被稱爲“事務處理器（transactor）”，它的核心部分是一個循環：有關事務處理器的示範代碼如下所示。
task run();
done = 0;
while (!done) begin
// 獲取下一個事務
// 進行變換
// 發送事務
end
endtask
2. 仿真環境階段
- 建立（build）
- 生成配置：把待測設計的配置和周圍的環境隨機化；
- 建立環境：基於配置來分配和連接測試平臺構件；
- 對待測設計進行復位；
- 配置待測設計：基於第一步中生成的配置，載入待測設計的命令寄存器；
- 運行（run）
- 啓動環境：運行測試平臺構件，例如各種BFM和激勵發生器；
- 運行測試：啓動測試然後等待測試完成。定向測試很容易判斷，但隨機測試卻比較困難。可以使用測試平臺的層作爲引導。從頂層啓動，等待一個層接收完來自上一層的所有輸入，接着等待當前層空閒下來，然後再等待下一層。應該同時使用超時檢測保證待測設計或者測試平臺不出現死鎖；
- 收尾（wrap-up）
- 清空：在最下層完成以後，你需要等待待測設計清空最後的事務；
- 報告：一旦待測設計空閒下來，你就可以清空遺留在待測設計中的數據了。你可以根據這些信息創建最終報告，如果測試失敗，務必把相應的功能覆蓋率結果刪除，因爲他們可能是不正確的。
3. 最大限度代碼重用
爲了驗證一個帶有數百個特性的複雜設備，必須編寫數百個定向測試。如果使用受約束的隨機激勵，你需要編寫的測試就會少很多。
與定向測試相比，隨機測試的主要工作是構建測試平臺，使它包含所有較低的層：場景、功能、命令以及信號。這個測試平臺代碼要能夠被所有的測試使用，所以它需要有很好的通用性。
4. 測試平臺的性能
創建受約束的隨機測試需要幾個步驟：
- 建立分層的測試平臺，包括自檢的部分；
- 按照驗證計劃中列舉的目標創建激勵，你可以使用隨機約束，也可以採用注入錯誤或者協議違例等迂迴的方式；
- 功能覆蓋率，這項任務的開始是創建一個強有力的驗證計劃，這個計劃必須帶有清晰而且便於測量的目標；
- 收集數據，結果分析；