系統級環境提高了開發人員的工作效率并更早地將產品推向市場，為架構分析、硬件/軟件協同開發和系統驗證提供了一個開發平臺。模型為任何系統級平臺提供了支柱；然而，開發這些模型所涉及的困難和費用限制了虛擬平臺的采用。Andy 描述了有效建模策略對虛擬平臺開發的重要性。

在過去的幾年里，開發團隊和方法論小組更加重視平臺驅動的設計技術。更短的產品生命周期和更高的上市時間壓力迫使公司投資于設計周期早期可用的系統級平臺。此外，向利用傳統和第三方 IP 的片上系統 （SoC） 設計技術的過渡為系統級建模提供了更好的結構和方法。同時，越來越多的嵌入式軟件和固件內容已將生產產品所需的大部分資源重新定位到軟件領域。在傳統的設計流程中，這意味著大部分開發過程在設計流程的后期轉移，從而增加了進度風險。

虛擬平臺有助于解決這些日益復雜的問題、市場壓力和內容變化。盡管一些工程師已經詳細描述了這些平臺的好處，但確定合適的建模方法通常留給讀者作為練習。為了闡明虛擬平臺的這一方面，以下討論將分析適當建模技術的不同方面。

具有諷刺意味的是，雖然模型為任何系統級平臺提供了支柱，但與開發這些模型相關的困難和費用限制了虛擬平臺的采用。此外，建模和支持工作消耗了開發和支持這些平臺的大部分成本。

模型抽象級別

對于本次討論，模型可以分為四個不同的部分：時序、功能、可尋址狀態和接口。模型的四個部分中的每一個都可以在不同的抽象級別上有所不同，從高級行為描述到實際設計實現。直接從反映真實設計行為的設計描述創建的模型稱為實現精確模型。表 1 中的建模堆棧顯示了最高和最低極端之間的連續抽象。

表格1

與大多數與計算相關的應用程序一樣，提高準確性對降低執行速度有直接影響。這與建模沒有什么不同。提高模型的準確性需要更多的處理并降低執行速度。

此外，提高模型準確性與創建和支持模型所需的工作量和時間直接相關。找到適當的速度與準確性權衡對于實現滿足虛擬平臺用戶需求并限制開發和維護平臺所需工作量的建模范例至關重要。

一方面，硬件工程師需要實現精確的模型來驗證他們的設計。另一方面，應用軟件開發人員可以使用高級行為模型。在這兩個極端之間存在較低級別的軟件，包括操作系統 （OS）、驅動程序、固件以及架構和性能分析。

應用軟件工程師最關心的是開發他們的應用程序并擁有一個高效的調試環境。他們不需要詳細模型的準確性；他們的代碼很少接觸到實際的硬件，因為它分層在其他軟件之上。但是，在某些情況下，應用軟件工程師可能需要了解需要更高準確性的簡單性能指標。

與應用程序代碼不同，操作系統和驅動程序開發涉及硬件；因此，開發這些組件的人員需要更高的準確度來了解他們的軟件和底層硬件如何交互。他們可以用速度換取更高的準確性，因為他們的代碼庫比應用軟件工程師的代碼庫要小。不定時行為模型可能對早期開發有用，但最終，操作系統和驅動程序開發人員必須了解他們的軟件如何使用更準確的模型工作，以確保整個系統（硬件和軟件）能夠協同工作。

固件工程師開發與硬件交互的代碼——引導代碼、自檢、診斷和控制臺。鑒于與硬件的這種高度交互和對硬件的依賴，這些工程師很少使用不準確的模型。他們可以交換模型速度以獲得更高的準確性，因為他們的軟件處于最低級別，并且與更高級別的軟件相比通常很小。調整低級固件和驅動程序軟件性能還需要周期精確的模型來了解對硬件的時序依賴性以及資源瓶頸。

架構師需要了解他們的硬件/軟件分區、IP 選擇、總線架構、內存架構和整體架構決策如何影響與性能、面積和功耗相關的系統。他們還必須了解管道效應、延遲、吞吐量、帶寬和活動。不按建筑師計劃執行的最終設計可能會極大地影響產品的成本、性能和進度。因此，架構師必須使用高度準確的模型來驗證他們的設計，以建立對其決策的信心。硬件工程師必須有實現精確的模型；任何其他級別的精度都不適合驗證設計。

