企业官网建设流程全解析

1. 项目缘起与整体设计思路

PLFM_RADAR 这个项目，从名字拆开看就是PhasedLinearFrequencyModulationRADAR——相位编码线性调频雷达。说白了，就是一套用 FPGA 做实时信号处理、STM32 做系统控制与数据交互的小型相控阵雷达原型系统。我第一次接触这个方向的时候，市面上能参考的完整开源方案非常少，要么是纯仿真的 MATLAB 脚本，要么是商用雷达的简化框图，真正把 FPGA 信号链和 STM32 控制链打通的工程案例屈指可数。所以这个项目的核心价值就在于：它是一条从天线阵列到基带处理再到上位机显示的完整链路，而不是某个孤立模块的演示。

先说说这套系统能干什么。它通过多个发射/接收通道构成一个相位阵列，利用通道之间的相位差实现波束的电子扫描，不需要机械转动天线就能改变波束指向。发射信号采用线性调频（LFM）波形，接收端做脉冲压缩，从而在保证作用距离的同时获得较高的距离分辨率。FPGA 负责高速 ADC 采样、数字下变频、匹配滤波、FFT 等运算密集型任务，STM32 则负责波形参数配置、时序控制、与上位机的通信以及系统状态管理。适合谁来参考？我认为有三类人：一是做雷达/通信方向的研究生，需要一套可落地的硬件验证平台；二是 FPGA 和 STM32 的进阶学习者，想找一个综合性强、涉及高速接口和实时信号处理的项目练手；三是对相控阵原理感兴趣但苦于没有实物验证条件的工程师。

为什么选择 FPGA + STM32 这个组合而不是单用其中一个？这是整个项目最核心的架构决策，我在下面会详细展开。简单说，FPGA 的强项是并行流水线和确定性时序，STM32 的强项是灵活的控制逻辑和丰富的外设接口，两者分工明确、各司其职，比强行用一颗芯片包揽所有任务要靠谱得多。

1.1 为什么是 FPGA 而不是 DSP 或纯 MCU

很多人第一反应是：雷达信号处理用 DSP 不就行了吗？TI 的 C6000 系列不就是干这个的？这话放在十年前没错，但现在的情况变了。LFM 脉冲压缩的核心操作是卷积或匹配滤波，数据率取决于采样率和脉冲宽度。假设 ADC 采样率 100 MSPS、量化位宽 14 bit，单个通道的数据率就是 1.4 Gbps。多通道相控阵的话，四通道就是 5.6 Gbps。这个量级的数据，DSP 靠串行指令流根本吃不下，而 FPGA 可以做到每个时钟周期并行处理多个采样点。

更关键的是确定性延迟。雷达系统对时序的要求极其苛刻——发射脉冲和接收窗口之间的切换必须在纳秒级完成，波束扫描的相位更新必须与脉冲重复周期严格同步。FPGA 的硬件逻辑天然满足这个要求，而 MCU 或 DSP 上跑操作系统或中断调度，延迟抖动可能达到微秒级，这在雷达里是不可接受的。

那为什么还要 STM32？因为 FPGA 不擅长做“决策”。比如根据上位机指令动态调整波形参数、管理多级工作模式切换、处理人机交互、记录日志、通过串口或以太网回传数据——这些任务用状态机在 FPGA 里硬写也能做，但开发效率低、修改成本高。STM32 跑裸机或 RTOS，改一行代码重新编译烧录就行，灵活得多。所以这套架构的本质是：FPGA 做“肌肉”，STM32 做“大脑”。

1.2 相控阵体制的选择：为什么是线性阵而不是平面阵

项目名里的“phased array”可以有很多种实现形式。我最终选了均匀线性阵（ULA），主要基于三点考虑。第一，线性阵的相位控制逻辑最简单，每个通道只需要一个移相量，波束只在一个维度上扫描，FPGA 里的相位累加器实现起来非常直接。第二，线性阵的通道数可以做得比较少，四到八个通道就能看到明显的波束形成效果，硬件成本和调试复杂度都在可控范围内。第三，对于验证 LFM 脉冲压缩和波束形成的基本原理来说，线性阵已经足够了，平面阵的二维扫描留到后续迭代再说。

