天工開(kāi)物｜征程 6 啟航新章：仿真篇

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

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

1.2 為什么要仿真？

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

• 設計組裝自動(dòng)控制系統。

• 評價(jià)目標系統性能和功能。

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

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

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

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

3. 數據回灌仿真

4. 為代碼調試提供便利  在開(kāi)發(fā)環(huán)境中同時(shí)存在了業(yè)務(wù)源代碼、編譯的目標程序以及 X86 平臺調試工具 gdb?？梢詫I(yè)務(wù)代碼逐行進(jìn)行襠部調試，加速功能 bug 的排查。

1.3 仿真系統的優(yōu)缺點(diǎn)

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

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

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

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

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

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

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

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

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

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

2.2 仿真實(shí)現原理

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

3. 仿真哪些東西

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

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

仿真功能作為算法工具鏈發(fā)布套件的一部分，其所依賴(lài)的環(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工具鏈其他功能一樣，在開(kāi)始使用仿真功能之前，需要先參考工具鏈使用手冊 load 算法工具鏈的 docker 鏡像，然后根據鏡像構建映射了 OE 包的用戶(hù)容器。 用戶(hù)容器啟動(dòng)后便可參考基礎示例體驗仿真功能了.

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

4.2 業(yè)務(wù)代碼編寫(xiě)

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

4.3 編譯腳本構成

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

• 依賴(lài)庫差異  

• SHELL 編譯腳本差異  

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

5. 仿真案例5.1 快速入門(mén)

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

5.2 擴展工程案例

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

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

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

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

3. 添加仿真編譯腳本并對原有的 CMakeLists.txt 進(jìn)行變動(dòng)同時(shí)對測試運行腳本 env.sh 微調以適應仿真場(chǎng)景需要。

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

6. 其他說(shuō)明6.1 與 征程5 仿真對比

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