作為一名linux驅動工程師，與驗證同事打交道的很多，這裡記錄一下晶片驗證方面的一些概念，方便後續查詢
原文連結：晶片驗證需要圍繞DUT做什麼
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要求。