隨著設計的復雜程度不斷增加，要求把更多的資源放到驗證上，不但要求驗證能夠覆蓋所有的功能，還希望能夠給出大量的異常情況來檢查DUT對應異常的處理狀態，這在傳統測試方法下往往是難以實現的。此外，設計不斷地重用，而驗證也希望能夠重用一樣的驗證模塊，這就催生了層次化的驗證方法。Synopsys的 VMM驗證方法學提供了基于SystemVerilog的驗證方法，包括了有約束的隨機數生成，層次化的驗證結構，以及以功能覆蓋率為指標的驗證流程。在本文中，圍繞Synopsys的VMM(Verification Methodology Manual)構建了一個MCU驗證環境。

2 DUT

在這個環境中驗證了一個8位MCU，該CPU時鐘周期即為指令周期，兼容MCU指令集，包含8位的運算邏輯單元，包含了ACC、B、PSW等常用的寄存器，4組R0-R7的R寄存器，支持直接，間接尋址，支持位操作，跳轉指令可以為8位有符號相對地址跳轉或者11位，16位無符號絕對地址跳轉。

4個優先級12個中斷，中斷包括外部輸入中斷，以及串口和計數器等的內部中斷，15位可編程Watchdog，另外包含程序ROM接口，外部RAM接口，內部RAM以及SFR接口。MCU本身并不包含memory，所有的ROM以及RAM都是通過外部接口進行通信，這里在VMM環境里實現了行為級的 memory model，來保存程序代碼和數據。

這個MCU也是在原有基礎上改進了指令周期，減少了大部分指令執行所需的指令周期。因為部分指令所需要的指令周期的縮短，很多原有采樣和賦值時間相應發生較大變化，在功能驗證的基礎上，需要關注是否因此對下一條指令產生影響，特別是中斷和部分指令同時發生時的一些特殊情況。

MCU的指令執行都會通過讀寫RAM memory來實現，另外所有的外設都會通過配置SFR memory來啟動相應功能，并會對相應的SFR置位來顯示外設的工作結果或是狀態，這里RAM memory和SFR memory內容就是需要關注的檢測點，只要保證RAM memory以及SFR memory內容的正確，就可以驗證MCU的所有功能正確。

3 基于VMM的MCU驗證結構

基于VMM的MCU驗證就需要充分利用VMM的特點，即為有約束的隨機數生成、自動數據對比檢查，和功能覆蓋率收集。

3.1 有約束的隨機指令生成

傳統的MCU驗證，需要寫匯編代碼，注入MCU程序ROM進行仿真，匯編代碼的質量和覆蓋率是影響驗證的主要因素。除了可以將應用程序作為 TestCase，只能根據驗證目標編寫對應的TestCase。這樣的TestCase屬于Direct TestCase，只能覆蓋一部分功能，尤其是MCU有指令組合的情況，以及除了ALU單元的外設單元，當外設單元與內部指令并行工作，Direct TestCase往往是不能滿足要求的。這里，VMM提供了有約束的隨機數生成，可以將MCU指令集進行分類，將同一格式的指令歸為一類，這樣可以通過一定的約束隨機的生成指令以及指令所需的參數，在下一節的指令類中會詳細講解關于指令的分類與生成。指令生成后，實現了一個匯編器，這個匯編器是由C代碼實現的，通過DPI將MCU的C模型接入驗證環境中，這樣生成的匯編指令可以實時轉化為16進制代碼，并且直接讀入MCU的ROM進行仿真。隨機指令生成，可以添加節省人力，并且給出更加特殊的TestCase，此外還可以對易錯的情況添加額外的約束，讓邊緣情況測試幾率更大，從而做到更多的驗證。

3.2 自動數據對比檢查

