吳李煜，張紫龍，張華君，田 野，常 勝

（1.武漢大學 物理科學與技術(shù)學院，湖北 武漢 430072；2.湖北航天飛行器研究所，湖北 武漢 430040）

0 引言

近年來，隨著深度學習技術(shù)的發(fā)展，其在終端應用領(lǐng)域的需求越來越廣泛。以低空航拍為應用場景切入點，目標檢測能有效提升飛行器的感知能力。目標檢測算法也是計算機視覺重要分支，研究檢測算法在嵌入式終端領(lǐng)域下的部署具有重要意義。區(qū)別于傳統(tǒng)檢測算法的應用場景，低空航拍的視場大、圖像背景復雜、目標小而多，檢測算法需要在現(xiàn)有結(jié)構(gòu)上進行針對性的優(yōu)化與訓練。將算法部署于遠程服務器的傳統(tǒng)方案一般要求高清且穩(wěn)定的遠程圖像通信，實時性通常較差，而終端平臺的計算力有限，往往難以定制，研發(fā)周期長。

終端應用領(lǐng)域中，嵌入式FPGA 有著可靠性強、集成度高、功耗低、可并行計算等優(yōu)點，因此本文選擇嵌入式FPGA 為開發(fā)平臺，提出了全流程的解決方案。算法基于經(jīng)典的SSD 檢測框架優(yōu)化網(wǎng)絡(luò)結(jié)構(gòu)，以此提高精確度、減少參數(shù)和計算量。硬件開發(fā)上，基于Vitis 工具鏈以及高層次綜合技術(shù)有效縮短硬件的研發(fā)周期。應用程序上，多線程運行且兼容動態(tài)鏈接庫的Python 主機程序兼具通用性和開發(fā)快捷性。OpenCL 層次的硬件調(diào)用也有效地節(jié)省了驅(qū)動開發(fā)耗時。

1 目標檢測算法優(yōu)化

本項目的訓練集和測試集由無人機針對目標場景定向采集制作，按照VOC2007 目標檢測數(shù)據(jù)集標注，共19 個場景和9 類檢測目標。

網(wǎng)絡(luò)框架的設(shè)計出發(fā)點是降低終端硬件的計算量和減少參數(shù)。因此選擇計算量和參數(shù)量較小的GhostBM 和FPN。檢測方案的出發(fā)點是提高精度，本文基于經(jīng)典的SSD 框架，針對檢測目標尺寸跨度較大的問題，為保證相應的有效感受野完全覆蓋目標且攜帶語義信息，設(shè)置了4 個不同尺寸的輸出stage，每個stage 都對應一個分類概率anchor 和一個檢測坐標anchor。采用基于anchor area 的K?means 聚類方法生成了8 個不同面積的anchor 超參。由于有效感受野小于理論感受野，所以網(wǎng)絡(luò)結(jié)構(gòu)整體上按照理論感受野的面積是anchor area 4 倍的標準設(shè)計。輸出特征圖的尺寸分別為56×96，28×48，14×24，7×12，可保證所有目標均可以找到與之對應的默認框。

檢測網(wǎng)絡(luò)算法結(jié)構(gòu)如表1 所示，其中是GhostBM中通道增大比例，為輸出通道數(shù)，為卷積步長，為模塊重復次數(shù)，Sn 為輸出Stage 編號，相同編號的輸出會經(jīng)過元素相加后進入Head。

表1 檢測網(wǎng)絡(luò)算法結(jié)構(gòu)

2 系統(tǒng)架構(gòu)設(shè)計

本文硬件開發(fā)平臺為Zynq UltraScale+MPSoC ZCU104 開發(fā)套件，平臺核心為ZU7EV 器件芯片，該芯片集成了4 核ARM Cortex?A53 處理器與FPGA，平臺配套了4 GB DDR4 內(nèi)存。硬件在Vitis 2020.1 平臺下編譯，并與預定義的操作系統(tǒng)、驅(qū)動程序和根文件系統(tǒng)的ZCU104 Base 2020.1 嵌入式基礎(chǔ)平臺連接，生成定制化的硬件平臺鏡像。

圖1 為本系統(tǒng)的設(shè)計框架圖，本系統(tǒng)軟硬協(xié)同地實現(xiàn)圖像檢測功能，檢測算法的計算流程交給計算能力更強的PL（Programmable Logic）部分。卷積網(wǎng)絡(luò)推斷本體由DPU 計算，輸入圖片的預處理、輸出分類矩陣的Softmax 計算與定位矩陣的解碼操作由定制的HLS 計算核來處理。PS（Processing System）用于部署控制性質(zhì)的任務，負責運行多線程的Python 主機程序和用于調(diào)度硬件的動態(tài)函數(shù)庫，并且負責圖像的輸入和輸出。

