Testbench是幾乎所有做動態仿真驗證的工程師都要面對的問題，可能是需要設計，或者開發，又或者是維護，總有很多事情要在這上面折騰。Testbench可以很簡單，也可以很復雜。

在面對具體的驗證對象的時候，如何利用我們手頭的工具，比如SV/UVM/Python等，去搭建一個簡潔高效的、可維護性和可重用性強的testbench，是一個非常重要且值得討論的問題，甚至不同的工程師就能總結出自己的一套經驗法則。

本文將從架構（Architecture）、實現（Implementation）、維護（Maintenance）這三個方面著手，討論設計和構建testbench通常需要考慮的問題，不涉及編程實操，不涉及驗證計劃。

01 Architecture

Testbench架構定義很大程度影響著仿真程序的執行效率。這里的討論將分三個小點展開：驗證環境本身結構，層次化測試激勵，以及配置信息的傳播。

最簡單的驗證環境，或者說驗證環境的一般雛形，包括driver、monitor、sequencer、model、checker、scoreboard等這么一些組件，連接關系也很簡單。然而在實際工程項目中，特別是到了系統集成級，由于驗證對象很龐大，驗證環境的組件數量往往成倍數增加，連接關系和控制關系也會變得更加復雜。

層次化的測試激勵來源于我們對測試場景的定義和對激勵控制的需求。一般來說，測試場景定義得越抽象，測試激勵的層次就會相應地增加，對測試激勵的控制也會更加復雜。舉個例子，假設我們想要測試CHI NoC中HN對某一種transaction的響應行為，那么只需要啟動讓RN agent直接發出transaction的sequence即可；某天我們想要測試HN處理不同hazard（多筆請求產生沖突）的行為，那么我們可以通過封裝多個base sequence來實現該目的。

配置信息的傳播在testbench架構中很重要。配置信息一般包括對DUT參數或者宏定義的配置、驗證環境組件的開關配置、測試激勵權重的配置等等。配置信息使得當前驗證環境可以被有效復用，可以覆蓋到更多的測試場景。通常我們可以通過分享config對象句柄的方式來傳遞配置信息。

02 Implementation

在實現上要考慮的問題會比較雜，這里舉幾個常見的主題：數據結構的定義，建模和檢查方式，覆蓋率收集，以及仿真的啟動和結束。

數據結構的定義應當完整，并提供足夠的方法使其能夠被高效操作。數據結構容易直接想到的就是sequence_item的定義，決定了數據在testbench各組件中游走的包格式。除此之外，需要定義config對象的數據結構，自定義的建模方式可能需要一種新的數據類型等等。

建模和檢查方式強依賴于驗證計劃。大白話是，確定需要覆蓋的測試點和覆蓋方法，對此再分門別類定義checker，根據checker所需要的信息定義建模方式。這里的建模指的是在testbench中實現DUT中某個模塊的功能，或者記錄DUT狀態信息，使得檢查測試結果時有理有據。

覆蓋率是芯片項目驗收的關鍵技術指標，收集覆蓋率就變成testbench必要的功能。定義覆蓋點的位置以及收集覆蓋率的方式都比較靈活，如果沒有統一規劃和管理，容易讓同一個testbench中收集覆蓋率變得分散而不好管理。

仿真的啟動和結束主要為了實現這兩部分功能：測試用例開始前的初始化和仿真結束時的狀態檢查。仿真驗證不代表一上來就給驗證對象灌激勵，除了要處理好復位、上電流程之外，通常還要其他初始化工作，比如將某些接口tie成固定值、初始化控制寄存器的值、加載memory的內容等等。仿真結束時，除了要確保DUT已經完成對測試激勵的完整響應，還需要檢查DUT以及testbench自身的一些狀態是否符合預期。

03 Maintenance

在項目迭代中通常會復用到前項目的驗證環境，這就導致testbench的維護工作需要做得比較長遠，否則容易積重難返，最后誰也不敢做出更新或者改進。Testbench的維護有這么幾個重要的主題：驗證環境的集成，工程目錄結構，各類腳本管理，以及相關文檔的整理。

驗證環境的集成指的是將底層驗證環境的向上復用，這種操作在實際項目中非常常見，也是提高驗證效率和節約人力的好方法。當testbench需要被集成復用，需要提前溝通好雙方的需求和配置方式。

工程目錄結構一般要遵守項目管理的統一安排，使得環境在需要維護時檢索效率比較高。否則，當驗證環境變得非常龐大之后，在一個結構混亂的工程目錄中找文件會非常麻煩，所以不要隨意存放文件。

環境腳本雖然不作為testbench本身的一部分，卻是維護驗證環境的必要工具。這里的腳本主要的工作有文本處理、自動化生成文件、提交仿真任務等內容，當需求發生變化，相應的腳本也就需要更新和維護。

審核編輯：劉清