TestBench即測試平臺，是為了檢驗待測設計（design under test，DUT）而搭建的驗證環境。有了這個環境，我們就可以對DUT輸入定向或隨機的激勵，以保證DUT的正確性。故驗證要做的事分為以下幾步：

1、生成各種各樣的輸入激勵

2、將輸入激勵傳遞到DUT上

3、DUT響應輸入激勵并輸出

4、檢查輸出與預期結果差異

5、發現功能錯誤后修改DUT

6、重復上述步驟收集覆蓋率

做個不太恰當的比喻，testbench就像一個書桌，你買來了一個鍵盤（DUT），你想要驗證它是不是正常工作，你就開始敲鍵盤檢查。你的十個手指就是激勵，數據線和屏幕相連，數據線為接口，屏幕是記分板，鍵盤使用說明書為參考模型。首先你把26個字母都敲了一遍（定向測試），發現屏幕上也出現了26個字母，每個鍵都能沒毛病，基本功能驗證了；但是還不夠，你又組合著敲了“guan zhu dian zan”（隨機測試），屏幕上突然出現“fen xiang zai kan”，這時你就發現bug了，趕緊找設計人員來修改代碼。

細心的同學發現，隨機測試豈不是邊界很大，甚至”永無止境“？因此就有了受約束的隨機激勵。使用定向測試和受約束的隨機測試，最終使得功能覆蓋率趨于要求值。最終，鍵盤驗證完沒問題了，再教給后面的人做物理設計，比如鍵程長短、工藝面積、功耗分析等等，一套流程下來沒問題就拿去廠子代工了。

說完了這個有點尬的比喻，我們理解了testbench就是模擬設計所在的環境，以檢查RTL代碼是否符合設計規范的玩意，其內部是分好幾個組件的。那testbench具體有哪些組件呢？請看下圖（PPT畫的，不是很專業）：

generator：產生不同的輸入激勵來驅動DUT 產生有效的數據，并發送給driver。

interface：用于連接testbench和DUT 如果一個設計包含成百上千個端口信號，那么連接、維護和重復利用這些信號就會很麻煩。如果將這些輸入輸出端口放到一塊組成一個接口，那么連接變得更加簡潔而不易出錯，后續添加新的信號更簡便，接口也便于重用。

driver：將激勵驅動到DUT

monitor：檢測DUT的輸出

scoreboard：用于比較輸出與預期值 scoreboard上有與DUT相應的參考模型，反映了DUT的預期行為。如果DUT的輸出和參考模型的輸出不匹配，則設計中存在功能缺陷。

environment：包含以上所有的組件，便于復用

test：可以包含不同配置的環境 因此，為了驗證DUT這份RTL代碼，驗證要做的事是：

1）了解spec，即代碼的規格說明書，有結構模型、功能描述、信號端口、寄存器定義等，它是設計和驗證對接工作的橋梁。

2）制定testplan，一個完整的驗證計劃需要考慮的東西有很多，它為后續工作的進行提供了方向。

3）構建testbench，根據具體驗證需求選擇相應的組件，搭建出盡量可重用的驗證環境。

4）編寫testcase，根據之前定制的驗證計劃，coding相應的測試用例，debug failcase，把全部case調試至pass。

5）收集coverage，跑regression回歸，根據覆蓋率來決定是否加case，直到滿足RTL freeze要求。

審核編輯：劉清