FPGA实现CameraLink相机数据转光纤传输的工程实践与调试经验

我把这几年在工业视觉项目里反复折腾 CameraLink、光纤传输和 Xilinx FPGA 的底层经验整理了一下。这篇不是产品说明书而是从一张现场问题清单出发完整记录一条“把 CameraLink 相机数据用 SFP 光口拉远到上位机”的高速链路从接口协议、高速收发器配置到底层代码组织是如何一步步落地的。尤其是中间那 4 套可以直接拿走的工程框架以及那些数据手册里不会写的坑都在下面说清楚。1. 这条链路到底在解决什么问题先花半分钟把项目背景对齐。CameraLink 是工业相机里非常常见的接口Base 配置下 28 位并行数据加 4 对 LVDS 差分时钟像素时钟最高能到 85 MHz理论带宽大概 2.04 Gbps。如果只是传 8 位灰度图、60 帧 1280 x 1024Base 规格勉强够用但一旦把分辨率拉到 2048 x 2048或者帧率提到 100 帧以上2.04 Gbps 就成了天花板。更要命的是CameraLink 线缆通常只能跑 3 米到 10 米产线上相机和控制器的距离一旦超过这个范围信号质量断崖式下跌。我之前做的一个半导体检测项目就卡在这相机装在设备深处工控机离了快 15 米CameraLink 走铜缆根本没法稳定工作。当时有两条路——换 CameraLink 长线中继器或者把数据转成光口走光纤。前者贵、延迟大、还只能点对点后者带宽高、抗干扰强、传输距离轻松上百米关键是链路中间还能串光交换机做多路汇聚。所以我选了更通用的方案FPGA 做 CameraLink 接收端内部做数据整理和缓存再通过 GT Transceivers Wizard 配置高速收发器走 Aurora 8B/10B 协议把数据降到 SFP 光模块上最后光纤到对面接收板卡恢复 CameraLink 或直接 PCIe 上上位机。“FPGA 收 CameraLink 数据、GTX 转 Aurora、SFP 出光”这条链路本质上就是把相机的并行接口数据重新封装成适合长距离传输的串行协议。开发重点是三个部分CameraLink 接口的物理层对接、FPGA 内部的跨时钟域数据处理、以及 GTX/Aurora 的可靠传输。再加上配套的 4 套工程源码其实就是对应不同相机的像素格式和带宽需求避免了每次项目都从头写接口逻辑。2. CameraLink 接口细节必须先吃透这个项目里最容易翻车的地方不是光口部分反而是 CameraLink 的接收端。很多人拿到相机第一件事就是对着资料写逻辑结果发现图像花屏、缺行、颜色错乱折腾一整天最后发现是信号约束或者相机驱动配置的问题。2.1 Base 配置的接线和时钟恢复CameraLink Base 配置一共需要 4 对 LVDS 数据线和 1 对时钟线。相机端发出来的时钟是差分时钟FPGA 这边通常用 IBUFDS 原语把差分信号转成单端。关键点在于这个时钟必须进全局时钟网络BUFG再分发到逻辑里同时你要对相机时钟做相位对齐。很多低成本的 CameraLink 接收方案用的是延时链做动态相位调整但实际项目里我更推荐在 FPGA 里例化 IDELAYE2 对每个 LVDS 通道做 per-bit 延时校准。下面是从工程里摘出来的时钟和数据接收框架Base 模式8 位灰度wire clk_p, clk_n; wire clk_cam_single; IBUFDS #( .DIFF_TERM (TRUE), .IOSTANDARD (LVDS_25) ) u_ibufgds_clk ( .I (clk_p), .B (clk_n), .O (clk_cam_single) ); BUFG u_bufg_clk ( .I (clk_cam_single), .O (clk_cam_bufg) );这段代码只是起点。真正要命的是 CameraLink 把 28 位并行数据分成了 3 个 8 位通道Port A/B/C外加一位 FVAL帧有效、一位 LVAL行有效、一位 DVAL数据有效。如果相机是 8 位灰度那么 A/B/C 三个通道拼起来其实是 24 位数据实际只用了 8 位剩下 16 位是补零还是复用到其他信号完全取决于到底用的是 Base、Medium 还是 Full 配置。2.2 一个坑数据时钟是 DDR 还是 SDR我第一次做这个项目的时候被一个细节坑过CameraLink 的数据是在时钟的上下沿都采样的也就是说它是 DDR 传输。而 GTX 和下游的图像处理模块绝大部分都是单沿SDR逻辑。中间必须做 DDR 转 SDR 的处理否则数据吞吐会掉一半。Xilinx 提供了现成的 IDDR 原语我通常直接例化两个 IDDR分别采上升沿和下降沿然后把两路拼成一个 16 位宽的 SDR 数据流。这个过程看似简单但对时序要求非常高尤其是 IDELAYE2 的调节步进。如果延时设置不对采到的数据会周期性出现错位表现出来就是图像上的固定条纹。后来我把这部分封装成了一个可复用的模块参数化数据位宽和延时值核心逻辑如下wire [3:0] data_p, data_n; wire [3:0] data_ddr; wire [7:0] data_sdr; genvar i; generate for (i 0; i 4; i i 1) begin : gen_idelay IDELAYE2 #( .IDELAY_TYPE (FIXED), .DELAY_SRC (IDATAIN), .IDELAY_VALUE (tap_value[i]) ) u_idelay ( .IDATAIN (data_p[i]), .DATAOUT (data_delayed[i]), .C (clk_cam_bufg), .CE (1b0), .INC (1b0), .CINVCTRL(1b0), .CNTVALUEIN(5d0), .CNTVALUEOUT(), .LD (1b0), .LDPIPEEN(1b0), .REGRST (1b0) ); end endgenerate IBUFDS_DIFF_OUT #( .DIFF_TERM(TRUE), .IOSTANDARD(LVDS_25) ) u_ibufds_data ( .I (data_p[i]), .B (data_n[i]), .O (data_ibuf), .OB (data_ibuf_b) ); IDDR #( .DDR_CLK_EDGE (SAME_EDGE_PIPELINED), .INIT_Q1 (1b0), .INIT_Q2 (1b0), .SRTYPE (SYNC) ) u_iddr ( .Q1 (data_ddr_rise), .Q2 (data_ddr_fall), .C (clk_cam_bufg), .CE (1b1), .D (data_ibuf), .R (1b0), .S (1b0) );这段代码配合上后面要讲的 tap_value 自动校准算法基本可以应对 85 MHz 以内的 CameraLink 输入时钟。再高的时钟建议直接上硬核或者更专业的 CameraLink 接收芯片不然时序收敛会让人想砸电脑。2.3 FVAL/LVAL/DVAL 的同步与消抖CameraLink 的帧同步信号 FVAL、行同步信号 LVAL不少相机输出并不是严格的全局同步尤其是一些低端工业相机在帧边界会出现几百纳秒的毛刺。如果直接拿来做 FIFO 写使能大概率会出现偶发丢帧。我的做法是先把这三个信号打两拍同步到像素时钟域再做一次边沿检测和毛刺滤除。具体的实现可以简单一点——连续采到 3 个同样的电平才认为是有效信号。这个逻辑不吃资源但能挡掉绝大多数毛刺。下面是一个典型的行场同步滤波逻辑片段reg [2:0] fval_sync, lval_sync; reg fval_filtered, lval_filtered; always (posedge clk_cam_bufg) begin fval_sync {fval_sync[1:0], fval_in}; lval_sync {lval_sync[1:0], lval_in}; if (fval_sync 3b000) fval_filtered 1b0; else if (fval_sync 3b111) fval_filtered 1b1; if (lval_sync 3b000) lval_filtered 1b0; else if (lval_sync 3b111) lval_filtered 1b1; end不要小看这个 filter。在实际产线上相机和 FPGA 板卡会用比较长的排线连起来电磁环境差一点一组毛刺打进来图像处理模块就会把一帧坏数据当成正常数据送出去上位机那边的缺陷检测就会误报。每加一个这种保护逻辑现场调试的时间就少半天。3. GT Transceivers Wizard 与 Aurora 8B/10B 的配置思路数据从 CameraLink 进来之后经过跨时钟域 FIFO 和打包逻辑接下来就进入高速传输部分。这里用到的两个核心 IP 是 GT Transceivers Wizard 和 Aurora 8B/10B。3.1 为什么要用 Aurora 而不是自己写 SerDes很多新手会问光口不就是把并行数据转串行发出去吗直接自己写一个并转串逻辑不就行了答案是可以但不推荐。原因有两点第一FPGA 里真正的并转串靠的是 GTX/GTH 高速收发器这些收发器内部有 PCS/PMA 层包含 8B/10B 编解码、时钟恢复、弹性缓冲、通道绑定等一系列复杂功能全部用用户逻辑实现不现实而且时序极难收敛。第二Aurora 8B/10B 协议是一款轻量级、开源Xilinx 提供的 IP 核免费的高速链路层协议。它把 GTX 收发器封装成了更友好的用户接口自动处理通道初始化、时钟补偿、流量控制等机制。说白了你只需要关心用户侧的数据怎么塞进去、怎么拿出来就行GTX 底层那些链路训练、字节对齐、逗号检测的细节Aurora 核都帮你挡掉了。用 GT Transceivers Wizard 单独配置 GTX 很灵活比如做自定义协议或者串行收发调试但真要稳定传输图像数据Aurora 是更成熟可靠的选择。这个项目里我用的是 Aurora 8B/10B单通道、线速率设成 2.5 Gbps 或者 5 Gbps看具体 SFP 模块的支持情况。3.2 GT Transceivers Wizard 里的关键参数配置 GT Transceivers Wizard 时我在意的不是默认选项而是下面这几个容易踩坑的参数Line Rate线速率根据 Aurora IP 侧的期望带宽和 SFP 模块支持范围来定。比如 Base 模式 2.04 Gbps 的图像数据流加上 Aurora 协议开销帧头、CRC、时钟补偿字符真实的 GTX 线速率我一般设 2.5 Gbps。如果是更高带宽的 Full 配置就需要 5 Gbps 或以上。RefClk 频率GTX 的参考时钟一般是 125 MHz 或者 156.25 MHz取决于线速率和 PLL 配置。内部 QPLL 或者 CPLL 会根据参考时钟自动分频倍频这个值一定不能拍脑袋定。TX/RX 极性SFP 模块和 FPGA 之间走的是差分对如果 PCB 布线时不小心把正负反了可以通过 TX/RX Polarity 选项在 GT 内部直接修省去改板的麻烦。RX Equalizer这个参数有点像示波器探头上的滤波补偿。SFP 模块出来的信号经过连接器和过孔会不同程度地产生损耗和码间干扰GTX 内部的 RX Equalizer 能做一些 boost 补偿。实际调试中如果误码率偏高优先调节这个参数。下面是一个典型 GTX 配置参数表单通道 2.5Gbps 示例方便对照自己的工程参数项推荐值说明Line Rate2.5 Gbps与 Aurora 侧一致RefClk125 MHz参考时钟源TX/RX PolarityFalse/True可选用于修正PCB差分对反接RX EqualizerAuto/Manual推荐先自动链路不稳切手动8B/10B EncodingAurora 核自动配置GTX 内部使能弹性缓冲由 Aurora 核管理不需要手动打开3.3 Aurora 8B/10B 核配置时的三个细节Aurora 8B/10B 核的配置向导也很直白无非是选择线速率、通道数、流控模式和接口类型。我在这里仅说三个经常被忽略的地方第一个是 Flow Control。Aurora 协议支持用户流控User Flow Control和原语流控。做图像传输时如果上游相机的速度快于下游光纤接收端 DMA 写入内存的速度就一定要开启用户流控在接收端 FIFO 快满时能反向告诉发送端“你等一下”。否则图像数据在光纤中途丢包或者接收端 FIFO 溢出表现就是图像撕裂。第二个是 User Interface 选择。Aurora 核的用户接口通常有两种模式Framing 和 Streaming。CameraLink 图像是分包 帧结构用 Framing 模式更自然可以保证每一帧图像作为完整的数据包传输接收端按帧边界恢复时序。Streaming 模式更偏字节流适合高速采集比如 ADC 数据但图像帧边界需要自己额外定义增加了设计复杂度。第三个是 Error 处理。Aurora 核会输出硬错误、软错误、通道未对齐等信号。实际项目里一定要把这些状态脚引出来单独做成指示灯或者 GPIO。否则整条链路已经跑飞了你还在那边调 CameraLink 延时根本找不到问题在哪。4. 四套工程源码的核心差异与选型建议这个项目打包了 4 套可以直接改用的工程源码。给人感觉好像只是数量多实际上这 4 套工程分别对应了不同像素格式、不同 CameraLink 配置和不同下游处理需求。用错了工程等于开卷考试拿了别人的卷子硬写自己名字。4.1 工程 ABase 8 位灰度 60 帧这套工程最简单适合刚上手做 CameraLink 转光纤的人。像素数据只有 8 位FVAL/LVAL/DVAL 控制简单GTX 线速率 2.5 Gbps 就够用。CameraLink 接收端只需要处理 3 个 8 位通道中真正有效的 1 个或 2 个通道。图像数据在 FPGA 内部直接当字节流打包进 AuroraFIFO 深度可以设小一点比如 1K x 8 bit。接收端解包后直接用 FIFO 读数据拼 RGB888 或者灰度图。选型建议如果你手里的相机是 CameraLink Base 规格、分辨率 1280 x 1024 60fps 以内选这套验证链路最省时间。4.2 工程 BBase 24 位彩色或双通道拼接彩色相机的数据量比灰度大了 3 倍。CameraLink Base 模式下三个 8 位通道刚好可以分别作为 R、G、B 数据。这套工程里的 CameraLink 接收模块需要把 A/B/C 三个通道的 DDR 数据全部采下来然后拼成 24 位并行数据再打到一个更宽的 FIFO 里。Aurora 侧的带宽也要相应提高线速率建议拉到 3.125 Gbps 或更高。选型建议工业检测里最常见的彩色线阵相机或者 200 万像素以下的彩色面阵相机直接参考这套工程。4.3 工程 CFull 配置 80 位数据带宽Full 配置的 CameraLink 把数据带宽扩展到了 80 位需要两路甚至更多的 GTX 通道绑定传输。此时 Aurora 8B/10B 核配置为多通道模式GTX 的差分对也需要从 1 对变成 2 对或 4 对。工程里比较关键的是通道绑定和绑定状态机的设计Aurora 核已经内置了通道对齐的机制但你需要在用户逻辑里保证多通道的数据拆分与重组顺序正确。选型建议2K x 2K 以上的高速面阵相机或者线阵相机行频特别高的场景别犹豫直接看这套工程。它对时序收敛的要求高很多建议先跑上板验证再改逻辑。4.4 工程 D带 DDR3 缓存的完整链路这套工程是在 C 或 A 的基础上增加了 DDR3 缓存的架构。为什么需要缓存因为工业相机的输出帧率往往不是稳定的尤其是外部触发模式可能一秒内突然来几帧大图下一段时间又空闲。如果不加缓存直接走 Aurora接收端的 DMA 或者显示模块很容易被突发数据打满。而加了一片 DDR3 之后整个链路变成了“CameraLink 到 DDR3 写入 DDR3 到 Aurora 读出”两个相对独立的阶段中间通过读写指针管理帧缓冲。这套工程也是 4 套里最复杂的它已经包含一个简单的跨时钟域帧管理模块。选型建议如果是做成通用的图像采集卡或者要带 Binning、ROI 等预处理功能强烈建议用这套。后续扩展也最容易因为数据已经落到 DDR3 了做算法处理或者多路分发都方便。5. 实操过程上板调试与代码移植要点配置好 IP 核、确定了工程模板剩下就是上板调试。这部分实际上是项目周期里最耗时的一环。我不打算流水账一样把所有步骤都列出来只说那几个决定成败的环节。5.1 CameraLink 延时的自动校准与验证前面提到 IDELAYE2 的 tap_value 是动态确定的。我在实际调试中写了一个基于 scan 的校准逻辑复位后先输出一个测试图像在 FPGA 内部产生棋盘格而不是接相机然后从 0 开始逐渐增大每个通道的 IDELAY tap 值同时检测接收到的图像是否出现花屏。如果固定某一段 tap 区间内图像完全干净记录下来并作为正式工作时的锁定值。这个方案听起来简单但有一个细节必须注意CameraLink 的 4 个 LVDS 通道的走线长度可能不一致每个通道的最佳延时值都不一样所以要分通道独立校准。我见过有人偷懒所有通道统一用同一个 tap 值结果换了根线缆之后图像就开始偏色其实就是不同通道的相位裕量不够了。校准完成后最好在工程里保留一个回读接口这样上位机可以通过串口或者 JTAG 实时读取当前的延时值方便产线排查问题。5.2 Aurora 链路的建立与误码率测试Aurora 链路起来之后第一件事不是传图像而是做误码率测试。最简单高效的办法是在发送端塞一个 PRBS 伪随机序列接收端用本地同步的 PRBS 生成器做比对。Xilinx ISE/Vivado 环境下可以直接用 IBERT 工具也可以自己写一个简单的 PRBS 模块挂到 Aurora 的用户接口上。在 2.5 Gbps 下连续跑 30 分钟无错基本可以认为物理链路是可靠的。如果出现偶发误码优先查 SFP 模块的电源噪声和 GTX 参考时钟的抖动其次才是代码逻辑问题。我还习惯在 Aurora 核的复位管理上做一次“软复位”。很多现场问题都是因为链路建立之后远端相机重新上电导致 Aurora 核检测到 Receive Channel 掉线。这时候发送端和接收端必须同时重新初始化否则只有一侧恢复数据就永远对不齐。工程里我增加了一个 watchdog 模块专门监测 Aurora 核的 channel_up 信号如果拉低超过 10 ms自动对整个数据链路做一次全局复位。5.3 时钟方案设计时钟是这套系统的生命线。CameraLink 输入进来的像素时钟是异步的Aurora 侧的用户时钟是 GTX 恢复出来的二者不在同一时钟域中间必须用异步 FIFO 隔离。FIFO 的读时钟也就是 Aurora 发送端用户时钟由 GTX 的 TXOUTCLK 分频或直接使用。接收端的恢复时钟由 Aurora 核自带通常不需要额外处理。一个很容易踩的坑是很多人的 CameraLink 时钟是 85 MHz但 GTX 线速率 2.5 Gbps 在 8B/10B 编码下的有效用户时钟是 250 MHz2.5 Gbps / 10 bit 250 M symbol/s。两个时钟完全不是一个数量级所以 FIFO 的读使能不能一股脑全开必须按自己打包的数据总量来控制。工程里我通常的做法是把 CameraLink 侧的帧数据打包成“帧头 行数据 帧尾”的结构帧头里写上这一帧的总字节数接收端解析完再处理。这样即使 FIFO 偶尔空一下也不至于丢掉整帧。6. 常见问题与排查技巧一览做这类高速接口项目没有一个晚上不被一点小问题绊住。下面列几个我实际踩过、且反复被问到的坑做成速查表方便对号入座。现象可能原因排查思路图像整体偏移或错位CameraLink IDELAY 值不匹配重新做 per-channel 延时校准检查各通道 tap 值差异图像固定条纹DDR转SDR提取逻辑有误确认 IDDR 的时序检查是否用了 SAME_EDGE_PIPELINED 模式偶尔丢帧FVAL/LVAL 毛刺检查同步滤波逻辑必要时加宽 filter 长度Aurora Channel Up 频繁掉线SFP 光功率不够或 GXT 参考时钟抖动大用 IBERT 或者光功率计测链路损耗检查 SFP 供电是否稳定接收端 FIFO 溢出上游带宽大于下游处理带宽开启 Aurora 用户流控并在接收端加大 FIFO 深度长时间运行后死机DDR3 读写跨时钟域没处理好仔细检查读写指针同步确保使用格雷码跨时钟域传输还有一个非常容易被忽略的小细节CameraLink 通道里的 DVAL 信号。部分相机在非有效数据区会把 DVAL 拉低而不是只用 FVAL/LVAL 嵌套表示。如果你的图像分割逻辑只判断 FVAL 和 LVAL很可能会把一行的填充数据当作有效像素送出去导致图像右侧出现一条伪彩边。做数据打包的时候尽量把 DVAL 也纳入写使能判断宁可少采几个像素不要采进垃圾数据。7. 工程源码的目录结构与移植建议四套工程源码的目录结构我都是按同一个标准组织的分别是camera_link_rx/、frame_process/、aurora_tx/、aurora_rx/、user_logic/。因为这个项目需要同时支持发送端CameraLink转光纤和接收端光纤转下一代设备比如 PCIe所以收发的代码是分开组织的避免一套工程互相干扰。camera_link_rx/负责 CameraLink 的物理层接收、DDR 转 SDR、行场帧同步提取。frame_process/负责图像数据打包、FIFO 缓存、跨时钟域处理。aurora_tx/和aurora_rx/是对 Aurora 8B/10B IP 核的一层封装会把 channel_up、hard_err、soft_err 等状态信号引到顶层。user_logic/放的是可修改的业务逻辑比如图像算法、串口指令、LED 指示灯控制。移植到新项目时大多数人只会改user_logic/和frame_process/里的参数不需要动camera_link_rx/那一大堆 LVDS 原语实例和 GTX 初始化逻辑。如果真的需要改 CameraLink 配置比如从 Base 升级到 Full那么camera_link_rx/的顶层接口和位宽映射都要同步动。为了减少这种改动风险我一律把接口定义放到一个单独的pkg_camera_link.vh头文件里参数改动一处就全项目生效要不然改来改去很容易遗漏某个子模块的位宽连接编译半天报一堆一堆的连线错误。再说一下版本和软件环境。这套代码我用的是 Vivado 2019.2 以上版本芯片型号从 Artix-7 到 Kintex-7 的 GTX 都能用如果是 Kintex UltraScale 系列的 GTHAurora 核的配置向导会有些许不同但整体逻辑结构保持兼容。GT Transceivers Wizard 的 IP 核版本在不同 Vivado 里会自动升级个别引脚名会有变化移植到新版本时留意一下 IP 生成的例化模板就好。8. 一点个人体会调试这种 FPGA 长链路项目最容易犯的错就是一上来直接调 IP 核参数。其实整个系统里最核心、最不稳定的部分往往不是光口而是 CameraLink 的物理层对接。你花一个下午把 IDELAY 校准逻辑调稳了后面 Aurora 链路几乎是一马平川反过来如果你在 LVDS 信号没调稳的情况下去调 GTX 均衡就会发现误码率总是忽高忽低排查一整天都找不出头绪。根据我的经验建议按这个顺序推进项目先用 IBERT 单独验证 GTX 和光模块物理链路再跑 Aurora 核回环测试然后接 CameraLink 信号做延时校准最后才把整条链路串起来跑图像。把每一步验证干净再往前走看似多花时间实际上比一锅端到最后再来查问题高效得多。希望这套工程和这些调试思路能帮你在下一块板子上少熬几个夜。