雷达系统为什么经常需要 FPGA？

学习雷达算法时，很多人会从 MATLAB 或 Python 开始：生成一段回波数据，加窗、做 FFT、运行 CFAR，最后画出距离-多普勒图或目标点云。

到了真正的雷达系统中，问题会明显不同。

ADC 持续产生采样数据，chirp 或 pulse 按照固定时序到来，多路接收通道需要保持同步，检测结果还要在规定时间内交给后续的跟踪、融合或控制模块。系统关心的不只是某一次计算能不能完成，更关心整条处理链路能否持续运行，以及每一帧数据能否按时处理完。

这正是 FPGA 经常出现在雷达系统中的原因。

FPGA 的核心价值并不只是“算力强”，而是能够靠近数据源，直接承接高速接口，把规则的数字信号处理过程实现为并行流水线，并在设计约束范围内提供稳定吞吐和可分析的处理时延。

因此，并不是所有雷达算法都必须放进 FPGA，而是雷达数据链路中有一部分工作天然适合硬件化。

一、真实雷达不是离线数据处理

离线仿真通常是先准备一段完整数据，再按步骤执行算法。真实雷达面对的则是连续进入的数据流。

以 FMCW 毫米波雷达为例，前端按照设定的 chirp sequence 持续发射和接收。多个接收通道经过 ADC 采样后形成原始数据，系统需要在每一帧或每一组 chirp 对应的时间窗口内完成必要处理。

如果处理速度长期低于数据产生速度，缓存会不断累积，最终可能出现延迟增加、丢帧或数据覆盖。

脉冲雷达、成像雷达、相控阵雷达虽然体制不同，但都会遇到相似的问题：

• 高速采样数据如何接入和缓存；
• 多通道数据如何同步、重排和校准；
• 前端处理能否持续跟上采样节奏；
• 每一帧结果能否在规定时间内输出；
• 系统负载变化是否会引入明显的延迟抖动。

这些问题并不属于某一个算法公式，而是完整的数据链路和系统架构问题。

FPGA 的价值，往往首先体现在这里：数据一进入系统就开始处理，而不是等数据全部搬到内存后，再由软件统一计算。

二、雷达处理链路大致包括什么

不同雷达的处理流程并不完全相同，但从工程实现看，常见系统通常包含以下环节：

ADC 与高速接口
        ↓
解串、同步和通道整理
        ↓
数字下变频、滤波和抽取
        ↓
距离向处理
        ↓
速度向处理
        ↓
阵列与角度处理
        ↓
检测和点迹生成
        ↓
跟踪、分类与融合

越靠近 ADC，数据速率通常越高，数据结构也越规则，对实时性的要求越强，因此更适合 FPGA。

越靠近系统后端，算法中的判断、状态和动态数据结构越多，对软件灵活性、算法迭代速度和生态工具的要求也越高，往往更适合 CPU、GPU、DSP 或 NPU。

所以，工程设计的重点不是把完整雷达算法全部搬进 FPGA，而是合理划分软硬件边界。

三、高速数据接入本身就是系统难点

雷达前端可能通过 LVDS、JESD204B/C、MIPI CSI-2、SerDes 或厂商专用高速接口输出数据。

这些数据进入数字处理平台后，通常还要完成：

• 接口解串；
• lane 对齐；
• 时钟域转换；
• 帧同步；
• 通道重排；
• 数据格式转换；
• 缓存管理；
• DMA 搬运。

如果把所有原始 ADC 数据直接送入处理器内存，再依靠软件逐步处理，系统可能同时受到数据搬运带宽和处理时延的限制。

现代 CPU 和 GPU 平台也可以借助 DMA、高速总线、零拷贝等技术提高吞吐，因此不能简单认为软件平台无法处理高速数据。真正的区别在于，当系统需要在接口侧完成严格同步、持续流式处理和低延迟格式转换时，FPGA 更容易构建专用数据路径。

数据进入 FPGA 后，可以在写入外部内存之前完成：

• 多通道同步与数据重排；
• 定点缩放和格式转换；
• 数字滤波与抽取；
• 通道增益和相位校准；
• 帧缓存与流量控制；
• 后续处理所需的数据整理。

这些功能未必属于传统意义上的“雷达算法”，但它们决定了后续算法能否得到连续、正确且时间对齐的数据。

很多雷达平台首先需要解决的，不是复杂检测算法，而是如何让高速数据稳定进入系统。

四、规则的前端计算适合流水线实现

雷达前端包含大量重复、规则的运算，例如：

• 窗函数；
• FIR 和 CIC；
• 数字下变频；
• 复数乘加；
• FFT；
• 能量累积；
• 相位补偿；
• 门限比较；
• 滑动窗口统计。

这些计算通常具有明确的数据依赖关系，适合被构建成流水线。

