芯片驗證需要圍繞DUT做什么？

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

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

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

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

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

5、發(fā)現(xiàn)功能錯誤后修改DUT

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

做個不太恰當?shù)谋扔?，testbench就像一個書桌，你買來了一個鍵盤（DUT），你想要驗證它是不是正常工作，你就開始敲鍵盤檢查。你的十個手指就是 激勵 ，數(shù)據(jù)線和屏幕相連，數(shù)據(jù)線為 接口 ，屏幕是 記分板 ，鍵盤使用說明書為 參考模型 。

首先你把26個字母都敲了一遍（ 定向測試 ），發(fā)現(xiàn)屏幕上也出現(xiàn)了26個字母，每個鍵都能沒毛病，基本功能驗證了；但是還不夠，你又組合著敲了**“** guan zhu dian zan” （ 隨機測試 ），屏幕上突然出現(xiàn)****“**** fen xiang zai kan ”**** ，這時你就發(fā)現(xiàn)bug了，趕緊找設計人員來修改代碼。

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

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

generator ：產(chǎn)生不同的輸入激勵來驅(qū)動DUT

產(chǎn)生有效的數(shù)據(jù)，并發(fā)送給driver。

interface ：用于連接testbench和DUT

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

driver ：將激勵驅(qū)動到DUT

monitor ：檢測DUT的輸出

scoreboard ：用于比較輸出與預期值

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

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

test ：可以包含不同配置的環(huán)境

因此，為了驗證DUT這份RTL代碼，驗證要做的事是：

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

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

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

4）編寫 testcase ，根據(jù)之前定制的驗證計劃，coding相應的測試用例， debug fail case ，把全部case調(diào)試至 pass 。

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