基于DSP的雷達信號處理模塊化設計研究

廉志玲

（中國電子科技集團第三十八研究所，安徽 合肥230031）

0 引言

當前，基于雷達的高數據率以及算法的復雜性，從IO平衡以及設備量的角度考慮，工程上雷達信號處理普遍采用專用芯片（DSP）來實現。

一方面，DSP有多個鏈路口可以以很高的數據率與外界通信；另一方面，通過專用的FFT，IFFT算法和電路設計，其進行雷達信號處理的效率和精度都要高于普通的計算機和處理器。從軟件編程的角度考慮，采用DSP芯片可以采用匯編和C語言混合編成，提高程序的運行效率，充分利用多核的優勢。

DSP處理架構雖然滿足了當前的處理要求，也給DSP的軟件開發人員帶來了很多的煩惱。這些煩惱有些是硬件帶來的，也有一些是軟件帶來的。以ADI的芯片為例，從開始的21160芯片，到后面的Ts201芯片，不僅芯片的架構發生了變化，整個匯編指令集也發生了變化，這意味著DSP的編程人員需要重新學習或者培訓，缺乏繼承性。

本文從一名軟件編程人員的角度，對雷達信號處理的參數化，模塊化設計存在的問題以及模塊化的實現方面，提出了自己的觀點和看法。

1 雷達信號處理的特點

一方面，雷達信號處理的數據率高，算法復雜；另一方面，一定時期內，雷達信號處理的算法相對穩定，這就為我們進行模塊化設計提供了依據。以最常見的脈沖多普勒雷達為例，典型的處理流程如下所示：

雖然不同的雷達的信號處理的流程和算法有所不同，但是某些模塊比如：DBF(數字波束形成),脈沖壓縮，濾波，恒虛警檢測，解距離/速度模糊，測角，以及距離凝聚，方位凝聚等等，卻是大部分體制的雷達所共有的。

2 雷達信號處理常見的約束條件

從上面的流程上看，理論上不同的雷達基本可以采用相同的處理架構和處理算法，但實際工程中，則遠非如此。原因除了軟件編程和管理的效率不高之外，還有個問題就是，不同的雷達的系統參數，硬件約束都不盡相同。

從硬件約束的角度講，某些雷達尤其是機載和星載雷達，其對雷達信號處理系統的重量，體積和功耗都有要求。這種情況就需要專門設計，盡量挖掘硬件的潛力，充分或盡量采用硬件(FPGA)來完成DBF，脈沖壓縮等功能。此時，若DBF和脈壓模塊是通用的，參數化的，將大大減少工作量，提高工作效率。

從系統參數的角度講，不同雷達或者同一雷達的不同模式的參數區別主要有：信號波形，信號帶寬，采樣率，波束個數，脈沖重復頻率(prf),發射信號的時寬，脈沖個數，以及對信號處理算法的要求等，這些參數的約束體現在雷達信號數據率和數據量，以及信號處理算法上。

3 信號處理模塊化設計的若干想法

3.1 采用C和匯編混合編程

如我們前面所說，不同公司的芯片或者同一芯片公司的不同系列的處理器，其匯編指令集是不兼容的。也就是說，即使我花費了巨大的人力，物力和財力，開發了自己的匯編指令庫，實現了底層模塊的通用化，參數化，當我們采用更高一級的處理器時，所有的這些庫函數都變的毫無用處，需要從零開始。

如果我們采用高級語言如C，由于有統一的國際標準，且與底層硬件關系不大，有更好的可維護性和可移植性,缺點是很難發揮多核處理的優勢，效率不高。匯編語言雖然效率高，但是開發時間長，修改和維護都比較困難。考慮到兩者的優缺點，采用C語言搭建處理框架，匯編完成運算量較大的子函數，這個當前大多數項目已經做到。

3.2 參數化設計

參數的可配置包含兩個方面，一方面，信號處理系統的子函數應當是參數化的，函數應該盡可能功能單一，處理簡單；另一方面，對于雷達系統來說，信號處理至少應該在某些方面是參數化的，比如脈沖數，重頻，發射時寬等等。