软件处理一般以数组或数据块为单位：从内存读取数据，执行计算，再把结果写回。FPGA 则可以在资源和时序允许的情况下，让不同数据同时处于流水线的不同阶段。

当前一组数据仍在后级计算时，后一组数据已经可以进入前级。系统关注的不只是完成一次运算需要多长时间，更关注能否按照固定节奏持续接收和处理数据。

以流式 FFT 为例，工程上除了关心 FFT 的点数和单次延迟，还要关注：

• 输入数据是否连续；
• 每个时钟周期能够接收多少样本；
• 不同帧之间是否需要间隔；
• 数据位宽如何增长；
• 中间结果如何缩放；
• 输出是否能够被后级及时接收。

CFAR 检测也具有类似特点。滑动窗口、参考单元统计、保护单元处理、噪声估计和门限比较，都可以进行一定程度的流水化和并行化。

在阵列雷达中，传统波束形成、通道相位补偿和多路复数乘加也具有较强的规则性。只要 FPGA 资源、存储带宽和时钟条件允许，就可以在通道、距离单元或波束方向上展开并行处理。

当然，并不是所有角度估计算法都适合直接放入 FPGA。对于包含特征值分解、大规模动态矩阵运算或频繁参数调整的算法，CPU、GPU 或异构实现有时更合适。

五、确定性比峰值算力更重要

CPU 和 GPU 可以提供很高的通用计算性能。GPU 尤其适合大规模并行计算、矩阵运算、点云处理和神经网络推理。

但在靠近采样端的处理链路中，系统不仅要看平均吞吐，还要看最坏情况延迟和帧间抖动。

例如，一套雷达系统要求每一帧都在固定时间内输出检测结果。某一帧偶尔慢很多，即使平均帧率仍然满足要求，也可能影响后续跟踪、融合或控制。

软件平台上的延迟可能受到多种因素影响：

• 操作系统调度；
• 中断响应；
• cache miss；
• DDR 访问竞争；
• DMA 队列拥塞；
• 多任务抢占；
• 驱动和运行时开销。

这些因素不一定意味着系统“算不动”，但可能带来不稳定的响应时间。

FPGA 的数据通路在设计完成后，许多时延可以按时钟周期分析。一个模块包含多少级流水线、处理一帧需要多少周期、FIFO 深度是多少，都可以在设计阶段估算，并通过仿真和测试验证。

不过，使用 FPGA 并不意味着整个系统自动获得完全固定的延迟。

如果数据还要经过共享 DDR、NoC、PCIe、复杂 DMA 队列或软件驱动，系统中仍然可能出现等待和抖动。更加准确的说法是：

FPGA 适合构建延迟可分析、吞吐可约束的数据路径，而最终的确定性仍然取决于完整系统架构。

对于雷达系统来说，这种可分析性往往比单纯的峰值算力更重要。

六、前端预处理可以减轻后端压力

原始 ADC 数据量很大，但后端应用通常并不需要长期保留所有采样数据。

FPGA 可以在前端完成一部分稳定、规则的处理，例如：

• 去直流和通道校准；
• 数字下变频与滤波抽取；
• 匹配滤波或距离 FFT；
• 多普勒处理和能量积累；
• 杂波抑制；
• CFAR 检测；
• 候选目标或点迹生成；
• 数据压缩和格式化。

经过这些处理后，后端接收到的可能不再是完整的原始采样流，而是距离-多普勒图、候选点、点云、特征数据或目标列表。

这会明显降低后端总线、内存和存储压力，也可以让 CPU、GPU 或 NPU 把更多资源用于：

• 目标跟踪；
• 目标分类；
• 多传感器融合；
• 可视化；
• 网络通信；
• 系统控制；
• 上层业务逻辑。

这种分工通常比“所有原始数据都送到一个处理器统一计算”更符合实时系统的工程需求。

规则、稳定、实时的部分放在 FPGA；需要灵活迭代、复杂判断或模型更新的部分放在软件侧，是一种常见的系统划分方式。

七、功耗和体积会影响平台选择

很多雷达系统部署在边缘侧，例如车载感知、工业测量、移动设备和现场监测平台。

这些场景通常会受到功耗、体积、散热和环境条件限制，不能简单依赖服务器级计算资源。

在固定精度、规则流水线和较高资源利用率的情况下，FPGA 可以通过专用数据通路减少部分指令调度和不必要的数据搬运，从而获得较好的性能功耗比。

但这不是放在所有场景下都成立的结论。

FPGA 的实际功耗会受到很多因素影响：

• 器件规模；
• 工作频率；
• 外部存储访问量；
• 数据位宽；
• DSP 和存储资源使用率；
• 高速收发器数量；
• 时钟网络；
• 板级电源与散热设计。

对于高度固定且大批量部署的算法，专用 ASIC 可能更加高效；对于大规模浮点矩阵运算，GPU 可能具有更高的开发效率和整体性能。

