使用FPGA實(shí)現(xiàn)深度學(xué)習(xí)技術(shù)應(yīng)用VIP

使用FPGA實(shí)現(xiàn)深度學(xué)習(xí)技術(shù)應(yīng)用這是新的系列教程，在本教程中，我們將介紹使用FPGA實(shí)現(xiàn)深度學(xué)習(xí)的技術(shù)，深度學(xué)習(xí)是近年來人工智能領(lǐng)域的熱門話題。在本教程中，旨在加深對(duì)深度學(xué)習(xí)和FPGA的理解。用C/C++編寫深度學(xué)習(xí)推理代碼高級(jí)綜合(HLS)將C/C++代碼轉(zhuǎn)換為硬件描述語言FPGA運(yùn)行驗(yàn)證在上一篇文章中，我們?cè)贛NIST數(shù)據(jù)集上創(chuàng)建并訓(xùn)練了一個(gè)網(wǎng)絡(luò)模型。從本文開始，為了在FPGA上運(yùn)行推理處理，我們將首先用C++編寫推理處理代碼。在這篇C++實(shí)現(xiàn)的第一篇文章中，我們開始針對(duì)卷積層的C++實(shí)現(xiàn)。具體內(nèi)容是（1）卷積層的實(shí)現(xiàn)，（2）運(yùn)算校驗(yàn)（C驗(yàn)證，C/RTL協(xié)同驗(yàn)證）（就是HLS的流程）。卷積層實(shí)現(xiàn)在上一篇文章中，我解釋了卷積層是對(duì)圖像的過濾過程，但是并沒有解釋輸入輸出通道如何處理，過濾時(shí)圖像的邊緣處理等。由于本文旨在實(shí)現(xiàn)層面的理解，因此我將詳細(xì)介紹這些要點(diǎn)。處理I/O通道在圖像處理中，對(duì)RGB輸入圖像進(jìn)行噪聲去除等濾波處理，并頻繁地進(jìn)行RGB圖像的處理。在這種情況下，卷積過程往往是針對(duì)每個(gè)通道（R/G/B）獨(dú)立完成的，輸入的G/B通道值不影響輸出的R通道結(jié)果。每通道獨(dú)立卷積另一方面，在卷積層中執(zhí)行的卷積過程中，所有輸入通道的值影響每個(gè)輸出通道。因此，對(duì)于輸出圖像的每個(gè)像素（輸出通道，Y坐標(biāo)，X坐標(biāo)），所有輸入通道和周圍的像素區(qū)域都會(huì)參與計(jì)算，導(dǎo)致計(jì)算量非常大。使用所有通道的卷積另外，如上所述每個(gè)通道獨(dú)立卷積的卷積層稱為DepthwiseConvolution。這通常用于減少計(jì)算量的網(wǎng)絡(luò)模型，例如MobileNet(https://arxiv.org/abs/1704.04861)。圖像邊緣處理在對(duì)圖像進(jìn)行卷積處理時(shí)，圖像邊緣的處理往往是一個(gè)問題。由于卷積過程在計(jì)算某個(gè)像素時(shí)使用了周圍像素，因此對(duì)于沒有周圍像素的像素，例如圖像邊緣的像素，就無法獲取周圍像素。卷積神經(jīng)網(wǎng)絡(luò)主要通過以下兩種方式處理邊緣像素。無填充：輸出圖像減少了輸入圖像的卷積區(qū)域。補(bǔ)零：將輸入圖像預(yù)先用卷積區(qū)域擴(kuò)展，用零填充該區(qū)域，對(duì)原始輸入圖像進(jìn)行卷積處理。沒有填充的卷積的圖形表示如下所示：在這種情況下，輸出圖像將是比輸入圖像小一個(gè)濾波器尺寸的區(qū)域（橙色部分）。如果內(nèi)核大小為3（中心像素+/-1），則輸出圖像大小在寬度和高度上都將為-2，因?yàn)閳D像之外的1個(gè)像素是無法進(jìn)行卷積的區(qū)域。無填充卷積：輸出圖像縮小接下來，零填充的圖形表示如下所示。在這個(gè)例子中，預(yù)先在輸入圖像的外部添加了一個(gè)值為0的區(qū)域（灰色區(qū)域），進(jìn)行卷積，這樣就不會(huì)出現(xiàn)圖像縮小現(xiàn)象。如果內(nèi)核大小為3，則帶填充的輸入圖像大小在寬度和高度上均為+2，因?yàn)?1像素將添加到屏幕外部且值為零。零填充卷積：輸出圖像大小保持不變?cè)谖覀兊哪Ｐ椭?，我們?cè)谒芯矸e層中使用零填充。C代碼如果根據(jù)目前為止的解釋用C語言實(shí)現(xiàn)卷積過程，它將類似于下面的代碼。

void

conv2d(const

float*

x,

const

float*

weight,

const

float*

bias,

int32_t

width,

int32_t

height,

int32_t

in_channels,

int32_t

out_channels,

int32_t

ksize,

float*

y)

{

for

(int32_t

och

=

0;

och

<

out_channels;

++och)

{

for

(int32_t

h

=

0;

h

<

height;

++h)

{

for

(int32_t

w

=

0;

w

<

width;

++w)

{

float

sum

=

0.f;

for

(int32_t

ich

=

0;

ich

<

in_channels;

++ich)

{

for

(int32_t

kh

=

0;

kh

<

ksize;

++kh)

{

for

(int32_t

kw

=

0;

kw

<

ksize;

++kw)

{

int32_t

ph

=

h

+

kh

-

ksize/2;

int32_t

pw

=

w

+

kw

-

ksize/2;

//

zero

padding

if

(ph

<

0

||

ph

>=

height

||

pw

<

0

||

pw

>=

width)

{

continue;

}

int64_t

pix_idx

=

(ich

*

height

+

ph)

*

width

+

pw;

int64_t

weight_idx

=

((och

*

in_channels

+

ich)

*

ksize

+

kh)

*

ksize

+

kw;

sum

+=

x[pix_idx]

*

weight[weight_idx];

}

}

}

//

add

bias

sum

+=

bias[och];

y[(och

*

height

+

h)

*

width

+

w]

=

sum;

}

}

}

}此函數(shù)的解釋如下所示：輸入--x:輸入圖像。shape=(in_channels,height,width)--weight:權(quán)重因子。shape=(out_channels,in_channels,ksize,ksize)--bias:偏置值。shape=(out_channels)輸出--y:輸出圖像。shape=(out_channels,height,width)參數(shù)：--width:輸入/輸出圖像的寬度--height:輸入/輸出圖像高度--in_channels：輸入圖像的通道數(shù)--out_channels：輸出圖像的通道數(shù)--ksize:內(nèi)核大小每個(gè)輸入/輸出的內(nèi)存布局shape=(...)如表格所示，但floatx[in_channels][height][width];將其視為定義為三維數(shù)組。卷積層的處理是一個(gè)6級(jí)循環(huán)。第一個(gè)三級(jí)循環(huán)確定輸出圖像上的位置，隨后的三級(jí)循環(huán)對(duì)該位置執(zhí)行卷積操作。零填充在第24-26行完成。由于實(shí)際創(chuàng)建零填充輸入圖像是低效的，所以零填充是通過在訪問圖像外部時(shí)不參與乘積之和來實(shí)現(xiàn)的。第31行是卷積過程中的積和運(yùn)算部分，這個(gè)積和運(yùn)算out_channels*height*width*in_channels*ksize*ksize進(jìn)行了兩次。這個(gè)卷積過程的操作數(shù)量非常大，在很多情況下，卷積層支配著卷積神經(jīng)網(wǎng)絡(luò)的執(zhí)行時(shí)間。這就是為什么計(jì)算單元比CPU多的GPU和FPGA更適合處理神經(jīng)網(wǎng)絡(luò)。第37行是偏差處理部分。到目前為止，我還沒有觸及什么是偏差處理，但正如我在這里所寫的那樣，它是一個(gè)簡(jiǎn)單地對(duì)輸出值進(jìn)行偏移的過程。這種偏差處理在輸入通道/內(nèi)核大小(Y,X)循環(huán)之外，因此處理步驟的數(shù)量非常微不足道。運(yùn)算檢查作為對(duì)上一節(jié)創(chuàng)建的函數(shù)運(yùn)行的確認(rèn)，conv2d我們將比較結(jié)果是否足夠接近在PyTorch的C++API(libtorch)上執(zhí)行的卷積計(jì)算。每個(gè)測(cè)試包括以下兩個(gè)步驟。C.驗(yàn)證C/RTL協(xié)同驗(yàn)證1、C驗(yàn)證類似于正常的軟件開發(fā)，gcc只是用通用的編譯器編譯源代碼并檢查結(jié)果。2、C/RTL協(xié)同驗(yàn)證是使用AMD-Xilinx提供的高階綜合工具VitisHLS進(jìn)行驗(yàn)證。對(duì)于此驗(yàn)證，HLS首先將C源代碼轉(zhuǎn)換為VerilogHDL等RTL。然后在Vivado中對(duì)生成的RTL執(zhí)行功能仿真。在這個(gè)邏輯仿真中，將一個(gè)類似于C驗(yàn)證的數(shù)據(jù)序列輸入到創(chuàng)建的電路中，確認(rèn)輸出結(jié)果是否正確。本節(jié)以后的內(nèi)容將以運(yùn)行創(chuàng)建的源代碼的形式進(jìn)行說明。源代碼將在后面發(fā)布。運(yùn)行環(huán)境運(yùn)行環(huán)境面向Linux機(jī)器。不支持Windows/Mac操作系統(tǒng)。此外，由于預(yù)裝gcc版本，該發(fā)行版針對(duì)Ubuntu18.04。難以自行準(zhǔn)備運(yùn)行環(huán)境的朋友，看看就行。需要以下工具。Vivado

2020.2（推薦2019.2）cmake>=3.11cmake比較麻煩，因?yàn)樗枰陌姹颈萢pt等包管理器可以安裝的版本高，但是可以下載預(yù)構(gòu)建的二進(jìn)制文件（cmake--Linux-x86_64.tar.gz）。C.驗(yàn)證測(cè)試代碼/tests/ref/conv2d.cc的使用，我不會(huì)在本文中詳細(xì)介紹，但測(cè)試將是一個(gè)正常的隨機(jī)測(cè)試?？梢园凑找韵虏襟E構(gòu)建代碼。請(qǐng)將-DVIVADO_HLS_ROOT的值相應(yīng)地替換為安裝的Vivado的路徑。$

