FPGA和CPU一直是雷達信號處理不可分割的組成部分。傳統上FPGA用于前端處理，CPU用于后端處理。隨著雷達系統的處理能力越來越強，越來越復雜，對信息處理的需求也急劇增長。為此，FPGA不斷在提高處理能力和吞吐量，CPU也在發展以滿足下一代雷達的信號處理性能需求。這種努力發展的趨勢導致越來越多的使用CPU加速器，如圖形處理單元（GPU）等，以支持較重的處理負載。

本文對比了FPGA和GPU浮點性能和設計流程。最近幾年，GPU已經不僅能完成圖形處理功能，而且成為強大的浮點處理平臺，被稱之為GP-GPU，具有很高的峰值FLOP指標。FPGA傳統上用于定點數字信號處理器（DSP），而現在足以競爭完成浮點處理功能，也成為后端雷達處理加速功能的有力競爭者。

在FPGA前端，40 nm和28 nm均報道了很多可驗證的浮點基準測試結果。Altera的下一代高性能FPGA將采用Intel的14 nm三柵極技術，性能至少達到5 TFLOP.使用這種先進的半導體工藝，性能可實現100 GFLOPs/W.而且，Altera FPGA現在支持OpenCL，這是GPU使用的一款優秀的編程語言。

峰值GFLOPS指標

目前的FPGA性能可達到1TFLOP以上峰值，AMD和Nvidia最新的GPU甚至更高，接近4 TFLOP.但在某些應用中，峰值GFLOP，即TFLOP，提供的器件性能信息有限。它只表示了每秒能完成的理論浮點加法或乘法總數。這一分析表示，在雷達應用中，很多情況下，FPGA在算法和數據規模上超過了GPU吞吐量。

一種中等復雜且常用的算法是快速傅里葉變換（FFT）。大部分雷達系統由于在頻域完成大量處理工作，因此會經常用到FFT算法。例如，使用單精度浮點處理實現一個4，096點FFT.它能在每個時鐘周期輸入輸出四個復數采樣。每個FFT內核運行速度超過80 GFLOP，大容量28 nm FPGA的資源支持實現7個此類內核。

但如圖1所示，該FPGA的FFT算法接近400 GFLOP.這一結果基于“按鍵式”OpenCL編譯，無需FPGA專業知識。使用邏輯鎖定和設計空間管理器（DSE）進行優化，7內核設計接近單內核設計的fMAX，使用28 nm FPGA，將其提升至500 GFLOP，超過了10 GFLOPs/W.

圖1.Stratix V 5SGSD8 FPGA浮點FFT性能

這一GFLOPs/W結果要比CPU或者GPU功效高很多。對比GPU，GPU在這些FFT長度上效率并不高，因此沒有進行基準測試。當FFT長度達到幾十萬個點時，GPU效率才比較高，能夠為CPU提供有效的加速功能。但是，雷達處理應用一般是長度較短的FFT，FFT長度通常在512至8，192之間。

總之，實際的GFLOP一般只達到峰值或者理論GFLOP的一小部分。出于這一原因，更好的方法是采用算法來對比性能，這種算法能夠合理的表示典型應用的特性。隨著基準測試算法復雜度的提高，其更能代表實際雷達系統性能。

算法基準測試

相比依靠供應商的峰值GFLOP指標來驅動處理技術決策，另一方法是使用比較復雜的第三方評估?？諘r自適應處理（STAP）雷達常用的算法是Cholesky分解。這一算法經常用于線性代數，高效的解出多個方程，可以用在相關矩陣上。

Cholesky算法在數值上非常復雜，要獲得合理的結果總是要求浮點數值表示。計算需求與N3成正比，N是矩陣維度，因此，一般對處理要求很高。雷達系統一般是實時工作，因此，要求有較高的吞吐量。結果取決于矩陣大小以及所要求的矩陣處理吞吐量，通常會超過100 GFLOP.

