天工開物｜征程 6 啟航新章：仿真篇

1. 仿真概述1.1 什么仿真？

仿真是使用其它相似的系統來模仿真實的需要研究或使用的系統，其所遵循的基本原則是相似性原理。仿真從框架上涉及到兩個系統：1)被仿的系統：需要研究或使用的系統；2）仿真出來的系統：在用戶側視角與被仿的系統有一定相似性。  注意：這里的系統是個抽象的概念，可以是軟件，也可以是硬件，還可以是復雜的綜合事件。在  征程6 開發平臺中，仿真的對象為“開發板及其上的系統”。

1.2 為什么要仿真？

仿真在不同行業不同背景下的的目的是不同的，這些目的包括但不限于：

• 設計組裝自動控制系統。

• 評價目標系統性能和功能。

• 為目標系統設計擴展功能和組件。

在 征程6 開發平臺中，仿真系統可以為我們提供下列便捷：

1. 緩解開發工作對開發板硬件的依賴  物理開發板的 CPU 是 ARM 的，其系統指令也是 ARM 平臺的，其上應用程序的代碼需要經過 arm 編譯器的處理。在缺少物理開發板的情況下，經過接口仿真在開發服務器（X86平臺）上實現了與 ARM 平臺側相似（因為系統及計算架構有異存在些許差異的情況是可能的，但差距一般很小）的功能。因為仿真接口和ARM平臺側接口在設計上保持了完全一致性，所以所開發的應用程序在經過不同編譯器處理后即可生成的平臺適用的目標程序并加以運行。對于開發而言，開發者在沒有獲得物理開發板前提前開始功能開發和驗證工作，從仿真的 X86 平臺切換真實的 ARM 平臺時，只需要對所開發的代碼修改編譯器和運行時庫便可以快速完成從仿真到真實平臺的轉換過程；對于用戶學習而言，OE 所提供的 ARM 側程序也可以通過改編譯器和運行時庫在開發服務器上加以使用。

2. 避免多人共享同一物理開發板時帶來的環境沖突問題  物理開發板屬于臨界資源，其上的系統版本在某一時刻是確定而且是唯一的。如果不同人在開發時所依賴的系統版本不同，那么得不到系統版本滿足的開發人員便無法進行開發工作。而仿真環境是通對通過 docker image 的版本加以區分的，其獨立且可以通過 DOCKER 容器構建多個相同或不同的仿真環境，如此一來，不同開發者對系統版本的依賴便可得到解決。

3. 數據回灌仿真

4. 為代碼調試提供便利  在開發環境中同時存在了業務源代碼、編譯的目標程序以及 X86 平臺調試工具 gdb。可以對業務代碼逐行進行襠部調試，加速功能 bug 的排查。

1.3 仿真系統的優缺點

仿真系統包括方便快捷、成本低廉、工作效率高等諸多優點，但是每一個事物都有其兩面性，仿真系統也存在一定缺點。在 征程6 開發平臺中，仿真系統的缺點包括：

1. 性能一致性  因為特定業務場景需要，真實開發板在設計時引入了特定加速硬件以加速計算過程，而仿真所依賴的開發機一般是為通用計算而設計的普通 PC 機，并不包含真實開發板所具備的加速硬件。所以這里的仿真更多是功能上的仿真。當然，顯卡作為普通計算機組件在很多 PC 機上是配備了的，同時顯卡也是AI加速的主要器件之一，在接口仿真實現時可以通過顯卡加速。然而這里仍然有兩個方面需要考慮：1）顯卡的加速效果與顯卡配置相關，同時即使配置上去了是否可以達到真實的開發板上特別設計過的加速硬件也很難說。2）仿真有很多個，其加速代碼的質量和開發時間也是逐步進行的，所以同樣硬件條件下隨著工具鏈版本迭代加速效果也可能是不同的。

2. 功能一致性  因為仿真系統和被仿真系統在計算架構、操作系統等方面存在差異，同樣的數據輸入在經過處理后得到的輸出結果可能存在些許差異，但差距一般很小。

