隨著軟件內容的重要性和復雜性不斷增長，該行業正面臨由多個異構處理器帶來的挑戰，這些處理器的通信比過去更加緊密。為了確保高質量軟件的快速上市，開發人員需要一個高性能、系統級的硬件虛擬原型，可以在其上設計、實施和測試軟件。雖然以前的原型在開發周期中太慢或到達太晚，但最近宣布的開放虛擬平臺 （OVP） 計劃可實現早期和快速的虛擬原型可用性。

電子設計自動化 （EDA） 流程建立在模型可互操作且供應商之間可自由互換的基本前提之上，這意味著模型可以從任何地方編寫或獲取，并且可以被任何供應商的工具所接受。這些特性對于支持高性能原型所需的抽象模型來說是難以捉摸的。正因為如此，EDA 未能提供能夠提供適當級別的功能和執行速度的系統級虛擬原型。

硬件和軟件領域發生的重大變化很快就會使沒有抽象模型的系統無法構建。通過采用重用，設計人員現在基本上是在組裝復雜的嵌入式系統，如樂高系統。處理器的復雜性已經碰壁了，這是由于以巨大的功率增加為代價而降低性能增益所造成的，因此今天的大多數系統都使用多個異構處理器而不是一個中央處理器。隨著系統功能的不斷增長，它必須應對向多處理器世界的過渡。由于所有這些變化，如果沒有可行的系統級模型，設計人員就無法繼續構建系統，在該模型上可以設計和驗證此功能和架構。

歷史的角度

硬件/軟件覆蓋

一些公司試圖通過提供可用于軟件開發的虛擬硬件模型將硬件和軟件社區結合在一起。例如，Mentor Graphics 的無縫替代每個處理器的指令集模擬器 （ISS） 模型，并將它們集成到傳統的寄存器傳輸級 （RTL） 仿真環境中。該模型有助于驅動程序調試，但對于其他任何事情都缺乏足夠的性能。無縫產品還包括幾個虛擬化主機內存系統的性能增強器，從而將其使用擴展到一些低級操作系統領域。

在后來的幾年中，更快的模型取代了 RTL 模型，例如 C 或 SystemC 模型。盡管這些模型提供了更好的性能，但復雜的系統仍然運行得太慢，不適合主流軟件使用。

SystemC 原型

業界花費了大量時間和精力來構建基于 SystemC 的虛擬平臺。示例包括由 CoWare創建和擴展的平臺以及 Eclipse 虛擬原型平臺 （VPP）下的擬議工作項目。這些原型提供了一個靈活且適應性強的平臺，可以在該平臺上分析總線流量、功率、性能和許多其他實現屬性。雖然比討論的 RTL 原型快得多，但這些原型的性能水平使其保持在硬件驗證和固件開發領域。

此外，SystemC 未能解決模型互操作性問題，這是 Open SystemC Initiative （OSCI） Transaction-Level Modeling （TLM） 小組正試圖糾正的問題。該集團的最新嘗試并沒有給業內許多人留下深刻印象，因為有些人稱這項努力“太少太晚了”。此外，這個提議的標準只涉及內存映射接口，限制了它定義完整系統級原型的能力。

其他公司，如 Virtutech 和 VaST Systems已經放棄了標準領域，并使用定制語言和工具來創建更快的處理器模型、內存系統和硬件的某些方面。雖然這些公司已經成功地創建了具有更高性能的原型，但它們仍受到模型可用性和專有格式問題的困擾。

不斷變化的需求和日益增加的復雜性

今天的大多數原型都包含時序，這對于硬件和架構驗證以及低級驅動程序測試至關重要。但是時間信息會減慢原型的速度。對于處理應用程序開發的軟件團隊，時間信息是不必要的。時間隨著每個處理器的計時而前進，并且每個線程的事件以正確的順序前進。

為了可靠地工作，多處理器應用程序必須執行不依賴于時間的同步。因此，軟件社區的系統級模型可以完全放棄計時，而是依賴于執行的順序和線程之間的適當同步。使用信號量、握手或其他機制執行同步，以確保需要通信的兩個軟件線程都處于交換數據的必要狀態。

