基于FPGA原型設計 能為您做些什么？

作為基于 FPGA 原型方法的擁護者，有人可能會(huì )認為我們只片面地看到了這種方法的優(yōu)點(diǎn)，而對其缺陷視而不見(jiàn)。但那絕非我們的本意。我們這本《基于 FPGA 的原型方法手冊》旨在全面揭示基于 FPGA的原型的利弊，因為最終我們并不想看到有人本來(lái)可以使用其他方法更好地達到目的（比如說(shuō)用基于System C的虛擬原型），卻行進(jìn)在這種方法的漫漫征途上。

讓我們來(lái)更深入地研究一下基于FPGA原型方法的目的和局限性，以及其對于系統級驗證和其他目的的適用性。把重點(diǎn)始終放在原型項目的目的上，讓我們在平臺、IP 使用、設計導出、調試及其他設計方面更容易地做出決策。這樣，我們就能夠通過(guò)分析世界上其他原型設計團隊的案例，從他們的項目中汲取經(jīng)驗。

基于FPGA的原型可滿(mǎn)足不同目的需求

原型設計不是一個(gè)按幾個(gè)按鈕就能完成的過(guò)程，在它不同的階段需要仔細的關(guān)注和思考。除說(shuō)明這個(gè)過(guò)程需要完成的工作和涉及到的專(zhuān)業(yè)知識外，我們還應解釋在 SoC 項目中該進(jìn)行（或者不該進(jìn)行）原型設計的原因。在與原型設計人員多年交談中，我們最常問(wèn)到的一個(gè)問(wèn)題是“為什么您這么做？”。答案有多種多樣，我們把它們總結成了表 1 中幾條常見(jiàn)的理由。舉例來(lái)說(shuō)，“真實(shí)環(huán)境中的數據效應”，這可能指的是某個(gè)團隊的工作是通過(guò)原型設計得到某個(gè)系統全速運行時(shí)的模型，并將其與其他系統或外設相連，目的可能是為了測試對某個(gè)新接口標準的合規情況。他們進(jìn)行原型設計的大致理由是“與真實(shí)環(huán)境接口”，而且原型設計也確實(shí)在真正的芯片器件面世之前，提供了實(shí)現這個(gè)目的的最快、最準確的途徑。

系統了解這些項目的目的和我們進(jìn)行原型設計的原因，將有助于我們判斷基于 FPGA 的原型設計是否能為我們的下一個(gè)項目提供幫助。

因此，讓我們探究一下表 1 所述的目的以及基于 FPGA 的原型方法如何能幫助實(shí)現這些目的。在許多情況下，我們還會(huì )給出真實(shí)環(huán)境中的一些實(shí)例，筆者藉此提前感謝那些奉獻自己經(jīng)驗、指導他人走向成功的人士。

高性能與準確度

只有基于 FPGA 的原型才能提供正確測試設計各個(gè)方面所需的速度和準確度。我們把這個(gè)理由放在首位的原因是，雖然項目有許多需要實(shí)現的給定目的，但對需要進(jìn)行原型設計的團隊來(lái)說(shuō)，這可能是所有理由中最根本的原因。舉例來(lái)說(shuō)，這個(gè)團隊的目的可能是驗證某些 SoC 的嵌入式軟件，觀(guān)察其在真實(shí)硬件上全速運行的情況，但使用原型的根本原因是為了確保高性能與準確度。我們在虛擬系統中可以在更高的性能水平下驗證該軟件，但我們無(wú)法達到使用真實(shí)的 RTL 所能實(shí)現的準確度。

實(shí)時(shí)數據流

難以驗證 SoC 的原因之一是因為其狀態(tài)取決于許多變量，包括其之前的狀態(tài)、輸入的次序以及更廣泛的 SoC 輸出系統效應（以及可能的反饋）。將 SoC 設計與系統的其他部分相連并以實(shí)時(shí)速度運行，可以讓我們立即觀(guān)察到實(shí)時(shí)條件、輸入和系統反饋的變化帶來(lái)的效應。

葡萄牙波爾圖市 Synopsys 公司 IP 團隊開(kāi)發(fā)的 HDMI 原型中的實(shí)時(shí)數據流就是一個(gè)很好的例子。在本實(shí)例中，高清(HD)媒體數據流經(jīng)處理內核的原型輸出到高清顯示器上，如圖 1 的方框圖所示。注意方框圖底部顯示的是實(shí)時(shí)音頻和高清視頻數據流，從接收器（從外部源）接收，流經(jīng)原型，輸出到與外部監控器相連的實(shí)時(shí)HDMI PHY 的整個(gè)流程。
通過(guò)使用投片前的原型，我們可以立即看到和聽(tīng)到不同的高清數據在我們的設計上的效果，反之亦然。只有采用基于 FPGA 的原型方法才支持這種實(shí)時(shí)數據流，不僅給此類(lèi)多媒體應用帶來(lái)極大好處，也能給許多其他要求對輸入數據流做出實(shí)時(shí)響應的應用帶來(lái)諸多裨益。

軟硬件集成