當每個處理函數都參數化，這些參數可以通過控制字跟時序打包發過來。還有一些參數是跟雷達相關的，開機后基本不需要改變的，這些參數可以在初始化階段由計算機發給硬件，硬件與DSP通過握手的方式完成系統參數初始化。

3.3 實時計算處理所需系數

很多工程人員習慣將相對穩定的數據提前算好，保存在系統內存里。該方法雖然在一定程度上減少了運算量，卻始終占據部分系統內存，而且當系統參數或者狀態變化時，該段數據需要重新生成，工程需要重新編譯，其實是不必要的。因為計算這些系數所需計算時間很少，實際工作時完全可以實時計算。

3.4 按照數據最大傳輸率設計系統

隨著雷達系統的大帶寬，多波束設計成為一種趨勢，I/O成為很多系統的瓶頸。在雷達信號處理算法相同的情況下，信號帶寬不同，結果在硬件實現時，在一個雷達上可以采用的架構換到另一個雷達則需要進行很大的改動。這主要是因為第一個雷達的處理架構沒有按照硬件最大數據率設計實現。

DSP芯片一般有多個鏈路口，若多個鏈路口同時進數，可大大提高其傳輸能力。但是需要說明的是，系統的最大傳輸能力往往會受到DSP和外部存儲器（SDRAM或DDR2）之間最大傳輸速率的限制。

3.5 降低處理結點的數據率

工程實現時，我們一方面考慮降低進入每一個處理結點的數據率，另一方面要考慮充分發揮硬件的傳輸處理能力。從降低數據率的角度考慮，一般有兩種方法，一種是將數據距離上分段處理，另一種方法是采用多個處理結點輪流處理。

3.6 內存復用

DSP的系統內存是有限的，從增加系統可用內存的角度考慮，我們希望每個處理結點的在用完內存后馬上釋放出來給后面的處理結點使用。這樣，雖然系統內存不變，但是相對每一處理結點，其可用的內存大小變大了。

在運算過程中，應盡量減少內存占用，解決該問題一般有兩種思路，一種是距離分段法，每次處理其中的一段，但是該方法在波束較多時效率會有所降低，比如恒虛警檢測需要距離交迭；另一種方法是分波束處理，每次處理其中的一個波束。筆者認為，實際處理時，可以將兩種方法結合起來：即在距離上分段處理，在處理順序上，按照波束逐個處理，因為并非每個波束都需要檢測目標，該方法可有效降低內存要求，同時降低運算量。

3.7 功能模塊的獨立性

首先，在進行編程實現時，少定義全局變量，盡量采用局部變量來替代全局變量，減少模塊/函數之間的耦合。

其次，在接口設計時，應同時考慮模塊的兼容性，比如：在PD處理時，需要做距離/速度兩維的解模糊，而在MTD處理時，只需要解距離模糊即可。這樣，解速度模糊和解距離模糊是兩個獨立的模塊，可以開關控制，開關的選擇與否不影響函數的上下文。

4 完善信號處理測試手段和測試方法

當前雷達系統的聯調過程中，系統聯調占用的時間要遠遠大于軟件編程所需要的時間。在系統聯調過程中，接口聯調，功能測試，算法調整占用了大部分的時間，基于此本文考慮從以下幾個方面減少聯調時間。

4.1 先期算法驗證

考慮到DSP的開發周期較長，信號處理系統在進行開發之前可以將一些不成熟的算法先用記錄儀和Matlab驗證，若算法有一定的優勢，再在硬件上實現，減少不必要的工作量。

4.2 系統級的自檢信號

在信號處理前端模擬生成陣元級的測試數據，在其中加入運動目標，基本可以驗證信號處理的大部分功能。

4.3 完善系統BIT信息

完善的信號處理BIT信息，可以快速定位信號處理的故障位置，判定軟件故障或硬件故障，給后期維護和客戶使用帶來方便，同時也可以見信號處理人員前期開發階段的排故時間。

5 結論

本文從一個軟件編程人員的角度，分析了雷達信號處理軟件模塊化，參數化面臨的問題以及可能的思路和解決措施。需要說明的是，雷達信號處理模塊化設計面臨的問題遠遠不止以上幾項，而水平所限，本文許多觀點可能不成熟，甚至是錯誤的。而模塊化，參數化的設計是雷達信號處理每個軟件人員的夢想和追求。