当然，线性阵的缺点也很明显：只能在一维扫描，波束宽度受阵列孔径限制，旁瓣抑制需要额外的加权处理。但作为原型验证平台，这些都不是问题，反而可以作为后续扩展的方向。

2. 核心硬件选型与信号链拆解

硬件是整个项目的骨架，选型一旦定下来，后面的软件架构基本就跟着走了。我在选型阶段花了大概两周时间反复对比，下面把关键决策和背后的逻辑说清楚。

2.1 FPGA 选型：为什么是 Xilinx Artix-7 而不是 Cyclone 或安路

FPGA 的选型主要看三个指标：逻辑资源、高速接口能力和开发工具链成熟度。Artix-7 系列（比如 XC7A100T 或 XC7A200T）在这三个方面都比较均衡。逻辑资源方面，100T 有约 10 万个逻辑单元，跑四通道的 DDC + 匹配滤波 + FFT 绰绰有余。高速接口方面，Artix-7 的 GTP 收发器支持到 6.6 Gbps，虽然这个项目用不到这么高的速率，但 ADC 的 LVDS 接口和 DDR3 存储控制器都需要 SelectIO 资源的支持，Artix-7 在这方面很成熟。

对比来看，Altera Cyclone IV 系列逻辑资源偏少，做多通道并行处理会比较吃力；安路 FPGA 虽然性价比高，但 IP 核生态和社区资料相对薄弱，遇到问题排查起来比较费劲。Xilinx 的 Vivado 工具链虽然吃内存，但 IP 集成度高，特别是 FIR Compiler、FFT IP、DDS Compiler 这些现成的核，能省掉大量手写 RTL 的时间。

注意：Artix-7 的 BRAM 资源在做多通道 FFT 时需要仔细规划。以 1024 点 FFT 为例，每个通道需要约 2 个 18Kb BRAM 做数据缓存和旋转因子存储，四通道就是 8 个。如果再加上匹配滤波的系数存储和 DDC 的混频表，BRAM 占用会很快上去。建议在方案阶段就用 Vivado 的资源估算工具跑一遍。

2.2 STM32 的定位：为什么选 F4 而不是 F1 或 H7

STM32 在这个项目里承担的任务包括：通过 SPI 配置 FPGA 寄存器、通过 UART/USB 与上位机通信、控制发射通道的使能时序、读取温度传感器和电源监控芯片、管理 SD 卡数据存储。这些任务对算力要求不高，但对外设数量和通信稳定性要求较高。

STM32F407 是我最终的选择。它有 3 个 SPI、6 个 USART、2 个 USB OTG、1 个 CAN 控制器，外设资源刚好够用。F1 系列主频只有 72 MHz，SPI 速率和 USB 吞吐量都偏低，配置 FPGA 时可能会成为瓶颈。H7 系列性能过剩，而且 H7 的 USB 驱动和 RTOS 适配在某些版本上存在兼容性问题，调试成本反而更高。F407 的 168 MHz 主频、192 KB SRAM 和 1 MB Flash，跑一个精简的 RTOS 加上通信协议栈完全没问题。

2.3 ADC 与 DAC 的选型逻辑

ADC 是接收链路的入口，选型直接决定了系统的动态范围和灵敏度。我选的是 AD9253，四通道 14 位 125 MSPS 的流水线 ADC。为什么是 14 位而不是 12 位或 16 位？12 位的动态范围约 72 dB，对于需要检测弱小目标的雷达来说偏紧；16 位 ADC 价格翻倍，而且在这个采样率下功耗和接口复杂度都上去了。14 位提供约 84 dB 的理论动态范围，配合脉冲压缩的增益，实际系统灵敏度可以做到 -90 dBm 左右，足够验证波束形成和脉冲压缩的效果。

DAC 方面，发射波形由 FPGA 内部的 DDS IP 核生成数字信号，再通过 DAC 转换成模拟中频。我选的是 AD9767，双通道 14 位 125 MSPS，与 ADC 的采样率匹配，方便做收发时序的对齐。

2.4 时钟树设计：相控阵的命门

相控阵雷达对通道间相位一致性的要求极高。如果各通道的采样时钟存在相位偏差，波束形成的方向图就会畸变。所以时钟树的设计是整个硬件里最需要仔细对待的部分。

