1.引言
芯片驗證(VerificatiON)越來越像是軟件而不是硬件工作。這點已逐漸成為業(yè)界的共識。
本文以軟件工程的視角切入,分析中科院計算所某片上系統(tǒng)(SoC)項目的驗證平臺,同時也介紹當前較為流行的驗證方法,即以專門的驗汪語言結(jié)合商用的驗證模型,快速建立測試平臺(test-bench)并在今后的項目中重用(reuse)之。
文中提及的高級驗證語言、方法學、驗證基本庫和仿真模型,這一套方法在近幾年中,正逐漸為業(yè)界廣為采用。計算所的工作,就是以這些最新成果為起點,對基于AXI總線協(xié)議的SoC,建立測試平臺。
這種新方法可大幅度提高芯片驗證的效率,尤其使項目初期的投入極大地降低。原因之一是,面向?qū)ο?a target="_blank">編程等軟件工程方法的大量引入。當然,這也對驗證工程師的技能提出了新的要求。
2.驗證方法
在驗證領(lǐng)域,顯見的趨勢是語言劃一、仿真平臺統(tǒng)一、更加正規(guī)和高效。以本文介紹的項目為例,語言是SySTemVerilog,平臺則基于VMM構(gòu)建,更有Verification IP助力,大幅提升了效率。正是因為部件可重用、半臺結(jié)構(gòu)化、以覆蓋率驅(qū)動和高度自動化等特點,驗證工作也愈加正規(guī),有流程可循。
專門的驗證語言,面世已有數(shù)年之久。它們出自于傳統(tǒng)的純粹Verilog(有時,部分引入C/C++)描述的驗證系統(tǒng),并有很大發(fā)展:Vera、e語言和目前已成IEEE標準的SystemVerilog就足這段時期技術(shù)創(chuàng)新的成果。
面向?qū)ο缶幊蹋∣bject-Oriented Programming)特性,溯其源頭便是C++語言。早在純Verilog語言驗證的時代,已有利用C++開發(fā)可重用驗證代碼的做法。工程師們看中的恰是OOP的封裝、繼承、多態(tài)、及可重用等優(yōu)異特性。
驗證語言沒有相應(yīng)函數(shù)庫的支持,語言本身也很難發(fā)揮效力。舉一個大家熟知的例子,視窗(Windows)編程中,使用C語言直接調(diào)用視窗系統(tǒng)的編程接口(APT)實現(xiàn),是較為傳統(tǒng)的做法,可目前卻鮮有視窗程序員這樣應(yīng)用。為什么?工作量巨大,需維護的信息太多,從窗口尺寸,菜單列表,到程序算法,都要加以考慮。因而作為解決方案之一的微軟基本庫(MFC)才得以大行其道。與之相得益彰的是,C++作為微軟基本庫的描述語言,也隨視窗系統(tǒng)的傳播,廣為流行開來。
現(xiàn)代芯片驗證領(lǐng)域,無例外地也出現(xiàn)了類似狀況。大量新方法、新模型、新類庫,不斷涌現(xiàn),減輕了驗證工程師們重復開發(fā)底層代碼的負荷,將更多精力投入到實際項目上。這一套新思路中,主要構(gòu)成部分便是驗證語言(如Vera、SystemVerilog)、驗證基本庫(RVM、VMM),和相應(yīng)的驗證模型(Verification IP)。
3.VMM的應(yīng)用
VMM不儀是方法學,更是該方法的具體實現(xiàn)。它包括一系列的類庫(class library)、類對象(ob-ject)聯(lián)接關(guān)系,以及用戶定制的代碼。
如圖1所示的測試平臺中,各部件(component),或即對象,是VMM基本類/擴展類的實例化(Instantiate)。所涉及到的VMM基本類有vmm_xactor、vmm_scenario_gen和vmm_data等。
聯(lián)接各部件,構(gòu)成一個整體還需要其他一些基本類,包括vmm_env、vmm_channel以及vmm_xactor_callbacks等。
除此之外,用戶要根據(jù)芯片的實際狀況,添加或修改約束條件(constraint)、接口聯(lián)線(interface)、執(zhí)行步驟、覆蓋率定義和自動比對機制(au-to-check)。
3.1 背景
該種類型的驗證平臺充分利用了軟件工程的成果,將整個測試平臺按照所實現(xiàn)的功能,分門別類予以切割,實現(xiàn)各模塊獨自開發(fā)、分別維護。
目前,芯片規(guī)模趨于龐大,協(xié)議愈形復雜,通常要傳遞海量數(shù)據(jù),并擁有數(shù)目繁多的端口。如果還以先前純Verilog的方式建立驗證系統(tǒng),將很難滿足芯片開發(fā)、投片的進度。
極而言之,簡單地激勵DUT輸入端口、監(jiān)控相應(yīng)的輸出端口和編寫臨時性的代碼來做數(shù)據(jù)比對,這種驗證方法已相當落后了。當然,我們也看到:對某些結(jié)構(gòu)簡單的芯片還有一定市場,純粹Verilog語言的驗證平臺也可以做到非常復雜(但是,很難維護),并且學習面向?qū)ο缶幊痰拇鷥r容易令人望而卻步。但這些都是主流之外的個例,故對此本文不深入展開。
現(xiàn)代驗證系統(tǒng),盡管包含數(shù)量眾多的模塊、多樣的數(shù)據(jù)類型/協(xié)議及各模塊間復雜的信息傳遞(保持同步、共享數(shù)據(jù)等),它仍然是繼承傳統(tǒng)方法,歸納以往的驗證經(jīng)驗,依照慣常的步驟建立測試平臺。
VMM方法也概莫能外。依照通常的流程,它為所有應(yīng)用VMM的測試平臺,設(shè)定了九個步驟,定義在 vmm_env 中 :gen_cfg、build、reset_dut、cfg_dut、start、wait_for_end、stop、cleanup和report。
另一方面,VMM平臺的架構(gòu),按抽象層次劃分,由以下部件組成:測試例(Test)、場景發(fā)生器(gen-erator)、驅(qū)動部件(driver)、監(jiān)控部件(monitor)、數(shù)據(jù)比對部件(scoreboard)、數(shù)據(jù)對象(data objects)、數(shù)據(jù)傳輸管道(channel)、回調(diào)函數(shù)集(callbacks)、配置總集(dut_cfg與sys_cfg)、覆蓋率統(tǒng)計部件,和聯(lián)接并集成以上所有部件的環(huán)境對象(environmentobject),如圖2所示。
VMM中各個部件的使用,可參看Synopsys與ARM共同出版的手冊。
3.2 評估標準
本所此前的驗證工作均采用高級驗證語言ve-ra,使用SystemVerilog則是第一次。VMM方法的引入,究竟能在多大程度上提高驗證效率?該項目既是實際工作,又是一次評估。
我們設(shè)定預期值是基于以下幾點考慮:
(1) 建立一個范例平臺,包含簡單的數(shù)據(jù)交易、自檢測、覆蓋率統(tǒng)計,需要多長時間?
(2) 可擴展性,即隨機測試向量的約束條件更改、自動比對機制按需求定制、功能覆蓋點的添加及AXI協(xié)議的監(jiān)控是否完備。
(3) 驗證流程可控性,如在已有的九步驟中插入額外動作;通過系統(tǒng)配置的改變,來控制各步驟執(zhí)行的順序和次數(shù)(比如一次reset多次cfg_dut以實現(xiàn)在線重復測試)。
(4) 易用性也應(yīng)當考慮在內(nèi)。畢竟,VMM方法涵蓋的內(nèi)容很廣,工程師們要完全掌握仍有個過程。在無法知其所以然的時候,能不能很快地知其然,并開展工作,顯得非常重要。
后文的敘述,都將圍繞著這幾方面展開。
4 、AXI-VIP的集成
如前所述,VMM方法具備抽象分層結(jié)構(gòu)、有九個執(zhí)行步驟等優(yōu)點,但它只是一個通用的方法,能否符合前面提出的四點判定標準,還是問題。
舉例來說,計算所的AXI主設(shè)備(master)仿真模型,是以Verilog編寫的,無法在短期內(nèi)實現(xiàn)與VMM平臺的互聯(lián);完整的AXI協(xié)議檢測,對本所第一顆基于該總線的片上系統(tǒng),顯得尤為重要;由于時間倉促,AXI仿真模型還有待修正。
這些都是項目進程中無法回避的問題,而VMM方法本身又沒有提供解決方法。
4.1 商用驗證模型
AXI驗證模型(VIP)是Synopsys公司的商用模型,可配置,數(shù)據(jù)交易嚴格符合AXI協(xié)議,具備完整的協(xié)議檢查功能。
最重要的一點是,AXI-VIP提供與VMM平臺的接口。實際上,這個VIP本身就實現(xiàn)了VMM平臺的驅(qū)動部件(Driver)加監(jiān)控部件(Monitor)的功能:向下層是與DUT通過端口相聯(lián),向上層則有基于vmm-channel/vmm_xactor_callbacks的數(shù)據(jù)傳輸管道。如圖2所示,除Test、Generator、和Scoreboard之外的部分,AXI-VIP都已實現(xiàn)。
這個商用模型對開發(fā)進度的實際貢獻,將取決于工程師能否快速上手。換言之,VIP的易用性決定了它的價值。
有鑒于此,Synopsys公司提供一個基于AXI-VIP的VMM范例。其中,DUT部分以AXI Bus VIP替代,TB部分實現(xiàn)了如圖2所示的分層架構(gòu)。工程師作為用戶,只需做如下修改,便能得到包含有簡單數(shù)據(jù)交易、自檢測、覆蓋率統(tǒng)計等功能的驗證平臺:
(1) 替換DUT,并修改接口信號名;
(2) 改寫測試例test_1的約束條件,得到自己的測試例;
(3) 增加對DUT的配置操作。
上述工作于一天內(nèi)完成,仿真輸出結(jié)果有波形文件、Log文件、及覆蓋率報告。
4.2 AXI-VIP支持的類
AXI VIP定義的類,都有相同的前綴名“dw_vip_axi”,它們構(gòu)成vmm_env當中的大部分:
這些類將例化產(chǎn)生主設(shè)備部件、從沒備部件、監(jiān)控部件、配置對象、數(shù)據(jù)對象、和數(shù)據(jù)傳輸管道等等。它們有著各自的變量、函數(shù),提供了豐富的控制功能,涵蓋所有類型的操作。
功能的完備并未損害AXI-VIP的易用性,這點在項目中得到了印證。通過三天的培訓與實做,工程師們能夠通過“修改約束條件來隨機產(chǎn)生測試向量”,按照芯片測試規(guī)范改寫“自動比對機制”,添加“功能覆蓋點”,并利用AXI監(jiān)控部件“自動檢查協(xié)議”并收集與AXI協(xié)議相關(guān)的覆蓋率。
這當中,按照芯片測試規(guī)范改寫“自動比對機制”沒有現(xiàn)成的VMM基本類可用。我們是從Synopsys提供的簡單范例人手,利用AX-I-VIP提供的回調(diào)函數(shù)集,獲取數(shù)據(jù)交易信息,并實時地比對流出與流入數(shù)據(jù)。如同其他的驗證系統(tǒng),這部分工作是最多樣化,也是最為核心的任務(wù),所以占用三天當中的大部分時問,也在意料之中。
我們在下一節(jié)中簡單介紹本項目“自動比對機制”的實現(xiàn)。
5.基于VMM的Scoreboard實現(xiàn)
本所驗證組以VMM方法為指導,利用AXI-VIP提供的回調(diào)函數(shù)集,快速建立了該測試平臺的自動比對機制。盡管還不能最終應(yīng)用在十幾個主/從設(shè)備的全系統(tǒng)中,但是,由于這部分代碼封裝在自定義的Scoreboard類當中,可重用,可擴展,并且符合VMM平臺的接口要求,可以很方便地合入將來的系統(tǒng)中。
該Scoreboard類的核心部分SystemVerilog代碼由Synopsys提供,如圖3所示。左端是主設(shè)備數(shù)據(jù)緩沖及比對,右端為從設(shè)備數(shù)據(jù)緩沖及比對,中間的1到N和N到1轉(zhuǎn)換,實現(xiàn)數(shù)據(jù)比對任務(wù)的分配。N個從設(shè)備的比對代碼,都擴展自相同的類。正因為這種設(shè)計它是可無限擴展的。基于本項目只有兩個主設(shè)備的特點,我們對左邊的結(jié)構(gòu)做了大幅度簡化。
核心的比對部分之外,關(guān)鍵任務(wù)就是實時地獲取各主/從沒備的數(shù)據(jù)流。這在AXI-VIP(也包括Synopsys公司的其他VIP)中,已經(jīng)有現(xiàn)成函數(shù)可用。本所工程師在兩天時間內(nèi)就學會使用,并結(jié)合實際完成了代碼的開發(fā)與調(diào)試。
AXI-VIP包括主設(shè)備、從設(shè)備、與監(jiān)控設(shè)備。它們在數(shù)據(jù)交易的幾個關(guān)鍵點將得到一次函數(shù)回調(diào)(callback)的機會,如表1所示。
依據(jù)這些回調(diào)函數(shù)對應(yīng)的數(shù)據(jù)交易階段,我們選取主設(shè)備的post_input_channel_get、從設(shè)備的pre_output_channel_put兩函數(shù)來獲取交易數(shù)據(jù)。
其他函數(shù)也可以用來獲取數(shù)據(jù),如監(jiān)控設(shè)備的pre_activity_channel_put,就可以得到輸入、輸出兩方面的數(shù)據(jù)。具體請參看AXI_VIP使用手冊。
另外,VMM回調(diào)函數(shù)還可以用于控制驗證流程、插入錯誤數(shù)據(jù)等等,限于篇幅,本文不再展開。
6、 結(jié)語
因為芯片驗證工作的趨勢是需要更多的軟件知識和技巧。本文以中科院計算所的SoC項目為例,講解了如何充分利甩專業(yè)的驗證語言基本庫和商用的仿真模型,快速建立測試平臺。文中詳細介紹了各部件的使用,和AXI-VIP對象如何納入VMM框架,以及這樣做的實際意義。
VMM方法基于SystemVerilog語言,提供了完整的函數(shù)庫,而作為補充的AXI-VIP,功能完備且易用性強。基于這一新方法,本所驗證組工程師在五個工作日內(nèi)快速建立了一套可方便擴展的測試平臺。在建立新系統(tǒng)的過程中,發(fā)現(xiàn)一個沒計的漏洞,充分體現(xiàn)廠該方法的高效性。
責任編輯:gt
評論