企业官网建设流程全解析

PLFM_RADAR的CFAR算法实现：FPGA滑动窗口恒虚警检测的完整设计思路

【免费下载链接】PLFM_RADAROpen-source, low-cost 10.5 GHz PLFM phased array RADAR system项目地址: https://gitcode.com/GitHub_Trending/pl/PLFM_RADAR

PLFM_RADAR（AERIS-10）是一款开源的 10.5 GHz 脉冲线性调频（PLFM）相控阵雷达，它的 FPGA 信号处理链路里藏着一个非常关键的角色——CFAR算法（恒虚警检测）。简单说，CFAR 负责在雷达回波里"找目标"，但它不是用一把死尺子量，而是用滑动窗口实时估计背景噪声，动态算出门限。本文将以 FPGA 上的单元平均恒虚警检测（CA-CFAR）为例，完整拆解它的设计思路：从数学原理、三种工作模式，到状态机、定点阈值、边缘处理，再到资源占用与测试验证，带你一步步看懂这块"雷达大脑"是如何工作的。

为什么雷达需要恒虚警检测？从固定门限说起

早期的雷达检测很简单：把回波幅度和一个固定阈值比较，超过就算目标。但现实世界的噪声并不恒定——雨天、地杂波、海杂波、天线增益起伏，都会让背景电平剧烈变化。固定门限会遇到两个尴尬场景：

• 门限设高了：强杂波下漏掉真实目标；
• 门限设低了：弱噪声里冒出一堆假目标。

CFAR算法的聪明之处在于：对每一个待检测单元，都从它周围的实际数据里估算当前噪声水平，再算出这个位置专属的自适应门限。噪声高门限就高，噪声低门限就低，从而把"虚警概率"（假目标率）稳定控制在设定值附近——这正是"恒虚警"三个字的由来。

CFAR滑动窗口的核心概念：CUT、训练单元与保护单元

要理解 FPGA 上的实现，先认识三个基本角色：

CFAR 的处理方式很像"滑动窗口"：窗口沿着距离轴逐个滑过，每到一处，就取窗口内两侧训练单元的平均值作为噪声估计，再乘以一个缩放因子 α 得到门限：

门限 = α × 噪声平均功率

PLFM_RADAR 的默认配置是：每侧 8 个训练单元、2 个保护单元，α 默认取 3.0。这样即便背景噪声忽高忽低，门限也能"跟着环境走"。

三种 CFAR 模式：CA-CFAR、GO-CFAR、SO-CFAR

不同场景对门限的偏好不同，PLFM_RADAR 的 FPGA 实现通过一个 2 比特配置位切换三种模式（cfar_ca.v）：

• CA-CFAR（单元平均）：取左右两侧噪声的平均值。均匀噪声下统计最优，是默认模式。
• GO-CFAR（选大）：取左右两侧中平均值更大的一侧。适合杂波边缘场景，能有效抑制"杂波边缘虚警"。
• SO-CFAR（选小）：取两侧中平均值更小的一侧。适合多目标密集场景，避免强目标互相抬高门限、掩盖邻居。

一个巧妙的工程细节：GO/SO 模式比较两侧平均大小时，FPGA 不做除法（除法太费资源），而是用交叉相乘——leading_sum × lagging_count与lagging_sum × leading_count比大小，结果完全等价且只需一次乘法。

FPGA 滑动窗口恒虚警检测的两阶段架构设计

真实雷达数据不是一维的，而是距离-多普勒二维图：64 个距离单元 × 32 个多普勒单元。FPGA 把 CFAR 分成两个阶段流水作业：

第一阶段：数据缓冲（BUFFER）多普勒处理器每输出一个复数值，FPGA 立即计算幅度|I|+|Q|（比开平方省资源），按{距离, 多普勒}地址写入一块 2048×17 bit 的 BRAM。当一帧数据收齐（frame_complete 脉冲到来），进入第二阶段。

第二阶段：逐列滑动检测（CFAR）算法逐列处理每个多普勒单元：

1. 从 BRAM 把该列的 64 个幅度读入行缓冲；
2. 初始化 CUT=0 时的左右窗口和；
3. 窗口沿距离轴滑动，每个 CUT 经过三级流水：算噪声和 → 乘 α → 比较判决；
4. 全部列处理完，回到空闲态等待下一帧。