我的方案是：用一个低相噪的晶振（100 MHz TCXO）作为主时钟源，通过时钟分配芯片（如 AD9517）产生多路同步时钟，分别送给 ADC、DAC 和 FPGA。AD9517 的通道间偏斜可以控制在皮秒级，满足相控阵的相位一致性要求。FPGA 内部再用 MMCM 产生各个模块所需的时钟域，但所有时钟域都同源，避免异步时钟带来的相位不确定性问题。

实操心得：时钟分配芯片的配置寄存器比较多，建议先用厂商提供的评估板软件生成配置脚本，再移植到 STM32 的初始化代码里。我一开始手写寄存器配置，调了整整两天才发现是某个分频比设错了。

3. FPGA 信号处理链的详细实现

FPGA 内部是整个项目的技术核心，信号处理链的每一级都需要仔细设计。我按照数据流的方向，从 ADC 接口开始，逐级拆解。

3.1 ADC 数据接收与 LVDS 接口调试

AD9253 的输出是 LVDS 差分信号，包括数据对和随路时钟。FPGA 端需要用 SelectIO 的 ISERDES 原语做串并转换，把高速串行 LVDS 数据还原成并行数据。这里的关键是源同步时序约束。ADC 输出的随路时钟和数据之间的相位关系是固定的，但 PCB 走线长度差异会引入偏斜。Vivado 里需要用set_input_delay约束来告诉工具数据相对于时钟的到达时间，否则综合出来的时序可能不满足。

我实际调试时遇到的问题是：数据偶尔出现错位，表现为频谱上出现规律的杂散。排查后发现是 ISERDES 的位对齐没有做动态校准。解决方案是在 FPGA 里加一个简单的训练模式：ADC 输出已知的测试码型（比如递增计数），FPGA 扫描不同的位对齐设置，找到误码率最低的那个。这个训练逻辑大概花了 200 行 Verilog，但省去了反复手动调整的麻烦。

3.2 数字下变频（DDC）的实现细节

ADC 采样得到的是中频信号，需要下变频到基带才能做后续处理。DDC 的标准做法是：数字混频器 + 低通滤波器 + 抽取器。混频器的本振信号由 DDS IP 核生成，频率设置为中频频率。低通滤波器用 FIR Compiler 实现，截止频率根据信号带宽设定。

这里有一个参数选择的坑：抽取倍数和滤波器阶数的权衡。假设 ADC 采样率 100 MSPS，信号带宽 5 MHz，中频 20 MHz。下变频后，有用信号在 -5 MHz 到 +5 MHz 之间，可以用 10 倍抽取把采样率降到 10 MSPS。但抽取前的低通滤波器必须把 10 MHz 以上的分量抑制掉，否则会混叠回来。FIR 滤波器的过渡带宽度取决于阶数，阶数越高过渡带越窄但资源消耗越大。我最终选了 64 阶的 FIR，过渡带约 2 MHz，阻带衰减 60 dB，在 Artix-7 上占用约 30 个 DSP48。

3.3 脉冲压缩：匹配滤波的 FPGA 实现

LFM 脉冲压缩的本质是匹配滤波，即接收信号与发射波形的共轭反转做卷积。在 FPGA 里实现卷积有两种方式：时域直接卷积和频域 FFT 乘法。时域卷积的优点是实现简单、延迟低，缺点是运算量与脉冲宽度成正比。假设脉冲宽度 10 微秒、采样率 10 MSPS，就是 100 个采样点，时域卷积需要 100 次乘加，四通道并行就是 400 次乘加，Artix-7 的 DSP 资源勉强够用。但如果脉冲宽度增加到 100 微秒，时域卷积就不现实了。

频域方法是用 FFT 把信号和参考波形都变换到频域，相乘后再 IFFT 回来。运算量从 O(N²) 降到 O(N log N)，适合长脉冲场景。我最终选了频域方案，用 Xilinx 的 FFT IP 核做 1024 点变换，四通道分时复用同一个 FFT 核，通过仲裁逻辑调度。这样 DSP 资源占用从 400 个降到 100 个左右，代价是增加了约 20 微秒的处理延迟。