表1顯示了基于Nvidia GPU指標1.35 TFLOP的基準測試結果，使用了各種庫，以及Xilinx Virtex6 XC6VSX475T，其密度達到475K LC，這種FPGA針對DSP處理進行了優化。用于Cholesky基準測試時，這些器件在密度上與Altera FPGA相似。LAPACK和MAGMA是商用庫，而GPU GFLOP則是采用田納西州大學開發的OpenCL實現的（2）。對于小規模矩陣，后者更優化一些。

表1.GPU和Xilinx FPGA Cholesky基準測試（2）

Altera測試了容量中等的Altera Stratix？V FPGA（460K邏輯單元（LE）），使用了單精度浮點處理的Cholesky算法。如表2所示，在Stratix V FPGA上進行Cholesky算法的性能要比Xilinx結果高很多。Altera基準測試還包括QR分解，這是不太復雜的另一矩陣處理算法。Altera以可參數賦值內核的形式提供Cholesky和QRD算法。

表2.Altera FPGA Cholesky和QR基準測試

應指出，基準測試的矩陣大小并不相同。田納西州大學的結果來自［512×512］的矩陣，而Altera基準測試的Cholesky是［360x360］，QRD則高達［450x450］。原因是，矩陣規模較小時，GPU效率非常低，因此，在這些應用中，不應該使用它們來加速CPU.作為對比，在規模較小的矩陣時，FPGA的工作效率非常高。雷達系統對吞吐量的要求很高，每秒數千個矩陣，因此，效率非常關鍵。采用了小矩陣，甚至要求把大矩陣分解成小矩陣以便進行處理。

而且，Altera基準測試是基于每個Cholesky內核的。每個可參數賦值的Cholesky內核支持選擇矩陣大小，矢量大小和通道數量。矢量大小大致決定了FPGA資源。較大的［360×360］矩陣使用了較長的矢量，支持FPGA中實現一個內核，達到91 GFLOP.較小的［60×60］矩陣使用的資源更少，因此，可以實現兩個內核，總共是2×42 = 84 GFLOP.最小的［30×30］矩陣支持實現三個內核，總共是3×25 = 75 GFLOP.

FPGA看起來更適合解決數據規模較小的問題，很多雷達系統都是這種情況。GPU之所以效率低，是因為計算負載隨N3而增大，數據I/O隨N2增大，最終，隨著數據的增加，GPU的I/O瓶頸不再是問題。此外，隨著矩陣規模的增大，由于每個矩陣的處理量增大，矩陣每秒吞吐量會大幅度下降。在某些點，吞吐量變得非常低，以至于無法滿足雷達系統的實時要求。

對于FFT，計算負載增加至N log2 N，而數據I/O隨N增大而增大。對于規模較大的數據，GPU是高效的計算引擎。作為對比，對于所有規模的數據，FPGA都是高效的計算引擎，更適合大部分雷達應用，這些應用中，FFT長度適中，但是吞吐量很大。

GPU和FPGA設計方法

GPU可以通過使用Nvidia專用CUDA語言或開放標準OpenCL語言來編程。這些語言在能力上非常相似，最大的不同在于CUDA只能用在Nvidia GPU上。

FPGA通常使用HDL語言Verilog或VHDL進行編程。這些語言的最新版雖然采用了浮點數定義，但都不太適合支持浮點設計。例如，在System Verilog中，短實數變量對應于IEEE單精度（浮點），實數變量對應于IEEE雙精度。

DSP Builder高級模塊庫

使用傳統的方法將浮點數據通路綜合到FPGA的效率非常低，如Xilinx FPGA在Cholesky算法上使用了Xilinx浮點內核產生函數的低性能顯示，。而Altera采兩種不同的方法。首先是使用DSP Builder高級模塊庫，這是基于Mathworks的設計輸入方法。這一工具支持定點和浮點數，支持7種不同精度的浮點處理，包括IEEE半、單和雙精度實現。它還支持矢量化，這是高效實現線性代數所需要的。最重要的是，它能夠將浮點電路高效的映射到目前的定點FPGA體系結構中，如基準測試所示，規模中等的28 nm FPGA，Cholesky算法接近了100 GFLOP.作為對比，在不具有綜合能力的規模相似的Xilinx FPGA上，實現Cholesky相同算法，性能只有20 GFLOP.