寫匯編代碼，讀入程序ROM，通過仿真來觀測結果，結果的正確性通過波形觀察，這種驗證方法測試數量比較有限，只能在人力控制范圍內進行驗證，不適合于遞歸以及大量TestCase的驗證。此外，在以往的MCU驗證中，一旦發生功能錯誤，真正的錯誤點有可能是多個指令之前，需要往前查找波形，往往 debug時候查找問題源會耗費大量時間，甚至有些深層次的問題因為不屬于驗證目標，或者不在觀測點內，往往會被忽略。在環境里，已經引入的隨機的指令生成，這就需要一個參照模型能夠生成對應的參照結果。這里實現一個用C語言描述的MCU參照模型，同樣通過DPI將MCU的C模型接入驗證環境中，這個模型以16進制代碼作為輸入，可以在每一條指令執行寫出一個參照結果。MCU的都是通過RAM保存數據，SFR寄存器來保存狀態，可以通過對比memory中的數據，來保證MCU的每一條指令的工作狀態都是和參考模型是一致的。而且每次添加TestCase后都不需要觀測波形或是生成參照結果，甚至可以直接將應用程序放入環境中加以測試。在環境里通過C參考模型寫出的每一條指令后的狀態會保存下來，由ScoreBoard來讀入，環境可以讀出MCU執行程序 ROM后RAM和SFR的值并傳遞給ScoreBoard，由ScoreBoard來進行自檢，并且在log中寫出自檢結果。

3.3 功能覆蓋率收集

在Direct TestCase下，匯編代碼都是特定目的的測試代碼，所關注的寄存器狀態，或是真實指令執行情況往往很難統計，代碼覆蓋率能提供的信息相當有限。在 VMM環境中，可以通過模型的執行結果來統計指令的執行情況，因為模型和RTL是功能一致的，內部數據每條指令之后都會對比自檢，可以將模型運行的結果和模型內部對應的SFR狀態位作為功能覆蓋率收集點，將關注的功能寫為覆蓋率模型，在仿真中自動收集，并在仿真所有TestCase后將覆蓋率結果合并在一起，給出一個最終的功能覆蓋率，這里要求功能覆蓋率和代碼覆蓋率都為100%。

4 驗證功能模塊的具體實現

4.1 簡介

以VMM為基礎，實現了一個驗證8位MCU的平臺，這個平臺可以隨機生成一系列的指令，并且在每個指令后進行自檢。下面就這個平臺的詳細實現加以介紹，4.2小節將會介紹隨機指令生成，以及Scenario約束的實現，4.3小節將會介紹Driver部分，這里Driver實現了Transactor的任務，除了實現匯編，將16進制代碼讀入ROM模型中，還要調用MCU的C模型并產生結果供后續ScoreBoard對比。 4.4小節將會介紹MCU的C模型，C模型行為是直接影響MCU是否正確的保證。4.5小節將會介紹memory模型的實現，包括Internal SFR、Internal RAM、External SFR以及External RAM。4.6小節介紹過于ScoreBoard的自檢機制，以及自動終止仿真的方法。4.7小節將會介紹關于功能覆蓋率模型的建立。

4.2 指令數據包以及Scenario Generator

在VMM環境中，所有的數據都是擴展vmm_data得到，在這里首先對指令分類，相同格式的指令皆為同一類型，

分類的依據在于指令格式，例如對從工作寄存器Rn到A的操作，或是從直接地址Rx到A的操作，這樣可以通過約束一個種類來隨機化指令格式，生成指令格式以后可以根據指令格式來填入相應的隨機值。首先就是約束指令格式對應的指令，代碼如：

constraint add_mode_decide_kind{

(addr_mode==RN_A) -> kind inside {MOV， ADD， ADDC， SUBB， XCH， ANL， ORL， XRL};

(addr_mode==RX_A) -> kind inside {MOV， ADD， ADDC， SUBB， XCH， ANL， ORL， XRL};

…………}

然后約束對應的寄存器地址，立即數，相對地址等，代碼如：

constraint inst_valid{

di_x inside {[0:255]};

reg_y inside {[0:255]};

reg_i inside {0， 1};

reg_n inside {[0： 7]};

…。}

