Timer測試方案 Timer測試平臺實現 測試平臺debug注意事項

一、測試的基本概念

IC驗證，一般也稱“功能驗證”，我們今天要講的，不是這個，是它的簡化版：模塊測試，是設計工程師完成代碼設計后，需要自己做的這部分驗證工作。IC驗證，我們將會在后續文章中，專門講解。

為什么說設計工程師做的模塊測試是IC驗證的簡化版？

在回答這個問題之前，我們先了解幾個概念：

• 白盒測試（White-box Test）
• 黑盒測試（Black-box Test）
• 灰盒測試（Grey-box Test）

這個幾個概念在軟件工程中都有介紹，IC設計驗證中一樣存在這幾個概念涉及的工作，所以直接借用。

白盒測試，一般是針對代碼結構進行的測試，所以也有稱白盒測試為“結構測試”。

黑盒測試，一般是行為測試，把設計當黑盒子，不用看代碼不用針對代碼結構進行測試。我們前面提到的IC驗證，通常指的“功能驗證”，就屬于“黑盒測試”。

灰盒測試，介于白盒測試和黑盒測試之間，兼顧兩者優點。

在實際工作中，設計工程師完成代碼設計之后，交給驗證工程師之前，除了檢查語法、可綜合性之外（當然還有其他檢查，設計剛入門，不用關心這么多），還需要進行基本的測試，這個基本的測試，原則上應該是白盒測試。

實際上，因為全靠設計工程師構造測試例來做覆蓋完成白盒測試的工作量太大，一般都用更實際的做法：簡單的功能測試。

做法：確認設計的代碼基本可以工作，基本的讀寫沒有問題后，就交給驗證工程師來做“IC驗證”，也就是功能驗證。當然，不同的團隊對設計交付代碼質量的要求不一樣，那么測試的內容和工作量也有差異。

二、Timer測試方案

Timer的測試方案涵蓋的內容包括：測試內容、測試例、測試平臺結構，在實際操作中，有些團隊略去了測試內容的梳理和測試平臺結構的設計，僅僅構造了一些這對基本功能的測試例，我們這部分保留這些內容，但是做了精簡。

1．測試內容

Timer模塊的白盒測試，簡化為基本的功能測試，如：

• 對總線接口的讀寫檢查
• 對模塊寄存器的復位值的檢查；
• 對寄存器讀寫的檢查；
• 對計數基本功能的檢查；
• 對代碼行、if語句各分支的執行檢查等；

針對這些功能，構造相應的測試例進行測試。

2．測試例

根據規格書上梳理待測試的功能。實際操作時有的工程師會簡化，經測試基本功能，確認設計可以動起來。如下表格是測試例的片段。

3．測試平臺結構

完成待測試功能的梳理和測試例的構造，我們接著要做是，設計構造測試平臺（Testbench）。

DUT：待測試對象（Device Under Test）,也就是我們前面用Verilog或VHDL寫的RTL設計代碼。

激勵：DUT和testbench之間只能通過頂層接口連接，所以，所有的測試數據都必須按照頂層接口的時序要求，輸入進DUT中。這里的測試數據也叫測試例或者測試向量。測試例，一般是采用直接測試例進行測試，這種測試方式針對性強，能夠快速將模塊驅動起來。

結果比較：等待DUT輸出結果（DUT會有標識，或通過主機輪詢，或DUT自己有標識接口），testbench必須按照頂層接口的時序要求，取出DUT的輸出結果，再與期望值比較，最后將比較結果打印出來，便于查看。

三、Timer測試平臺實現

實現語言： 可以用verilog語言，或者VHDL語言，或者SystemVerilog語言等。

仿真工具 ：Modelsim、VCS、NC-Verilog/NC-VHDL

下面是平臺代碼實現的片段。

1. 頂層文件代碼

頂層包含：

• 時鐘和復位信號的定義；
• 時鐘周期的參數定義；
• 驗證環境文件的導入；
• 時鐘的產生；
• 復位信號的產生；
• 模塊的例化；
• 在初始化中運行測試例任務；

2 .總線激勵

假定Timer的總線接口是Z總線，下面的代碼就是實現一個Z總線的寫操作，將wdata寫入zaddr這個地址里面。

3.測試例

測試例主要是將上面的總線驅動task調用起來對模塊進行驅動，讓模塊正常工作起來。同時設定一定的循環次數，每一次新的運行需要等待中斷到來之后進行新的寄存器配置。

4.結果比較

為了提高debug效率，將從DUT出來的結果和理想結果進行自動對比，并將對比結果打印出來。

結果比較一般流程是等待DUT的中斷到來，然后讀取Timer的寄存器的值與期望值做比較。

四、測試平臺Debug注意事項

1. 在對整個testbench進行編譯時候，初期語法錯誤較多，這時候需要多聯系上下文來check，很多時候工具報的問題不在出錯誤的地方。
2. Debug經常遇到的問題是測試例跑死，這種情況一般是等待的事件沒有等到，或者寄存器配置錯誤。