VMM驗證方法在AXI總線系統(tǒng)中的實現(xiàn)

芯片驗證越來越像是軟件而不是硬件工作，這點已逐漸成為業(yè)界的共識。本文以軟件工程的視角切入，分析中科院計算所某片上系統(tǒng)(SoC)項目的驗證平臺，同時也介紹當前較為流行的驗證方法，即以專門的驗證語言結合商用的驗證模型，快速建立測試平臺(Test-bench)并在今后的項目中重用。

本文提及的高級驗證語言、方法學、驗證基本庫和仿真模型，這一套方法在近幾年中正逐漸被業(yè)界廣為采用。計算所的工作就是以這些最新成果為起點，對基于AXI總線協(xié)議的SoC建立測試平臺。

這種新方法可大幅度提高芯片驗證的效率，尤其是項目初期投入極大地降低，原因之一是面向對象編程等軟件工程方法的大量引入。當然，這也對驗證工程師的技能提出了新的要求。

驗證方法

在驗證領域，顯見的趨勢是語言劃一、仿真平臺統(tǒng)一、更加正規(guī)和高效。以本文介紹的項目為例，語言是SystemVerilog，平臺則基于VMM構建，更有驗證模型(Verification IP)助力，大幅提升了效率。正是因為部件可重用、平臺結構化、以覆蓋率為導向和高度自動化等特點，驗證工作也愈加正規(guī)，有流程可循。

專門的驗證語言，面世已有數(shù)年之久。它們出自于傳統(tǒng)的純粹Verilog(有時部分引入C/C++)描述的驗證系統(tǒng)，并有很大發(fā)展。Vera、e語言和目前已成IEEE標準的SystemVerilog就是這段時期技術創(chuàng)新的成果。

面向對象編程特性，溯其源頭便是C++語言。早在純Verilog語言驗證的時代，已有利用C++開發(fā)可重用驗證代碼的做法。工程師們看中的恰是OOP的封裝、繼承、多態(tài)及可重用等優(yōu)異特性。

驗證語言沒有相應函數(shù)庫的支持，語言本身也很難發(fā)揮效力。舉一個大家熟知的例子，視窗(Windows)編程中，使用C語言直接調用視窗系統(tǒng)的編程接口(API)實現(xiàn)，是較為傳統(tǒng)的做法，可目前卻鮮有視窗程序員這樣應用。為什么？工作量巨大，需維護的信息太多，從窗口尺寸、菜單列表到程序算法，都要加以考慮。因而作為解決方案之一的微軟基本庫(MFC)才得以大行其道。與之相得益彰的是，C++作為微軟基本庫的描述語言，也隨視窗系統(tǒng)的傳播，廣為流行開來。

現(xiàn)代芯片驗證領域，無例外地也出現(xiàn)了類似狀況。大量新方法、新模型和新類庫不斷涌現(xiàn)，減輕了驗證工程師們重復開發(fā)底層代碼的負擔，將更多精力投入到實際項目上。這一套新思路中，主要構成部分便是驗證語言(如Vera、SystemVerilog)，驗證基本庫(RVM、VMM)和相應的驗證模型。

VMM的應用

VMM不僅是方法學，更是該方法的具體實現(xiàn)。它包括一系列的類庫(class library)、類對象(object)聯(lián)接關系以及用戶定制的代碼。如圖1所示的測試平臺中，各部件或即對象，是VMM基本類/擴展類的實例化(Instantiate)。所涉及到的VMM基本類有vmm_xactor、vmm_scenario_gen和vmm_data等。

圖1：測試平臺框圖。

聯(lián)接各部件，構成一個整體還需要其它一些基本類，包括vmm_env、vmm_channel以及vmm_xactor_callbacks等。除此之外，用戶要根據(jù)芯片的實際狀況，添加或修改約束條件、接口聯(lián)線、執(zhí)行步驟、覆蓋率定義和自動比對機制(auto-check)。

1. 背景

該種類型的驗證平臺充分利用了軟件工程的成果，將整個測試平臺按照所實現(xiàn)的功能，分門別類予以切割，實現(xiàn)各模塊獨自開發(fā)、分別維護。目前，芯片規(guī)模趨于龐大，協(xié)議愈形復雜，通常要傳遞海量數(shù)據(jù)，并擁有數(shù)目繁多的端口。如果還以先前純Verilog的方式建立驗證系統(tǒng)，將很難滿足芯片開發(fā)和投片的進度。

簡而言之，簡單地激勵DUT輸入端口、監(jiān)控相應的輸出端口和編寫臨時性的代碼來做數(shù)據(jù)比對，這種驗證方法已相當落后了。當然，我們也看到某些結構簡單的芯片還有一定市場，純粹Verilog語言的驗證平臺也可以做到非常復雜(但是很難維護)，并且學習面向對象編程的代價容易令人望而卻步。但這些都是主流之外的個例，故對此本文不深入展開。

現(xiàn)代驗證系統(tǒng)，盡管包含數(shù)量眾多的模塊、多樣的數(shù)據(jù)類型/協(xié)議及各模塊間復雜的信息傳遞(保持同步、共享數(shù)據(jù)等)，它仍然是繼承傳統(tǒng)方法，歸納以往的驗證經驗，依照慣常的步驟建立測試平臺。

VMM方法也概莫能外。依照通常的流程，它為所有應用VMM的測試平臺設定了九個步驟，定義在vmm_env中：gen_cfg、build、reset_dut、cfg_dut、start、wait_for_end、stop、cleanup和report。

另一方面，VMM平臺的架構按抽象層次劃分，由以下部件組成：測試例(test)、場景發(fā)生器(generator)、驅動部件(driver)、監(jiān)控部件(monitor)、數(shù)據(jù)比對部件(scoreboard)、數(shù)據(jù)對象(data object)、數(shù)據(jù)傳輸管道(channel)、回調函數(shù)集(callback)、配置總集(dut_cfg與sys_cfg)、覆蓋率統(tǒng)計部件，以及聯(lián)接并集成以上所有部件的環(huán)境對象(environment object)，如圖2中所示。

圖2：在測試平臺中使用驗證IP可大為降低工作量。

VMM中各個部件的使用，可參看Synopsys與ARM共同出版的手冊。

2. 評估標準

該研究所之前的驗證工作均采用高級驗證語言Vera，使用SystemVerilog則是第一次。VMM方法的引入，究竟能在多大程度上提高驗證效率？該項目既是實際工作又是一次評估。

我們設定預期值，是基于以下幾點考慮：

a. 建立一個范例平臺(包含簡單的數(shù)據(jù)交易、自檢測、覆蓋率統(tǒng)計)需要多長時間？

b. 可擴展性，即隨機測試向量的約束條件更改、自動比對機制按需求定制、功能覆蓋點的添加及AXI協(xié)議的監(jiān)控是否完備。

c. 驗證流程可控性，如在已有的九步驟中插入額外動作；通過系統(tǒng)配置的改變，來控制各步驟執(zhí)行的順序和次數(shù)(比如一次reset多次cfg_dut以實現(xiàn)在線重復測試)。

d. 易用性也應當考慮在內。畢竟，VMM方法涵蓋的內容很廣，工程師們要完全掌握仍有個過程。在無法知其所以然的時候，能不能很快地知其然，并開展工作，顯得非常重要。