10Gbps实时图像重采样：一个FPGA项目的完整交付复盘-平芜编程栈

用一个项目复盘这一系列的文章描述的实战内容，仅供参考。项目背景：这是某军工单位的项目，核心需求是：ADC采集图像传感器数据后，在FPGA内完成实时重采样，输出满足后端处理要求的图像数据流。

硬指标：

这类项目的特点：指标看着不多，但每一个都在挑战FPGA的极限。10Gbps在FPGA里不算高，但“10Gbps + us级延迟 + 非线性重采样”三个条件同时成立，难度呈指数级上升。

数据流路径

ADC → FIFO缓冲 → 边缘检测 → 重采样映射 → 输出FIFO → 后端

初看是一条直线，但实际要做成三级流水线 + 双缓冲，原因后面说。

存储方案选型
重采样的核心是查找表。映射关系是非线性的，无法用公式实时计算，必须预存映射表。

最终选了URAM，但需要解决一个关键问题：URAM数量有限，映射表大小超过单块URAM容量，必须分块 + 地址预计算，让查表请求在流水线里提前一个周期准备好地址。

这个决策的代价是：流水线深度增加2级，但延迟仍在us级内，可以接受。

问题现象：
仿真一切正常，上板后高频输入时输出图像出现周期性畸变，不是随机噪声，是固定位置的像素错误。

根本原因：
URAM读端口出现并发访问冲突。重采样存在多路并行查表请求，多个读指令抢占同一读端口，造成流水线停顿、图像出现周期性畸变。

解决思路：
URAM做成多端口伪实现——用多块URAM分片存储映射表，每片独立读端口，查表请求根据地址哈希分散到不同URAM片。代价是URAM占用翻倍，但10Gbps吞吐下这是唯一解。

详见F学社《SerDes实战第4篇：GTX/GTH收发器配置》—— URAM/BRAM资源规划与带宽计算

问题现象：
功能正确后，测量端到端延迟，发现是3.2us，超了客户要求的1us上限。

根本原因：
为满足10Gbps吞吐能力，初始设计划分出9个功能流水线阶段，链路总延迟达到3.2μs，超出指标要求。

解决思路：
我们通过任务重叠、模块合并重构数据流，将功能阶段优化至5个，最终端到端延迟降至0.8μs，符合要求。

关键教训：延迟优化不是砍功能，是重新排布数据流的时空关系。

本次延迟为全链路实测值，包含ADC接口、数据处理、输出链路等全部开销，采用高速示波器完成测量。
详见F学社《AXI协议实战第2篇：AXI4-Full突发传输》—— 突发深度与流水线效率的平衡

问题现象：
客户要求在运行时可以动态更新映射表（因为成像条件变化，映射关系需要微调），但直接更新URAM会导致正在进行的重采样用错表项，输出图像出现“撕裂”。

解决思路：
双缓冲URAM。两块URAM交替使用：

切换时机必须是帧间，不能在帧中间切换。这个“帧间切换”的逻辑看起来简单，但实际操作中有个隐蔽坑：如果更新速度赶不上帧率（映射表太大，一帧时间内没更新完URAM_B），需要主动降帧率或者丢弃更新请求，不能让切换发生在帧中间。

🔗详见F学社《AXI协议实战第4篇：AXI跨时钟域与数据一致性》—— 多时钟域下的数据一致性保证

问题现象：
输出图像的边缘位置总是偏，不是完全错，是系统性偏移几个像素，和方向有关。

根本原因：
边缘检测模块输出的有效像素坐标，和重采样模块期望的输入坐标，原点定义不同。边缘检测以“检测到的边缘中心”为原点，重采样以“输入图像左上角”为原点，两个坐标系没有做显式转换，导致系统性偏差。

解决思路：
看起来是个小问题，但定位花了两天。因为偏移是系统性的，不是随机的，很容易被误判为“映射表参数不对”，在错误方向上调了很久。

最终解决就是在两个模块之间加一个坐标转换层，把边缘检测的坐标映射到重采样的坐标系，3行代码，但找对位置花了一天半。

关键教训：模块接口不仅要通数据，还要对齐语义。数据能流通不代表语义正确。

🔗详见F学社《AXI协议实战第3篇：AXI-Stream反压与背靠背传输》—— 接口语义对齐与握手协议设计

客户验收通过，项目交付。

指标要拆解到每个模块，不能只看整体
10Gbps是整体指标，但真正卡瓶颈的是“URAM读端口能不能在一个周期内响应多个查表请求”。整体的10Gbps掩盖了局部的冲突。
延迟优化 = 重新排布，不是砍功能
很多人面对延迟超标第一反应是“减少功能”，但真正有效的是重新排布数据流的时空关系，让可以并行的事情并行，让必须串行的路径尽量短。
动态更新 = 状态机设计问题
能动态更新是功能需求，但“更新不影响正在进行的处理”是架构需求。后者往往比前者难，需要在架构设计阶段就考虑，不能事后打补丁。
接口语义对齐比接口连通更重要
数据能从一个模块流到下一个模块，不代表两个模块对数据的理解一致。系统性偏差比随机错误更难定位。