得到了指令的格式，隨機得到指令，指令參數，在以上約束下就可以生成一條符合語法的指令。通過在TestCase中約束指令格式，或是地址數據就可以在TestCase中控制Generator生成的指令，通過變換隨機種子就可以生成不同類型的指令集合。

使用宏定義對數據類擴展就可以得到數據類的Generator和Channel：

`vmm_channel(inst)

`vmm_scenario_gen(inst， “inst”)

每次scenario Generator生成一條指令，并且通過channel傳遞給Driver。可以將一系列約束做為一個scenario，這樣可以控制指令與指令之間的關系，將一系列scenario合并可以生成更多的隨機組合，例如：

$void(scenario_kind) == R0_OP -> {

foreach(items[i]){

items[i].addr_mode inside {0，1，2，4，5，6，7，8，10，11，12，13，14，21，22，23，24，26，27，28=};

items[i].reg_x inside {0};

items[i].reg_n inside {0};

items[i].reg_i inside {0};

}

}

驗證這里能夠做到盡可能大量重復地測試某些指令的集合，以便將一些邊緣情況測到，例如實際應用上會反復使用累加器或是反復調用R0-R7，都可以通過約束來實現。大量隨機的代碼測試下，可以給出更邊緣的TestCase，盡可能地測試到一些邊緣情況。

4.3 Driver

這里Driver實現了Transactor的功能，除了實現將asm代碼匯編，將16進制代碼讀入ROM模型中，還要調用MCU的C模型并產生結果，供后續ScoreBoard對比。

由于匯編器需要將所有指令代碼讀入進行統一匯編，由Generator生成的所有指令代碼在Driver中會被寫入asm文件，通過DPI調用一個匯編的 C function來處理這個asm文件，生成一個HEX 代碼文件，Driver可以讀入這個HEX 代碼，并且寫入一個用SystemVerilog實現的ROM模型中，另外通過DPI調用一個C的MCU仿真器，可以實時寫出每一條指令MCU的SFR、 RAM狀態，同樣這些狀態都保留在單獨的文件中，以作為ScoreBoard的輸入。

因為MCU的指令組合可以說是無法測全的，真正的測試往往要發生在應用代碼測試上，Driver除了可以接受從channel中得到的指令，也可以直接從外部文件得到asm代碼或是16進制代碼，這樣已有的MCU測試代碼或是應用程序都可以在這個環境中直接調用。此外，中斷的外部輸入也有隨機的數據灌入，外部端口的輸入數據也是在指令數據包中產生，并且由TestCase控制的。MCU工作方式的特殊性，導致Driver相對于驗證環境較為獨立，與驗證環境的接口都是磁盤文件。

4.4 C模型

環境中使用兩個C模型：匯編器和仿真器，將asm代碼匯編成為16進制代碼，并仿真16進制代碼。通過DPI調用C函數如下：

import “DPI” function void asmb_r(string in_file， string out_file);

import “DPI” function void siml(int run_for_n_ins， string in_file2， string in_file1， string in_file， string out_file， string out_file2， string out_file3， string out_file4);

如Driver所示，輸入輸出都是磁盤文件。匯編器通過查表將指令翻譯成16進制代碼，對于變量將用哈希表實現，通過查表替換，插入校驗碼，最后得出的16進制代碼，作為MCU的C模型仿真輸入，并且由Driver的ROM模型讀入。

仿真器輸入16進制代碼，通過先解碼16進制代碼，然后逐條執行代碼，所有memory都是在C中實現，每個指令分別調用相應的函數，此外還有相應的中斷函數處理中斷，在每一條指令后寫出SFR，Internal RAM以及External RAM中的值到磁盤文件中，以作為RTL仿真的參照，C模型的結果直接影響整個驗證的準確性，因為RTL是由時鐘驅動，而C模型是不帶時序關系，有些指令的執行結果需要根據時序做部分調整，調整模型在驗證中占去較多資源。

4.5 memory模型