圖1 系統(tǒng)框架圖

3 硬件設(shè)計

3.1 DPU 卷積核定制

本項目卷積算法網(wǎng)絡(luò)硬件加速核由Xilinx 官方DPU IP 核定制生成，它是專用于卷積神經(jīng)網(wǎng)絡(luò)且高度優(yōu)化的可配置計算引擎。

結(jié)合ZCU104 開發(fā)平臺的硬件資源和實際網(wǎng)絡(luò)速度的需求，本文規(guī)劃部署2 個定制DPU 核，設(shè)置其硬件架構(gòu)為B4096，其計算并行度體現(xiàn)在3 個維度上，分別對應像素并行度為8，輸入通道并行度為16，輸出通道并行度為16。由于DPU 核的DSP 部分采用了Double Data Rate（DDR）技術(shù)，工作在2 倍于控制部分時鐘的時鐘域下，因此對于控制部分時鐘，其峰值每時鐘周期可做4 096 次計算。針對性地設(shè)置為低RAM 高DSP 模型，并開啟深度卷積和ReLU6 的硬件支持。

本系統(tǒng)DPU 的兩個輸入時鐘分別設(shè)置為300 MHz和600 MHz。

3.2 HLS 功能核設(shè)計

3.2.1 預處理核

預處理模塊負責將讀取的圖片由硬件進行并行化處理，輸出滿足網(wǎng)絡(luò)推斷格式要求的數(shù)組。該模塊主要包含圖片Resize、減均值、BGR 通道轉(zhuǎn)RGB 通道以及圖像量化，量化值為固定值0.5。輸出的數(shù)組尺寸為448×768×3，數(shù)值分布于0 值兩邊，數(shù)據(jù)類型為8 位整型，數(shù)值范圍為-128～127。

圖2為預處理的設(shè)計方案。接口部分輸入輸出數(shù)據(jù)位寬均為8，同時所有模塊按照3 通道的2 個像素并行處理，并行處理的數(shù)據(jù)位寬為48。由于預處理核的計算并非瓶頸，故未額外增大并行度。為了匹配ZYNQ 的高性能數(shù)據(jù)接口的位寬，外部接口設(shè)置為兩條128 位的Axi Master 數(shù)據(jù)總線，通過高性能接口連接DDR。設(shè)置一條Slave_axilite 控制總線連接Arm 核，設(shè)置輸入輸出的尺寸與3 組均值寄存器，時鐘設(shè)置為150 MHz。模塊設(shè)計分為連接模塊和處理模塊，所有模塊流水線式同步運行，內(nèi)部模塊間的連接設(shè)置為2 深度的FIFO（隊列）。連接模塊負責數(shù)據(jù)總線與FIFO 的相互轉(zhuǎn)化以及數(shù)據(jù)位寬的轉(zhuǎn)化。預處理核的Resize 處理模塊使用Xilinx 官方的視頻庫函數(shù)。減均值、移位與通道轉(zhuǎn)化處理模塊以流水線方式執(zhí)行，執(zhí)行間隔為一個時鐘周期。

圖2 預處理核模塊與數(shù)據(jù)流

3.2.2 Softmax 核

Softmax 在深度學習中用于求輸出矩陣的分類概率，在本系統(tǒng)中負責計算Class?Head 輸出矩陣的分類概率。其計算公式如下：

圖3 為Softmax 核的設(shè)計方案。接口部分，輸入為量化后的8 位整型數(shù)據(jù)，輸出為32 位浮點數(shù)據(jù)，分別有2 條數(shù)據(jù)總線、1 條控制總線，可設(shè)置處理數(shù)組的長度和量化比例。時鐘設(shè)置為150 MHz。模塊并行同步工作，模塊間以FIFO 連接。

圖3 Softmax 核模塊與數(shù)據(jù)流

圖4 為Softmax 計算模塊的流程圖，左半部分8 位寬的數(shù)據(jù)不間斷讀入，乘上量化值恢復成浮點型，指數(shù)計算后存儲在指定的寄存器內(nèi)同時做求和，直到一個求和輪次結(jié)束后保存進SUM 寄存器。同時右半部分同步計算上一個求和輪次中各個指數(shù)值與上一次和的商，得到分類概率輸出給FIFO。該模塊通道間以流水線執(zhí)行，間隔等同于通道長度值，平均處理一個數(shù)據(jù)的間隔為一個時鐘周期。

