追蹤
小螃蟹的筆記本
關於部落格
旅遊/ 攝影/ 影視/ 工作/ 理財/ 雜記
  • 63961

    累積人氣

  • 1

    今日人氣

    0

    追蹤人氣

VMM驗證方法在AXI匯流排系統中的實現

晶片驗證越來越像是軟體而不是硬體工作,這點已逐漸成為業界的共識。本文以軟體工程角度切入,分析中科院運算所某系統單晶片(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)和相應的驗證模型(Verification IP)。

VMM的應用

VMM不僅是方法學,更是該方法的具體實現。它包括一系列的類庫(class library)、類物件(object)連接關係以及用戶定製的程式碼。如圖1所示的測試平台中,各元件或即物件,是VMM基本類/擴展類的實例化 (Instantiate)。所涉及到的VMM基本類有vmm_xactor、vmm_scenario_gen和vmm_data等。


連接各元件,構成一個整體還需要其它一些基本類,包括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中所示。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所示。左端是主設備數據緩衝及比對,右端為從設備數據緩衝及比對,中間的1到N和N到1轉換,實現數據比對任務的分配。N個從設備的比對程式碼,都擴展自相同的類。正因為這種設計它是可無限擴展的。基於本計劃只有兩個主設備的特點,我們對左邊的結構做了大幅度簡化。


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

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

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

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

本文小結

因為晶片驗證工作的趨勢是需要更多的軟體知識和技巧。本文以中科院運算所的SoC計劃為例,講解了如何充分利用專業的驗證語言基本庫和商用的模擬模型快速設立測試平台。文中詳細介紹了各元件的使用和AXI-VIP對象如何納入VMM類別,以及這樣做的實際意義。

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

相簿設定
標籤設定
相簿狀態