MCU外圍連接了四個外部memory，包括Internal SFR、Internal RAM、External SFR以及External RAM。在驗證MCU時，memory中的值就可以保證MCU的工作狀態，因此在驗證中，MCU的外部memory都是用SystemVerilog實現的行為模型，除了通過interface io來響應MCU的讀寫要求之外，還有數據通道通往ScoreBoard，這里每個MCU時鐘都會將memory值記錄下來送往ScoreBoard，由于Internal SFR、Internal RAM、External SFR僅有128 byte，數據量較小，可以每個時鐘周期來檢查，但對于External RAM有64k byte，對比或是傳輸都比較耗費資源。另外，對External RAM的操作并不多，這里實現的是在Testcases中約束對于External RAM的地址都為低256 byte，這樣可以有效地控制數據量并且在每個時鐘周期檢查memory狀態，另外一種可選方式是每隔一定數量的指令來對比External RAM的值，同樣對仿真影響較小。

4.6 ScoreBoard

ScoreBoard收集到從各個memory傳遞過來的memory值，因此對應一塊memory就會有一塊ScoreBoard，對比通過讀取MCU 的C模型寫出的memory狀態值，由于MCU模型寫出的值是每條指令執行之后的值而memory傳遞過來的數據為每個時鐘周期，這里 ScoreBoard不但要負責解讀C模型寫出的參照memory結果文件，通過參照將確認每個指令執行時鐘周期長度，然后從memory模型傳遞過來的數據中選取該指令執行之后一個時鐘周期的數據與參照數據進行對比，考慮到部分數據會有延遲，ScoreBoard在對比時，不僅僅考慮當前比較時間點上的數據，如果對比失敗，ScoreBoard的自檢會進入子線程，繼續讀取memory傳遞過來的數據，考慮到MCU支持指令延遲操作最多8個時鐘周期，如果在后續16個周期內得到正確的值，ScoreBoard會認為結果正確，并且中止子線程返還檢查成功標志。

MCU指令一旦開始運行，尤其是隨機指令，指令執行不是順序，有時會跳入死循環，很難設定仿真中止時間，這里設定了兩種機制，一種是仿真指令計數，另一種就是根據覆蓋率分析，通過VMM的覆蓋率分析函數，可以動態的得到覆蓋率情況，如果隨機指令跳入死循環，覆蓋率就會一直維持不變，每次覆蓋率分析不變就進行計數，當計數超過限定，就會讓ScoreBoard結束，通過環境對ScoreBoard的監測，一旦ScoreBoard停止，整個仿真也會停下。

4.7 功能覆蓋率模型

對于MCU這樣的DUT，代碼覆蓋率已經不能夠代表驗證進度，而功能覆蓋率也只能代表相當一部分待驗證的功能，這里對于基本的memory，功能覆蓋率僅要求所有位都被指令操作過，對于特殊寄存器SFR，需要指定某些特定位有相應的“0”以及“1”狀態。代碼如下：

coverpoint memory[‘h87]

{

wildcard bins b87m_0_0 = {8’bxxxxxxx0};

wildcard bins b87m_1_0 = {8‘bxxxxxxx1};

wildcard bins b87m_0_1 = {8’bxxxxxx0x};

wildcard bins b87m_1_1 = {8‘bxxxxxx1x};

}

另外可以收集指令與指令參數的交叉覆蓋率分析，例如：

covergroup gen_port_cov;

coverpoint addr_mode;

coverpoint kind;

cross addr_mode， kind;

option.weight = 0;

endgroup

可以說對于MCU這樣的DUT，功能點很難被完全描述，但是功能覆蓋率還是提供了一部分量化指標，供驗證參考。

5 小結

本文實現了一個驗證MCU指令的基于VMM的驗證環境，在這個環境里不但可以使用隨機的指令生成來輸入指令，也可以使用已有的應用程序代碼，另外提供了 memory自檢環境，可以在每一條指令執行后檢查memory值，從最全面角度保證每條指令執行結果是正確的。此外還提供了功能覆蓋率模型，收集覆蓋率結果。這個環境可以被復用擴展，基于這個MCU開發的軟件都可以在這個驗證環境中先運行以保證軟件的正確性。
審核編輯：彭菁