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

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

1.2 為什么要仿真？

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

• 設計組裝自動控制系統(tǒng)。

• 評價目標系統(tǒng)性能和功能。

• 為目標系統(tǒng)設計擴展功能和組件。

在 征程6 開發(fā)平臺中，仿真系統(tǒng)可以為我們提供下列便捷：

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

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

3. 數(shù)據(jù)回灌仿真

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

1.3 仿真系統(tǒng)的優(yōu)缺點

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

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

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

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

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

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

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

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

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

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

2.2 仿真實現(xiàn)原理

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

3. 仿真哪些東西

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

4. 功能如何使用4.1 基礎使用環(huán)境準備

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

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

4.2 業(yè)務代碼編寫

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

4.3 編譯腳本構(gòu)成

仿真平臺和被仿真平臺的 CPU 架構(gòu)和指令集是不同的，所以說使用的編譯器和運行時庫也會存在差異。業(yè)務代碼構(gòu)建完成后，進行編譯時，需要針對不同的目標運行平臺選擇正確的編譯器和運行時庫，下下述為X86 仿真平臺和 ARM 目標開發(fā)板平臺在部署工程實現(xiàn)時依賴庫和腳本間的差異（來自 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 開發(fā)板平臺的基本腳本邏輯和編譯邏輯，用戶可以以此參照為自己的工程添加仿真構(gòu)建邏輯。  

5.2 擴展工程案例

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

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

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

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

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

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

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

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