FPGA做CNN說白了就是把卷積神經(jīng)網(wǎng)絡里最耗時的計算部分從GPU或者CPU手里搶過來用硬件邏輯的并行性去硬算。我在這個項目里做的就是在FPGA上實現(xiàn)了一個能對實時視頻流做CNN卷積計算的加速器輸入是普通的攝像頭圖像數(shù)據(jù)輸出是經(jīng)過卷積特征提取后的結果整條鏈路跑在硬件上不依賴上位機。這個項目適合兩類人參考一類是剛接觸FPGA但想往AI方向靠的開發(fā)者另一類是已經(jīng)在用GPU做推理、但被功耗和延遲卡住想看看FPGA方案到底能不能打的算法工程師。我會把整個設計思路、卷積計算的硬件拆分、實時性怎么保證、以及我踩過的坑全部攤開來講盡量讓每個環(huán)節(jié)都能直接抄作業(yè)。1. 項目核心設計思路為什么要用FPGA算卷積1.1 卷積計算的計算特征與硬件匹配分析CNN里的卷積層本質上就是一組乘累加運算。一個3x3的卷積核滑過整張圖像每個輸出像素需要做9次乘法和8次加法再加上偏置和激活函數(shù)。假設輸入是1080p分辨率30幀每秒第一層卷積是3x3x3的核輸出通道64個那一秒鐘的運算量大概是1920乘以1080乘以30乘以9乘以3乘以64算下來接近1000億次乘累加操作。這個量級用CPU做實時基本沒戲GPU能做但功耗和體積在嵌入式場景里往往受不了。FPGA的優(yōu)勢在于它的邏輯資源可以按照數(shù)據(jù)流的形狀去定制硬件結構。卷積運算天然是數(shù)據(jù)并行的——不同輸出像素之間沒有依賴關系不同輸出通道之間也沒有依賴關系。GPU是SIMT架構同一時刻執(zhí)行同一指令遇到分支或者訪存沖突就會浪費計算單元FPGA不一樣我可以把卷積核拆成一組并行的乘累加流水線再用行緩存把圖像數(shù)據(jù)按滑動窗口的方式喂進去每個時鐘周期都能吐出一個有效的輸出結果。這里有一個關鍵認知需要糾正FPGA做CNN并不是去和GPU拼峰值算力而是拼計算效率。GPU的算力很高但數(shù)據(jù)搬運和調度開銷也大FPGA可以為特定的卷積層結構定制數(shù)據(jù)通路數(shù)據(jù)從DDR讀進來之后在片上SRAM里循環(huán)復用盡可能減少對外部存儲的訪問次數(shù)。在我這個項目里片上行緩存的命中率做到90%以上,整體有效算力利用率能拉到60%左右,這在FPGA平臺上已經(jīng)是個相當不錯的數(shù)字了。1.2 軟硬件任務劃分哪些計算放在FPGA哪些留在ARM實際的圖像CNN處理系統(tǒng)往往不是純FPGA單芯片就能搞定的。以Xilinx Zynq系列為例芯片上同時有ARM核和FPGA邏輯。我的方案是把CNN推理的卷積層主體全部下沉到PL端也就是FPGA邏輯部分ARM端只負責三件事一是通過DMA把圖像數(shù)據(jù)從DDR搬到FPGA的行緩存里二是配置卷積核權重和偏置參數(shù)三是處理CNN最后一層輸出的后處理邏輯。任務劃分的核心原則是計算密集型的、數(shù)據(jù)流規(guī)整的操作放在FPGA控制邏輯復雜、分支多、數(shù)據(jù)量小但對靈活性要求高的操作放在ARM。比如卷積、池化、激活函數(shù)這些都是FPGA的強項而像非極大值抑制、目標框解碼、分類結果的softmax這些在FPGA上寫起來很別扭邏輯資源消耗大而且靈活性差留在ARM上跑更合理。我建議在做軟硬件劃分時先用軟件仿真把整個CNN模型的每層耗時跑一遍。比如某個模型一共20層其中卷積層占了95%的耗時那FPGA就把這20層里面計算量最大的15層全部硬件化剩下幾層全連接或者特殊的歸一化層根據(jù)數(shù)據(jù)量大小決定要不要也放進去。我的經(jīng)驗是如果一層的數(shù)據(jù)量小于1MB且計算量小于100萬次乘加就不值得放在FPGA上搬來搬去的開銷比計算本身還大。1.3 技術選型用Verilog手寫還是用HLS高層次綜合這是FPGA做CNN項目里第一個要做的選擇。HLS就是用C/C寫算法邏輯然后工具自動轉換成RTL代碼手寫Verilog則是直接從寄存器傳輸級開始搭。我在這個項目里選擇了Verilog手寫卷積核心但用HLS工具做了一版原型驗證。手寫Verilog的好處是可控性強。卷積計算的數(shù)據(jù)通路每個寄存器在哪一拍打入、每個乘法器和加法器怎么組合我心里都有數(shù)。通過Vivado的分析結果我可以精確控制時序和資源利用率。壞處是開發(fā)周期長尤其是并行優(yōu)化的時候控制信號之間的時序關系很容易搞亂。HLS的好處是開發(fā)效率高算法工程師寫起來沒有心理負擔一個for循環(huán)嵌套就能表達卷積。我在做原型驗證時用Vitis HLS寫了一個基本的卷積函數(shù)加#pragma HLS PIPELINE和UNROLL指令大概一天時間就能跑通功能仿真。但HLS生成的代碼在時序優(yōu)化上經(jīng)常需要反復調指令和約束而且出現(xiàn)問題的時候不好定位debug起來比手寫代碼痛苦得多。給個實操建議如果你做的是工業(yè)級產(chǎn)品、需要長期維護我建議核心卷積模塊手寫Verilog控制邏輯和接口部分可以用HLS快速生成如果只是做算法驗證和學術研究全用HLS就夠了。兩條路我都走過最終項目交付時核心計算模塊用的是手寫VerilogHLS版本作為功能參考留在了仿真環(huán)境里。2. 卷積計算的硬件核心實現(xiàn)從行緩存到乘累加陣列2.1 圖像數(shù)據(jù)的片上緩存策略行緩存與滑動窗口CNN卷積計算在硬件上要解決的第一個問題是圖像數(shù)據(jù)的復用。一個3x3卷積核計算輸出像素時需要用到輸入圖像中3行3列共9個像素。如果每次都從DDR里讀9個像素數(shù)據(jù)帶寬會被迅速打爆。正確的做法是在FPGA的片上SRAM里維護一個行緩存結構。具體做法是這樣的對于3行輸入行緩存用三塊獨立的BRAM塊隨機存取存儲器分別存儲第n行、第n1行、第n2行的數(shù)據(jù)。當計算輸出第n行時數(shù)據(jù)流按列推進每個時鐘周期從三塊BRAM中各讀出一個像素組成一個3x3窗口。窗口在水平方向滑動一個像素后就讀下一列。當整個第n行計算完畢三塊BRAM同時移位丟掉第n行讀入第n3行。整個行緩存的深度只需要等于圖像寬度比如1920個像素。如果圖像是RGB三通道那需要三組這樣的行緩存每組對應一個顏色通道。這樣做的好處是DDR帶寬的壓力被降到了一個很低的水平——每個輸入像素只需要從DDR讀一次之后的所有復用都在片上進行。我實測下來1080p圖像數(shù)據(jù)從DDR搬運到行緩存的帶寬需求只有約200MB/s而DDR3/4的實際可用帶寬通常有幾個GB/s完全不是瓶頸。滑動窗口的具體生成邏輯里還要考慮邊界像素的填充問題。比如卷積核尺寸是3x3在圖像最左邊一列窗口會越界到圖像外面。通常做法是補零或者復制邊緣像素。我在設計里加了一個信號padding_mode通過一個多路選擇器控制窗口邊緣數(shù)據(jù)源的切換支持零填充和邊緣復制兩種策略這樣既適配了常見的CNN模型也為上層算法留了靈活性。2.2 乘累加陣列的并行度設計輸出通道拆分與循環(huán)展開有了窗口數(shù)據(jù)接下來就是卷積計算的核心——乘累加陣列。陣列的規(guī)模直接決定了吞吐量。一個設計原則是用FPGA的DSP切片資源來搭建乘累加單元而不是用邏輯查找表實現(xiàn)乘法和加法。Xilinx 7系列的DSP48E1切片一個就能完成18x25位的乘法和48位的累加速度可以跑到幾百兆赫茲。我用的芯片是Zynq-7045一共900多個DSP切片理論上可以搭建大量乘累加單元。我的設計采用的是輸出通道并行策略。假設輸入通道數(shù)是3輸出通道數(shù)是64我一次同時計算4個輸出通道。這意味著同一時刻我需要從行緩存中讀取3個通道的窗口數(shù)據(jù)分別送入4組乘累加單元組每組內有9個乘法器和8個加法器用于完成一個輸出像素的計算。這樣總的DSP用量是4乘以9等于36個每個時鐘周期可以產(chǎn)生4個輸出像素值。這里有一個關于循環(huán)拆分的技巧。傳統(tǒng)的卷積實現(xiàn)是遍歷輸出通道、遍歷輸入行、遍歷輸入列、遍歷輸入通道、遍歷卷積核行、遍歷卷積核列六重循環(huán)。在硬件上我需要把這六重循環(huán)中的一部分展開成并行結構。我的經(jīng)驗是把輸出通道循環(huán)展開把輸入通道和卷積核尺寸循環(huán)合并成一個串行累加過程。展開哪個維度、串行哪個維度要根據(jù)DSP資源和數(shù)據(jù)復用率來選擇。如果并行度太高比如一次計算16個輸出通道雖然吞吐量上去了但BRAM的端口數(shù)量可能不夠用。我的行緩存是三通道同時讀BRAM的讀寫端口是有限的當并行輸出通道數(shù)超過BRAM端口能提供的數(shù)據(jù)帶寬時就得做數(shù)據(jù)復制這又會增加資源消耗。所以并行度是一個需要整體權衡的指標不能一味往大了選。我這個項目里4輸出通道并行、3輸入通道同時讀取、9個窗口位置并行計算組合起來是36個乘法器同時工作已經(jīng)完全滿足了1080p30fps的實時要求。2.3 定點數(shù)據(jù)格式與精度分析卷積計算的乘法累加結果需要存儲在特定的數(shù)據(jù)格式里。GPU上跑CNN多用FP32浮點但在FPGA上浮點計算消耗的資源大約是定點的4到5倍。為了節(jié)省資源提高頻率我選擇了INT16定點格式作為主要的存儲格式乘法過程中使用INT16乘以INT8的混合精度。權重我用INT8量化輸入特征圖也用INT8表示但累加器用INT32。原因很簡單兩個8位定點數(shù)相乘結果是16位多個16位結果累加過程中可能溢出到32位所以累加器至少要32位。最后經(jīng)過ReLU激活函數(shù)之前再從INT32截斷回INT16。這個截斷可以用算術右移實現(xiàn)我通過一個scale參數(shù)來控制右移位數(shù)這個scale是在訓練后量化階段標定出來的。很多第一次做FPGA CNN的人會擔心定點化以后精度下降太大。我的實際測試結論是在圖像分類這種任務上INT8量化后Top-1精度損失通常小于0.5%比如在ImageNet上從72.4%降到72.0%左右在目標檢測任務上mAP損失會在1到2個點之間。如果任務對精度特別敏感可以考慮INT16甚至混合精度——但代價是DSP資源翻倍。我踩過一個坑量化時只關注了權重的量化誤差忽略了特征圖的動態(tài)范圍。實際上CNN的中間層特征圖分布差異很大有的層數(shù)值集中在0附近有的層數(shù)值跨度很大用同一個scale值可能讓某一層嚴重失真。我的解決方案是在量化階段逐層統(tǒng)計特征圖的數(shù)值分布為每一層單獨確定scale參數(shù)硬件上為每層配置一個scale寄存器在層切換時更新即可。這塊工作量說大不大但能明顯改善量化后的精度值得認真做。2.4 池化層與激活函數(shù)的硬件化CNN里卷積層之后通常跟著池化層和激活函數(shù)。池化有最大池化和平均池化兩種硬件實現(xiàn)都不復雜。最大池化就是在2x2窗口里取最大值我用4個寄存器暫存一個2x2區(qū)域的像素再用比較器樹分兩級比較得出最大值平均池化則是4個值相加右移2位更簡單。激活函數(shù)我用的是ReLU判斷最高符號位如果是負數(shù)就輸出0正數(shù)就直接透傳。整個邏輯只需要一個多路選擇器加一個符號位判斷一個LUT就能搞定。如果要實現(xiàn)LeakyReLU或者Swish這類更復雜的激活函數(shù)在FPGA上就麻煩一些。LeakyReLU需要乘一個小系數(shù)可以用一個DSP切片Swish需要計算sigmoid這個在FPGA上一般用查找表加分段線性逼近來做開銷會增加不少。我的建議是在設計CNN模型時優(yōu)先選擇ReLU系列激活函數(shù)不僅訓練簡單硬件實現(xiàn)也幾乎是零成本。如果必須用復雜激活函數(shù)盡量放在CPU上處理只在最后幾層用不要在卷積層中間插入太多非線性變換。3. 實時性系統(tǒng)設計與性能優(yōu)化3.1 實時性指標計算與數(shù)據(jù)流規(guī)劃實時性是這個項目的硬指標。我設定的目標是輸入1080p30fps的YUV420圖像整個CNN處理鏈路達到30幀每秒的吞吐率。這意味著每一幀圖像的處理時間必須小于33毫秒。我設計的數(shù)據(jù)流是這樣的DMA從DDR讀取一幀2560x1440的原始圖像數(shù)據(jù)經(jīng)過格式轉換模塊把YUV轉為RGB這一步用流水線加法器和乘法器實現(xiàn)然后送入卷積計算模塊。卷積模塊按行處理每次處理3行窗口輸出一路特征圖。整個過程采用幀級并行流水線——當DMA在搬運第N1幀時卷積模塊正在計算第N幀而后處理模塊正在處理第N-1幀三級流水同時工作每幀的實際處理時間取決于最慢的一級。卷積模塊本身的處理延時是主要瓶頸。即使主頻跑到200MHz每個時鐘周期輸出4個像素一幀1920x1080的圖像需要1920乘以1080除以4約52萬個時鐘周期也就是2.6毫秒。再加上多層卷積串行的累計延時單幀處理時間可以控制在20毫秒以內。33毫秒的預算其實是留了充足余量的。實際規(guī)劃數(shù)據(jù)流時要注意一個容易忽略的點卷積層的輸出特征圖分辨率。很多CNN為了提高精度會在中間層做二分之一或四分之一下采樣特征圖變小了但通道數(shù)變多了。通道數(shù)增加對FPGA的處理能力提出了新要求。我的方案是在特征圖分辨率較小、單層計算量相對減少的情況下可以通過時分復用機制讓同一組乘累加單元分時處理不同的輸出通道提高DSP的利用率。3.2 乒乓緩存與DMA搬運的時序協(xié)同實時系統(tǒng)里最大的坑是數(shù)據(jù)斷流。一旦DDR數(shù)據(jù)搬運跟不上卷積模塊的消費速度整個流水線就會空轉幀率直接跳水。我的解決方法是乒乓緩存。乒乓緩存的意思是把片上的幀緩存分成兩個區(qū)當一個區(qū)在被DMA寫入新數(shù)據(jù)時卷積模塊從另一個區(qū)讀取數(shù)據(jù)。當DMA寫滿一個區(qū)、卷積模塊讀完另一個區(qū)兩個區(qū)進行切換。這樣避免了讀寫同一塊存儲時的仲裁沖突。DMA的搬運和卷積的讀操作在時間上是重疊的數(shù)據(jù)流可以保持連續(xù)不間斷。DMA搬運本身也要做精心的調度。我的做法是使用Xilinx的AXI DMA IP核配置為Scatter-Gather模式把一幀圖像分成多個512字節(jié)的描述符每個描述符指定一段連續(xù)的物理地址。DMA會連續(xù)搬運整個描述符鏈表搬運完成時產(chǎn)生中斷通知ARM核ARM核對下一個描述符鏈表進行重新配置。這樣的好處是DMA連續(xù)工作不需要每次搬運都重新啟動。實操中的時序協(xié)同經(jīng)驗需要讓DMA的突發(fā)傳輸長度匹配DDR的頁大小。比如DDR3的頁大小是8KB突發(fā)傳輸配置為16個256bit的數(shù)據(jù)正好能湊滿一個頁。這樣讀寫DDR時的效率最高不會因為頻繁換行造成額外的懲罰周期。這個細節(jié)我當時是看了Vivado的寄存器讀寫統(tǒng)計才發(fā)現(xiàn)的之前傳輸效率一直上不去后來改成頁大小對齊后帶寬直接提升了30%。3.3 時序約束與關鍵路徑優(yōu)化FPGA設計的最后一步是時序收斂。CNN卷積模塊因為乘累加鏈比較長關鍵路徑往往出現(xiàn)在兩個地方一個是行緩存到乘累加陣列的組合邏輯路徑另一個是累加器鏈上多個DSP串行級聯(lián)的路徑。對于行緩存到乘累加的路徑我的優(yōu)化方法是插入寄存器打拍。行緩存輸出的數(shù)據(jù)經(jīng)過對齊以后先存入寄存器再進入乘法器。這樣一來BRAM的輸出到DSP的輸入就是寄存器到寄存器的路徑布線壓力小很多。代價是增加了一個時鐘周期的延遲但卷積計算是流水線的一個周期的額外延遲完全無所謂。對于累加器鏈問題在于多個DSP級聯(lián)時前一個DSP的輸出直接作為后一個DSP的輸入路徑很長。我的做法是用DSP的DSP48E1內部級聯(lián)功能通過CASCADEIN/CASCAEOUT端口把多個DSP串起來這樣累加過程在DSP內部完成不走通用布線資源延遲可以大幅降低。在Vivado里做約束的時候我建議給卷積核心模塊單獨設置時鐘。如果整個系統(tǒng)只有一個200MHz時鐘卷積模塊、DMA、DDR控制器共用一個時鐘域任何一處時序不收斂都會導致整個設計失敗。更穩(wěn)妥的做法是用PLL生成兩個時鐘一個150MHz給 DDR和DMA使用一個200MHz給卷積核心使用中間通過異步FIFO做跨時鐘域數(shù)據(jù)交換。這樣可以分別優(yōu)化各自的時序收斂的難度會降低不少。3.4 系統(tǒng)級驗證從仿真到板級調試驗證是整個項目里最磨人的階段我把它分成三個層次。第一層是功能仿真用Vivado自帶的仿真器驗證卷積模塊的RTL邏輯是否正確。我準備了兩種測試激勵一種是用C模型生成的隨機數(shù)據(jù)作為輸入比對硬件計算結果和軟件仿真結果是否一致另一種是用PyTorch跑通一個真實的小模型把每一層的輸出導出成二進制文件作為硬件仿真里的參考數(shù)據(jù)。第二層是邏輯綜合加時序仿真。綜合完成后看資源利用率和時序報告確認工作頻率能達到設計要求。時序仿真是帶布線延遲的仿真比功能仿真更接近真實情況。這個階段最容易發(fā)現(xiàn)的問題是復位信號的時序問題——異步復位信號如果有毛刺會導致寄存器進入未知狀態(tài)系統(tǒng)里檢測邏輯經(jīng)常在這種階段出錯。第三層是板級調試。我一直用ILA集成邏輯分析儀作為主要的調試手段。在關鍵信號上插入探針比如行緩存的控制狀態(tài)機、乒乓緩存的切換信號、DMA的搬運完成中斷。有一次在板子上發(fā)現(xiàn)輸出的圖像有規(guī)律性的條紋用ILA抓取數(shù)據(jù)后發(fā)現(xiàn)是行緩存切換時讀地址延遲了一個周期導致行數(shù)據(jù)錯位。這個bug在仿真里不好復現(xiàn)因為仿真用的是理想時鐘真實板子的時鐘相位噪聲會暴露這類問題。板級調試還要注意電源的穩(wěn)定性。CNN計算全速運行的時候FPGA內核電壓的電流需求會突然增大如果電源的紋波過大可能導致DSP單元的計算結果出錯。我給核心電壓加了幾個大容量去耦電容并且用示波器確認了動態(tài)壓降在50mV以內才敢放心跑全速。4. 常見問題與排查技巧實錄4.1 數(shù)據(jù)路徑問題圖像花屏、錯位、顏色混亂這類問題在FPGA圖像處理項目里幾乎必然遇到。我經(jīng)歷過的主要有幾種現(xiàn)象對應不同的根因問題現(xiàn)象圖像顯示錯位水平方向隔一段就有一條錯開的線。大概率是行緩存讀地址或DMA搬運的突發(fā)長度與圖像寬度不匹配。比如圖像寬度是1920像素但DMA搬一次突發(fā)傳輸了2048像素多出來的128像素會導致后續(xù)行數(shù)據(jù)錯開。解決辦法是在DMA描述符里精確配置圖像的線性緩沖長度并逐行對齊。問題現(xiàn)象顏色通道錯亂紅的變藍、藍的變綠。這是YUV422或YUV420轉RGB時的采樣位置沒對齊導致的。YUV420的UV分量分辨率只有Y的一半UV采樣位置錯一個像素就會導致整個畫面顏色偏掉。我寫了一個專門的測試圖樣比如純紅、純綠、純藍的色塊逐塊確認轉換結果。問題現(xiàn)象圖像閃爍或偶發(fā)花屏。這類隨機性問題先查DMA的地址連續(xù)性和DDR的訪問沖突。我在DMA中斷處理里加入了幀計數(shù)和地址回讀確認每一幀的搬運源地址和預期一致。另一個常見原因是DDR控制器的刷新周期和DMA的實時帶寬要求沖突調整DDR控制器的仲裁策略可以緩解。4.2 時序收斂問題關鍵路徑超時和布局布線的博弈Vivado的時序報告經(jīng)常讓人頭大。報紅色的路徑可能長達幾十納秒遠超時鐘周期。我的經(jīng)驗是先看報告里是哪一段路徑再決定處理方式。如果關鍵路徑是LUT到LUT的組合邏輯通常是因為邏輯層級太深。比如計算窗口均值時累加器鏈超過了5級就要考慮改用DSP切片或者重新做運算樹的平衡。乘累加陣列的求和樹我一般用4輸入加法器構成平衡樹而非簡單的串行加法這樣邏輯深度從9級降到3級。如果是DSP到BRAM的路徑超時可能是數(shù)據(jù)位寬太大導致布線延遲增加。比如累加結果是32位但BRAM輸入只需要16位就應該在數(shù)據(jù)寫入BRAM之前做截斷寄存避免大位寬信號走太遠。另外值得一提的是Vivado的物理綜合選項比如phys_opt_design的INSERT_SLL選項有時候效果奇好用一下可能直接讓時序過線。4.3 資源沖突問題BRAM和DSP的合理分配FPGA里的BRAM和DSP數(shù)量有限設計過程中經(jīng)常出現(xiàn)資源不夠或者利用率極低的情況。我的建議是先用綜合報告看各個模塊的資源消耗找出最吃資源的模塊。BRAM資源不夠的常見原因是緩存圖像數(shù)據(jù)的行緩存過深。比如4K分辨率的行緩存每行3840像素16bit寬度三個通道再加雙緩沖需要的內存就非?？捎^。如果芯片BRAM不夠用可以把行緩存改小用分塊處理的方法比如把圖像分成上下兩個半幀分別卷積再拼接結果。DSP資源不夠的時候優(yōu)先檢查有沒有在不需要的地方用了乘法器。比如計算卷積結果使用了乘法器的同時如果某個控制信號的計算也用了乘法器就會出現(xiàn)浪費?？刂菩盘柕某朔梢愿挠靡莆患臃ǖ男问焦?jié)省DSP給真正的卷積計算。4.4 實現(xiàn)精度和實測性能的對賬方法最后養(yǎng)成一個習慣每個版本都能對照實測結果和理論預測的差距。如果實測幀率比理論值低很多先從數(shù)據(jù)斷流找原因如果實測功耗比預測值高很多先從數(shù)據(jù)翻轉率找原因。我在完成當前版本后對著Vivado的報告把整體項目的資源利用率、DSP利用率、BRAM利用率、時鐘頻率、整幀處理時延記錄在一張表里方便后期做性能基準和版本對比。5. 項目優(yōu)化過程和后續(xù)演進方向5.1 第一版到第三版的性能迭代記錄這個項目我一共經(jīng)歷了三版大的迭代。第一版用HLS快速原型主頻能跑到150MHz處理1080p30fps勉強夠但資源利用率很高DSP幾乎占滿沒有留下任何余量。第二版換成手寫Verilog重構核心模塊主頻提升到180MHzDSP利用率降到60%并且加入了乒乓緩存和DMA分塊搬運數(shù)據(jù)流順暢了很多。第三版進一步優(yōu)化了累加器樹的邏輯深度和BRAM的使用策略主頻穩(wěn)定在200MHz整幀處理時間控制在15毫秒以內已經(jīng)完全滿足實時性要求。每一次迭代我都會更新一個性能對比表把主頻、資源、幀率、功耗的記錄保存下來。這樣后期如果要換芯片做國產(chǎn)化替代也可以直接參考這些數(shù)據(jù)。5.2 從單模型到多模型模型切換與動態(tài)配置項目后期的一個新需求是同一個硬件平臺支持多個CNN模型切換。比如一個模型做圖像分類一個模型做物體檢測系統(tǒng)根據(jù)應用場景動態(tài)加載對應模型。硬件上卷積模塊本身是通用的切換模型只需要更新權重存儲器的內容。我在DDR里劃分了一個模型區(qū)ARM啟動時把模型文件解析成權重二進制通過DMA寫到FPGA的權重BRAM中。整個模型切換時間控制在200毫秒以內不影響業(yè)務邏輯的實時性。權重存儲是個容易被忽略的細節(jié)。一個典型的CNN模型5層卷積的權重可能有幾十MBFPGA片上BRAM放不下只能放在DDR。我的做法是把權重也按行緩存的思路組織卷積計算到某一層時才把該層權重從DDR預取到片上權重緩存中。這樣既保證了計算連續(xù)性又不浪費BRAM資源。5.3 關于后續(xù)可以嘗試的新方向如果繼續(xù)往深處做我建議關注這幾個方向一是模型壓縮配合硬件設計比如對權重做剪枝后硬件的計算和存儲都能進一步節(jié)省二是嘗試更先進的封裝架構比如把多個FPGA組成集群做更大模型的并行推理三是在FPGA上集成更多AI算子比如目前CNN中常見的卷積層之外的注意力機制和Transformer模塊。FPGA的優(yōu)勢在于靈活自定義這些新方向的硬件化實現(xiàn)都是可以持續(xù)深挖的課題。說句實在話FPGA做CNN并不輕松比起調包調參的軟件玩法它的每個細節(jié)都需要硬件工程師親自打磨。但當你看到攝像頭拍進來的畫面經(jīng)過自己寫的硬件管線實時輸出識別結果的那一刻那種成就感是純粹的軟件實現(xiàn)給不了的。如果這個項目讓你對FPGA加速深度學習產(chǎn)生了興趣建議先從一個最簡單的單層卷積開始把行緩存和乘累加陣列調通再逐步加層、加優(yōu)化這條路走下來收獲會非常大。