基于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 结论

本文从一个软件编程人员的角度，分析了雷达信号处理软件模块化，参数化面临的问题以及可能的思路和解决措施。需要说明的是，雷达信号处理模块化设计面临的问题远远不止以上几项，而水平所限，本文许多观点可能不成熟，甚至是错误的。而模块化，参数化的设计是雷达信号处理每个软件人员的梦想和追求。