面向FPGA的OpenCL

GPU編程人員較為熟悉OpenCL.面向FPGA的OpenCL編譯意味著，面向AMD或Nvidia GPU編寫的OpenCL代碼可以編譯到FPGA中。而且，Altera的OpenCL編譯器支持GPU程序使用FPGA，無需具備典型的FPGA設計技巧。

使用支持FPGA的OpenCL，相對于GPU有幾個關鍵優勢。首先，GPU的I/O是有限制的。所有輸入和輸出數據必須由主CPU通過PCI Express？（PCIe？）接口進行傳輸。結果延時會讓GPU處理引擎暫停，因此，降低了性能。

面向FPGA的OpenCL擴展

FPGA以各種寬帶I/O功能而知名。這些功能支持數據通過千兆以太網（GbE）和Serial RapidIO？（SRIO），或直接從模數轉換器（ADC）和數模轉換器（DAC）輸入輸出FPGA.Altera定義了OpenCL標準的供應商專用擴展，以支持流操作。這種擴展對于雷達系統非常關鍵，數據能夠從定點前端波束成形直接輸出，支持浮點處理階段的數字下變頻處理，實現脈沖壓縮，多普勒，STAP，動目標顯示（MTI），以及圖2所示的其他功能。通過這種方法，數據流在通過GPU加速器之前，避免了CPU瓶頸問題，從而降低了總處理延時。

圖2.通用雷達信號處理圖

即使與I/O瓶頸無關，FPGA的處理延時也要比GPU低很多。眾所周知，GPU必須有數千個線程才能高效工作，這是由于存儲器讀取很長的延時，以及GPU大量的處理內核之間的延時。實際上，GPU必須有很多任務才能使得處理內核不會暫停等待數據，否則會導致任務很長的延時。

而FPGA使用了“粗粒度并行”體系結構。它建立了多個經過優化的并行數據通路，每一通路在每個時鐘周期輸出一個結果。數據通路的例化數取決于FPGA資源，但一般要比GPU內核數少很多。但是，每一數據通路例化的吞吐量要比GPU內核高得多。這一方法的主要優勢是低延時，這在很多應用中都是關鍵的性能優勢。

FPGA的另一優勢是很低的功耗，極大的降低了GFLOPs/W.使用開發板測量FPGA功耗，表明Cholesky和QRD等算法是5-6 GFLOPs/W，而FFT等簡單算法則是10 GFLOPs/W.一般很難進行GPU能效測量，但是，Cholesky的GPU性能達到50 GFLOP，典型功耗是200 W，得到的結果是0.25 GFLOPs/W，單位FLOP的功率比FPGA高20倍。

對于機載或車載雷達裝備，系統體積、重量和功耗（SWaP）都非常重要。在未來的系統中，雷達工作很容易達到數十個TFLOP.總處理能力與現代雷達系統的分辨率和覆蓋范圍相關。

融合數據通路

OpenCL和DSP Builder都依靠“融合數據通路”這種技術（圖3），以這種技術實現浮點處理，能大幅度減少桶形移位電路，支持使用FPGA開發大規模高性能浮點設計。

圖3.采用融合數據通路實現浮點處理

為降低桶形移位頻率，綜合過程盡可能使用較大的尾數寬度，從而不需要頻率歸一化和去歸一化。27×27和36×36硬核乘法器支持比單精度實現所要求的23位更大的乘法計算，54×54和72×72結構的乘法器支持比52位更大的雙精度計算，這通常是雙精度實現所要求的。FPGA邏輯已經針對大規模定點加法器電路進行了優化，包括了內置進位超前電路。