在上述實(shí)例中，讀者可能已經(jīng)注意到原型使用了一塊小型 MicroBlazeTM CPU，并備有外設和存儲器，從而體現了一個(gè) SoC 的所有常見(jiàn)模塊。在這個(gè)設計中，運行在 CPU 上的軟件主要用于加載和控制 A/V 處理。然而，在許多SoC 設計中，軟件最耗精力。

鑒于軟件已成為 SoC 開(kāi)發(fā)工作的主體部分，軟件工作在項目日程中占據關(guān)鍵位置越來(lái)越常見(jiàn)。當 SoC 能夠有效達到量產(chǎn)標準的時(shí)候，決定項目實(shí)際完成日期的是軟件開(kāi)發(fā)和驗證工作。在這種情況下，系統開(kāi)發(fā)團隊如何才能提升軟件開(kāi)發(fā)和驗證工作的效率呢？要回答這個(gè)問(wèn)題，我們需要查看軟件開(kāi)發(fā)團隊把時(shí)間都花在什么地方。

為軟件開(kāi)發(fā)建立 SoC 的模型軟件由于自身的復雜性，很難做到完美。對我們在日常使用計算機的過(guò)程中遇到的軟件升級、服務(wù)包和漏洞修補的情況，我們都已經(jīng)司空見(jiàn)慣。但是，具體到嵌入 SoC 中的軟件，這種無(wú)休止的軟件改進(jìn)方法就遇到了障礙。另一方面，相比于通用的計算機軟件而言，與嵌入式軟件互動(dòng)的系統，其設定的使用模式和環(huán)境條件都更容易確定。而且，為較簡(jiǎn)單的系統開(kāi)發(fā)的嵌入式軟件可以比較簡(jiǎn)單，也就更易于全面驗證。

舉例來(lái)說(shuō)，控制車(chē)輛子系統或電子玩具的 SoC 比在實(shí)時(shí)操作系統 (RTOS) 上運行許多應用和流程的智能手機更容易
進(jìn)行全面測試。

如果我們更加仔細地觀(guān)察運行在這類(lèi)智能手機上的軟件，例如圖 2 所示的 Android 軟件，我們可以看到一種多層布置，這稱(chēng)為軟件協(xié)議棧。（該圖基于軟件設計師 Frank Abelson 在其所著(zhù)的《Unlocking Android》一書(shū)中的原始圖。
）

在觀(guān)察軟件協(xié)議棧時(shí)，我們會(huì )發(fā)現，協(xié)議棧的最底層——也就是那些最接近硬件的部分，主要是為了滿(mǎn)足將軟件映射到 SoC 硬件上的需求。這就需要對硬件有絕對的了解，甚至包括地址和時(shí)鐘周期等。軟件協(xié)議棧最底層的設計人員往往稱(chēng)自己為平臺工程師，他們的工作就是準確描述硬件，以便協(xié)議棧的更高層次能夠識別和重復使用。這種描述被某些 RTOS 廠(chǎng)商稱(chēng)為板支持包(BSP)，與我們日常使用的 PC 的基本輸入/輸出系統 (BIOS) 類(lèi)似。

協(xié)議棧從下往上第二層包含 RTOS的內核以及將較高層次的軟件與被描述的硬件相連的必要驅動(dòng)程序。在這些協(xié)議棧的最底層中，平臺工程師和驅動(dòng)程序開(kāi)發(fā)人員需要在真實(shí)的 SoC 或完全準確的SoC 模型上驗證他們的代碼。這個(gè)層面的軟件開(kāi)發(fā)人員需要全面了解各時(shí)鐘周期軟件的行為。

作為軟件開(kāi)發(fā)人員的另一極，在協(xié)議棧的頂層，我們可以看到用戶(hù)空間，在這里可以同時(shí)運行多個(gè)應用，比如像智能電話(huà)中的聯(lián)系人管理器、視頻顯示器、互聯(lián)網(wǎng)瀏覽器和實(shí)際呼叫的電話(huà)子系統。這些應用中的每一個(gè)都不能直接訪(fǎng)問(wèn) SoC 硬件，而且實(shí)際上在某種程度上違背了所有硬件考慮事項。這些應用依賴(lài)運行在協(xié)議棧較低層的軟件代表自己與 SoC 硬件及系統其他部分通信。

我們可以歸納為：在協(xié)議棧的每一層，軟件開(kāi)發(fā)人員只需要一個(gè)足夠準確的模型來(lái)讓自己的代碼認為自己運行在目標 SoC 上即可。超過(guò)必要的準確度只會(huì )讓模型在模擬器上的運行速度下降。實(shí)際上，任何層面的 SoC 建模，都要求我們把硬件和協(xié)議棧描述為比當前層面更低的一層，以便進(jìn)行驗證。而且在理想的情況下，我們應該只要求夠用的準確度，以實(shí)現最高性能。

