1. 从“PLFM_RADAR”这个名字说起：它到底想做什么
第一次看到“PLFM_RADAR”这个项目名，很多人会愣一下。PLFM 这四个字母不是随便拼的，它大概率指向Pulse Linear Frequency Modulation，也就是脉冲线性调频。说白了，这是一种雷达发射波形的调制方式，信号频率在脉冲持续时间内线性变化，接收端通过匹配滤波或者去斜处理，把回波中的频率差换算成距离信息。而 RADAR 就是整套系统的总称。把这两个词拼在一起，基本可以判断：这是一个以线性调频脉冲为体制的雷达信号处理项目，核心工作大概率落在FPGA 做实时信号处理、STM32 做系统控制与数据交互这条经典分工线上。
为什么我敢这么判断？因为热词里同时出现了 phased array、FPGA、STM32、高速 ADC 采样、DDR 读写、LVDS 接收、FFT IP 核、频谱仪这些关键词。这些词不是随便凑的，它们共同勾勒出一个典型的雷达信号处理链路：天线或阵列接收信号，经过射频前端下变频，送到高速 ADC 采样，采样数据通过 LVDS 或并行接口进入 FPGA，FPGA 内部完成数字下变频、脉冲压缩、FFT、CFAR 检测等运算，中间数据缓存在 DDR 里，最后把目标信息通过串口、网口或者 USB 送给 STM32 做显示、上报或者上位机交互。这条链路里的每一个环节，在热词里都能找到对应的影子。
所以这篇内容适合谁看？如果你正在做雷达相关的毕业设计、嵌入式竞赛、实验室预研项目，或者你手上有 FPGA 和 STM32 两块板子想串起来做一个完整的信号采集处理系统，那这篇内容会对你有直接帮助。如果你只是刚入门 FPGA，想找一个能同时练到时序、接口、存储、算法的综合项目，PLFM_RADAR 也是一个很好的载体。我不会只讲空泛的架构，而是把每个环节里真正会卡住人的地方拆开讲，包括参数怎么定、接口怎么对、DDR 怎么读写不冲突、STM32 怎么和 FPGA 握手这些实操层面的东西。
需要先说明一点：项目正文和关键词都是空的，所以下面的内容是基于标题“PLFM_RADAR”和热词网络搜索到的技术方向，结合我在类似项目中的实际经验做的合理还原。具体到你手上的硬件平台，参数和引脚肯定要按实际原理图调整，但思路和方法是通用的。
2. 线性调频脉冲雷达的信号链拆解
2.1 为什么是线性调频，而不是单频连续波
雷达体制有很多种，最简单的单频连续波雷达只能测速，测不了距离，因为它没有时间标记。脉冲雷达通过发射短脉冲再接收回波，用飞行时间算距离，但普通脉冲的距离分辨率受脉冲宽度限制，想要高分辨率就得用极窄脉冲，而极窄脉冲意味着峰值功率高、带宽大，工程上很难做。
线性调频脉冲巧妙地绕开了这个矛盾。它发射的是一个宽度较大但频率在变化的脉冲，接收端通过匹配滤波把长脉冲压缩成一个窄尖峰，这个尖峰的宽度反比于信号带宽，而不是脉冲宽度。也就是说，你可以用 10 微秒的脉冲、100 兆赫兹的带宽，得到等效于 10 纳秒脉冲的距离分辨率，同时峰值功率还不用做得很高。这就是脉冲压缩的核心价值，也是 PLFM_RADAR 这类项目存在的意义。
在 FPGA 里实现脉冲压缩，常见做法是频域相乘：对回波做 FFT，乘以发射信号的共轭频谱，再做 IFFT。这样比时域卷积快得多，尤其是当脉冲很长的时候。热词里出现的“FFT IP 核”“信号频谱仪”正好对应这个环节。如果你用的是 Xilinx 或 Altera 的 FPGA，直接调 FFT IP 核是最省事的，但要注意 IP 核的配置参数，比如点数、数据位宽、缩放方式，这些会直接影响资源占用和运算精度。
2.2 数字下变频在 FPGA 里的位置
射频前端把信号搬到中频之后，ADC 采到的还是中频信号，里面既有正频率成分也有负频率成分。为了降低后续处理的数据率，通常要在 FPGA 里做数字下变频，把中频信号搬回基带，然后抽取滤波。这一步的关键是NCO（数控振荡器）和混频器的实现。
NCO 一般用相位累加器加查找表或者 CORDIC 算法实现，输出正弦和余弦两路本振信号，和 ADC 数据相乘得到 I/Q 两路基带信号。混频之后要接一个低通滤波器，滤掉二倍频分量，然后做抽取。抽取倍数要根据信号带宽来定，比如中频 60 兆、带宽 10 兆，那抽取到 20 到 25 兆采样率就够了，再高就是浪费资源。
这里有个容易踩的坑：NCO 的频率控制字计算。假设系统时钟 100 兆，你想产生 60 兆的本振，频率控制字就是 60/100 乘以 2 的相位累加器位宽次方。如果位宽是 32 位，那控制字就是 0.6 乘以 2 的 32 次方，约等于 2576980377。这个数算错了，本振频率就偏了，后面全错。我见过有人直接把 0.6 乘以 2 的 31 次方，结果频率差了一倍，查了半天才发现是位宽搞混了。
2.3 脉冲压缩与 CFAR 检测的衔接
脉冲压缩之后，信号变成了一维的距离像，每个距离单元对应一个复数幅度。接下来要做的是检测，也就是判断哪些距离单元里有目标。最简单的是固定门限，但实际环境里噪声和杂波是变化的，固定门限要么虚警太多，要么漏检太多。所以通常用CFAR（恒虚警率）检测，根据周围参考单元的动态噪声水平来调整门限。
CFAR 在 FPGA 里实现，常见的是 CA-CFAR（单元平均）或者 OS-CFAR（有序统计）。CA-CFAR 就是把待检测单元两侧的参考单元取平均，乘以一个门限因子。这个门限因子和虚警率有关，虚警率越低，门限因子越大。实现的时候要注意参考单元的数量和保护单元的设置，保护单元是为了防止目标能量泄漏到参考窗里导致门限被抬高。
热词里没有直接出现 CFAR，但“雷达”“信号处理”这些词背后必然包含检测环节。如果你做的只是信号采集和显示，那 CFAR 可以放到上位机做；但如果要做实时处理，FPGA 里跑 CFAR 是绕不开的。我的建议是，第一版先把脉冲压缩跑通，CFAR 用 MATLAB 或者 Python 离线验证，等数据链路稳定了再往 FPGA 里搬。
3. FPGA 侧的数据通路：从 ADC 到 DDR 再到输出
3.1 高速 ADC 采样与 LVDS 接口的对接
雷达项目里 ADC 的采样率通常不低，几十兆到几百兆都很常见。高速 ADC 和 FPGA 之间的接口，低速时用并行 CMOS，高速时基本都用LVDS。LVDS 是差分信号，抗干扰能力强，速率可以做到几百兆甚至上千兆。热词里“fpga 的 lvds 接收”说明这个项目大概率用了 LVDS 接口。
LVDS 接收在 FPGA 里通常用ISERDES或者SelectIO原语来实现串并转换。以 Xilinx 7 系列为例，一个 LVDS 对可以跑到 1.25 Gbps 左右，用 ISERDES 做 1 比 8 或者 1 比 10 的串并转换，把高速串行数据变成低速并行数据给内部逻辑。这里的关键是时钟对齐，也就是要保证采样时钟的边沿落在数据眼图的中间。通常用 IDELAY 或者 IDELAYCTRL 来调整延迟，配合眼图扫描找到最佳采样点。
我踩过的一个坑是：LVDS 的差分对引脚分配必须严格按照 Bank 的规则来，不是随便两个 IO 就能当差分对用的。Xilinx 的 FPGA 里，差分对是成对的，P 端和 N 端有固定的引脚关系，分配错了要么不工作，要么时序很差。还有，LVDS 的终端电阻一般是 100 欧姆，有些 ADC 内部已经集成了，有些需要外部加，这个要看 ADC 的数据手册。
3.2 多端口 DDR 读写：雷达数据缓存的命脉
雷达信号处理里，数据量大、实时性要求高，FPGA 内部 BRAM 根本存不下，必须外挂 DDR。热词里“基于 fpga 的多端口 ddr 读写程序”说明这个项目里 DDR 是核心存储介质。DDR 的读写本身不难，难的是多端口并发访问：ADC 数据要写进去，FFT 要读出来，STM32 可能要读结果，这几个操作如果同时发生，就会冲突。
解决冲突的常见方案是分时复用加 FIFO 缓冲。比如把 DDR 的访问时间切成时隙，写通道和读通道轮流占用，每个通道前面挂一个 FIFO 做数据缓冲。FIFO 的深度要算好，太浅了会溢出，太深了浪费 BRAM。假设 ADC 写入速率是 100 兆样本每秒，DDR 带宽是 400 兆样本每秒，那写通道占 25% 的时间，读通道可以占 75%，只要 FIFO 能扛住突发就行。
另一个方案是用DDR 的多 Bank 特性，不同端口访问不同的 Bank，减少冲突。但 Bank 切换有开销，而且不是所有 FPGA 的 DDR 控制器都支持精细的 Bank 管理。我的经验是，如果数据率不是特别高，分时复用加 FIFO 最稳妥，调试也简单。如果你用的是 Xilinx 的 MIG 或者 Altera 的 UniPHY，它们本身有仲裁机制，但你要把优先级配好，否则低优先级通道可能饿死。
还有一个细节：DDR 的刷新操作会占用带宽，通常占 5% 到 10%。算带宽的时候要把这部分扣掉，不然实际能用的带宽比你理论算的要少。我一般会留 20% 的余量，宁可 DDR 跑不满，也不要让数据通路卡死。
3.3 从 FPGA 到 STM32 的数据交互
FPGA 处理完的数据要送给 STM32 做显示或者上报，两者之间的接口有很多选择：SPI、UART、FSMC、USB、网口。热词里“stm32 如何做 usb 设备”“k210 与 stm32 通讯”“agile_modbus stm32”说明这个项目可能涉及多种通信方式。
如果数据量不大，比如只是目标距离和速度，用 UART 或者 SPI 就够了。UART 简单，但速率有限，115200 波特率下每秒也就一万多字节。SPI 快得多，可以到几十兆，但需要额外的片选和时钟线。如果数据量大，比如要把原始回波传给上位机，那 USB 或者网口更合适。STM32 的 USB 可以做 CDC 设备，虚拟成串口，速率比 UART 高很多，而且上位机不用额外装驱动。
FPGA 和 STM32 之间的握手协议要设计好。我通常用一个简单的命令-应答机制：STM32 发命令字，FPGA 收到后执行，完成后拉一个中断或者状态位，STM32 再读数据。命令字里可以包含操作类型、起始地址、长度等信息。状态位要加超时保护，万一 FPGA 没响应，STM32 不能死等，要有超时重试或者报错机制。
这里有个实际经验：跨时钟域的信号一定要做同步处理。FPGA 和 STM32 的时钟是独立的，如果直接把 FPGA 的信号拉到 STM32 的中断引脚，可能产生亚稳态。正确做法是在 FPGA 侧用两级触发器同步，或者在 STM32 侧用外部中断加软件消抖。我见过因为没做同步导致 STM32 频繁误中断的案例，查了很久才发现是跨时钟域的问题。
4. STM32 在雷达系统里的角色与控制逻辑
4.1 为什么雷达项目里还要放一颗 STM32
有人会问，FPGA 都这么强了，为什么还要 STM32？直接用 FPGA 做所有事情不行吗？行，但没必要。FPGA 擅长并行流水线运算，适合做信号处理；但它的顺序控制、人机交互、协议栈处理不如 MCU 灵活。STM32 跑个 FreeRTOS，做菜单显示、按键响应、串口协议解析、SD 卡存储，这些用 C 语言写起来比 Verilog 快得多，改起来也方便。
而且从系统架构上看，FPGA 和 STM32 分工明确：FPGA 负责实时性要求高的底层信号处理，STM32 负责上层管理和交互。这样即使 FPGA 那边算法要改，STM32 的代码基本不用动；反过来 STM32 要加个新功能，也不用碰 FPGA。这种解耦对项目维护很重要，尤其是毕业设计或者竞赛项目，时间紧、需求变，解耦能省很多事。
热词里“stm32 项目”“基于 stm32 的毕业设计”“stm32 报站程序完整代码”说明 STM32 在这个项目里承担的是系统控制角色。具体到 PLFM_RADAR，STM32 可能要做的事情包括：初始化配置 FPGA、发送工作参数（比如脉冲宽度、带宽、PRF）、接收目标信息、驱动显示屏、通过 USB 或网口和上位机通信、存储日志数据。
4.2 STM32 与 FPGA 的接口设计细节
接口设计要考虑三个问题：速率、实时性、可靠性。速率决定了你能传多少数据，实时性决定了你多久能拿到一次结果，可靠性决定了数据会不会丢或者错。
如果只是传目标点迹，数据量很小，一帧可能就几十个字节，UART 足够了。但 UART 有个问题：它是异步的，波特率有误差，长时间传输可能累积偏差。所以要么用高精度晶振，要么在协议里加校验和重传。我一般会在帧头加一个同步字，帧尾加 CRC，收到后先校验再处理，校验不过就丢弃，让 FPGA 重发。
如果数据量大，比如要传距离像或者原始数据，那 SPI 或者 FSMC 更合适。STM32 的 FSMC 可以像访问外部内存一样访问 FPGA 的寄存器，读写速度很快，适合大数据块传输。但 FSMC 的时序要配好，地址建立时间、数据保持时间这些参数要和 FPGA 侧的时序匹配，不然读出来的数据是错的。我通常先用示波器看时序波形，确认读写信号和数据的相位关系，再调 FSMC 的参数。
USB 是另一个选择。STM32 的 USB 外设可以做 CDC 或者自定义 HID，CDC 虚拟串口最方便，上位机不用写驱动。但 USB 的中断优先级和缓冲区管理要小心，如果 FPGA 送数据太快，STM32 来不及处理，USB 缓冲区溢出就会丢数据。解决办法是在 FPGA 侧加流控，STM32 的缓冲区快满时拉一个信号告诉 FPGA 暂停发送。
4.3 用定时器做雷达时序控制的可行性
热词里“stm32 定时器模式”“stm32 定时器捕获测频率”说明定时器是 STM32 的常用外设。在雷达系统里，定时器可以用来产生 PRF（脉冲重复频率）信号，也可以用来测量回波到达时间。
用 STM32 的定时器产生 PRF，优点是灵活，频率和占空比都可以软件调；缺点是精度不如 FPGA 的时钟分频。如果 PRF 要求不高，比如几 kHz，STM32 定时器完全够用。但如果要求很高，比如几十 kHz 且抖动要小，那还是让 FPGA 产生更靠谱。我的做法是：STM32 负责设定 PRF 参数，通过 SPI 写给 FPGA，FPGA 用计数器分频产生精确的 PRF 信号，同时把这个信号回送给 STM32 做同步参考。
定时器捕获可以用来测量回波脉冲的到达时间，但雷达回波不是简单的方波，直接捕获边沿意义不大。更常见的是用定时器做时间戳，记录每次发射和接收的时刻，配合 FPGA 的距离测量结果做交叉验证。这个在调试阶段很有用，可以帮你判断 FPGA 算出来的距离对不对。
5. 调试与验证：那些文档里不会写的坑
5.1 Testbench 怎么写才能真正发现问题
热词里“fpga 如何正确写 testbench”说明很多人对验证环节有困惑。我的观点是：testbench 不是走形式，它的目的是模拟真实激励，暴露设计缺陷。一个合格的 testbench 至少要包含：时钟和复位生成、激励数据产生、输出数据采集、自动比对。
以 PLFM_RADAR 的脉冲压缩模块为例，testbench 里应该产生一段线性调频信号作为输入，同时用 MATLAB 或者 Python 算出理论上的压缩结果，存成文件。仿真时把 FPGA 的输出和理论结果逐点比对，误差在允许范围内才算通过。这样比只看波形图靠谱得多，因为波形图你只能看个大概，量化误差、截位误差这些细节根本看不出来。
还有一个技巧：在 testbench 里加入异常激励。比如输入突然中断、数据超范围、复位中途拉低，看看设计会不会跑飞。真实系统里这些情况都可能发生，仿真时提前暴露比上板后发现好得多。我做过一个项目，仿真时一切正常，上板后偶尔出错，查了一周才发现是复位释放时机和时钟不同步导致的。后来在 testbench 里专门加了复位时序的异常测试，问题就复现了。
5.2 上板调试：从 LED 到逻辑分析仪
FPGA 上板调试，第一步永远是点灯。别笑，点灯能确认时钟有没有、复位对不对、引脚分配有没有错。如果 LED 不亮，后面所有事情都别谈。点灯之后，可以加一个计数器分频，让 LED 闪烁，确认时钟频率对不对。
接下来是ChipScope 或者 SignalTap，也就是嵌入式逻辑分析仪。把关键信号引出来，设置触发条件，抓波形。比如你可以设置触发条件为“ADC 数据有效且 FIFO 非空”，抓一段数据看看写入 DDR 的数据对不对。ChipScope 很吃 BRAM 资源，采样深度和信号数量要权衡，一般抓几百到几千个采样点就够了。
如果 ChipScope 不够用，那就上外部逻辑分析仪。把 FPGA 的测试引脚引出来，接逻辑分析仪，可以抓更长时间、更多通道。但外部逻辑分析仪的速度有限，太高速的信号抓不了，而且引脚多了布线也麻烦。我的经验是：低速控制信号用逻辑分析仪，高速数据通路用 ChipScope，两者结合基本能覆盖大部分调试场景。
5.3 STM32 侧的常见问题与排查
STM32 这边的问题通常比 FPGA 少，但也有一些经典坑。比如延时函数卡死，热词里“stm32 延时函数 delay 卡死”就是一个典型。delay 卡死一般是中断优先级配置有问题，或者 SysTick 被其他高优先级中断打断了。如果你在中断里调用 delay，而 delay 又依赖 SysTick 中断，那就死锁了。解决办法是：中断里不要用阻塞式延时，用状态机或者定时器回调。
还有JTAG 引脚被占用的问题。STM32 的 JTAG 引脚和普通 GPIO 是复用的，如果你不小心把 PA13、PA14、PA15、PB3、PB4 配成了普通 IO，下次就下载不了程序了。热词里“stm32 禁用 jtag”说的就是这个。解决办法是在初始化代码里先禁用 JTAG 保留 SWD，或者用 BOOT 引脚进入系统存储器启动模式，擦除 Flash 后再重新下载。
串口通信乱码也是高频问题。原因通常是波特率不匹配、时钟配置错误、或者电平不兼容。STM32 的 USART 时钟来自 APB 总线，如果系统时钟配错了，波特率就不对。我一般先用示波器量一下 TX 引脚的实际波特率，和设定值对比，差太多就是时钟问题。电平方面，STM32 是 3.3V，如果对方是 5V，要么加电平转换，要么用兼容 5V 的引脚。
6. 系统联调与性能评估的实操思路
6.1 分阶段联调，不要一上来就全系统跑
雷达系统联调最忌讳的就是所有模块一起上电，然后发现没反应，不知道哪里的问题。正确的做法是分阶段验证：先单独测 ADC 采样，确认数据能进 FPGA；再测 DDR 读写，确认数据能存能取；再测脉冲压缩，用已知信号验证算法；再测 STM32 通信，确认命令和数据能通；最后全链路联调。
每个阶段都要有明确的通过标准。比如 ADC 阶段，标准是：输入已知频率的正弦波，FPGA 抓到的数据做 FFT 后峰值频率和输入一致，信噪比符合预期。DDR 阶段，标准是：写入一组递增数，读出来完全一致，连续读写一万次不出错。脉冲压缩阶段，标准是：输入线性调频信号，压缩后的峰值位置和理论值误差小于一个距离单元。
分阶段的好处是，一旦出问题，排查范围小。如果全系统跑，出了问题可能是 ADC 配置错、DDR 冲突、算法 bug、通信协议错，甚至电源不稳，排查起来非常痛苦。我见过一个团队，全系统联调时发现数据不对，查了两周才发现是 ADC 的参考电压引脚虚焊，这种问题如果分阶段测，第一轮就能发现。
6.2 性能评估：分辨率、信噪比、实时性
系统跑通之后，要评估性能。雷达系统最核心的三个指标是：距离分辨率、信噪比增益、实时性。
距离分辨率取决于信号带宽，理论值是光速除以两倍带宽。比如 100 兆带宽，分辨率就是 1.5 米。实际测的时候，可以用两个已知距离的角反射器，看距离像上两个峰能不能分开。如果分不开，要么带宽不够，要么脉冲压缩的加权函数太宽。
信噪比增益来自脉冲压缩，理论值是时间带宽积。比如脉冲宽度 10 微秒、带宽 100 兆，时间带宽积就是 1000，信噪比增益约 30 分贝。实测的时候，对比压缩前后的信号噪声比，看增益够不够。如果差太多，可能是 FFT 的截位误差太大，或者滤波器系数不对。
实时性看的是从 ADC 采样到输出结果的总延迟。这个延迟包括：ADC 转换时间、FPGA 流水线延迟、DDR 读写延迟、STM32 处理时间。如果要求实时显示，总延迟要小于人眼能感知的范围，一般 100 毫秒以内。如果要求实时控制，比如跟踪目标，那延迟要更小，可能要到毫秒级。测延迟的方法很简单：在 FPGA 里加一个计数器，记录从采样到输出的时钟周期数，乘以时钟周期就是延迟。
6.3 从单目标到多目标的扩展思路
第一版系统通常只处理单目标，但实际场景里多目标是常态。从单目标扩展到多目标，主要改的是检测和跟踪环节。检测方面，CFAR 本身就能处理多个目标，只要目标之间距离足够远，不在同一个参考窗里就行。如果目标很近，参考窗会互相干扰，这时候要用 OS-CFAR 或者 GO-CFAR 来改善。
跟踪方面，单目标只需要记录一个距离和速度，多目标就要做数据关联。最简单的是最近邻关联，把当前帧的检测点和上一帧的轨迹按距离匹配。复杂一点用卡尔曼滤波，预测目标下一时刻的位置，再和检测点关联。这些算法在 STM32 上跑有点吃力，可以放到上位机做，STM32 只负责把检测点传上去。
如果要做相控阵，那还要考虑波束形成。热词里“phased array”说明这个项目可能涉及阵列处理。波束形成在 FPGA 里做，本质是对多通道信号加权求和，权重决定了波束指向。权重的计算涉及相位补偿，和阵元间距、信号波长、期望指向角都有关系。这部分计算量大，通常用 CORDIC 或者查找表来实现。
7. 一些个人体会和后续可扩展的方向
做 PLFM_RADAR 这类项目，最大的感受是：信号链路上每一个环节都不能马虎，但最耗时间的往往不是算法，而是接口和调试。算法有 MATLAB 可以仿真，有 IP 核可以调用，但接口时序不对、数据位宽不匹配、跨时钟域没同步，这些问题仿真时看不出来，上板就抓瞎。所以我的建议是，前期在接口和验证上多花时间，后期调试会轻松很多。
另一个体会是：不要追求一次做完美。第一版能把数据从 ADC 采进来、存到 DDR、做一次 FFT、通过串口发出来，就已经成功了。CFAR、多目标跟踪、相控阵这些可以后续迭代。我见过太多项目卡在“想一次做全”上，结果什么都没做完。先跑通最小闭环，再逐步加功能，这是最稳妥的路径。
后续扩展的话，有几个方向可以考虑。一是提高处理带宽，换更高速的 ADC 和更大的 FPGA，把瞬时带宽做到几百兆甚至上千兆。二是增加通道数，从单通道扩展到多通道，做数字波束形成。三是优化算法，比如用脉冲多普勒处理来测速，用 SAR 成像算法来做高分辨率成像。四是改善人机交互，用 Qt 或者 Python 写一个上位机，实时显示距离像和检测结果，比串口打印直观得多。
最后分享一个小技巧：在 FPGA 里预留一些调试寄存器，可以动态配置参数，比如 PRF、脉冲宽度、FFT 点数、CFAR 门限。这样调试的时候不用重新综合，改个寄存器值就能试不同参数，效率高很多。这些寄存器通过 STM32 或者上位机写，用起来很方便。我在最近一个项目里加了二十多个调试寄存器，调试时间至少省了一半。
