如何利用verilog驗證二分法查找的設計代碼

這篇文章再探討一下如何利用verilog驗證二分法查找的設計代碼。

話說IC君當時畢業(yè)的時候，拿了一個專門做驗證的offer，最終為了愛情放棄了它?，F(xiàn)在集成電路的規(guī)模越來越大，需要的驗證人員越來越多，薪資待遇也是水漲船高。

verilog驗證不同于設計，不需要遵循可綜合的限制，只要verilog支持的語法都能拿來用，這個時候就需要大家發(fā)揮自己的想象力，竭盡所能找到所有的bug，并且能夠快速的報告錯誤。

有時候甚至可以利用一些腳本自動將錯誤信息發(fā)送到郵箱。想象一下，下班前丟一個testbench到服務器上仿真，第二天上班的時候喝喝茶看看郵件就把bug抓了，是不是美滋滋的

如果我不是驗證工程師，有沒有必要學點簡單的驗證技術(shù)呢？平時在做項目的過程中，大家負責的電路中可能有很多跟二分法查找類似的小模塊。你可能一不小心寫錯了代碼，或者搭錯了電路。這些小模塊我們最好隨手驗證一下，雖然最終也會有其它人專門驗證，但一些明顯的錯誤如果被別人抓到了，還是有點不太爽的。

通常驗證的代碼要包含三個部分：

1) 產(chǎn)生模擬激勵(波形)。

2) 將輸入激勵加入到測試模塊并收集其輸出響應；

3) 將響應輸出與期望值進行比較。

1

由于verilog是一個模擬硬件并行執(zhí)行的過程，所以上面三個部分沒有順序之分。

將輸入激勵加入到測試模塊并收集其輸出響應：

首先是模塊信號的定義，輸入信號會作為激勵加入到測試模塊SAR，SAR的輸出信號也會送到tb_sar模塊的線網(wǎng)信號pucode。

然后就是產(chǎn)生模擬激勵(波形)的過程：

從前2篇文章我們知道，6位的SAR查找過程需要跳5次clk，每次clk上升沿的INCR可能為1，也可能為0。驗證過程必須要覆蓋所有可能的INCR的值。

這里我們?nèi)缟蠄D先產(chǎn)生RSTB 信號，接著CLK信號toggle 5次，并用val[0],val[1],val[2],val[3],val[4]分別賦值給這5次的INCR，這是代碼中內(nèi)部小for循環(huán)（count）來實現(xiàn)。

為了遍歷所有的INCR，我們必須重復前面的過程32次，遍歷val[4:0]的取值從0-31，這樣就可以覆蓋到所有可能的INCR值了。這是代碼中外部大for循環(huán)（val）來實現(xiàn)。

下面是產(chǎn)生輸出文件的過程，這里我們設置輸出結(jié)果的格式是fsdb，當然我們也可以設置成vcd的格式。fsdb的文件size比較小，而且利用verdi的波形工具nWave看起來也比較方便。在實際項目過程中，有時候我們要跑的testbench很多，跑出來的結(jié)果文件就會很多，如果不用fsdb格式，最終需要更大的存儲空間。

fsdb(fast signal database)文件是verdi使用一種專用的數(shù)據(jù)格式，類似于VCD，但是它是只保留了仿真過程中信號的有用信息，除去了VCD中信息冗余，就像對VCD數(shù)據(jù)進行了一次huffman編碼。因此fsdb數(shù)據(jù)量小，而且會提高仿真速度。fsdb是通過verilog的PLI接口來實現(xiàn)的。$fsdbDumpfile,$fsdbDumpvars等

VCD是一個通用的波形文件格式，是IEEE1364標準(Verilog HDL語言標準，p325)中定義的一種ASCII文件.可以通過Verilog HDL的系統(tǒng)函數(shù)$dumpfile,$dumpvars等來生成，基本所有的Verilog仿真器都會支持。

將響應輸出與期望值進行比較：

接下來是產(chǎn)生期望值，期望值這里我們定義為nextpu，驗證工程師的主要工作職責就是用與設計工程師不同的方法產(chǎn)生期望值。一般的公司都會是不同的人來做驗證，可能有些小公司是一個人既做設計又做驗證。

最后是比較期望值和測試模塊SAR的輸出，如果不同則打印出錯誤信息。這里用一個always語句實現(xiàn)，如果pucode發(fā)生變化就比較結(jié)果，有錯誤就輸出到屏幕。

2

下圖就是整個驗證的波形：

可以看出val從0-31依次變化，pucode和nextpu的值也是一樣，沒有什么錯誤。

再看一下某一次的二分法查找過程：

首先rstb會從low到high，這樣pucode就會被設置成初始值6'b100000；

在5次clk toggle的過程中，incr一直為0，pucode會一直發(fā)生變化，最終pucode變?yōu)?'b000001。

驗證了我們之前文章的2個版本的設計代碼，竟然都沒有錯誤，因為本來就是一個小模塊，出現(xiàn)錯誤的可能性也不大。

不過沒有錯誤，感覺怪怪的，把設計代碼改一改，確認我們的驗證代碼是不是真正起作用了，哈哈。

我們把設計代碼中一句：

改成如下所示：

再run一下驗證代碼：

pucode和nextpu就有了不一致性：

這時候debug一下，就很容易定位錯誤的代碼。

寫到這里關(guān)于二分法查找（二進制搜索/逐次逼近SAR）的學習就告一段落了。這個模塊雖然小，但是起碼把開出spec，設計電路，驗證電路基本的流程都過了一遍，以后可能還會嘗試類似小模塊的學習。

不積跬步無以至千里，IC的學習就是一個慢慢積累違反人性的過程，希望大家能一起學習進步~。