舉例來(lái)說(shuō)，協(xié)議棧頂層的應用開(kāi)發(fā)人員可以在真實(shí)的SoC或 SoC 模型上測試代碼。在這種情況下，模型的準確度只要能夠讓?xiě)谜J為自己運行在真正的 SoC 上就足夠，它不需要精確到時(shí)鐘周期，也不需要了解硬件的細致結構。但這里速度非常重要，因為在許多情況下有多個(gè)應用會(huì )同時(shí)運行，并與真實(shí)環(huán)境中的數據接口。

這種只為軟件層提供“夠用的準確度”的建模方法為不同的軟件開(kāi)發(fā)人員提供了多種不同的建模環(huán)境，供他們在SoC 項目的不同階段使用?？梢圆捎肧ystemC 這樣的語(yǔ)言進(jìn)行事務(wù)處理層面的建模，創(chuàng )建出一個(gè)準確度低但速度足夠快的仿真器模型，用來(lái)同時(shí)運行許多應用。如果實(shí)時(shí)的真實(shí)數據的處理不是很重要，那么考慮采用虛擬原型方法比較好。

不過(guò)，必須完整運行整個(gè)軟件協(xié)議?；虮仨毺幚碚鎸?shí)環(huán)境中的數據時(shí)，最適合采用基于 FPGA 的原型方法。

使用原型驗證軟件的實(shí)例只有采用基于 FPGA 的原型方法才能夠打破建模方法中準確度與性能之間內在的相互牽制關(guān)系。采用 FPGA，我們既能實(shí)現實(shí)時(shí)的速度，又能以完全的 RTL 周期精度建模。這樣，單個(gè)原型不僅能供低層軟件驗證要求的準確模型使用，又能供高層應用開(kāi)發(fā)人員需要的高速模型使用。實(shí)際上，整個(gè) SoC軟件協(xié)議棧都可以在單個(gè)基于 FPGA的原型上建模。德克薩斯州奧斯汀市Freescale Semiconductor公司移動(dòng)產(chǎn)品部的 Scott Constable 及其團隊開(kāi)展的項目就是采用 FPGA 驗證軟件的一個(gè)很好的例子。

Freescale非常想加快 SoC 開(kāi)發(fā)進(jìn)程，因為手機市場(chǎng)上產(chǎn)品生命周期短，需要產(chǎn)品盡快打入市場(chǎng)。這不僅是為了贏(yíng)得競爭，也是為了避免迅速過(guò)時(shí)。通過(guò)分析流程中耗時(shí)最多的環(huán)節，Freescale發(fā)現通過(guò)加快手機3G協(xié)議測試工作可以帶來(lái)最明顯的效果。如果測試工作能夠在流片前完成，Freescale就可以將項目時(shí)間縮短數月。與通常只有一到兩年的產(chǎn)品生命周期而言，這非常重要。

協(xié)議測試是一個(gè)復雜的過(guò)程，就算以較高的實(shí)時(shí)速度進(jìn)行，也需要一天才能完成。使用 RTL 級仿真需要花上數年，而在較快的仿真器上運行也要數周時(shí)間，這都不切合實(shí)際。采用 FPGA 是因為這是實(shí)現必要的時(shí)鐘速度，及時(shí)完成測試的唯一途徑。

協(xié)議測試需要開(kāi)發(fā)產(chǎn)品的各種軟件特性，包括硬件驅動(dòng)程序、操作系統和協(xié)議棧代碼。雖然如前所述主要的目的是協(xié)議測試，通過(guò)使用 FPGA，所有這些軟件開(kāi)發(fā)工作都能夠在流片前完成，從而大大加快各種最終產(chǎn)品的開(kāi)發(fā)進(jìn)度。

Freescale 構建了一個(gè)多芯片系統的原型，其中包括一個(gè)雙核 MXC2 基帶處理器和一個(gè) RF收發(fā)器芯片的數字部分?；鶐幚砥鲀戎靡粋€(gè)用于調制解調器處理的 Freescale StarCore DSP內核、一個(gè)用于用戶(hù)應用處理的ARM?926 內核，以及 60 多個(gè)外設。

Synopsys HAPS-54 原型板用來(lái)實(shí)現原型（如圖 3 所示）。該基帶處理器有 500 多萬(wàn)個(gè) ASIC門(mén)，Scott 的團隊使用 Synopsys Certify 工具將其在原型板上劃分給三個(gè)賽靈思 Virtex-5FPGA，同時(shí)把數字 RF 設計布置在第四個(gè) FPGA 中。Freescale 決定不構建模擬部分的原型，而是直接從 Antritsu協(xié)議測試盒中以數字形式提供移動(dòng)網(wǎng)絡(luò )數據。

較早的內核使用的某些設計技術(shù)對ASIC 來(lái)說(shuō)非常有效果，但對 FPGA 來(lái)說(shuō)卻不太好用。另外，RTL 的一部分是從系統級設計代碼中自動(dòng)生成的，由于其過(guò)于復雜的時(shí)鐘網(wǎng)絡(luò )，對 FPGA 來(lái)說(shuō)也是相當不利。因此，必須對 RTL 進(jìn)行一些調整，使其更加兼容 FPGA，這樣做的成效非常顯著(zhù)。