做机器视觉项目的同学应该都懂，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