圖4 Softmax 核計算模塊的流程

3.2.3 Decode 核

Decode 在檢測算法中用于將檢測位置矩陣通過anchor 來解碼成檢測框的實際坐標，負責將Local?Head的輸出矩陣解碼，其計算公式如下：

網(wǎng)絡(luò)的位置輸出通道為4，分別為，，，，anchor 提供了，，，這4 個參數(shù)矩陣。輸出的，，，這4 個通道數(shù)據(jù)分別代表了檢測框下框線值、左框線值、上框線值、右框線值，該值為所在圖像中的比例坐標值，乘上圖像長寬則為絕對坐標值。

圖5 為Decode 核的設(shè)計方案。輸入為DPU 輸出的8 位整型數(shù)據(jù)，32 位浮點型anchor 數(shù)據(jù)，其中和維度的數(shù)據(jù)由于并行需要合并了位寬，和維度的數(shù)據(jù)長度固定且運算復用，可一次性讀入。輸出為32 位浮點型結(jié)果。所以接口部分設(shè)有4 條數(shù)據(jù)總線、1 條控制總線，可設(shè)置處理數(shù)組長度與量化比例。時鐘設(shè)置為200 MHz。模塊并行同步執(zhí)行，以2 深度FIFO 連接。

圖5 Decode 核模塊與數(shù)據(jù)流

圖6 為Decode 計算模塊設(shè)計。圖中以坐標的解碼計算為例，模塊最開始會一次性從內(nèi)存接口讀入和維度anchor 數(shù)據(jù)；然后按照圖示不斷從FIFO 中讀入數(shù)據(jù)，4 個通道并行計算后輸出。該模塊的流水線間隔為一個時鐘周期。

圖6 Decode 核示意圖

4 軟件設(shè)計

4.1 DPU 執(zhí)行庫生成

DPU 的執(zhí)行庫基于Vitis AI 組件生成。圖7 為生成網(wǎng)絡(luò)算法執(zhí)行程序的操作流程。

圖7 DPU 執(zhí)行程序生成流程

網(wǎng)絡(luò)基于tensorflow 訓練，訓練完成后的權(quán)重和閾值為浮點數(shù)，計算也為浮點運算，不適合FPGA，需要量化。經(jīng)驗表明，8 位量化產(chǎn)生的精度損失較小，對計算力和存儲的要求卻能大大下降，因此采用了8 位量化。流程上，首先需要將網(wǎng)絡(luò)浮點模型固化成靜態(tài)圖，輸入校準集，使用量化工具將整個網(wǎng)絡(luò)量化，生成部署靜態(tài)圖和評估靜態(tài)圖。

根據(jù)圖1，可以看出關(guān)于混合式教學在中小學領(lǐng)域應用的研究文獻最早出現(xiàn)在2007年，并且文獻的數(shù)量一直在持續(xù)增長，原因除了科學發(fā)展支撐，還有國家政策引領(lǐng)——在2015年，國務院倡導大眾創(chuàng)業(yè)萬眾創(chuàng)新，建立線上和線下、國內(nèi)與國外、政府和企業(yè)合作等一系列的創(chuàng)新機制，越來越多的教育模式應運而生，如創(chuàng)科教育、STEAM教育等[7]。智能機、平板、電腦普及，人人都可以隨時隨地的使用不同終端進行學習，傳統(tǒng)的教學模式得以改變，混合式教學也應運而生，隨著科技進步的飛速發(fā)展，越來越多的研究者將視角轉(zhuǎn)到了中小學，混合式教學關(guān)于中小學應用的研究文獻的數(shù)量不斷增長。

隨后生成部署程序。網(wǎng)絡(luò)部署工具可以根據(jù)該硬件描述文件與部署靜態(tài)圖，將量化后的算法網(wǎng)絡(luò)模型映射到高度優(yōu)化的DPU 執(zhí)行序列中，構(gòu)造一個內(nèi)部計算圖，可交叉編譯生成網(wǎng)絡(luò)指令庫文件。主機程序可以通過DNNDK 的n2cube 庫調(diào)度該指令庫來控制DPU 的運行。

4.2 HLS 調(diào)用庫設(shè)計

在ARM 核的Linux 操作系統(tǒng)上，基于Xilinx Runtime 環(huán)境，可以通過OpenCL 異構(gòu)調(diào)用的方式縮短驅(qū)動設(shè)計流程，實現(xiàn)對硬件的調(diào)用。