當需要進行歸一化和去歸一化時，另一種可以避免低性能和過度布線的方法是使用乘法器。對于一個24位單精度尾數（包括符號位），24×24乘法器通過乘以2n對輸入移位。27×27和36×36硬核乘法器支持單精度擴展尾數，可以用于構建雙精度乘法器。

在很多線性代數算法中，矢量點乘是占用大量FLOP的底層運算。單精度實現長度是64的長矢量點乘需要64個浮點乘法器，以及隨后由63個浮點加法器構成的加法樹。這類實現需要很多桶形移位電路。

相反，可以對64個乘法器的輸出進行去歸一化，成為公共指數，最大是64位指數?？梢允褂枚c加法器電路對這些64路輸出求和，在加法樹的最后進行最終的歸一化。如圖4所示，這一本地模塊浮點處理過程省掉了每一加法器所需要的中間歸一化和去歸一化。即使是IEEE 754浮點處理，最大指數決定了最終的指數，因此，這種改變只是在計算早期進行指數調整。

圖4.矢量點乘優化

但進行信號處理時，在計算最后盡可能以高精度來截斷結果才能獲得最佳結果。這種方法傳遞除單精度浮點處理所需要尾數位寬之外的額外的尾數位寬，一般從27位到36位補償了單精度浮點處理所需要的早期去歸一化這種次優方法，。采用浮點乘法器進行尾數擴展，因此，在每一步消除了對乘積進行歸一化的要求。

這一方法每個時鐘周期也會產生一個結果。GPU體系結構可以并行產生所有浮點乘法，但不能高效并行進行加法。原因是因為不同的內核必須通過本地存儲器傳輸數據實現通信，因此缺乏FPGA架構的連接的靈活特性。

融合數據通路方法產生的結果比傳統IEEE 754浮點結果更加精確，如表3所示。

表3.Cholesky分解準確性（單精度）

使用Cholesky分解算法，實現大規模矩陣求逆，獲得了這些結果。相同的算法以三種不同的方法實現：

n在MATLAB/Simulink中，采用IEEE 754單精度浮點處理。

n在RTL單精度浮點處理中，使用融合數據通路方法。

n在MATLAB中，采用雙精度浮點處理。

雙精度實現要比單精度實現精度高十億倍（10的9次方）。

MATLAB單精度誤差、RTL單精度誤差和MATLAB雙精度誤差對比確認了融合數據通路方法的完整性。采用了這一方法來獲得輸出矩陣中所有復數元素的歸一化誤差以及矩陣元素的最大誤差。使用Frobenius范數計算了總誤差：

由于范數包括了所有元素的誤差，因此比單一誤差大很多。

此外，DSP Builder高級模塊庫和OpenCL工具流程都針對下一代FPGA體系結構，支持并優化目前的設計。由于體系結構創新和工藝技術創新，性能可以達到100峰值GFLOPs/W.

結論

高性能雷達系統現在有新的處理平臺選擇。除了更好的SWaP，與基于處理器的解決方案相比，FPGA能提供低延時和高GFLOP.隨著下一代高性能計算優化FPGA的推出，這種優勢會更明顯。

Altera的OpenCL編譯器為GPU編程人員提供了幾乎無縫的通路來評估這一新處理體系結構的指標。Altera OpenCL符合1.2規范，提供全面的數學庫支持。它解決了傳統FPGA遇到的時序收斂、DDR存儲器管理以及PCIe主處理器接口等難題。

對于非GPU開發人員，Altera提供DSP Builder高級模塊庫工具流程，支持開發人員開發高fMAX定點或浮點DSP設計，同時保持基于Mathworks的仿真和開發環境的優點。使用FPGA的雷達開發人員多年以來一直使用該產品，實現更高效的工作流程和仿真，其fMAX性能與手動編碼HDL相同。

審核編輯：湯梓紅