2. FPGA器件与开发流程

任务载荷实时数据处理对FPGA的要求，与普通接口逻辑或低速控制有本质区别：数据率高、并行通道多、算法链路长、时序余量小，而且一旦上星或装机，修改代价极高。因此，器件选型和开发流程必须围绕“算力—存储—接口—时序—可验证性”这条主线展开，而不是先选一个开发板再往上堆功能。

一、资源选型：先算清需求，再对照器件手册

选型的第一步不是看型号，而是把载荷处理链路拆成可量化的资源需求。以一条典型的遥感载荷实时处理链路为例：输入为4路LVDS，每路速率800 Mbps，总输入3.2 Gbps；前端做去噪与通道均衡，中间做FFT或卷积，后端做目标检测与打包输出。此时需要估算四类资源：

• 逻辑资源：并行乘法器、加法树、状态机、仲裁逻辑。若每时钟需完成256次复数乘加，按每DSP可做1次18×18乘加估算，至少需要256个DSP切片，再留30%余量。
• 存储资源：行缓存、帧缓存、系数表、中间结果。例如一帧4096×256、16 bit，单帧约2 MB，若做三行缓存加一帧乒乓，则需约4 MB片上RAM或外挂DDR。
• 接口资源：高速收发器、LVDS、DDR控制器、SRIO/PCIe/AXI等。3.2 Gbps输入若走LVDS，需确认器件LVDS接收通道数与最高速率；若走GTY，则需确认收发器数量和参考时钟架构。
• 时钟与布线资源：全局时钟、区域时钟、MMCM/PLL数量，以及高速信号可用的Bank和引脚。

把上述需求整理成一张“需求—器件”对照表，再对照Xilinx Kintex-7、Zynq UltraScale+、Artix-7或国产同等级器件的手册逐项核对。选型时不要只看最大型号，而要看“最接近且留有余量”的型号：DSP和BRAM余量建议不低于25%，高速收发器余量不低于20%，否则后期算法迭代或接口扩展会非常被动。

二、时序约束：把“能跑”变成“可重复地跑”

很多FPGA设计在实验室能跑，但换温度、换批次或换综合策略后就不稳定，根因往往不是逻辑错，而是时序约束不完整。面向载荷处理，时序约束至少要覆盖四类路径：

1. 主时钟约束：用create_clock定义输入时钟周期，例如200 MHz对应5 ns。若时钟由MMCM倍频到400 MHz，则需对MMCM输出自动派生或手动约束。
2. 输入/输出延迟约束：用set_input_delay和set_output_delay描述外部器件到FPGA引脚、FPGA引脚到外部器件的时序关系。例如DDR源同步接口需同时约束时钟与数据之间的偏斜。
3. 跨时钟域约束：用set_clock_groups -asynchronous或set_false_path隔离异步时钟域，避免工具在无关路径上浪费优化，同时防止漏约束导致亚稳态。
4. 多周期路径与例外：对乘法器流水线、大位宽加法树等允许跨多周期的路径，用set_multicycle_path放宽约束，但必须确认功能上确实允许。

约束完成后，必须看综合与实现报告中的WNS、TNS、WHS、THS。若WNS为负，优先检查是否漏约束或约束过紧；若WNS为正但余量小于0.3 ns，建议通过插入流水线、降低扇出或调整布局来增加余量。对载荷处理而言，时序余量本身就是可靠性指标。

三、综合实现与板级验证：从RTL到可复现的硬件

综合阶段要关注三点：一是综合策略，面积优先还是时序优先；二是资源映射是否合理，例如DSP是否被正确推断、BRAM是否被正确例化；三是是否出现大量LUTRAM替代BRAM导致布线拥塞。实现阶段则重点看布局布线后的资源利用率、时钟树和拥塞报告。若某区域拥塞严重，可通过Pblock约束把相关逻辑绑定到特定区域，或调整流水线层级。

板级验证不能只靠“下载后灯亮了”。建议按以下顺序推进：

• 静态检查：确认引脚约束、电平标准、Bank电压与外部器件一致。
• 时钟与复位验证：用示波器或ILA确认时钟频率、占空比和复位释放时序。
• 接口回环：先做LVDS或GTY内部回环，再对接外部源，逐步定位链路问题。
• 数据通路验证：用ILA抓取关键节点，对比输入激励与输出结果，确认算法链路无误。
• 长时间运行：在高温或满负荷下连续运行，观察误码率、温度与电源波动。

把上述流程串起来，可以看到FPGA开发不是“写代码—综合—下载”的线性动作，而是一个以时序和验证为约束的闭环：需求量化决定选型边界，选型边界决定约束策略，约束策略影响综合实现结果，板级验证又反过来修正需求和约束。对载荷处理而言，最值得投入时间的不是反复改RTL，而是在前期把资源账算清、把时序约束写全、把验证路径设计好。这样即使算法迭代，也能在可控范围内快速收敛。