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