做机器视觉项目的同学应该都懂CameraLink相机最让人头疼的往往不是价格而是那根传输线。标准CameraLink线缆有效距离基本上被限制在10米以内一旦超过这个距离信号完整性问题就会接踵而至花屏、闪断、偶发性丢帧排查起来非常痛苦。我去年接手一个产线改造项目相机装在移动小车上控制机柜在30米开外最初试着加长线缆跑到12米就开始出现异常最后只能另想办法。最终敲定的方案是用FPGA做一次协议转换把CameraLink数据流重新组织之后通过GT Transceivers Wizard配置出来的高速收发通道经过Aurora 8B10B架构编码经由SFP光模块走光纤传输到对面。这套路跑通之后稳定性和灵活性都很理想而且整个方案是可以复制的。如果你也在研究CameraLink远距离传输、同时手里有FPGA开发板和光模块或者本身就在做类似的高速图像采集和转发这篇内容应该能帮你把整个链路的工程细节串起来。标题里提到的4套工程源码我后面会专门讲怎么组织、怎么拿来改到自己板子上这里先顺着技术链路往下拆。1. CameraLink远传的困境为什么最终选择了FPGA光口方案1.1 线缆长度限制只是表面问题CameraLink线缆标称距离其实是10米这个数值并不是厂商随便给的。CameraLink在物理层是LVDS差分信号差分传输在抗干扰和速度方面有天然优势但LVDS也受制于线缆的寄生电容、阻抗连续性和地电位差。超过十米之后就算信号不立刻失效传输误码率也会明显抬升表现为高分辨率下的雪花点、扫描线错位或者直接黑屏。工程上确实有CameraLink中继器或者延长器产品但中继器本质上只是把LVDS信号整形放大并不能解决长距离分布带来的地环路问题和布线难度。产线上如果跨越多个工位、两道安全门甚至楼上楼下之间部署拉LVDS线是不现实的这时候很多人会想办法把CameraLink数据重新包装传到以太网或者光纤上。1.2 专用转换盒、网口相机和自研FPGA方案的取舍市面上有专门的CameraLink转光纤模块功能上和你自己用FPGA做基本一致一端接收相机数据打包后走光模块另一端恢复成CameraLink电气信号给采集卡。这类模块稳定、有外壳、有厂商保修但代价是价格不低、协议固定你没法在中间嵌入图像预处理、多相机合并或者自定制同步逻辑。另外一个思路是把相机直接换成GigE Vision或者USB3 Vision接口这种方案改动最小但产线上已经存在的CameraLink相机、镜头、光源触发关系都要重新调整换相机连带换采集软件账面成本往往比做一块FPGA转换板还高。FPGA方案的核心价值在于CameraLink的数据格式虽然看起来复杂但它本质上是“并行数据加同步信号”的结构FPGA做并行数据的缓存、打包、格式转换非常顺手。再加上板级集成GT高速收发器的FPGA芯片越来越普及一片芯片既能接CameraLink解串芯片又能把数据打包成Aurora 8B10B流通过SFP送出去链路自由度很高。1.3 FPGA方案带来的三个额外红利用FPGA做转换还有一个额外好处就是可以做“转发同时处理”。比如在发送端插入一个灰度直方图统计模块、ROI裁剪模块或者将多路CameraLink图像合到一条更高速的光链路上这些在专用转换盒上很难做到。再从工程维护角度讲FPGA方案只要保留JTAG和下载接口现场出了问题就可以更新逻辑不用把整个硬件拆回来。这在交钥匙项目里非常实用我后来给客户做运维培训时只要教他们重新下载bit文件这一个动作就够了。2. 整条数据通路解剖从CameraLink并行数据到SFP光模块2.1 CameraLink Base模式下的28位并行流先看信号源头。多数工业相机使用的是CameraLink Base模式物理连接器上包含四对数据差分线加一对时钟差分线。FPGA板一级通常会在靠近连接器的地方放一颗CameraLink解串芯片比如DS90CR288A或者兼容型号把串行LVDS信号解成28位并行数据和一路像素时钟。这28位并行数据的定义值得牢记其中24位是图像数据通常划分为A0~A7、B0~B7、C0~C7三组另外还有4个同步控制位也就是FVAL帧有效、LVAL行有效、DVAL数据有效和SPARE/保留位。像素时钟频率决定有效数据率标准Base模式通常会跑到85MHz左右也就是说理想情况下最多有85MHz乘以24bit约等于2.04Gbps的像素有效带宽这个数字后面做带宽预算时要用到。在实际FPGA工程中接收端拿到的是“像素时钟28位并行数据”。只要把数据按LVAL和FVAL的关系识别出来剩下的工作就是纯逻辑层面的打包与发送难度比直接处理LVDS底层要低很多。2.2 有效带宽估算光口线速率不能拍脑袋定既然要把CameraLink数据放到光口就要先算出实际需要多大带宽。以1280乘1024分辨率60帧、24位RGB为例图像本身的像素带宽约是1.89Gbps再加上行消隐、帧消隐期间可能携带的控制字、帧计数、CRC校验整体有效数据率会来到2Gbps上下。这个数据如果用Aurora 8B10B发送线速率的选择要考虑8B10B编码造成的物理开销。8B10B编码的规则是每8位用户数据会被映射为10位线上传输码因此用户有效利用率最高只有80%。所以如果选3.125Gbps线速率用户侧最多能拿到约2.5Gbps扣除Aurora协议本身的同步字和时钟补偿字符实际留给图像数据的余量大概在2.3Gbps以上承载常规Base模式画面没有问题。但如果相机分辨率或帧率高比如6480乘4864这种高分辨率面阵相机即使使用CameraLink Medium或Full模式也必须同步提高光口线速率或增加lane数量。我个人的工程习惯是把实际摄像机数据率测算出来之后至少留20%以上裕量再结合FPGA参考时钟和光模块类型确定最终线速率。不要为了迁就便宜光模块把线速率选到极限否则后续调试误码率会非常难受。2.3 “透明传输”还是“结构化传输”的架构选择CameraLink转SFP有两种组织数据的方法。一种是把解串出来的28位并行流连同像素时钟同步打成一个连续比特流接收端再原样恢复出CameraLink时序。这种思路接近“线缆的延长”在逻辑上最简单但会浪费掉一部分带宽因为消隐区的无效信号也被原样搬过去了而且接收端几乎没有机会插手做图像处理。另一种做法是结构化传输只在LVAL有效期间采集像素数据把FVAL和LVAL表征的行场关系转换成自己的帧头、行头字段再加上帧号、时间戳这类自定义信息。这样光纤里跑的是一个符合Aurora帧格式的逻辑数据流接收端解析出清晰的图像帧结构以后再接入DDR缓存或者做显示更方便。后面要介绍的工程源码基本都按结构化传输来设计。3. GT Transceivers Wizard与Aurora 8B10B的组合为什么比自研靠谱3.1 普通IO和SelectIO到不了这个频率可能有同学问为什么非要动用GT收发器用FPGA的普通IO加LVDS接口直接发不行吗如果只看像素时钟85MHz普通IO确实够用但LVDS在物理线缆上的长度和速率都有天花板。CameraLink本身是把28位并行数据在物理层做了7比1串行化线缆上每对差分线的速率是像素时钟的7倍。我们做光口转换最终物理层只要达到和CameraLink相当或略高的单通道速率即可普通IO是跑不了3.125Gbps这种线速率的。FPGA内部的GT硬核就是为这种高速串行收发准备的。GT收发器自带高速PLL、串行器/解串器、8B10B编解码器、时钟恢复电路。7系列里的GTX/GTH、UltraScale里的GTH/GTY基本都能覆盖我们需要的3.125Gbps或5Gbps。3.2 Aurora 8B10B弥补了GT缺少的“链路逻辑”单独使用GT收发器时必须自己处理一堆底层问题发送端的初始码对齐、接收端的字节边界寻找、两个方向链路建立后的握手确认、时钟补偿序列插入。这些工作在单板上看不出难度一旦两端设备通过光纤对上问题就变成“我需要一套双方都遵循的启动协议”。Aurora 8B10B就是Xilinx提供的一套链路层协议它专门用来管理GT收发器的初始化、通道绑定、时钟补偿和错误监控对用户公开一个类似简单的流接口。用户不需要关心光纤两端怎样对齐字节只要等待Aurora核的channel_up信号拉高就可以开始发送用户数据。在Xilinx工程中Aurora 8B10B核会自动配对底层GT收发器。可以这样理解GT Transceivers Wizard和Aurora的关系GT Wizard负责收发器物理层Aurora核则是搭建在物理层之上的链路控制逻辑。很多参考工程直接用Aurora IP核它内部会实例化出GT原语需要单独约束GT位置和参考时钟时再由GT Transceivers Wizard的IP设置帮我们生成完整的收发器封装。两者配合使用就是标题里“基于GT Transceivers Wizard Aurora8B10B编解码架构”的含义。3.3 与PCIe、以太网MAC、GTP专用协议相比Aurora是最短路径有人会问同样带Aurora为什么不直接用PCIe或者以太网PCIe需要处理地址空间、BAR、DMA、中断工程复杂度远高于Aurora以太网需要组包和MAC管理还要考虑帧间隔和ARP这类网络协调协议对点对点图像传输来说是绕路。Aurora本身是点到点协议旨在把高速链路两端的有效数据以尽可能低延迟搬过去非常贴合这种“相机到远端处理器”的单向大流量场景。Aurora 8B10B