1. 星载图像处理任务与FPGA角色定位

遥感卫星在轨获取的图像数据量正在快速增长。以一台典型的多光谱推扫式相机为例，若探测器为 4096 像元、每像元 12 bit 量化、行频 8 kHz，则单谱段原始数据率约为 4096 × 12 × 8000 ≈ 393 Mbps；若同时输出可见光近红外 8 个谱段，原始数据率可达 3 Gbps 量级。而星地数传链路在多数低轨任务中只有几百 Mbps 的有效带宽，且每天仅有数次过境窗口。这意味着：如果不在星上先做处理，大量数据要么被丢弃，要么只能降分辨率、降帧率下传，遥感信息的时效性和可用性都会大打折扣。

星上实时处理的需求由此产生，并且可以归纳为三类典型任务。第一类是数据压缩与降码率，包括无损/近无损压缩、感兴趣区域（ROI）优先编码，目标是在保真度可接受的前提下把数据率压到数传带宽以内。第二类是几何与辐射预处理，例如非均匀性校正、坏像元替换、条带噪声抑制、辐射定标系数应用，使下传数据直接可用。第三类是在轨智能提取，如云检测、舰船/火点/溢油目标检测、变化检测，只把目标切片和元数据下传，把“数据下传”变成“信息下传”。这三类任务对计算的要求不同，但共同点是：必须在严格的功耗、体积和可靠性约束下，以流水线方式持续吞吐。

为什么是 FPGA，而不是 CPU 或 GPU？关键在于星载环境的约束与图像流水线的数据特征。星上单机通常限定在几瓦到几十瓦功耗、无主动散热、且要承受总剂量与单粒子效应；同时图像处理是典型的“像素流进、像素流出”结构，天然适合空间并行与流水线并行。FPGA 可以在每个时钟周期同时处理多个像素，用查找表、DSP 切片和块 RAM 搭建定点的卷积、滤波、统计与编码逻辑，做到“一个时钟一段处理”，延迟可预测、吞吐可确定。相比之下，CPU 的指令级串行与缓存不确定性难以稳定满足行频实时性，GPU 虽然算力高，但功耗与抗辐照加固代价在多数小卫星任务中难以接受。

把 FPGA 放回整条星上图像处理链路来看，它的位置非常明确：位于探测器前端与数传/存储后端之间，承担“实时、定流、低延迟”的那一段处理。典型信号链是：焦平面探测器 → 模拟前端 AFE（相关双采样、可编程增益放大、ADC 量化）→ FPGA 接收与预处理 → 压缩/智能处理 → 存储或数传。FPGA 在这里既是数据通道的“交通枢纽”，也是算力的“第一现场”。它需要完成高速串行/并行接口接收、跨时钟域处理、行缓存与窗口生成、定点运算、以及向下游输出标准格式码流。

下面这张图给出一个典型的星载图像处理信号链与 FPGA 内部功能划分，帮助建立“数据从哪来、在 FPGA 里经过什么、到哪去”的整体位置感。

从图中可以看到，FPGA 并不是孤立地“做算法”，而是嵌在一条有明确上下游的链路中。上游是探测器和 AFE，决定了数据格式、位宽和时序；下游是存储与数传，决定了输出码率、帧格式和接口协议。FPGA 内部则按“接口接收—缓存与窗口—预处理—压缩/智能—封装输出”的顺序组织流水线，每一级都在同一像素节拍下工作。理解这条链路，是后续设计流水线架构、分配资源和评估时序的基础。

在工程实践中，判断 FPGA 是否适合承担某一处理任务，通常看三个条件：一是数据是否以规则流形式到达，二是算法能否用定点、有限窗口或可展开的迭代实现，三是实时性要求是否高于通用处理器的确定性能力。以 3×3 中值滤波为例，若行频 8 kHz、每行 4096 像素，则像素时钟约 32.8 MHz；FPGA 用三行 BRAM 缓存加比较网络，可在每个时钟输出一个滤波结果，延迟仅几行，完全满足实时性。而如果换成需要全局迭代优化的复杂反演算法，FPGA 实现代价会急剧上升，这时更适合“FPGA 做预处理 + 下传后地面精处理”的分工。