AMD Versal 自適應 SoC 設計的系統級驗證加速漸進式方案

作者：Adam Taylor



AMD Versal 自適應 SoC 為開發者提供了一種異質運算架構，將可程式邏輯（ PL ）、AI 引擎以及高效能處理系統整合於單一裝置之中。這些運算單元透過可程式片上網路（ NoC ）互聯，並協同用於實現複雜、高效能的系統。

這種架構的靈活性帶來了顯著的效能和效率提升，但也增加了驗證的複雜性。Versal 裝置的設計跨越多個領域，包括 AI 引擎圖、基於 HLS 或 RTL 的可程式邏輯設計，以及運行在處理系統上的軟體。每個領域都使用不同的工具和抽象層，通常由不同團隊開發。

驗證這些元件作為一個整合系統能否正確運作，是 Versal 元件開發中最具挑戰性的環節之一。系統級驗證必須確保演算法正確、子系統間整合無誤，並且部署到硬體後行為正確。傳統上，此層級的驗證依賴硬體仿真，儘管硬體仿真很準確，但其帶來了複雜性和效能限制，限制了其在設計早期階段的實用性。

AMD Vitis 統一軟體平台引進了一系列替代模擬流程，克服了這些限制。功能模擬、基於 XSIM 的子系統模擬以及硬體在環驗證實現了一種漸進式的驗證方法，可以更早啟動、執行更快，並降低整體專案風險。這些流程相互補充，可有效應用於 Versal 自適應 SoC 系統開發。

傳統基線：硬體模擬

在新系統模擬流程出現之前，Versal 裝置設計的主要驗證方式是在 Vitis 軟體中進行硬體模擬。這個流程結合了多個獨立模擬器來模擬 Versal 元件的主要子系統。

在典型的硬體模擬驗證中，處理系統使用 QEMU 進行仿真，可程式邏輯使用具有 HDL 測試平台的 XSIM 進行模擬，AI 引擎陣列使用基於 System-C 的 AI 引擎（ AIE ）仿真器進行模擬。這些模擬器協同提供全系統的功能準確性，並支援與可程式邏輯和 AI 引擎互動的軟體應用的執行。

儘管這種方法能產生有效且資訊豐富的結果，但它較為複雜性。每個模擬器的運作速度遠低於實際矽片，而且時間解析度通常也各不相同。因此，需要投入大量努力來配置和維護模擬器間的同步。

為了確保系統行為的正確性，QEMU、XSIM 和 AIE 模擬器之間的時鐘、事件、記憶體事務和中斷必須持續協調。這種跨模擬器同步會帶來通訊開銷和頻繁的上下文切換，進而顯著降低整體模擬吞吐量。諸如調試可見性和事務級建模等額外因素則會進一步導致執行緩慢。

隨著 Versal 自適應 SoC 設計複雜度的提升，管線更深、資料通路更寬、互連更複雜，硬體模擬的限制愈發明顯。雖然硬體模擬在某些應用場景下仍然很有價值，但並不總是適用於快速迭代或早期系統驗證。

漸進式系統模擬策略

Versal 元件開發並非完全依賴硬體模擬，而是受惠於漸進式系統模擬策略，在設計流程的不同階段應用不同的驗證技術。


此策略包含三種互補流程：

1. 功能模擬聚焦高階演算法正確性

2. 基於 XSIM 的子系統模擬可驗證 AI 引擎與可程式邏輯間的集成

3. 硬體在環驗證是在軟體控制下，在真實 Versal 裝置上執行設計 每個流程都針對特定的驗證目標，避免了在不需要時進行全硬體模擬的開銷。這些共同提供了一條從演算法到硬體的結構化路徑。

流程 1 - Versal 自適應 SoC 系統的功能模擬

功能模擬著重於驗證設計“做什麼”，而非其在週期層面的行為。對於 Versal 裝置而言，這通常涉及在將 AI 引擎圖和 HLS 生成的核心整合到更大的系統之前對其進行驗證。

Vitis 功能模擬（ Vitis Functional Simulation ）使開發人員能夠使用 Python、MATLAB 或 C++（早期存取）對 AI 引擎和 HLS 設計進行模擬。這使得驗證可以在與演算法開發相同的環境中進行，從而減少了軟體建模與硬體實現之間的摩擦。

由於功能模擬運行於更高的抽象層，其模擬性能遠高於硬體仿真。這使得在設計流程早期處理大規模資料集、探索架構參數、評估數值效能指標變得切實可行。

為了實現軟體框架與 Versal 裝置設計之間的無縫交互，功能模擬採用統一數組類型，支援 AI 引擎和 HLS 核心常用的定點和浮點資料格式。這就使得資料交換無需手動轉換，也不會面臨精確度損失。