3. 開發投入  因為業務代碼的最終運行環境（arm架構）和 仿真環境間的差異，需要在開發階段構建兩套編譯腳本: X86 平臺編譯腳本 For 仿真; arm 平臺編譯腳本 For 最終的板端部署。

4. 系統特性約束  仿真的本質是 X86 平臺上“模仿”出接口以實現在 ARM 平臺上的功能。在 X86 仿真平臺下無法使用 ARM 平臺下特有的功能和指令，如 Neon。因此，功能仿真過后在最后的實車部署階段，還是需要依賴工程的深度優化（Neon 加速等），還會涉及對齊等工作。

2. 仿真在 征程6 計算平臺的實現2.1 仿真框架概述

在 征程6 開發平臺中,仿真功能是通過地平線統一異構計算框架 HUCP（Horizon Unified Computing Platform）來實現的。相對于 征程5 的 DNN 預測庫，HUCP 支持自定義算子（Plugin）并 新增了數學計算庫（FFT、BLAS等）、CV 庫等的封裝, 進行了功能和邊界的擴展以提供計算圖全圖（視頻通路 + 前/后處理 + 多模型串街 + 自定義計算）表達的能力，支持將全圖一起送入下游編譯。

注：為支持全圖表達能力，在 Torch 開發環境新增 FLAP 和 LEAP 兩套自定義計算組件，支持通過 DSL、Numba、Triton 等算法友好的 Python 編程方式，添加模型前/中/后的自定義計算，包括：

1. 在 Pyramid、GDC 等硬件 IP 功能上拆分封裝出的各種 OP（LEAP）

2. CPU/ VPU 上實現的自定義計算（前/后處理，自定義算子等）（FLAP）

2.2 仿真實現原理

 上圖 是 征程6 開發平臺感知部署框架的構成，可以看出 HUCP 介于應用程序和運行平臺之間，是應用程序和運行平臺之間的“中間件”。對上，HUCP 為上層應用開發設計和提供了一套統一的應用程序編程接口（API）；對下，隱蔽不同 CPU 架構在接口實現上帶來的差異，不同架構的運算平臺調用各自的系統接口對 HUCP 提供的編程接口進行實現和編譯以生成不同架構的動態鏈接庫供編譯器連接時調用。

3. 仿真哪些東西

仿真功能依賴于統一異構計算框架 HUCP，而 HUCP 所提供的應用程序編程接口在實現時不僅調用了 BPU、CPU、DSP 等常規硬件資源，同時也包含對 Pyramid、GDC、Stitch、Codec 等視頻通路上的硬件 IP（不包含非計算的 camera 接入部分）資源的利用。在 征程6 SoC 上這些硬件是真實存在的，在 X86 平臺下，通過接口的 X86 平臺實現對這些硬件進行了仿真，從而透明化了不同平臺間接口調用的差異。對于應用程序開發者而言，在面向接口編程的思想指導下僅需在編譯階段選擇對應平臺的編譯工具和編譯庫即可。

4. 功能如何使用4.1 基礎使用環境準備

仿真功能作為算法工具鏈發布套件的一部分，其所依賴的環境已經集成在工具鏈發布（v3.0.12之后）的 docker 鏡像中，仿真功能基礎示例（horizon_j6_open_explorer_xxx-py38_20240430/samples/ucp_tutorial/dnn/basic_samples/code/00_quick_start）也包含在工具鏈每次發版的 OE 包中。因此跟使用AI工具鏈其他功能一樣，在開始使用仿真功能之前，需要先參考工具鏈使用手冊 load 算法工具鏈的 docker 鏡像，然后根據鏡像構建映射了 OE 包的用戶容器。 用戶容器啟動后便可參考基礎示例體驗仿真功能了.

注：詳細的工具鏈使用手冊 docker 基礎環境準備和 docker 使用，請參考 征程5 開發環境部署。

4.2 業務代碼編寫