注意：FFT IP 核的配置里有一个“缩放因子”选项，决定了每级蝶形运算后的数据位宽。如果缩放不当，要么溢出导致波形失真，要么位宽浪费导致精度损失。建议先用 MATLAB 仿真确定最优缩放方案，再配置 IP 核。

3.4 波束形成的相位加权逻辑

波束形成的核心是对各通道的信号施加不同的相位偏移，使得来自特定方向的信号同相叠加。在 FPGA 里，这个相位偏移可以通过复数乘法实现：每个通道的基带信号乘以一个复系数，系数的相位由波束指向角和通道位置决定。

相位系数的计算公式是：Δφ = 2π × d × sin(θ) / λ，其中 d 是阵元间距，θ 是波束指向角，λ 是波长。假设阵元间距为半波长，θ 从 -45° 到 +45° 扫描，相位偏移范围是 -π 到 +π。FPGA 里用一个查找表存储不同角度对应的相位系数，STM32 通过 SPI 更新查找表的内容。

这里有一个精度问题：相位系数的量化位数直接影响波束指向的精度。我用的是 16 位相位量化，对应约 0.0055° 的相位分辨率，换算成波束指向误差在 0.1° 以内，足够满足原型验证的需求。

4. STM32 控制层的设计与实现

STM32 这边的工作看起来没有 FPGA 那么“硬核”，但实际调试中遇到的问题一点也不少。控制层的稳定性直接决定了整个系统能不能长时间可靠运行。

4.1 与 FPGA 的 SPI 通信协议设计

STM32 和 FPGA 之间的通信采用 SPI 接口，STM32 做主设备，FPGA 做从设备。协议设计上，我用了一个简单的寄存器映射方案：每个功能模块对应一段地址空间，STM32 通过写地址和数据来配置 FPGA 的工作参数。

具体帧格式是：1 字节命令 + 2 字节地址 + 4 字节数据。命令字节区分读/写操作，地址字段选择目标寄存器，数据字段承载实际参数。FPGA 端用一个状态机解析 SPI 帧，根据地址把数据写入对应的寄存器。

调试时踩过的坑：SPI 的时钟极性和相位（CPOL/CPHA）必须和 FPGA 端的采样逻辑匹配。我一开始用 Mode 0，结果 FPGA 在时钟上升沿采样时数据还没稳定，读回来的全是 0xFF。改成 Mode 3 后问题解决。另外，SPI 速率不要一上来就拉到最高，先用 1 MHz 调通，再逐步提高到 10 MHz 以上。

4.2 发射时序控制的实现

雷达的发射和接收是分时进行的。STM32 需要控制发射通道的使能信号，确保发射脉冲结束后再打开接收窗口。这个时序的精度要求是微秒级，STM32 的定时器可以满足。

我的做法是用 TIM2 产生一个周期性的触发信号，周期等于脉冲重复间隔（PRI）。触发信号同时送给 FPGA 和发射通道的使能电路。FPGA 收到触发后启动 DDS 生成 LFM 波形，发射通道在波形生成完毕后自动关闭，接收通道在预设的延迟后打开。整个时序链的延迟通过示波器实测校准，确保发射泄漏不会饱和接收前端。

4.3 上位机通信与数据回传

STM32 通过 USB CDC 或 UART 与上位机通信，回传处理后的雷达数据。数据率取决于工作模式：搜索模式下只回传波束扫描的角度和检测到的目标距离，数据率很低；成像模式下需要回传完整的距离-多普勒矩阵，数据率可能达到几 Mbps。

我用的是 USB CDC 虚拟串口，配置为全速模式（12 Mbps），实际吞吐量约 1 MB/s。对于原型验证来说够用了。如果后续需要更高的数据率，可以改用 STM32 的以太网外设或者 USB 高速模式。

实操心得：USB CDC 在 Windows 上有时会出现枚举失败的问题，特别是反复插拔之后。我后来在 STM32 的 USB 初始化代码里加了一个延时，等 USB 时钟稳定后再启动 CDC 接口，问题就很少出现了。

5. 系统联调与常见问题排查

联调阶段是整个项目最耗时间的部分。各个模块单独测试都正常，连在一起就出各种奇怪的问题。我把调试过程中遇到的典型问题和解决方法整理成下表，方便大家快速定位。

