基于FPGA的原型可滿足不同目的需求

原型設計不是一個按幾個按鈕就能完成的過程，在它不同的階段需要仔細的關注和思考。除說明這個過程需要完成的工作和涉及到的專業知識外，我們還應解釋在 SoC 項目中該進行（或者不該進行）原型設計的原因。

在與原型設計人員多年交談中，我們最常問到的一個問題是“為什么您這么做？”答案有多種多樣，我們把它們總結成了表1中幾條常見的理由。系統了解這些項目的目的和我們進行原型設計的原因，將有助于我們判斷基于FPGA的原型設計是否能為我們的下一個項目提供幫助。

因此，讓我們探究一下表1所述的目的以及基于FPGA的原型方法如何能幫助實現這些目的。

高性能與準確度

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

實時數據流

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

葡萄牙波爾圖市Synopsys公司IP團隊開發的HDMI原型中的實時數據流就是一個很好的例子。在本例中，高清（HD）媒體數據流經處理內核的原型輸出到高清顯示器上，如圖1的方框圖所示。

圖1 HDMI 原型方框圖

通過使用投片前的原型，我們可以立即看到和聽到不同的高清數據在我們的設計上的效果，反之亦然。只有采用基于FPGA的原型方法才支持這種實時數據流，不僅給此類多媒體應用帶來極大好處，也能給許多其他要求對輸入數據流做出實時響應的應用帶來諸多裨益。

軟硬件集成

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

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

為軟件開發建立SoC的模型

軟件由于自身的復雜性，很難做到完美。對我們在日常使用計算機的過程中遇到的軟件升級、服務包和漏洞修補的情況，我們都已經司空見慣。但是，具體到嵌入 SoC 中的軟件，這種無休止的軟件改進方法就遇到了障礙。另一方面，相比于通用的計算機軟件而言，與嵌入式軟件互動的系統，其設定的使用模式和環境條件都更容易確定。而且，為較簡單的系統開發的嵌入式軟件可以比較簡單，也就更易于全面驗證。舉例來說，控制車輛子系統或電子玩具的SoC比在實時操作系統（RTOS）上運行許多應用和流程的智能手機更容易進行全面測試。

如果我們更加仔細地觀察運行在這類智能手機上的軟件，例如圖2所示的Android軟件，我們可以看到一種多層布置，這稱為軟件協議棧。

圖2 Android軟件協議棧

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

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

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

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

這種只為軟件層提供“夠用的準確度”的建模方法為不同的軟件開發人員提供了多種不同的建模環境，供他們在SoC項目的不同階段使用。可以采用SystemC這樣的語言進行事務處理層面的建模，創建出一個準確度低但速度足夠快的仿真器模型，用來同時運行許多應用。如果實時的真實數據的處理不是很重要，那么考慮采用虛擬原型方法比較好。

不過，必須完整運行整個軟件協議?；蛱幚碚鎸嵀h境中的數據時，最適合采用基于FPGA的原型方法。

使用原型驗證軟件的實例

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

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

協議測試是一個復雜的過程，就算以較高的實時速度進行，也需要一天才能完成。采用FPGA是因為這是實現必要的時鐘速度，及時完成測試的唯一途徑。

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

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

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

圖3 Freescale的SoC設計在HAPS-54原型板上的分區

較早的內核使用的某些設計技術對ASIC來說非常有效果，但對FPGA來說卻不太好用。另外，RTL的一部分是從系統級設計代碼中自動生成的，由于其過于復雜的時鐘網絡，對FPGA來說也是相當不利的。因此，必須對RTL進行一些調整，使其更加兼容FPGA，這樣做的成效非常顯著。

僅在完成首個芯片后一個月，Freescale團隊就成功地從這個系統中撥出了第一個移動電話呼叫，把產品開發進度縮短了6個多月，這非常具有里程碑式的意義。

這個例子說明基于 FPGA的原型方法能夠給軟件開發團隊提供什么樣的增值工具，能夠在產品質量和項目進程方面帶來怎樣顯著的回報。

接口優勢：測試真實條件下的數據效應

很難想象有這樣一種 SoC 設計可以不遵守輸入數據、處理數據、生成輸出數據的基本結構。實際上，如果我們深入SoC設計，就會發現無數的子模塊遵循著同樣的結構，直到單個門級。

要在這些層級中的每一個層級驗證正確的處理，要求我們提供完整的輸入數據集，并觀察處理結果的輸出數據是否正確。對單個門來說，這個工作很簡單，對小型 RTL 模塊來說，也是可能的。但隨著系統日趨復雜，從統計上來說基本沒有可能確保輸入數據和初始條件的完整性，尤其是在有軟件運行在一個以上的處理器的時候。

最后一點非常重要，因為不可預測的輸入數據能擾亂所有的SoC系統，即便是精心設計的關鍵SoC設計也難以幸免。與新輸入的數據或者輸入數據不尋常的組合或序列相結合的，是非常多的SoC 可能的前置狀態，可能會使SoC處于某種無法驗證的狀態。當然，這種情況不一定是什么問題，SoC可以在無需系統的其他部分干預的情況下恢復，或者用戶根本就沒有察覺。

但是，不能驗證的狀態必須在最終芯片中避免，因此我們需要盡可能全面地測試設計的方法。在設計的功能仿真過程中，驗證工程師會采用有力的方法，比如受約束隨機激勵和高級測試工具來完成多種測試，旨在達到可接受的測試覆蓋面。但是，完整性仍受驗證工程師選擇的方向和給定的約束條件的限制，并受限于可用于運行仿真的時間。結果雖然受約束隨機驗證永遠不可能窮盡，但能夠大大增強我們已經測試了所有輸入的組合（包括可能的輸入和極端情況輸入）的信心。

對實驗室可行性實驗的優勢