UCP 為應用程序開發者提供了統一的業務編程接口，在面向接口編程的思想指導下透明化了不同平臺間接口調用的差異。因此，在業務代碼構建上，不同運行平臺的業務代碼并無差別，開發者可將注意力集中在業務邏輯之上，待業務代碼構建完成后開發者僅需在編譯時選擇對應平臺的編譯工具和編譯庫即可完成編譯進行業務測試。  注：如果想在基于 ARM 架構的開發板平臺上通過 ARM 平臺下特有的功能和指令（如 Neon）加速業務處理過程，同時基于仿真調試業務邏輯，可通過編譯宏區別平臺分別進行編程，由此帶來的工作量和兩個環境下數據對齊問題需要用戶自己評估。

4.3 編譯腳本構成

仿真平臺和被仿真平臺的 CPU 架構和指令集是不同的，所以說使用的編譯器和運行時庫也會存在差異。業務代碼構建完成后，進行編譯時，需要針對不同的目標運行平臺選擇正確的編譯器和運行時庫，下下述為X86 仿真平臺和 ARM 目標開發板平臺在部署工程實現時依賴庫和腳本間的差異（來自 OE 包基礎實例程序horizon_j6_open_explorer_xxx-py38_20240430/samples/ucp_tutorial/dnn/basic_samples/code/00_quick_start）。

• 依賴庫差異  

• SHELL 編譯腳本差異  

• CMakeLists.txt 腳本中 ARM&X86 差異  

5. 仿真案例5.1 快速入門

該示例代碼展示了 x86 仿真平臺和 arm 開發板平臺的基本腳本邏輯和編譯邏輯，用戶可以以此參照為自己的工程添加仿真構建邏輯。  

5.2 擴展工程案例

OE 包原 ai_benchmark 示例為方便向開發者提供參考模型后處理邏輯，構建了插件式“數據處理+模型推理+推理結果處理與展示”業務流框架。為方便開發者使用仿真功能進行自有模型的后處理代碼調試，最大限度復用已有的插件式雨霧流程框架，我們對原有的 ai_benchmark 工程進行了部分修改并添加了仿真編譯腳本，開發者可以參考擴展工程中 fcos 的后處理代碼邏輯（類繼承關系）構建適配自己模型的后處理文件并在配置中加以引用。因擴展工程中編譯腳本是自動進行新增文件索引和編譯的，用戶只需要將自己擴展的后處理代碼文件保存至與 fcos 的后處理代碼文件統計的 method 目錄（注意頭文件和源文件分別存放）下進行編譯即可，無需進行他們腳本代碼的開發。

擴展工程相對于 OE 包中原 ai_benchmark 示例代碼有如下差異：

1. 保留了原 ai_benchmark 示例代碼中所有的插件式框架代碼，包括推理數據準備、模型推理代碼以及與后處理、輸出四者間的調度邏輯。

2. 刪除了源代碼中大部分模型的后處理邏輯，僅保留了 fcos 的部分以作示例。

3. 添加仿真編譯腳本并對原有的 CMakeLists.txt 進行變動同時對測試運行腳本 env.sh 微調以適應仿真場景需要。

4. 用戶可以參考 fcos 的后處理邏輯可針對自己的模型構建后處理進行功能仿真驗證。  點擊下載 擴展示例工程代碼

6. 其他說明6.1 與 征程5 仿真對比

J征程5 仿真功能提供的是一套基于 GPU 環境的 QAT 定點模型（紅框1）推理方式，但因為該模型位于編譯之前，所以端側 runtime 數據類型的變化并不能同步體現在 x86 端。而相同的場景下，征程6 使用新一代 HBDK4 工具鏈對其進行了標準化，如下圖所示，編譯環節會同時產出一個上板模型和一個可 GPU 推理的仿真模型（紅框2），SoC 和 x86 端可以使用完全相同的 API 無感地加載和推理這兩個模型。因此，在 征程6 工具鏈中，算法同學能夠在 x86 環境下快速、便捷地完成原型驗證、回灌仿真等工作，節約大量算法/工程對齊的開銷，后續也能絲滑地遷移至 SoC 環境（只需替換模型文件，基于交叉編譯工具重新編譯工程即可），從而極大地提升了生產開發效率。