隨著時間的推移，開發人員不再關心單個塊或孤立的算法如何發揮作用，而是關心控制和協調塊和算法以形成一個完整的多功能系統。這種額外的能力會導致復雜性增加。總系統復雜度與通信的獨立節點數量的平方成正比。這些節點可以相互通信并協作以執行全部功能。暗示，這些節點中的每一個都執行獨立的任務或與其他節點協調以完成更復雜的任務。隨著多處理器片上系統 （SoC） 的出現，軟件現在已成為真正的多節點，因為線程可以以完全并發的方式執行并實時相互交互。

多處理器軟件需求

過去，將代碼交叉編譯到主機上既快捷又簡單。但是，這不適用于多處理器軟件。盡管當前的臺式機現在有兩個或四個處理器，但它們提供的關于軟件如何在實際嵌入式硬件上運行或執行的視圖不太可靠，這些硬件可能在處理器之間進行特殊通信或需要異構處理器。多處理器軟件需要更精確的原型來研究應用程序通信和同步。

在規模的另一端，許多公司利用物理原型進行軟件驗證。雖然這些原型以近乎實時的速度運行并具有準確的時序，但它們在開發周期中可用的太晚了，因為軟件中發現的問題無法通過硬件的必要更改來反映。隨著多處理器系統的引入，實時查看每個處理器在做什么變得更加困難，單步執行等操作幾乎是不可能的。設計人員需要一個能夠提供相同性能水平但在設計周期早期可用的平臺。

過壓保護概述

OSCI 維護 SystemC 語言并提供免費的模擬器。盡管這些產品看似有益，但實際上它們扼殺了商業進步。此外，SystemC 也未能解決前面討論的模型互操作問題。

Imperas 最近推出了 OVP 計劃，以推廣開放虛擬平臺的概念。OVP 鼓勵開發人員采用新的嵌入式軟件開發方式，尤其是針對 SoC 和多處理器 SoC 平臺。該公司對 OVP 和 OVPsim 采取了不同的方法，首先向公眾提供接口，從而解決模型互操作性問題。該公司提供了幾個模型來演示接口的功能以及一個 Windows 平臺模擬器，供開發人員構建和調試模型。

接口

OVP 包含四個 C 接口，如圖 1 所示。

圖1

ICM 將系統模塊聯系在一起，例如處理器、內存子系統、外圍設備和其他硬件模塊。ICM 是一個 C 接口，當編譯并與每個模型和一些目標文件鏈接時，它會生成一個可執行模型。鑒于它是標準 C 代碼，任何 C 編譯器都可用于創建模型。ICM 接口還允許定義內存映像，以便可以將程序或數據預加載到系統模型中。

VMI 是允許處理器模型與內核和其他組件進行通信的虛擬機或處理器接口。VMI 本質上是 OVP 提供的高性能執行的核心。OVP 使用帶有即時編譯器的代碼變形方法將處理器指令映射到主機提供的指令中。中間是一組優化的操作碼，處理器操作映射到其中。OVPsim 提供對本機機器功能的解釋或編譯。這與解釋每條指令的傳統 ISS 方法不同。VMI 還為文件 I/O 等功能啟用了一種虛擬化形式，允許使用提供的標準庫在主機上直接執行。

PPM 是外圍建模接口，類似于第四個接口 BHM，用于更通用的行為。這些模型在模擬器的第二部分運行，稱為外圍模擬引擎。OVPworld 聲明“這是一個受保護的運行時環境，不會使模擬器崩潰”。它通過為每個模型創建單獨的地址空間并將通信限制為 API 提供的機制來實現這一點。這兩個接口之間的主要區別在于 PPM 接口理解總線和網絡。因此，它在功能方面類似于 OSCI TLM 接口提案。BHM 更類似于具有流程激活和等待時間或特定事件的能力的傳統行為建模語言。

性能基準

OVPworld 網站上提供了幾種不同的處理器模型和預打包的演示。開發人員可以使用免費的模擬器來創建自己的平臺。表 1 顯示了運行各種基準測試的每個內核獲得的性能結果。

硬件/軟件虛擬原型的基石

OVP 有可能為硬件和軟件開發提供真正的系統級虛擬原型。它有望成為第一個通用抽象建模系統，將形成完整流向硬件和軟件社區的基石。雖然這在 DSP 設計等專業領域之前已經完成，但在更一般的情況下從未解決過。OVP 已經為這些原型打開了商業市場，這意味著它可以比 SystemC 獲得更多的商業關注。如果成功，OVP 將解決模型互操作性問題，從而使整個行業受益。

審核編輯：郭婷