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 fail case ，把全部case調試至 pass 。

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