該庫包含初始化函數(shù)和執(zhí)行函數(shù)兩部分外部函數(shù)。初始化部分，執(zhí)行基本的OpenCL 初始化函數(shù)，為HLS 硬件申請內(nèi)核對象，申請內(nèi)存對齊的全局變量。創(chuàng)建Buffer 對象，完成虛擬地址與物理地址的映射，并將該物理地址設(shè)置為HLS 核的數(shù)據(jù)總線啟動地址。執(zhí)行部分，設(shè)置執(zhí)行時改變的HLS 核寄存器，負責主機數(shù)據(jù)與全局變量的搬移與HLS 核的硬件執(zhí)行。

通過交叉編譯，該OpenCL 程序可以編譯成可供上級主機程序調(diào)用的外部函數(shù)庫。

4.3 主程序設(shè)計

主程序基于Python 編寫，有利于直接移植算法設(shè)計環(huán)境的函數(shù)。通過ctypes 庫來實現(xiàn)C/C++兼容，完成庫程序的調(diào)用。主程序基于多線程方案實現(xiàn)，其設(shè)計方案如圖8 所示。

圖8 主程序設(shè)計

圖像輸入借助OpenCV 庫，可從存儲卡中讀取圖片或者通過VideoCapture 獲得USB 攝像頭的數(shù)據(jù)。HLS硬核可通過第4.2 節(jié)生成的外部函數(shù)庫調(diào)用執(zhí)行，DPU程序可通過DNNDK 庫與第4.1 節(jié)生成的指令庫調(diào)用執(zhí)行，由于DPU 推斷網(wǎng)絡(luò)并不構(gòu)成速度瓶頸，故只使用了單DPU 做推斷。軟件后處理為排序操作，不涉及計算，負責檢測框篩選，將檢測框在原圖描述出來并標注類別和概率。圖像借助千兆網(wǎng)口和SSH 工具輸出，在遠程主機上直觀顯示。當然，也可以為了減少網(wǎng)絡(luò)帶寬，不輸出圖片，改為直接輸出檢測分類結(jié)果與坐標位置。

線程間分別設(shè)置了深度為3 的線程隊列，允許線程流水線式并行執(zhí)行，線程間內(nèi)存共享，故不引入額外內(nèi)存搬移消耗。

5 測試與分析

本項目在ZCU104 開發(fā)板上完成測試。測試集由無人機對目標場景針對性拍攝而成。

5.1 占用資源情況

FPGA 的資源消耗如表2 所示?？梢钥吹?，本系統(tǒng)充分地利用了平臺硬件資源。

表2 FPGA 的資源消耗

5.2 檢測準確性

基于完整軟件測試集，分別對浮點模型和量化后的評估模型對于目標檢測的均值平均精度（mean Average Precision，mAP）指標進行測試。表3 為測試結(jié)果，一般可以認為量化評估模型圖的運行結(jié)果能基本代表硬件結(jié)果。從表中可以看到本項目有比較高的檢測精度。

表3 檢測精度

圖9 示意了2 個場景下的目標檢測結(jié)果。

圖9 兩個場景的目標檢測結(jié)果圖

5.3 運行速度

運行的耗時由1 000 次圖像輸入計算平均值得到，線程耗時項排除了隊列等待時長?；赟D 卡讀入的圖像尺寸為1 280×720，基于攝像頭讀入的圖像尺寸為640×480。為了形成對比，專門測試了使用ARM 核運行預處理核后計算的情況，如表4 所示。

表4 內(nèi)核耗時 ms

根據(jù)表4 結(jié)果可以發(fā)現(xiàn)，多線程運行總耗時一般取決于最大耗時線程，由于HLS 核由線程鎖阻塞執(zhí)行，其線程耗時求和可影響總耗時。對比表中SD 卡讀入的2 種情況，由ARM 核做網(wǎng)絡(luò)的前后處理的計算會形成速度瓶頸，使用HLS 硬件加速則可以有效提升運行速度。

以由HLS 核加速的SD 卡讀入測試為例，該方案總耗時約為50 ms，計算可得速度約為20 f/s。

6 結(jié)語

本文針對低空航拍的目標檢測場景，提出了其終端部署的全流程解決方案。經(jīng)過測試，該方案在測試集上檢測精度為0.55，處理速度約為20 f/s，檢測精度高、運行速度快，滿足了終端運行的實時性要求。該方案利用多種高層次技術(shù)，實現(xiàn)快速部署，縮短了定制周期且易于移植，并且可推廣至其他深度學習的嵌入式部署設(shè)計。