这种"缓冲一帧、处理一帧"的乒乓设计，让 FPGA 能以固定节拍完成全部 2048 个单元的检测，逻辑清晰且易于验证。

阈值计算的定点化：Q4.4 格式与 α 补偿

浮点除法在 FPGA 上是奢侈品，PLFM_RADAR 的做法是全定点：

• 主机把 α 写成 Q4.4 定点数（8 bit，其中低 4 位是小数），通过 USB 写入寄存器；
• 阈值 =(α × 噪声和) >> 4，即一次乘法加一次移位，DSP48 一拍完成；
• 由于 α 是按"训练单元总数"预先折算的（例如统计 α=4.88 时，实际写入 α/16≈0.305），因此不需要再做除法。

另外，门限计算设置了饱和保护：乘积溢出时钳位到最大幅度值，避免异常数据产生错误判决。

边缘单元怎么处理？滑窗不够宽的工程取舍

滑动窗口滑到距离轴两端时，训练单元会"不够用"。PLFM_RADAR 的处理策略是有多少用多少：只对仍落在有效范围内的单元求和并计数，窗口外的按 0 处理。

这会导致边缘门限偏低、虚警率略升——但工程上这是可接受的：雷达的距离图两端通常是近距杂波区，少量边缘虚警无伤大雅，而且换来的是状态机逻辑大幅简化。代码里通过一组带边界检查的增量计算（lead/lag 四个索引的 add/rem 有效性判断），在一个时钟周期内同时完成"窗口移入移出"的差值更新。

资源占用与实时性：85微秒处理一帧

FPGA 实现最怕"跑不动"。这份设计把资源控制得相当克制：

时序上，一帧 32 列全部检测完约需 8500 个时钟周期 @100 MHz，即85 µs；而帧周期在 PRF=1932 Hz、32 个 chirp 下约 16.6 ms。检测耗时不到帧周期的 1%，余量非常充裕，未来加更多列或更细的网格也不怕。

如何通过 USB 配置 CFAR 参数

CFAR 的所有参数都开放给上位机，通过 USB 命令寄存器实时调整（集成在 radar_system_top.v 中）：

值得一提的兼容性设计：当 CFAR 关闭时，模块自动回退到原来的简单阈值直通模式，老代码无需任何改动即可继续工作——这是工程上很加分的"向后兼容"思路。

14 个测试用例：如何验证一个恒虚警检测器

算法正确性靠的是严谨的验证。配套测试台 tb_cfar_ca.v 一口气写了 14 个用例，覆盖各种刁钻场景：

• 均匀噪声下零虚警；
• 单个强目标只报 1 个检测、目标在 0 号与 63 号边缘单元也能检出；
• 两个目标间距大于窗口时能同时检出；
• GO/SO 模式在非对称噪声下的行为差异；
• α 调大后虚警减少、保护单元挡住目标能量泄漏；
• 复位中断恢复、背靠背连续帧处理、计数跨帧累积等健壮性测试。

所有用例通过run_regression.sh一键回归（run_regression.sh），并带[PASS]/[FAIL]标记，与 CI 流程无缝衔接。

效果可视化：从检测结果到雷达界面

CFAR 的检测结果最终会通过 USB 上报到 Python 上位机，呈现在雷达界面的距离-多普勒图和目标列表里——每个目标的距离、速度、方位角一目了然。如果你对整条信号链感兴趣，可以参考 radar_receiver_final.v 里的 ADC → DDC → 匹配滤波 → 多普勒 FFT → MTI → CFAR 的完整接收链路。

小结

从数学上的滑动窗口原理，到 FPGA 上的状态机、定点阈值、边缘取舍，再到 14 个用例的回归验证，PLFM_RADAR 的 CFAR 实现给出了一份教科书式的FPGA 恒虚警检测设计范本：它用 1 块 BRAM、1 个 DSP、约 300 个 LUT 的极小代价，换来了自适应门限、三种检测模式、85 µs 一帧的实时性能和完整的向后兼容。对于想学习雷达信号处理或 FPGA 算法落地的开发者来说，cfar_ca.v 这份源码本身就是最好的教材——读一遍，你就同时理解了"雷达目标检测的原理"和"硬件工程师的工程智慧"。

【免费下载链接】PLFM_RADAROpen-source, low-cost 10.5 GHz PLFM phased array RADAR system项目地址: https://gitcode.com/GitHub_Trending/pl/PLFM_RADAR