在項目的初始階段，需要對芯片拓撲、性能、功耗以及片上通信結構做出基本決策。部分決策采用算法或系統級建模工具便可良好執行，但也可以采用 FPGA 進行某些額外的實驗。這是否是真正基于FPGA的原型設計呢？我們正使用 FPGA進行某個概念的原型設計，但這與使用算法或數學工具不同，因為我們需要某些可能是由這些高級工具生成的 RTL。一旦進入FPGA，就可采集早期信息幫助推進算法和最終SoC架構的優化?；贔PGA的原型為項目該階段帶來的優勢是，可使用更準確的模型，而且這些模型的運行速度非常快，能夠與實時輸入互動。

這種類型的實驗性原型值得一提，因為它們是在全面的SoC項目中使用基于FPGA的原型設計硬件和工具的又一途徑，可為我們的投資帶來更高的回報。

在實驗室外使用原型

基于FPGA的原型設計可用于驗證SoC設計的一個真正獨到之處，是其獨立工作的能力。這是因為FPGA可通過閃存EEPROM卡或其他獨立介質進行配置，無須主機PC管理。因此該原型不但可獨立運行，而且還可用于各種環境下的SoC設計測試，這與其他建模技術（如需要依賴主機干預的仿真）提供的環境儼然不同。

在極端情況下，原型可以完全從實驗室中取出，用于現場真實環境中。比如將原型安裝在開動的車輛上，研究設計對外部噪聲、移動、天線場強等條件變化的依賴性。比如，本文作者就曾將移動電話的基帶原型安裝在車輛上，通過公共GSM網絡在移動中撥打電話。

芯片架構師與其他產品專家需要與早期客戶互動，展示其算法的重要特性。基于FPGA的原型設計在項目極早期的這個階段可能是非常關鍵的優勢，但這種方法與主流SoC原型設計略有不同。

基于FPGA原型的不足

我們撰寫本文的目的是公正地看待基于FPGA的原型的優勢與局限性，因此在前面談及各種優勢之后，我們將在下面介紹部分局限性。

首先最重要的是，FPGA原型不是RTL模擬器。如果我們的目的是編寫一些RTL，然后盡快在FPGA中實施，以查看它是否能工作，那么我們應該重新思考所忽略的東西。FPGA對運行RTL“模型”來說確實是一種速度更快的引擎，但當我們開始設置該模型的時候，速度優勢就會大打折扣。此外，模擬器的儀表盤部分能夠完整地控制激勵和掌握結果。我們應該思考儀表化FPGA的方法，深入了解設計的功能性，但即便是在這方面最完善的設計，也只能提供一部分真正能用于 RTL 模擬器儀表盤的信息。因此，該模擬器是用于重復編寫和評估RTL代碼更加理想的環境，因此我們應該等到模擬基本完成后，RTL相當成熟后才能將其交付給FPGA原型設計團隊。

基于FPGA的原型不是ESL

Synopsys的Innovator或Synphony等電子系統級（ESL）工具或算法工具可在SystemC中完成設計，或通過預定義模型庫進行構建。然后，我們不但可在相同的工具中模擬這些設計，而且還可深入了解其系統級性能，包括運行軟件，在項目初期階段進行軟硬件權衡。

使用基于FPGA的原型方法，我們需要RTL，因此它不太適合研究算法或架構，因為這兩者通常不采用RTL方式表達。對軟件來說，FPGA原型設計的優勢是在當 RTL 成熟得可以構建硬件平臺的時候，軟件可在更加準確以及更加真實的環境中運行。對那些具有天馬行空想法的人來說，可以編寫少量RTL在FPGA上運行，進行可行性研究。這是一種極少而又非常重要的FPGA原型設計的使用方法，但別把它和整個SoC的系統級或算法研究混淆在一起。

持續性是關鍵

優秀的工程師往往會為其工作選擇適當的工具，但應該隨時有一種方法可以將半成品交給他人繼續完成。我們應該能夠在盡量不增加工作量的情況下，將來自ESL模擬的設計移交給基于FPGA的原型。此外，部分ESL工具還可通過高層次綜合實現設計，生成RTL供SoC項目整體使用?；贔PGA的原型能夠接收該RTL，并以高周期精度在電路板上運行。但我們需要再次等到RTL相對穩定下來，這需要等到項目軟硬件分區和架構研究階段完成后。

采用FPGA進行原型設計的原因

當前SoC是從算法研究人員到硬件設計人員，乃至軟件工程師和芯片布局團隊等眾多專家的工作結晶，在項目不斷發展的同時，各類專家也都有自己的需求。SoC項目的成功很大程度上取決于上述各類專家所使用的硬件驗證、軟硬件聯合驗證以及軟件驗證的方法，基于FPGA的原型設計可為每一類專家帶來各種不同的優勢。

對于硬件團隊而言，驗證工具的速度可對驗證吞吐量產生巨大的影響。因此一些團隊采用基于FPGA的原型為這種硬件測試提供具有更高性能的平臺。例如，我們可以在近乎實時的條件下運行整個操作系統的引導程序，節省需要花上數天才能達到相同目的的模擬時間。

對于軟件開發團隊而言，基于FPGA的原型可為目標芯片提供獨特的流片前模型，能夠在開發接近尾聲時高速、高度準確地進行軟件調試。

對于整個團隊而言，SoC項目的關鍵階段是在軟硬件初次結合的時候。硬件將由最終軟件執行，而執行方式可能是單純硬件驗證方案難以預見或預測的，從而最終將出現新的硬件問題。這在多核系統中或者在那些運行同步實時應用的系統中特別普遍。如果這種軟硬件的采用要等到第一個器件制造完畢后，那么毫不夸張地說，到那時再發現新的缺陷就不太好了。

?