基于混合建模的SoC軟硬件協(xié)同驗(yàn)證平臺(tái)研究
摘 要 針對(duì)SoC片上系統(tǒng)的驗(yàn)證,提出新的驗(yàn)證平臺(tái),實(shí)現(xiàn)SoC軟硬件協(xié)同驗(yàn)證方法。首先介紹SoC軟硬件協(xié)同驗(yàn)證的必要性,并在此基礎(chǔ)上提出用多抽象層次模型混合建模(Co-Modeling)的方法構(gòu)建出驗(yàn)證平臺(tái)。然后,闡述了此驗(yàn)證平臺(tái)的優(yōu)點(diǎn),如驗(yàn)證環(huán)境統(tǒng)一、仿真速度快等,接下來介紹了驗(yàn)證平臺(tái)架構(gòu)及關(guān)鍵部分的具體實(shí)現(xiàn)。最后以一個(gè)實(shí)例說明此驗(yàn)證平臺(tái)的可用性。此驗(yàn)證平臺(tái)適于實(shí)現(xiàn)SoC軟硬件協(xié)同驗(yàn)證,降低了SoC的驗(yàn)證難度。
關(guān)鍵詞 片上系統(tǒng)軟硬件協(xié)同驗(yàn)證混合建模驗(yàn)證平臺(tái)
引 言
伴隨著微電子產(chǎn)業(yè)的發(fā)展和摩爾定律的不斷應(yīng)驗(yàn),IC設(shè)計(jì)的規(guī)模越來越大,集成度也越來越高,已經(jīng)足以將整個(gè)系統(tǒng)集成到一個(gè)芯片中,這種技術(shù)就是SoC(System onChip,片上系統(tǒng))技術(shù)。相對(duì)于PCB(Printed CircuitB0ard,印刷電路板)級(jí)的系統(tǒng),SoC的優(yōu)點(diǎn)是顯而易見的。SoC意味著更好的電路時(shí)序和更高的可靠性,但同時(shí)SoC也意味著更復(fù)雜的邏輯。為了解決SoC的眾多設(shè)計(jì)難題,SoC設(shè)計(jì)方法學(xué)中最顯著的一個(gè)特征就是IP(Intellec-tual Property,知識(shí)產(chǎn)權(quán))的復(fù)用技術(shù);然而系統(tǒng)的復(fù)雜度決定了不可能簡(jiǎn)單地將各個(gè)IP模塊集成起來就完成了SoC的設(shè)計(jì),SoC驗(yàn)證成為了一個(gè)新的問題。
在驗(yàn)證問題成為SoC設(shè)計(jì)的新的挑戰(zhàn)之后,人們逐漸提出各種應(yīng)對(duì)方法。其中,SoC軟硬件協(xié)同驗(yàn)證的思想,切實(shí)反應(yīng)了SoC驗(yàn)證中的問題和解決方法,越來越多地受到關(guān)注。本文以SoC軟硬件協(xié)同驗(yàn)證思想為基礎(chǔ),提出一種驗(yàn)證平臺(tái)的實(shí)現(xiàn);同時(shí)考慮到SoC的不同設(shè)計(jì)層次,建立起統(tǒng)一的高速的系統(tǒng)級(jí)驗(yàn)證環(huán)境,有效的緩解了SoC驗(yàn)證中的關(guān)鍵難題。
1 SoC軟硬件協(xié)同驗(yàn)證
SoC設(shè)計(jì)中,系統(tǒng)的功能是需要SoC的軟件硬件相互配合共同實(shí)現(xiàn)的,這就出現(xiàn)了軟硬件接口的驗(yàn)證問題。在以往的系統(tǒng)設(shè)計(jì)流程中,由于軟件的實(shí)際運(yùn)行需要一個(gè)完整的可用的硬件平臺(tái),軟件與硬件的接口的驗(yàn)證過程是在硬件全部開發(fā)完畢,至少獲得了硬件原型之后。這樣的開發(fā)流程最嚴(yán)重的問題就是,軟硬件之間的接口可能出現(xiàn)設(shè)計(jì)上的錯(cuò)誤。而要糾正這樣的錯(cuò)誤,要么修改軟件來適應(yīng)硬件(這一般都會(huì)導(dǎo)致系統(tǒng)整體性能的損失),要么修改硬件來適應(yīng)軟件(這又要導(dǎo)致硬件的設(shè)計(jì)、制造的更改,造成成本上升,設(shè)計(jì)周期延長)。無論哪一種方法都是設(shè)計(jì)者所不希望看到但是又不能保證避免的。所以,在SoC的設(shè)計(jì)方法學(xué)中,必須在軟硬件的開發(fā)過程中,就完成硬件原型的建立,并開始軟硬件的聯(lián)合驗(yàn)證,即SoC軟硬件協(xié)同驗(yàn)證。
2 混合建模實(shí)現(xiàn)SoC軟硬件協(xié)同驗(yàn)證
本文在一般的SoC軟硬件協(xié)同驗(yàn)證的基礎(chǔ)上,提出混合建模方法(Co-Modeling),使用各種不同抽象層次的模型共同組成SoC硬件系統(tǒng),直接為SoC的軟件提供可運(yùn)行的載體,來實(shí)現(xiàn)SoC軟硬件協(xié)同驗(yàn)證。不同抽象層次的模型包括事務(wù)級(jí)模型、功能性模型的高抽象層次的模型和RTL模型。
2.1 驗(yàn)證平臺(tái)架構(gòu)說明
如圖1所示,整個(gè)驗(yàn)證平臺(tái)的架構(gòu)可以分為兩個(gè)部分:軟件建模部分,以PC機(jī)上軟件的形式建模;硬件建模部分,以FPGA的形式建模。全部的硬件部分和除“ARM軟件集成開發(fā)環(huán)境”之外的軟件部分都用來建模SOC硬件系統(tǒng),SoC軟件可以直接在這個(gè)SoC硬件系統(tǒng)模型上運(yùn)行、調(diào)試,如圖中“ARM軟件集成開發(fā)環(huán)境”所示。驗(yàn)證平臺(tái)建模的SoC硬件系統(tǒng),是針對(duì)ARM架構(gòu)的SoC,以AHB總線為基礎(chǔ)。AHB總線上的各模塊為建模的基本單元。
驗(yàn)證平臺(tái)軟件部分中最重要的模型是CPU的ISS(Instlruction Set Simulator,指令集仿真器),用來模擬SoC系統(tǒng)中的CPU,可以提供軟件代碼執(zhí)行時(shí)周期準(zhǔn)確的仿真結(jié)果。平臺(tái)中使用的是ARM系列CPU的ISS,稱為ARMulator。ARMulator也是ARM CPU軟件集成開發(fā)環(huán)境的直接載體,SoC的軟件開發(fā)人員可以在基于AR-Mulator’的集成開發(fā)環(huán)境中運(yùn)行、調(diào)試源代碼,與其在真實(shí)的CPU上的運(yùn)行調(diào)試完全相同。其他的總線模型,如圖中所示的IP3、IP4,用來描述SoC硬件系統(tǒng)中除CPU之外的一些模塊,最好都是SystemC語言描述的事務(wù)級(jí)模型。事務(wù)級(jí)模型是RTL級(jí)硬件模型的抽象,省略了RTL級(jí)的實(shí)現(xiàn)細(xì)節(jié),但是仍然以周期數(shù)精確等方式反映了RTL級(jí)模型的特點(diǎn),是設(shè)計(jì)初期系統(tǒng)建模的常用選擇。不過考慮到驗(yàn)證環(huán)境的通用性,再加上ARMulator本身也并不是SystemC語言的模型,而是基于C的功能性模型,驗(yàn)證環(huán)境自然需要同時(shí)支持事務(wù)級(jí)模型與功能性模型,因此,驗(yàn)證平臺(tái)也支持其他總線模塊以C/C++等語言描述的功能級(jí)模型。這些模型與ARMulator都連接到AHB總線的模型上,如圖1中IP3、IP4所示,AHB總線模型負(fù)責(zé)完成ARMulator。與軟件方各總線模型間,以及與硬件方之間的連接。
驗(yàn)證平臺(tái)硬件部分的物理載體是以FPGA為主的PCB板卡,以PCI總線為物理通道連接到PC機(jī)。SoC硬件系統(tǒng)中RTL模型形式的總線模塊全部下載到FPGA內(nèi)部,如圖1中的IPl、IP2。由于FPGA內(nèi)模塊的RTL模型與CPU之間的總線通信數(shù)據(jù)可以在軟件方得到良好的可觀測(cè)性,對(duì)于以驗(yàn)證總線模塊間通信正確性為目的的系統(tǒng)級(jí)驗(yàn)證來說,模塊間通信數(shù)據(jù)的可觀測(cè)性是足夠的,這也就部分避免了硬件建模方法觀測(cè)性不足的缺點(diǎn)。
因?yàn)檐浖降哪P统橄髮哟伪扔布絉TL模型的抽象層次高,所以要想把軟件方模型和硬件方模型組合起來形成可用的SoC硬件系統(tǒng),就必須完成這兩種抽象層次之間的數(shù)據(jù)同步和交換,這個(gè)任務(wù)是BFM完成的。BFM的具體實(shí)現(xiàn)將在后面詳細(xì)闡述??傮w的效果是,在軟件方模型看來,BFM代表了硬件上的RTL模型,對(duì)軟件方隱藏了RTL模型的實(shí)現(xiàn)細(xì)節(jié),軟件方只需要訪問BFM,就得到了相應(yīng)模塊的數(shù)據(jù);而在硬件方模型看來,BFM代表了軟件方的所有總線模塊,BFM驅(qū)動(dòng)的RTL級(jí)總線信號(hào)就是由軟件方中各總線模塊的總線訪問轉(zhuǎn)化而來的。
硬件方與軟件方接口的實(shí)現(xiàn),以PCI總線為基礎(chǔ),遵守SCE-MI(Standard C-Emulation Modeling Interface)協(xié)議。SCE-MI是.Accellera組織提出的用于規(guī)范協(xié)同仿效平臺(tái)中軟件方與硬件方之間的接口的協(xié)議,是業(yè)界實(shí)際的標(biāo)準(zhǔn),目前已被多個(gè)商業(yè)化驗(yàn)證平臺(tái)支持。本驗(yàn)證平臺(tái)的BFM遵守SCE-MI協(xié)議接口,也是為了驗(yàn)證平臺(tái)以及BFM本身的通用性。
如上所述,通過BFM的層次轉(zhuǎn)接作用,軟件方模型和硬件方模型得以完成連接,不同抽象層次的模型共同構(gòu)成了SoC的硬件系統(tǒng);而SoC的軟件則可以以此硬件系統(tǒng)為基礎(chǔ),得到實(shí)際的運(yùn)行和調(diào)試,最終建立起了混合建模的軟硬件協(xié)同驗(yàn)證環(huán)境。
2.2 以平臺(tái)為基礎(chǔ)的驗(yàn)證流程
基于上述驗(yàn)證平臺(tái),混合建模方法的流程如圖2所示。在系統(tǒng)級(jí)仿真和軟硬件劃分之后,開始軟件和硬件的并行設(shè)計(jì),同時(shí)開始軟硬件協(xié)同驗(yàn)證。協(xié)同驗(yàn)證過程可以分為三個(gè)階段。在最初的驗(yàn)證階段中,SoC硬件系統(tǒng)全部由軟件方的模型建模。隨后的階段,開始完成硬件系統(tǒng)中高層模型中IP模塊的逐個(gè)細(xì)化,此時(shí),完成了RTL模塊開發(fā)的IP可從軟件建模部分移到硬件建模部分的FPGA中,還未開發(fā)出的模塊,或是未完成配置的IP仍然由軟件方的模型建模。這樣,設(shè)計(jì)人員完成一個(gè)模塊的細(xì)化,驗(yàn)證人員就可以開始系統(tǒng)級(jí)驗(yàn)證工作,而不必等到系統(tǒng)的全部模塊全部完成細(xì)化后才開始驗(yàn)證。這樣,一方面避免了驗(yàn)證等待設(shè)計(jì)的情況;另一方面,模塊的逐個(gè)細(xì)化,可以使新出現(xiàn)的仿真錯(cuò)誤的bug被定位到最后細(xì)化的模塊中,有效降低了驗(yàn)證的難度。最后的階段,除CPU之外,SoC硬件的所有模塊都被逐步移到了驗(yàn)證平臺(tái)的硬件方FPGA中,即基本完成了RTL級(jí)模型的SoC軟硬件協(xié)同驗(yàn)證,之后向快速原型驗(yàn)證的遷移是也非常方便的,大部分的驗(yàn)證環(huán)境都可以復(fù)用。
總的來說,混合建模方法的好處就在于:建立支持不同抽象層次模型的驗(yàn)證環(huán)境,從而在不同層次的驗(yàn)證中實(shí)現(xiàn)驗(yàn)證環(huán)境的復(fù)用,也使得在不同層次的設(shè)計(jì)過程中始終都可以進(jìn)行系統(tǒng)級(jí)驗(yàn)證;同時(shí)糅合了軟件和硬件建模方法的特點(diǎn)來解決RTL模型仿真速度慢的問題,并且避免了硬件建模的低可觀測(cè)性增加系統(tǒng)驗(yàn)證難度的問題。
3 總線功能模型BFM
在上述的驗(yàn)證平臺(tái)中,BFM模塊起著混合建模方法中高層次模型與RTL模型間的轉(zhuǎn)接作用,是驗(yàn)證平臺(tái)中最為關(guān)鍵的組成部分。下面詳細(xì)闡述BFM模塊的概念和具體實(shí)現(xiàn)。
3.1 BFM及事務(wù)級(jí)的概念
BFM是與TL(Transaction Level,事務(wù)級(jí))的概念分不開的。TL模型是高于RTL模型的一個(gè)抽象層次,忽略了RTL模型中具體的信號(hào)和時(shí)序信息,但是保持RTL模型中模塊的框架和模塊間數(shù)據(jù)通信的信息和周期數(shù)。TL模型最典型的例子就是符合總線接口協(xié)議的模塊,例如符合AHB總線接口的一個(gè)模塊A,模塊A的TL模型保持與其RTL模型相同的模塊接口、模塊邊界以及內(nèi)部功能,但是其內(nèi)部功能只是功能性描述,不涉及硬件具體實(shí)現(xiàn);模塊的接口則是忽略了AHB總線接口協(xié)議的具體信號(hào)和相關(guān)時(shí)序,只關(guān)心其總線訪問的關(guān)鍵信息,如訪問的地址、數(shù)據(jù)、完成訪問所花的周期數(shù)等。模型的優(yōu)點(diǎn)是忽略了硬件具體實(shí)現(xiàn)細(xì)節(jié),使得模型大大簡(jiǎn)化,模型的建立和仿真都不復(fù)雜,同時(shí)又保留了部分RTL模型的特征,使得仿真結(jié)果的精確度有一定保證,滿足了系統(tǒng)級(jí)仿真的需求。
BFM的作用是完成TL和RTL之間的數(shù)據(jù)同步和交互。簡(jiǎn)單的來說,BFM一方面完成了將RTL級(jí)的總線傳輸信號(hào)抽象為事務(wù)級(jí)的數(shù)據(jù)包的作用,封裝了總線傳輸中繁瑣的具體時(shí)序信息,只將其中的地址、數(shù)據(jù)等有用信息提取出來,形成TL信息,完成了抽象程度的提升;另一方面,BFM根據(jù)特定的接口標(biāo)準(zhǔn),在TL數(shù)據(jù)的基礎(chǔ)上,補(bǔ)充其缺失的RTL時(shí)序、信號(hào)信息,還原為RTL數(shù)據(jù),即完成抽象程度的下降。因此,BFM與模塊接口的標(biāo)準(zhǔn)是緊密結(jié)合的,一種BFM負(fù)責(zé)一種接口標(biāo)準(zhǔn)的TL和RTL數(shù)據(jù)的相互轉(zhuǎn)化。下面以我們驗(yàn)證平臺(tái)中的BFM為例,說明TL數(shù)據(jù)訪問與RTL數(shù)據(jù)訪問之間的對(duì)應(yīng)關(guān)系。驗(yàn)證平臺(tái)中的BFM以AHB總線為接口。
3.2 BFM的具體實(shí)現(xiàn)
本文中的BFM可以分為兩個(gè)組成部分:與SCE-MI協(xié)議的接口和與AHB總線的接口。與SCE-MI協(xié)議的接口部分完成TL數(shù)據(jù)的接收和發(fā)送。與AHB總線的接口部分完成總線RTL信號(hào)的驅(qū)動(dòng),其實(shí)現(xiàn)的關(guān)鍵在于AHB總線協(xié)議的信號(hào)識(shí)別,這里采用有限狀態(tài)機(jī)來檢測(cè)、控制AHB總線RTL信號(hào),下面給出狀態(tài)機(jī)中控制AHB單周期總線傳輸?shù)臓顟B(tài)機(jī)狀態(tài)轉(zhuǎn)移圖。如圖3所示,狀態(tài)HTRANS對(duì)應(yīng)AHB時(shí)序圖中address phase周期;狀態(tài)WAIT對(duì)應(yīng)Data Phase;狀態(tài)SUSPEND對(duì)應(yīng)AHB時(shí)鐘停止,接收/發(fā)送TL數(shù)據(jù)的狀態(tài);狀態(tài)ERROR對(duì)應(yīng)總線傳輸出錯(cuò)的情況。
BFM是為了驗(yàn)證的目的而引入的一個(gè)額外模塊。BFM本身的設(shè)計(jì)和驗(yàn)證雖然會(huì)增加工作量,但是由于BFM作為一個(gè)VIP(Verification IP),可以在不同的驗(yàn)證流程中得到復(fù)用。例如,本驗(yàn)證平臺(tái)中AHB總線接口的BFM,就可以在不同的使用AHB總線的SoC驗(yàn)證中得到復(fù)用,相當(dāng)于降低了BFM的開發(fā)復(fù)雜度。BFM遵守SCE-MI協(xié)議的規(guī)定也正是出于通用性的考慮。
4 實(shí)驗(yàn)與結(jié)論
為了說明驗(yàn)證平臺(tái)的可行性和驗(yàn)證的高效性,以一個(gè)AC3音頻格式解碼系統(tǒng)為例,使用混合建模的方法構(gòu)建其系統(tǒng)級(jí)模型并完成了驗(yàn)證。AC3音頻解碼系統(tǒng)的硬件架構(gòu)如圖4所示,系統(tǒng)采用ARM架構(gòu),主要由ARM處理器核、存儲(chǔ)器以及解碼硬件加速器IP、DAC(Digital to AnalogConverter,數(shù)模轉(zhuǎn)換器)構(gòu)成。采用混合建模的方法,ARM處理器核以及存儲(chǔ)器部分在軟件方建模,解碼加速器IP、DAC則使用RTL模型,在硬件方建模。實(shí)驗(yàn)證明,混合建模的驗(yàn)證平臺(tái)是可行的,驗(yàn)證速度也在可以接受的范圍內(nèi)。
總的來說,本文介紹的基于混合建模的SoC軟硬件協(xié)同驗(yàn)證的方法,針對(duì)SoC驗(yàn)證挑戰(zhàn)中最突出的問題,提出在SoC的設(shè)計(jì)過程中以混合建模的方式完成SoC整個(gè)系統(tǒng)的建模并開始驗(yàn)證,使系統(tǒng)各層次之間的驗(yàn)證平滑過渡,縮短了設(shè)計(jì)周期;同時(shí)也減少了軟硬件之間不協(xié)調(diào)的可能性,避免了大跨度的設(shè)計(jì)流程的迭代,并且滿足了系統(tǒng)級(jí)仿真的速度要求,沒有影響驗(yàn)證的效率。因此,這種方法對(duì)于SoC的驗(yàn)證方法的不斷完善有著一定的積極意義。