因此，选择 FPGA 时，需要同时评估：

• 输入数据速率；
• 最大允许时延；
• 算法并行度；
• 定点化成本；
• 外部存储带宽；
• 板卡功耗与散热；
• 开发周期；
• 后续维护和升级需求。

FPGA 的优势来自系统匹配，而不是某一个独立指标。

八、FPGA 并不适合所有雷达算法

适合 FPGA 的任务通常具有以下特征：

• 靠近 ADC 或高速接口；
• 数据连续进入；
• 运算结构规则；
• 并行度较高；
• 时延要求严格；
• 算法变化相对较少；
• 需要与板级 I/O 紧密配合。

典型任务包括：

• 高速采集；
• 数据解串和同步；
• DDC；
• 数字滤波；
• FFT；
• 固定结构的波束形成；
• 部分 CFAR 处理；
• 数据压缩；
• 低延迟控制。

不一定适合 FPGA 的任务通常具有另外一些特点：

• 算法频繁修改；
• 分支和状态复杂；
• 依赖动态内存结构；
• 需要快速更新模型；
• 高度依赖成熟软件库；
• 需要复杂操作系统和网络服务。

目标跟踪、多传感器融合、复杂分类、可视化和系统策略，通常更适合由软件处理。

大规模神经网络训练一般也不会放在 FPGA 雷达前端中完成。神经网络推理是否适合 FPGA，则要看模型规模、时延要求、数据精度和平台资源，不能一概而论。

九、现代雷达通常采用异构架构

现实中的雷达处理平台，很少在 FPGA、CPU 和 GPU 之间只选择一种。

更常见的是异构协同：

• FPGA 负责高速接口、数据同步、前端预处理和低延迟数据通路；
• CPU 或 DSP 负责参数配置、流程控制和部分中间层算法；
• GPU 或 NPU 负责点云处理、目标分类和神经网络推理；
• 操作系统负责网络、存储、日志和应用管理。

在 SoC FPGA 中，处理器系统和可编程逻辑集成在同一器件内，可以缩短控制路径，减少部分板级数据交换，也便于构建软硬件协同系统。

RFSoC 则进一步集成高速 ADC、DAC、处理器系统和可编程逻辑，适合构建波形生成、直接采样、数字变频和实时处理平台。

不过，RFSoC 并不等于完整的雷达射频前端。天线、功率放大器、低噪声放大器、滤波器、混频器以及其他射频器件是否需要保留，仍然取决于工作频率、信号带宽、动态范围和具体系统架构。

无论平台形态如何，系统设计的核心问题都没有改变：

• 哪些处理必须靠近数据源；
• 哪些处理需要严格控制时延；
• 哪些算法值得硬件化；
• 哪些模块应该保留软件灵活性。

十、什么时候不一定需要 FPGA

FPGA 并不是雷达研究的必选项。

以下情况未必需要立即使用 FPGA：

• 数据速率较低；
• 主要进行离线算法研究；
• 系统没有严格的帧周期要求；
• 项目处于算法快速验证阶段；
• 通用处理器已经能够稳定满足吞吐和最坏情况时延；
• 项目更重视开发效率，而不是板级集成和低延迟；
• 目前尚未确定真实接口、采样率和通道数量。

在算法尚未稳定时，先使用 MATLAB、Python、CPU 或 GPU 完成模型验证，通常更有效率。

等到接口、数据率、时延、功耗和部署约束逐渐明确后，再把适合的模块迁移到 FPGA，可以减少过早硬件化带来的开发成本。

FPGA 开发需要处理定点化、资源评估、时序收敛、跨时钟域、接口调试和硬件验证等问题。算法一旦硬件化，修改成本通常高于软件。

因此，是否使用 FPGA，应该来自明确的系统约束，而不是因为“雷达系统通常都这么做”。

总结

FPGA 在雷达系统中的主要作用，不是替代所有处理器，而是承接最靠近信号源、数据速率最高、时间约束最严格的那部分处理。

它可以连接高速数据接口，完成多通道同步、数据整理、滤波、FFT、波束形成、检测和数据压缩，并把连续的原始采样流逐步转换成更适合后端处理的结构化结果。

CPU、GPU、DSP 和 NPU 仍然有各自适合的位置。现代雷达平台更常见的做法，是根据数据流、算法结构和实时要求进行异构分工。

因此，在设计雷达处理平台时，与其简单地问“是否需要 FPGA”，不如沿着数据链路逐段分析：

• 数据从哪里进入；
• 数据速率有多高；
• 系统允许多少延迟；
• 哪些计算结构稳定；
• 哪些模块必须持续实时运行；
• 哪些算法需要保留软件灵活性。

这些问题明确以后，FPGA 在系统中的位置也就自然清楚了。