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

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

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

驗證方法

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

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

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

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

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

VMM的應用

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

圖1：測試平臺框圖。

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

1. 背景

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

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

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

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

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

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

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

2. 評估標準

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

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

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

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

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

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

后文的敘述都將圍繞著這幾方面展開。

AXI-VIP的集成

        如前所述，VMM方法具備抽象分層結構、有九個執行步驟等優點，但它只是一個通用的方法，能否符合前邊提出的四點判定標準還成問題。舉例來說，計算所的AXI主設備(master)仿真模型是以Verilog編寫的，無法在短期內實現與VMM平臺的互聯；完整的AXI協議檢測，對本所第一顆基于該總線的片上系統顯得尤為重要；由于時間倉促，AXI仿真模型還有待修正。這些都是項目進程中無法回避的問題，而VMM方法本身又沒有提供解決方法。

1. 商用驗證模型

        AXI驗證模型(VIP)是Synopsys公司的商用模型，可配置、數據交易嚴格符合AXI協議，具備完整的協議檢查功能。最重要的一點是，AXI-VIP提供與VMM平臺的接口。實際上，這個VIP本身就實現了VMM平臺的驅動部件(Driver)加監控部件(Monitor)的功能：向下層是與DUT通過端口相聯，向上層則有基于vmm_channel/vmm_xactor_callbacks的數據傳輸管道。如圖2所示，除Test、Generator和Scoreboard之外的部分，AXI-VIP都已實現。這個商用模型對開發進度的實際貢獻將取決于工程師能否快速上手。換言之，VIP的易用性決定了它的價值。

        有鑒于此，Synopsys公司提供一個基于AXI-VIP的VMM范例。其中，DUT部分以AXI Bus VIP替代，TB部分實現了如圖2所示的分層架構。工程師作為用戶只需做如下修改，便能得到包含有簡單數據交易、自檢測、覆蓋率統計等功能的驗證平臺：替換DUT，并修改接口信號名；改寫測試例test_1的約束條件，得到自己的測試例；增加對DUT的配置操作。上述工作于一天內完成，仿真輸出結果有波形文件、Log文件及覆蓋率報告。

2. AXI-VIP支持的類

AXI- VIP定義的類都有相同的前綴名“dw_vip_axi”，它們構成vmm_env當中的大部分：

a. dw_vip_axi_master_rvm；

b. dw_vip_axi_slave_rvm；

c. dw_vip_axi_monitor_rvm；

d. dw_vip_axi_master_transaction_scenario_gen；

e. dw_vip_axi_port_model_configuration；

f. dw_vip_axi_system_model_configuration；

g. dw_vip_axi_master_transaction_channel；

h. dw_vip_axi_slave_resp_transaction_channel；

i. dw_vip_axi_monitor_transaction_channel。

        這些類將例化產生主設備部件、從設備部件、監控部件、配置對象、數據對象和數據傳輸管道等等。它們有著各自的變量、函數，提供了豐富的控制功能，涵蓋所有類型的操作。

        功能的完備并未損害AXI-VIP的易用性，這點在項目中得到了印證。通過三天的培訓與實做，工程師們能夠通過"修改約束條件來隨機產生測試向量"，按照芯片測試規范改寫"自動比對機制"，添加"功能覆蓋點"，并利用AXI監控部件"自動檢查協議"并收集與AXI協議相關的覆蓋率。

        這當中，按照芯片測試規范改寫“自動比對機制”沒有現成的VMM基本類可用。我們是從Synopsys提供的簡單范例入手，利用AXI-VIP提供的回調函數集，獲取數據交易信息，并實時地比對流出與流入數據。如同其他的驗證系統，這部分工作是最多樣化，也是最為核心的任務，所以占用三天當中的大部分時間，也在意料之中。

基于VMM的Scoreboard實現

        本所驗證組以VMM方法為指導，利用AXI-VIP提供的回調函數集，快速建立了該測試平臺的自動比對機制。盡管還不能最終應用在十幾個主/從設備的全系統中，但是，由于這部分代碼封裝在自定義的Scoreboard類當中，可重用、可擴展，并且符合VMM平臺的接口要求，可以很方便地合入將來的系統中。該Scoreboard類的核心部分SystemVerilog代碼由Synopsys提供，如圖3所示。

圖3：自檢測單元的結構框圖。

        左端是主設備數據緩沖及比對，右端為從設備數據緩沖及比對，中間的1到N和N到1轉換，實現數據比對任務的分配。N個從設備的比對代碼，都擴展自相同的類。正因為這種設計它是可無限擴展的。基于本項目只有兩個主設備的特點，我們對左邊的結構做了大幅度簡化。

        核心的比對部分之外，關鍵任務就是實時地獲取各主/從設備的數據流。這在AXI-VIP(也包括Synopsys公司的其他VIP)中，已經有現成函數可用。本所工程師在兩天時間內就學會使用，并結合實際完成了代碼的開發與調試。

        AXI-VIP包括主設備、從設備與監控設備，它們在數據交易的幾個關鍵點將得到一次函數回調的機會，如表1所示。

表1：回調函數與相應管道的對應關系表。

        依據這些回調函數對應的數據交易階段，我們選取主設備的post_input_channel_get，從設備的pre_output_channel_put兩函數來獲取交易數據。

        其它函數也可以用來獲取數據，如監控設備的pre_activity_channel_put，就可以得到輸入、輸出兩方面的數據。具體請參看AXI-VIP使用手冊。另外，VMM回調函數還可以用于控制驗證流程、插入錯誤數據等等，限于篇幅，本文不再展開。

本文小結

        因為芯片驗證工作的趨勢是需要更多的軟件知識和技巧。本文以中科院計算所的SoC項目為例，講解了如何充分利用專業的驗證語言基本庫和商用的仿真模型快速建立測試平臺。文中詳細介紹了各部件的使用和AXI-VIP對象如何納入VMM框架，以及這樣做的實際意義。

        VMM方法基于SystemVerilog語言，提供了完整的函數庫，而作為補充的AXI-VIP，功能完備且易用性強。基于這一新方法，本所驗證組工程師在五個工作日內快速建立了一套可方便擴展的測試平臺。建立新系統的過程中，發現一個設計的漏洞，充分體現了該方法的高效性。