對于非微電子專業做FPGA的同學們來講，常常把仿真驗證環境的搭建給忽略了，為了追求所謂的“高效”，自己寫的代碼根本就沒怎么仿真驗證過，就急急忙忙的上板調試。有的同學說也做過仿真啊，后來一看發現竟然是用Vivado等FPGA綜合工具自帶的仿真器來簡單的仿真了一下，其實這些都還僅僅是停留在模塊級的個別功能點仿真。一個通信的FPGA樣機或者是一款ASIC芯片的仿真驗證，是需要仔細把所有的功能點細分之后串聯起來做出來一個兼顧軟硬件及各種應用場景的全流程的仿真驗證。類似的有各種成熟的方法，如UVM等，但對于初學者而言，其實用ModelSim完全可以搭建出來一個稍微像樣的可回歸的能夠看覆蓋率的仿真驗證環境的。近期發現很多同學不重視仿真驗證環境搭建，認為沒必要搭建仿真驗證環境，結果沒有充分驗證的代碼上板后發現BUG，費了長達一兩周的時間不斷的添加追蹤信號看波形終于定位到了問題，結果一看是一個邏輯錯誤，用仿真的方法完全可以復現，如果有仿真環境，發現問題定位問題并解決問題可能就是一個小時就可以搞定的事情，結果因為沒有仿真驗證環境白白的浪費了大量的時間。

一、把所有代碼分為設計代碼文件夾hdl和仿真文件夾sim 在hdl文件夾下是對應所有的設計代碼，本文中選用opencores網站中十百千自適應的MAC控制器作為設計代碼。

sim文件夾下存放仿真環境搭建的各種文件。

testbench下存放最頂層的testbench.v；bfm文件夾下存放以太網phy的簡單模型產生以太網數據包的激勵，時鐘復位產生模塊及數據對比模塊；filelist文件夾下存放驗證環境中所有的.v文件列表文件，為了看覆蓋率，一般要把設計代碼文件列表和仿真代碼文件列表分開成兩個不同的文件（windows下自動生成verilog列表文件的源碼本公眾號之前也分享過，詳見如何快速生成Verilog代碼文件列表？（內附開源C代碼））；in_out下就存放每個不同的測試例對應的激勵數據包和經過MAC核控制器后出去的數據包；run目錄下存放運行的批處理文件和sim的tcl腳本文件；testcase下存在各種不同的測試例。

二、編寫腳本

腳本分為run.bat批處理腳本和sim.do兩個文件，都在上述run文件夾下，run.bat如下：

其中vsim -c 一行中的-c用來表示是否啟動Modelsim的圖形界面，有-c就表示啟動圖形界面，沒有就表示不啟動。

sim.do就比較簡單了，就是完成建ModelSim工程及仿真等動作：

需要注意的一點是，上面把仿真代碼文件列表和設計代碼文件列表分開后，就可以單獨的vlog，同時給設計代碼添加上看覆蓋率的命令。

本文后續內容是某天所做的更改記錄，大家可以通過這些記錄便能看出搭建改環境的一些較為核心的內容。

1、在data_cmp.v模塊增加輸入信號testcase_name，將測試例名字引入數據包比較模塊，利用testcase_name信號，可以每次測試不同測試例的時候在數據記錄文件夾in_out里面可以產生不同的數據記錄log文件。

具體截圖如下：

上圖中增加了INITIAL_DATA_CMP的task，可以每次在不同的測試例開頭對整個芯片進行復位的時候啟動該task，即可建立對應該testcase的記錄文件。

目前存在的問題是最開始復位的時候，testcase_name還未有實際的測試例名字，導致會產生兩個沒有用的文件。如下圖：

2、在data_cmp.v中增加名為OVER的task，在每個測試例運行結束后可以關閉掉為該測試例新建的文件指針。

OVER任務具體實現如下：

在不同的testcase末尾調用該task：

3、手動將文件列表文件rtl.f拆分成設計代碼文件列表hdl_filelist.v和仿真代碼文件列表sim_filelist.v。

并修改運行腳本，使得運行結束后可以看到設計代碼文件的覆蓋率。

修改批處理文件，使用modelsim圖形界面的方式

發現第二個測試例中間的數據包計數未從0開始，修改代碼

在所有testcase中增加一行代碼，讓data_cnt和i都從0開始。

修改后就能每個testcase都從0開始運行：

此時在modelsim圖形界面下也能看到設計代碼對應的覆蓋率情況：

雙擊某個文件就能打開對應代碼是否被驗證到的情況：

目前只是驗證了百兆模式下100個隨機幀和千兆模式下100個隨機幀，大家可以在上面的基礎上不斷的去增加測試例。后續內容就需要大家不斷的增加測試例來完成對所有代碼的全覆蓋仿真，并且在此過程中也能夠對MAC核的各種功能更加的熟悉。

審核編輯 ：李倩