Testbench是幾乎所有做動(dòng)態(tài)仿真驗(yàn)證的工程師都要面對的問題，可能是需要設(shè)計(jì)，或者開發(fā)，又或者是維護(hù)，總有很多事情要在這上面折騰。Testbench可以很簡單，也可以很復(fù)雜。

在面對具體的驗(yàn)證對象的時(shí)候，如何利用我們手頭的工具，比如SV/UVM/Python等，去搭建一個(gè)簡潔高效的、可維護(hù)性和可重用性強(qiáng)的testbench，是一個(gè)非常重要且值得討論的問題，甚至不同的工程師就能總結(jié)出自己的一套經(jīng)驗(yàn)法則。

本文將從架構(gòu)（Architecture）、實(shí)現(xiàn)（Implementation）、維護(hù)（Maintenance）這三個(gè)方面著手，討論設(shè)計(jì)和構(gòu)建testbench通常需要考慮的問題，不涉及編程實(shí)操，不涉及驗(yàn)證計(jì)劃。

01 Architecture

Testbench架構(gòu)定義很大程度影響著仿真程序的執(zhí)行效率。這里的討論將分三個(gè)小點(diǎn)展開：驗(yàn)證環(huán)境本身結(jié)構(gòu)，層次化測試激勵(lì)，以及配置信息的傳播。

最簡單的驗(yàn)證環(huán)境，或者說驗(yàn)證環(huán)境的一般雛形，包括driver、monitor、sequencer、model、checker、scoreboard等這么一些組件，連接關(guān)系也很簡單。然而在實(shí)際工程項(xiàng)目中，特別是到了系統(tǒng)集成級，由于驗(yàn)證對象很龐大，驗(yàn)證環(huán)境的組件數(shù)量往往成倍數(shù)增加，連接關(guān)系和控制關(guān)系也會(huì)變得更加復(fù)雜。

層次化的測試激勵(lì)來源于我們對測試場景的定義和對激勵(lì)控制的需求。一般來說，測試場景定義得越抽象，測試激勵(lì)的層次就會(huì)相應(yīng)地增加，對測試激勵(lì)的控制也會(huì)更加復(fù)雜。舉個(gè)例子，假設(shè)我們想要測試CHI NoC中HN對某一種transaction的響應(yīng)行為，那么只需要啟動(dòng)讓RN agent直接發(fā)出transaction的sequence即可；某天我們想要測試HN處理不同hazard（多筆請求產(chǎn)生沖突）的行為，那么我們可以通過封裝多個(gè)base sequence來實(shí)現(xiàn)該目的。

配置信息的傳播在testbench架構(gòu)中很重要。配置信息一般包括對DUT參數(shù)或者宏定義的配置、驗(yàn)證環(huán)境組件的開關(guān)配置、測試激勵(lì)權(quán)重的配置等等。配置信息使得當(dāng)前驗(yàn)證環(huán)境可以被有效復(fù)用，可以覆蓋到更多的測試場景。通常我們可以通過分享config對象句柄的方式來傳遞配置信息。

02 Implementation

在實(shí)現(xiàn)上要考慮的問題會(huì)比較雜，這里舉幾個(gè)常見的主題：數(shù)據(jù)結(jié)構(gòu)的定義，建模和檢查方式，覆蓋率收集，以及仿真的啟動(dòng)和結(jié)束。

數(shù)據(jù)結(jié)構(gòu)的定義應(yīng)當(dāng)完整，并提供足夠的方法使其能夠被高效操作。數(shù)據(jù)結(jié)構(gòu)容易直接想到的就是sequence_item的定義，決定了數(shù)據(jù)在testbench各組件中游走的包格式。除此之外，需要定義config對象的數(shù)據(jù)結(jié)構(gòu)，自定義的建模方式可能需要一種新的數(shù)據(jù)類型等等。

建模和檢查方式強(qiáng)依賴于驗(yàn)證計(jì)劃。大白話是，確定需要覆蓋的測試點(diǎn)和覆蓋方法，對此再分門別類定義checker，根據(jù)checker所需要的信息定義建模方式。這里的建模指的是在testbench中實(shí)現(xiàn)DUT中某個(gè)模塊的功能，或者記錄DUT狀態(tài)信息，使得檢查測試結(jié)果時(shí)有理有據(jù)。

覆蓋率是芯片項(xiàng)目驗(yàn)收的關(guān)鍵技術(shù)指標(biāo)，收集覆蓋率就變成testbench必要的功能。定義覆蓋點(diǎn)的位置以及收集覆蓋率的方式都比較靈活，如果沒有統(tǒng)一規(guī)劃和管理，容易讓同一個(gè)testbench中收集覆蓋率變得分散而不好管理。

仿真的啟動(dòng)和結(jié)束主要為了實(shí)現(xiàn)這兩部分功能：測試用例開始前的初始化和仿真結(jié)束時(shí)的狀態(tài)檢查。仿真驗(yàn)證不代表一上來就給驗(yàn)證對象灌激勵(lì)，除了要處理好復(fù)位、上電流程之外，通常還要其他初始化工作，比如將某些接口tie成固定值、初始化控制寄存器的值、加載memory的內(nèi)容等等。仿真結(jié)束時(shí)，除了要確保DUT已經(jīng)完成對測試激勵(lì)的完整響應(yīng)，還需要檢查DUT以及testbench自身的一些狀態(tài)是否符合預(yù)期。

03 Maintenance

在項(xiàng)目迭代中通常會(huì)復(fù)用到前項(xiàng)目的驗(yàn)證環(huán)境，這就導(dǎo)致testbench的維護(hù)工作需要做得比較長遠(yuǎn)，否則容易積重難返，最后誰也不敢做出更新或者改進(jìn)。Testbench的維護(hù)有這么幾個(gè)重要的主題：驗(yàn)證環(huán)境的集成，工程目錄結(jié)構(gòu)，各類腳本管理，以及相關(guān)文檔的整理。

驗(yàn)證環(huán)境的集成指的是將底層驗(yàn)證環(huán)境的向上復(fù)用，這種操作在實(shí)際項(xiàng)目中非常常見，也是提高驗(yàn)證效率和節(jié)約人力的好方法。當(dāng)testbench需要被集成復(fù)用，需要提前溝通好雙方的需求和配置方式。

工程目錄結(jié)構(gòu)一般要遵守項(xiàng)目管理的統(tǒng)一安排，使得環(huán)境在需要維護(hù)時(shí)檢索效率比較高。否則，當(dāng)驗(yàn)證環(huán)境變得非常龐大之后，在一個(gè)結(jié)構(gòu)混亂的工程目錄中找文件會(huì)非常麻煩，所以不要隨意存放文件。

環(huán)境腳本雖然不作為testbench本身的一部分，卻是維護(hù)驗(yàn)證環(huán)境的必要工具。這里的腳本主要的工作有文本處理、自動(dòng)化生成文件、提交仿真任務(wù)等內(nèi)容，當(dāng)需求發(fā)生變化，相應(yīng)的腳本也就需要更新和維護(hù)。

審核編輯：劉清