對DUT輸入定向或隨機的激勵

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

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

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

3、DUT響應(yīng)輸入激勵并輸出

4、檢查輸出與預(yù)期結(jié)果差異

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

6、重復(fù)上述步驟收集覆蓋率

做個不太恰當?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了，趕緊找設(shè)計人員來修改代碼。

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

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

generator：產(chǎn)生不同的輸入激勵來驅(qū)動DUT 產(chǎn)生有效的數(shù)據(jù)，并發(fā)送給driver。

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

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

monitor：檢測DUT的輸出

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

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

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

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

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

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

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

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

審核編輯：劉清