基于FPGA原型設(shè)計 能為您做些什么?
作為基于 FPGA 原型方法的擁護者,有人可能會認為我們只片面地看到了這種方法的優(yōu)點,而對其缺陷視而不見。但那絕非我們的本意。我們這本《基于 FPGA 的原型方法手冊》旨在全面揭示基于 FPGA的原型的利弊,因為最終我們并不想看到有人本來可以使用其他方法更好地達到目的(比如說用基于System C的虛擬原型),卻行進在這種方法的漫漫征途上。
讓我們來更深入地研究一下基于FPGA原型方法的目的和局限性,以及其對于系統(tǒng)級驗證和其他目的的適用性。把重點始終放在原型項目的目的上,讓我們在平臺、IP 使用、設(shè)計導出、調(diào)試及其他設(shè)計方面更容易地做出決策。這樣,我們就能夠通過分析世界上其他原型設(shè)計團隊的案例,從他們的項目中汲取經(jīng)驗。
基于FPGA的原型可滿足不同目的需求
原型設(shè)計不是一個按幾個按鈕就能完成的過程,在它不同的階段需要仔細的關(guān)注和思考。除說明這個過程需要完成的工作和涉及到的專業(yè)知識外,我們還應(yīng)解釋在 SoC 項目中該進行(或者不該進行)原型設(shè)計的原因。在與原型設(shè)計人員多年交談中,我們最常問到的一個問題是“為什么您這么做?”。答案有多種多樣,我們把它們總結(jié)成了表 1 中幾條常見的理由。舉例來說,“真實環(huán)境中的數(shù)據(jù)效應(yīng)”,這可能指的是某個團隊的工作是通過原型設(shè)計得到某個系統(tǒng)全速運行時的模型,并將其與其他系統(tǒng)或外設(shè)相連,目的可能是為了測試對某個新接口標準的合規(guī)情況。他們進行原型設(shè)計的大致理由是“與真實環(huán)境接口”,而且原型設(shè)計也確實在真正的芯片器件面世之前,提供了實現(xiàn)這個目的的最快、最準確的途徑。
系統(tǒng)了解這些項目的目的和我們進行原型設(shè)計的原因,將有助于我們判斷基于 FPGA 的原型設(shè)計是否能為我們的下一個項目提供幫助。
因此,讓我們探究一下表 1 所述的目的以及基于 FPGA 的原型方法如何能幫助實現(xiàn)這些目的。在許多情況下,我們還會給出真實環(huán)境中的一些實例,筆者藉此提前感謝那些奉獻自己經(jīng)驗、指導他人走向成功的人士。
高性能與準確度
只有基于 FPGA 的原型才能提供正確測試設(shè)計各個方面所需的速度和準確度。我們把這個理由放在首位的原因是,雖然項目有許多需要實現(xiàn)的給定目的,但對需要進行原型設(shè)計的團隊來說,這可能是所有理由中最根本的原因。舉例來說,這個團隊的目的可能是驗證某些 SoC 的嵌入式軟件,觀察其在真實硬件上全速運行的情況,但使用原型的根本原因是為了確保高性能與準確度。我們在虛擬系統(tǒng)中可以在更高的性能水平下驗證該軟件,但我們無法達到使用真實的 RTL 所能實現(xiàn)的準確度。
實時數(shù)據(jù)流
難以驗證 SoC 的原因之一是因為其狀態(tài)取決于許多變量,包括其之前的狀態(tài)、輸入的次序以及更廣泛的 SoC 輸出系統(tǒng)效應(yīng)(以及可能的反饋)。將 SoC 設(shè)計與系統(tǒng)的其他部分相連并以實時速度運行,可以讓我們立即觀察到實時條件、輸入和系統(tǒng)反饋的變化帶來的效應(yīng)。
葡萄牙波爾圖市 Synopsys 公司 IP 團隊開發(fā)的 HDMI 原型中的實時數(shù)據(jù)流就是一個很好的例子。在本實例中,高清(HD)媒體數(shù)據(jù)流經(jīng)處理內(nèi)核的原型輸出到高清顯示器上,如圖 1 的方框圖所示。注意方框圖底部顯示的是實時音頻和高清視頻數(shù)據(jù)流,從接收器(從外部源)接收,流經(jīng)原型,輸出到與外部監(jiān)控器相連的實時HDMI PHY 的整個流程。
通過使用投片前的原型,我們可以立即看到和聽到不同的高清數(shù)據(jù)在我們的設(shè)計上的效果,反之亦然。只有采用基于 FPGA 的原型方法才支持這種實時數(shù)據(jù)流,不僅給此類多媒體應(yīng)用帶來極大好處,也能給許多其他要求對輸入數(shù)據(jù)流做出實時響應(yīng)的應(yīng)用帶來諸多裨益。
軟硬件集成
在上述實例中,讀者可能已經(jīng)注意到原型使用了一塊小型 MicroBlazeTM CPU,并備有外設(shè)和存儲器,從而體現(xiàn)了一個 SoC 的所有常見模塊。在這個設(shè)計中,運行在 CPU 上的軟件主要用于加載和控制 A/V 處理。然而,在許多SoC 設(shè)計中,軟件最耗精力。
鑒于軟件已成為 SoC 開發(fā)工作的主體部分,軟件工作在項目日程中占據(jù)關(guān)鍵位置越來越常見。當 SoC 能夠有效達到量產(chǎn)標準的時候,決定項目實際完成日期的是軟件開發(fā)和驗證工作。在這種情況下,系統(tǒng)開發(fā)團隊如何才能提升軟件開發(fā)和驗證工作的效率呢?要回答這個問題,我們需要查看軟件開發(fā)團隊把時間都花在什么地方。
為軟件開發(fā)建立 SoC 的模型軟件由于自身的復雜性,很難做到完美。對我們在日常使用計算機的過程中遇到的軟件升級、服務(wù)包和漏洞修補的情況,我們都已經(jīng)司空見慣。但是,具體到嵌入 SoC 中的軟件,這種無休止的軟件改進方法就遇到了障礙。另一方面,相比于通用的計算機軟件而言,與嵌入式軟件互動的系統(tǒng),其設(shè)定的使用模式和環(huán)境條件都更容易確定。而且,為較簡單的系統(tǒng)開發(fā)的嵌入式軟件可以比較簡單,也就更易于全面驗證。
舉例來說,控制車輛子系統(tǒng)或電子玩具的 SoC 比在實時操作系統(tǒng) (RTOS) 上運行許多應(yīng)用和流程的智能手機更容易
進行全面測試。
如果我們更加仔細地觀察運行在這類智能手機上的軟件,例如圖 2 所示的 Android 軟件,我們可以看到一種多層布置,這稱為軟件協(xié)議棧。(該圖基于軟件設(shè)計師 Frank Abelson 在其所著的《Unlocking Android》一書中的原始圖。
)
在觀察軟件協(xié)議棧時,我們會發(fā)現(xiàn),協(xié)議棧的最底層——也就是那些最接近硬件的部分,主要是為了滿足將軟件映射到 SoC 硬件上的需求。這就需要對硬件有絕對的了解,甚至包括地址和時鐘周期等。軟件協(xié)議棧最底層的設(shè)計人員往往稱自己為平臺工程師,他們的工作就是準確描述硬件,以便協(xié)議棧的更高層次能夠識別和重復使用。這種描述被某些 RTOS 廠商稱為板支持包(BSP),與我們?nèi)粘J褂玫?PC 的基本輸入/輸出系統(tǒng) (BIOS) 類似。
協(xié)議棧從下往上第二層包含 RTOS的內(nèi)核以及將較高層次的軟件與被描述的硬件相連的必要驅(qū)動程序。在這些協(xié)議棧的最底層中,平臺工程師和驅(qū)動程序開發(fā)人員需要在真實的 SoC 或完全準確的SoC 模型上驗證他們的代碼。這個層面的軟件開發(fā)人員需要全面了解各時鐘周期軟件的行為。
作為軟件開發(fā)人員的另一極,在協(xié)議棧的頂層,我們可以看到用戶空間,在這里可以同時運行多個應(yīng)用,比如像智能電話中的聯(lián)系人管理器、視頻顯示器、互聯(lián)網(wǎng)瀏覽器和實際呼叫的電話子系統(tǒng)。這些應(yīng)用中的每一個都不能直接訪問 SoC 硬件,而且實際上在某種程度上違背了所有硬件考慮事項。這些應(yīng)用依賴運行在協(xié)議棧較低層的軟件代表自己與 SoC 硬件及系統(tǒng)其他部分通信。
我們可以歸納為:在協(xié)議棧的每一層,軟件開發(fā)人員只需要一個足夠準確的模型來讓自己的代碼認為自己運行在目標 SoC 上即可。超過必要的準確度只會讓模型在模擬器上的運行速度下降。實際上,任何層面的 SoC 建模,都要求我們把硬件和協(xié)議棧描述為比當前層面更低的一層,以便進行驗證。而且在理想的情況下,我們應(yīng)該只要求夠用的準確度,以實現(xiàn)最高性能。
舉例來說,協(xié)議棧頂層的應(yīng)用開發(fā)人員可以在真實的SoC或 SoC 模型上測試代碼。在這種情況下,模型的準確度只要能夠讓應(yīng)用認為自己運行在真正的 SoC 上就足夠,它不需要精確到時鐘周期,也不需要了解硬件的細致結(jié)構(gòu)。但這里速度非常重要,因為在許多情況下有多個應(yīng)用會同時運行,并與真實環(huán)境中的數(shù)據(jù)接口。
這種只為軟件層提供“夠用的準確度”的建模方法為不同的軟件開發(fā)人員提供了多種不同的建模環(huán)境,供他們在SoC 項目的不同階段使用??梢圆捎肧ystemC 這樣的語言進行事務(wù)處理層面的建模,創(chuàng)建出一個準確度低但速度足夠快的仿真器模型,用來同時運行許多應(yīng)用。如果實時的真實數(shù)據(jù)的處理不是很重要,那么考慮采用虛擬原型方法比較好。
不過,必須完整運行整個軟件協(xié)議棧或必須處理真實環(huán)境中的數(shù)據(jù)時,最適合采用基于 FPGA 的原型方法。
使用原型驗證軟件的實例只有采用基于 FPGA 的原型方法才能夠打破建模方法中準確度與性能之間內(nèi)在的相互牽制關(guān)系。采用 FPGA,我們既能實現(xiàn)實時的速度,又能以完全的 RTL 周期精度建模。這樣,單個原型不僅能供低層軟件驗證要求的準確模型使用,又能供高層應(yīng)用開發(fā)人員需要的高速模型使用。實際上,整個 SoC軟件協(xié)議棧都可以在單個基于 FPGA的原型上建模。德克薩斯州奧斯汀市Freescale Semiconductor公司移動產(chǎn)品部的 Scott Constable 及其團隊開展的項目就是采用 FPGA 驗證軟件的一個很好的例子。
Freescale非常想加快 SoC 開發(fā)進程,因為手機市場上產(chǎn)品生命周期短,需要產(chǎn)品盡快打入市場。這不僅是為了贏得競爭,也是為了避免迅速過時。通過分析流程中耗時最多的環(huán)節(jié),F(xiàn)reescale發(fā)現(xiàn)通過加快手機3G協(xié)議測試工作可以帶來最明顯的效果。如果測試工作能夠在流片前完成,F(xiàn)reescale就可以將項目時間縮短數(shù)月。與通常只有一到兩年的產(chǎn)品生命周期而言,這非常重要。
協(xié)議測試是一個復雜的過程,就算以較高的實時速度進行,也需要一天才能完成。使用 RTL 級仿真需要花上數(shù)年,而在較快的仿真器上運行也要數(shù)周時間,這都不切合實際。采用 FPGA 是因為這是實現(xiàn)必要的時鐘速度,及時完成測試的唯一途徑。
協(xié)議測試需要開發(fā)產(chǎn)品的各種軟件特性,包括硬件驅(qū)動程序、操作系統(tǒng)和協(xié)議棧代碼。雖然如前所述主要的目的是協(xié)議測試,通過使用 FPGA,所有這些軟件開發(fā)工作都能夠在流片前完成,從而大大加快各種最終產(chǎn)品的開發(fā)進度。
Freescale 構(gòu)建了一個多芯片系統(tǒng)的原型,其中包括一個雙核 MXC2 基帶處理器和一個 RF收發(fā)器芯片的數(shù)字部分。基帶處理器內(nèi)置一個用于調(diào)制解調(diào)器處理的 Freescale StarCore DSP內(nèi)核、一個用于用戶應(yīng)用處理的ARM?926 內(nèi)核,以及 60 多個外設(shè)。
Synopsys HAPS-54 原型板用來實現(xiàn)原型(如圖 3 所示)。該基帶處理器有 500 多萬個 ASIC門,Scott 的團隊使用 Synopsys Certify 工具將其在原型板上劃分給三個賽靈思 Virtex-5FPGA,同時把數(shù)字 RF 設(shè)計布置在第四個 FPGA 中。Freescale 決定不構(gòu)建模擬部分的原型,而是直接從 Antritsu協(xié)議測試盒中以數(shù)字形式提供移動網(wǎng)絡(luò)數(shù)據(jù)。
較早的內(nèi)核使用的某些設(shè)計技術(shù)對ASIC 來說非常有效果,但對 FPGA 來說卻不太好用。另外,RTL 的一部分是從系統(tǒng)級設(shè)計代碼中自動生成的,由于其過于復雜的時鐘網(wǎng)絡(luò),對 FPGA 來說也是相當不利。因此,必須對 RTL 進行一些調(diào)整,使其更加兼容 FPGA,這樣做的成效非常顯著。
相關(guān)推薦
-
-
herbertwj | 2004-08-15
-
-
-
sandman555 | 2005-02-05
-
-
-
-
-
sandman555 | 2005-02-05
-
-
-
-
sandman555 | 2005-02-05
評論