功能模擬對於早期驗證尤其有效，因為在早期驗證中，快速迭代和演算法洞察比週期準確性更重要。

>>演算法到子系統的過渡

一旦功能正確性得到驗證，下一步挑戰就是確保 AI 引擎設計能夠與可程式邏輯和系統級基礎架構正確整合。在這一階段，僅靠功能模擬已不夠，因為它無法捕捉資料流動、介面行為或子系統互動。

這一轉變標誌著子系統層級模擬變得至關重要。

流程 2 - 基於 XSIM 的子系統模擬

基於 XSIM 的模擬讓 Vitis 子系統可以直接在 AMD Vivado 設計套件環境中進行模擬。在此流程中，在 Vitis 中定義的設計（包含 AI 引擎、HLS 和 PL 核心）被打包為一個 Vitis 子系統，並導入到 Vivado 設計套件專案中，與周圍的可程式邏輯進行整合。

Vitis 子系統利用 AI 引擎測試平台進行測試，取代了處理系統。在此情況下，測試平台應採用System Verilog 編寫，因此無需再使用 QEMU。與硬體模擬相比，這能顯著降低仿真開銷。此方法讓可程式邏輯設計師不僅能驗證 AI 引擎功能，還能檢查資料傳輸、介面正確性、與自訂 RTL 模型的整合行為，同時保持對 RTL 和 AI 引擎活動的可見性。

由於此流程避免了完整的處理器仿真及相關開銷，因此其執行速度遠超硬體模擬，同時仍能提供有意義的系統上下文資訊。它是功能模擬與硬體執行之間的重要中間步驟。至關重要的是，基於 XSIM 的驗證是周期準確的（ AI 引擎模擬為週期近似），這使得開發人員可以驗證效能和接口，還可以驗證吞吐量和延遲。。

>>借助 Vitis 工具實現分析和可見性

在基於 XSIM 的模擬過程中，可以利用 Vitis Analyzer 對 AI 引擎的執行情況進行分析。這樣能夠深入了解圖結構、tile 利用率和執行行為，進而補充 Vivado 工具所提供的 RTL 級可見性。

透過將 XSIM 中觀察到的子系統行為與 AI 引擎執行資料進行關聯，開發人員可以在進行硬體實現之前發現效能瓶頸和整合問題。

在此階段，團隊可以確信演算法是正確的，並且 AI 引擎與可程式邏輯子系統能夠按預期協同工作。

流程 3 - 硬體在環驗證

硬體在環驗證是漸進式模擬策略的最後階段。在此流程中，設計部署到真實 Versal 裝置上，但仍由基於主機的軟體環境控制。

借助 Vitis 硬體在環功能，Vitis 子系統與運行在目標 Versal 裝置上的輕量級伺服器整合在一起。主機系統透過乙太網路與該伺服器通信，發送測試向量並接收結果進行分析。來自主機的資料可透過 MATLAB 或 Python 傳遞，兩種語言均為演算法開發的常用程式語言。

與硬體模擬不同，計算在真實矽片上完成。這便消除了跨模擬器同步的需求，並允許精確測量性能、時序和數值行為。同時，此流程的軟體驅動特性保證了可重複性和可觀測性。

硬體在環測試使開發人員能夠在將設計整合到完整系統之前驗證子系統的行為和性能，從而在開發的關鍵階段降低風險。

>>透過漸進式驗證降低風險

透過圍繞功能模擬、基於 XSIM 的子系統模擬和硬體在環執行建置驗證流程，Versal 裝置開發人員可以在不需要硬體模擬時，避免硬體模擬帶來的成本和複雜性。

每個階段都針對特定的風險類別，並逐步增強驗證信心。功能模擬可以驗證演算法，子系統仿真可以驗證集成，硬體在環可以驗證實際執行情況。

這種方法能夠實現更快迭代、更早洞察、更可預測的系統層級結果。

總 結

隨著 Versal 自適應 SoC 設計複雜性的不斷提升，驗證策略必須超越單純依賴硬體模擬。儘管硬體仿真仍然具有價值，但其複雜性和效能限制使其不盡然適合早期和迭代驗證。

Vitis 統一軟體平台提供了一套互補的模擬與驗證流程，解決了這些挑戰。功能模擬、基於 XSIM 的子系統模擬以及硬體在環驗證，共同構成了一種適用於 Versal 設計的可擴展且高效的系統級驗證策略。

透過逐步應用這些流程，您可降低風險、提升信心，並加快從演算法開發到硬體部署的進程。

資 源

如果您希望了解本文中提及技術的更多信息，以下資源將對您有所幫助：

• UG1701 VFS 文檔

• Vitis-Tutorials VFS 範例

• Vitis 功能模擬早期存取專區 (新 C++ 流程；AMD 計畫於 2026.1 正式上線)

• 硬體在環早期訪問專區



閱讀原文