所有模型的單一抽象級別并不總是適用于所有情況。例如，考慮內存架構權衡的架構師可能會嘗試分析每個預期內存子系統的內存延遲和吞吐量。在這種情況下，架構師可能需要高度精確的內存控制器和內存接口模型，以確保他們完全了解性能。系統的其余部分可以在更抽象的層次上建模，因為它對分析并不重要。使用支持混合抽象級別并為不同抽象級別的模型啟用即插即用的模型方法有助于優化執行速度和分析準確性。

最后，在考慮所有可能的用例時，工程師應注意平臺很少只針對一種類型的用戶。更常見的是創建一個虛擬平臺來滿足多種類型用戶的需求，從軟件開發人員到架構師，在某些情況下，還包括硬件設計人員。因此，平臺內必須支持不同的抽象級別。

互操作性和兼容性

在創建建模方法時，開發人員應確保模型彼此可互操作，跨抽象層分布，并與各種平臺和第三方工具兼容。一致性對于保證不同模型開發人員創建的模型相互兼容也很重要。

雖然并不完美，但標準通過支持各種模型抽象并提供與不同平臺和第三方工具的兼容性，有助于增加模型之間的一致性、兼容性和互操作性。

SystemC 等建模語言提供了連接和執行不同模型的基礎平臺。SystemC 提供了支持多個抽象級別和通信接口的靈活性。將 SystemC 與接口標準相結合，例如由 Open SystemC Initiative （OSCI） 開發的提議的事務級建模 （TLM） 2.0 規范，提供了一個環境，該環境保持與各種建模元素和抽象的兼容性，并使它們彼此可互操作，并且其他平臺。

此外，當從不同的抽象級別細化模型時，開發人員應該盡可能多地重用從一個模型到另一個模型的信息，并從一個 IP 塊的一個修訂版本到另一個重用建模信息。一致的方法和標準提供了完成這些任務的機制。開發人員還可以重用接口、狀態訪問機制和從一個模型到另一個模型的時間。Spirit IP-XACT（來自 SPIRIT 聯盟的 IP 元數據規范）等標準可以幫助開發人員導入和導出配置信息，并檢查模型修訂和抽象之間的差異。

不能保證不同模型和抽象之間的互操作性或提供與其他平臺和第三方工具的兼容性的建模方法不適用于大多數項目。事實上，缺乏互操作性和兼容性已經減緩了嵌入式行業對虛擬平臺的采用。

滿足供應鏈需求

在整個供應鏈中提供模型的需求不斷增長，這強化了互操作性、兼容性和標準的重要性。IP 提供商必須提供其 IP 的早期模型，因為客戶需要能夠為他們的產品選擇合適的 IP。如果沒有合適的模型，客戶就無法知道哪種 IP 最適合他們的系統?？蛻暨€需要一個用于他們自己的開發（架構、硬件和軟件）的平臺，以便用正確的產品進入他們的市場窗口。

任何支持跨供應鏈交付 IP 的建模方法都必須考慮到這一點。IP 必須與最終客戶的平臺和模型兼容，同時提供安全性并且不受逆向工程的影響。

打破建模障礙

一個經過深思熟慮的建模方法可以克服虛擬平臺采用的障礙，并確保用戶獲得虛擬平臺可以提供的所有價值。虛擬平臺建模應支持各種抽象級別的模型、模型即插即用以及互操作性、兼容性和重用標準。

行業需要提供工具，以跨各種抽象級別以一致的方式自動支持模型生成。這些工具必須包含標準并保留開發人員對其模型的投資。要求應：

提高模型開發人員的工作效率

重用來自遺留模型或不同抽象級別的模型的信息

支持標準以確?；ゲ僮餍院湍Ｐ偷狡渌摂M平臺的遷移路徑

提供一致性檢查以驗證跨抽象級別的模型

為模型支持和分發提供配置管理和修訂控制幫助

審核編輯：郭婷