mkdir

/build$

cd

/build$

cmake

..

-DVIVADO_HLS_ROOT=/tools/Xilinx/Vivado/2022.2$

cmake

--build

.使用以下命令進(jìn)行測(cè)試：如果沒有任何錯(cuò)誤，那它就是成功的。$

ctest

-V

-R

"conv2d_ref"C/RTL協(xié)同驗(yàn)證運(yùn)行以下命令以使用HLS啟動(dòng)C/RTL協(xié)同驗(yàn)證。大約需要5分鐘。$

ctest

-V

-R

"conv2d_hls_cosim"當(dāng)執(zhí)行C/RTL協(xié)同驗(yàn)證時(shí)，會(huì)自動(dòng)創(chuàng)建一個(gè)HLS項(xiàng)目文件，因此可以使用它來檢查高級(jí)綜合和RTL仿真波形的結(jié)果。要檢查這一點(diǎn)，請(qǐng)使用以下命令啟動(dòng)HLS：$

vitis_hls

&HLS打開后，單擊“打開項(xiàng)目”，如下所示，導(dǎo)航到/build/tests/hls/conv2d/conv2d_hls_cosim目錄并單擊“確定”。然后，HLS綜合報(bào)告將顯示如下屏幕所示。從此報(bào)告中，可以看到從PerformanceEstimates列創(chuàng)建的電路的估計(jì)性能，以及從UtilizationEstimates看到在目標(biāo)設(shè)備上實(shí)施時(shí)的估計(jì)資源使用情況。點(diǎn)擊頂部紅框包圍的區(qū)域，可以看到仿