5.1 典型问题速查表

5.2 电源噪声对雷达性能的影响

这个问题值得单独拿出来说。雷达接收链路的灵敏度很高，电源上的微小噪声都会耦合到信号里，表现为底噪抬升或杂散。我一开始用普通的 LDO 给 ADC 供电，结果频谱上在 50 kHz 和 100 kHz 附近出现了明显的杂散，后来换成低噪声 LDO（如 ADM7150）并增加 LC 滤波，杂散降低了约 15 dB。

PCB 布局上也有讲究：模拟电源和数字电源要分开走线，ADC 的模拟输入走线要远离时钟线和数字信号线，地平面要完整不要被分割。这些看起来是基本功，但实际做的时候很容易忽略。

5.3 FPGA 时序收敛的调试经验

Artix-7 在 100 MHz 以上的时钟频率下，时序收敛可能会比较紧张。我遇到的问题是 DDC 模块的 FIR 滤波器在 125 MHz 时钟下建立时间不满足，Vivado 报了一堆时序违例。

解决方法有三个方向：一是降低时钟频率，把 FIR 的工作时钟降到 62.5 MHz，用多周期路径的方式处理；二是插入流水线寄存器，把组合逻辑打散；三是优化综合策略，用 Performance_Explore 模式让工具多花时间找最优解。我最终组合使用了后两种方法，时序违例从 200 多条降到 0。

6. 实测效果与性能评估

经过大约三个月的开发和调试，系统基本达到了设计目标。我把关键性能指标整理如下，供大家参考。

6.1 主要性能参数

6.2 实测中的意外发现

有一个现象出乎我的意料：在波束扫描到 ±40° 以上时，方向图的旁瓣电平明显升高，从 -13 dB 恶化到 -8 dB 左右。排查后发现是阵元之间的互耦效应导致的。线性阵的边缘阵元受到的互耦影响和中间阵元不同，导致各通道的实际相位响应偏离理论值。解决方法是在相位系数表里加入一个校准因子，通过实测各通道的相位响应来修正。校准后旁瓣电平恢复到 -11 dB 左右。

这个经验说明：理论仿真和实际系统之间永远有差距，特别是射频前端部分。做相控阵的时候，校准环节不能省。

6.3 与纯仿真结果的对比

我用 MATLAB 做了完整的系统仿真，包括波形生成、通道传播、接收处理、波束形成。仿真结果和实测结果的对比显示：距离维的处理基本一致，脉冲压缩后的主瓣宽度和旁瓣电平吻合度很高；但角度维的差异比较明显，主要是互耦和通道不一致性的影响。这也验证了一个观点：信号处理算法可以在仿真里验证，但阵列校准必须在实物上做。

7. 后续扩展方向与个人体会

这个项目目前完成的是基础版本的验证，后续还有不少可以扩展的方向。比如把线性阵扩展成平面阵实现二维扫描，增加多普勒处理实现动目标检测，或者把 FPGA 的处理链升级到支持更宽的带宽和更多的通道。STM32 这边也可以加入 SD 卡数据记录功能，方便离线分析。

我在这个项目里最大的体会是：FPGA 和 STM32 的协同设计，难点不在单个芯片的编程，而在两者之间的接口和时序配合。SPI 通信看起来简单，但实际调试中因为时序不匹配导致的问题占了总调试时间的三分之一以上。建议后来者在做类似项目时，先把通信接口调通，再逐步加入信号处理逻辑，不要一上来就把所有模块都连在一起。

另外一点关于相控阵的：相位一致性是相控阵的命门。时钟树、PCB 走线、通道增益、滤波器群延迟，任何一个环节的不一致都会体现在波束方向图上。我在调试阶段花了大量时间做通道校准，但这是值得的——没有校准的相控阵，波束形成效果还不如单通道。

最后分享一个调试小技巧：在 FPGA 里预留一个 ILA（集成逻辑分析仪）的触发接口，把关键信号引出来。调试时用 Vivado 的 ILA 抓波形，比用示波器一个个探点效率高得多。我甚至在 STM32 的固件里加了一个命令，可以通过 SPI 触发 FPGA 的 ILA 采集，实现软硬件联合调试。这个功能在排查偶发性问题时特别有用。