1. 为什么要把CameraLink转成光口现实中的传输距离与线缆难题做工业视觉和医疗影像的朋友应该都有这种体验CameraLink接口在短距离内确实皮实但一旦超过5米问题就接踵而来。我在一个产线改造项目里就吃过亏客户现场相机和采集卡之间要走一条7米左右的线槽普通CameraLink线缆加上中继器勉强跑通可图像偶发花屏、丢帧排查了整整两天也没找到稳定复现的条件。后来拆开线槽才发现有一段线缆转弯半径太小部分差分信号对已经损伤只是勉强还能通讯。这个经历让我下决心把CameraLink转成光口来做传输。光纤的最大优势不在于速度多快而在于传输距离和抗干扰能力。SFP光模块走多模光纤50米到300米都是常规操作单模光纤更是能到10公里以上。对于产线跨车间、户外监控、医疗设备远程显示这类场景这个距离量级完全碾压铜线方案。另外光电隔离天然解决接地环路和电磁干扰问题这在电机密集的工业现场价值极高。借助FPGA平台CameraLink采集端和光口发送端可以在同一颗芯片内完成不需要额外的转换芯片。其中GT Transceivers Wizard负责配置FPGA内部的高速收发器通道Aurora 8B10B协议则承担数据打包和链路管理。这套架构的成熟度很高Xilinx官方IP核很少出幺蛾子时序收敛有保障调试手段也完善。整体下来数据通路就是CameraLink信号进来FPGA做解码和缓存按Aurora帧格式打包从SFP光模块发出去。这篇文章我会按照实际做项目的顺序来拆解覆盖硬件平台选型、CameraLink接收端设计、GTX/GTH配置要点、Aurora 8B10B核的用法、上板调试步骤和多通道扩展方案。文中涉及的具体参数以我手头这块Xilinx Kintex-7开发板为例但逻辑对所有7系列器件基本通用。2. CameraLink接收端的处理从LVDS到并行数据的关键一跳2.1 CameraLink接口协议速览CameraLink不是一个单纯的数据总线它定义了Base、Medium、Full三种配置对应不同的相机带宽需求。最常用的Base模式包含4对数据LVDS、1对时钟LVDS和若干控制信号Medium和Full模式则分别使用8对和16对数据LVDS。对于SDR单像素模式时钟频率一般在20MHz到85MHz之间DDR双像素模式则是时钟的上升沿和下降沿各传输一次数据。接口芯片通常选DS90CR288A或者Channel Link系列的接收芯片它们把LVDS串行数据转成28位或更多位的并行TTL信号。以Base模式为例4对LVDS数据线加上1对LVDS时钟接收芯片输出28位并行数据组合关系是3个端口Port A/B/C各8位视频数据加上FVAL、LVAL、DVALID三个同步信号共27位再加一个保留位凑成28位。这里需要特别注意数据位序和芯片手册的映射关系我早期调试时就是把Port A和Port B接反了结果图像是斜条纹加色彩错乱看起来像信号被搅碎了。2.2 FPGA侧时序约束与数据采样DS90CR288A输出的并行时钟RXCLK和CameraLink相机的像素时钟同频FPGA逻辑需要用这个时钟作为采集主时钟。很多人会在这一步犯懒直接把RXCLK接到普通IO上也不做时序约束结果就是偶尔花屏。正确做法是在XDC文件里对这一组信号做明确约束set_input_delay -clock [get_clocks clk_pixel] -max 2.5 [get_ports {camlink_data[*]}] set_input_delay -clock [get_clocks clk_pixel] -min 0.5 [get_ports {camlink_data[*]}] set_input_delay -clock [get_clocks clk_pixel] -clock_fall -max 2.5 [get_ports {camlink_data[*]}] set_input_delay -clock [get_clocks clk_pixel] -clock_fall -min 0.5 [get_ports {camlink_data[*]}]这组约束表示数据相对于时钟的建立时间要求。如果芯片手册上写明setup时间和hold时间就把数值代入替换。我用的DS90CR288A手册里的参数是setup为1.2nshold为1.5ns所以约束里用了偏保守的值。约束做完后可以给数据总线的各位加一级寄存器打拍再进后续的FIFO或缓存模块。这样做的好处是避免组合逻辑毛刺被直接采进缓存。2.3 行场有效信号的生成与数据打包CameraLink的FVAL帧有效、LVAL行有效和DVALID数据有效三个信号是判断图像数据边界的关键。我的做法是把它们和像素数据一起打包进自定义的总线格式高3位作为标志低28位作为数据。这样一步到位省去后续逻辑里单独判断有效信号带来的时序风险。收到完整一帧后把帧头标志置位然后用异步FIFO把数据从像素时钟域转到用户逻辑时钟域。注意千万不要用LVAL信号去触发帧同步因为不同相机的行有效脉冲宽度并不恒定直接用LVAL做帧边界容易遇到残帧问题。FVAL下降沿才是真正的一帧结束标志。拿到连续两帧的FVAL下降沿后就可以统计帧率和分辨率。我常在这一步插入一个调试计数器用ILA抓一下FVAL、LVAL和DVALID的时序关系确认和相机手册的数据时序图一致再往后面走。这一步看起来简单但能省掉后面Aurora调试时一大半的疑惑。3. GT Transceivers Wizard与Aurora 8B10B之间的分工逻辑3.1 GTX还是GTH从速率要求回推选型CameraLink的Base模式85MHz像素时钟时数据速率大约680MbpsFull模式也就2.72Gbps左右。但实际设计不会只为了满足原始带宽还要考虑Aurora协议带来的8B10B编码开销20%冗余以及可能的多通道扩展需求。Kintex-7系列的GTX支持到12.5GbpsGTH支持到13.1Gbps在这个应用场景里GTX就绰绰有余了。如果是Artix-7系列GTX速率上限会低一些但Base和Medium模式的CameraLink转光口也足够用。选择GTX后线速率建议直接按3.2Gbps或者5Gbps来配。我选了3.2Gbps原因有两个一是裕量足够二是参考时钟可以选100MHz或者125MHz满足Aurora核的参考时钟整数倍关系省去PLL配置的麻烦。如果后续打算扩展到多通道这个速率同样适用平滑升级不影响光模块选型。3.2 GT Transceivers Wizard配置的敏感参数创建一个GT Transceivers Wizard核核心配置项包括协议模板、线速率、参考时钟、数据位宽和编码方式。Aurora 8B10B协议对应编码方式选择8B10B数据位宽可以直接用核推荐的32位当然也可以按需改成16位或者64位。关键在于参考时钟频率和线速率之间的比值GTX内部CPLL或者QPLL需要保证参考时钟落在合法范围内通常100MHz和125MHz最稳。QPLL和CPLL的选择也要说一嘴单个GTX通道通常用CPLL即可多个通道共享时使用QPLL。Aurora 核通常会要求共享时钟结构一致所以从开始就要规划好是每个通道独立一个GTX还是多个通道绑在一个QPLL下。我自己做4通道方案时全部用QPLL共享同一个参考时钟这样多通道在逻辑上天然同步省掉后续调整延迟的麻烦。3.3 Aurora 8B10B核的通道配置与流控Aurora 8B10B核支持的通道数量从1到16可选每个通道的线速率需要和GTX配置完全一致。数据接口可以选择流模式Streaming或者帧模式Framing对于图像数据传输来说帧模式更合适因为它天然支持以帧为单位传递数据而且能把帧错误隔离在单个帧内不会污染整条链路。这里有个关键参数用户接口的数据宽度。Aurora核的用户接口数据宽度是总数据位宽例如单通道32位四通道就是128位。如果你的图像数据总线不是这个位宽可以在Aurora核外部做一个简单的位宽适配FIFO或者让Aurora核的接口宽度就是实际使用宽度。我的建议是外部适配因为这样Aurora核本身逻辑简单调试时定位问题也方便。流控方面Aurora核有两种用户流控User Flow Control和通道流控Channel Flow Control。图像传输通常用不上用户流控但通道流控一定要开启。当接收端FIFO快满时接收端会向发送端回传暂停信号防止数据溢出。我在调试时发生过接收端没开流控、发送端全力发包导致DDR写满丢数的情况加流控后这类问题基本绝迹。4. SFP光模块选型与板级设计的实战考量4.1 光模块类型多模、单模和速率FPGA的GTX串行接口和SFP光模块之间是CML电平直连中间不需要额外的驱动芯片。SFP模块选择上最常见的是千兆SX/LX模块和万兆SR/LR模块。千兆SX用于短距离多模光纤850nm波长千兆LX用于长距离单模1310nm。考虑到GTX线速率设在3.2Gbps千兆SFP模块的传输速率上限一般在4.25Gbps左右正好够用也可以选支持到4.25Gbps的工业级模块。如果你是做医疗或军工项目光模块的温漂和可靠性要重点考察工业级模块比商业级模块贵一些但能在-40到85摄氏度环境下稳定工作。消费级光模块在高温环境下误码率会明显上升时机久了还会出现偶发链路Down的情况排查起来非常难受。4.2 GTX与SFP之间的交流耦合与端接电阻GTX的TX和RX引脚直接接到SFP连接器的SI引脚上即可。需要注意四点交流耦合电容放在GTX引脚一侧容值选100nF或220nF必须要用C0402封装的NP0电容避免电容谐振点落在工作频段内。GTX的TX端内部已经有端接电阻不需要额外并联电阻。RX端同理。SFP的TX_Disable引脚必须拉低或由FPGA控制逻辑拉低否则光模块可能不发光。SFP的Mod_ABS、TX_Fault等引脚建议配置成普通GPIO读状态方便上电时判断光模块是否在位和是否故障。这些细节在原理图评审时容易被忽略但真出了问题就是硬伤。我之前有一版板卡SFP的TX_Disable被悬空结果默认电平不确定有一部分板卡上电后光模块不工作排查了半天最后发现是缺了一个下拉电阻。4.3 参考时钟的布线与抖动控制GTX的参考时钟如果抖动过大直接表现为误码率上升。PCB布线时要单独走线远离开关电源和LVDS数据线串接一个0欧电阻或磁珠隔离噪声。使用差分晶振时频率稳定度建议在±50ppm以内这一点SFP光模块的协议里也有要求链路两端时钟偏差过大会导致失锁。通用做法是用一个100MHz或者125MHz的LVDS差分晶振接到GTX的参考时钟引脚当然也可以从主时钟芯片分配一路给GTX。个人更推荐独立差分晶振因为主时钟芯片的其它输出通道可能被DDR或PCIe的时钟切换打扰导致GTX参考时钟上出现短时频偏。5. Aurora链路的握手、数据流设计与带宽估算5.1 Aurora通道初始化的状态监控Aurora核在配置完成后首先需要完成通道初始化包括通道对齐、校验和链路层同步。初始化期间Aurora的channel_up信号会保持拉低等所有通道都对齐后channel_up才置高。初始化失败最常见的原因是GTX的线速率和参考时钟不匹配、SFP光模块没有发出光信号、光纤两端接反或者对端没有接Aurora核。调试这个阶段我的方法是用ILA抓Aurora核的gt_rxresetdone、gt_txresetdone、channel_up和lane_up信号。正常情况下resetdone先拉高lane_up随后拉高最后channel_up拉高。哪个信号卡住就说明哪一环有问题。有一次我折腾了半小时发现是光纤一端没插紧Mod_ABS引脚一直是高电平光模块压根没被识别到。5.2 数据帧格式和字节序的统一Aurora协议本身不限制用户数据的格式但两端必须约定一致。我做CameraLink转光口时定义了一个简单的帧格式4字节帧头固定0xAA55AA554字节帧长度包含有效图像数据字节数2字节行宽、2字节行高有效图像数据4字节帧尾固定0x0D0A0D0A发送端每完成一帧CameraLink数据的采集按这个格式组装调用Aurora核的用户接口写入。接收端解析帧头、读取数据、校验帧尾然后把图像数据写入DDR或者输出给后级模块。字节序问题在这里非常容易踩坑GTX发送侧和接收侧的字节顺序可能因为端序不一致而颠倒Aurora核的字节交换选项要按需打开。提示在开始做图像传输之前建议先跑一个简单的回环测试。把GTX的TX短接到RX或者通过SFP光模块和光纤跳线对接往Aurora通道里写一组递增数看看读出顺序是否一致。这一步通过后再处理图像数据会从容很多。5.3 带宽计算和缓存深度评估以Base模式85MHz像素时钟、SDR模式为例有效图像数据速率是85M x 8bit x 3port 2040Mbps约2.04Gbps。Aurora 8B10B编码后线速率是2.04Gbps x 10/8 2.55Gbps。如果GTX配置成3.2Gbps裕量大约25%足够覆盖帧头帧尾开销和流控反压带来的瞬时带宽下降。接收端的DDR缓存深度要根据帧大小来评估。1080p30的8bit Bayer图一帧大约1920 x 1080 2M像素按原始8bit算约2MB。DDR3/DDR4随便分配一个32MB或64MB的地址段就绰绰有余。如果做多通道同步采集比如4路CameraLink同时进FPGA再统一从光口发出那么DDR带宽要按4倍来算此时选择DDR3-1066数据率1066MHz位宽16bit基本可以满足但建议用ILA实时抓一下DDR读写的仲裁延迟确认不会因为冲突丢数据。6. 上板调试的关键步骤和实测中的坑6.1 硬件自检链路的建立上板的第一步不是跑Aurora而是确认硬件基础。先用JTAG连上FPGA读一下器件IDCODE确认芯片型号没问题。然后点亮SFP的LED指示灯确认光模块的供电和I2C通信正常。部分SFP模块支持DDM数字诊断监控通过I2C可以读到光功率、温度、电压这是判断光路是否正常的利器。我一般会在上板调试时做一个简易的I2C读取模块把光功率值通过UART打印出来两根光纤都接好并互通后光功率应该在-10dBm到-3dBm之间如果看到-20dBm以下很大概率是光纤没对接好或者光模块类型不匹配。6.2 误码率测试的方法Aurora链路建起来之后先别急着接CameraLink相机做一个PRBS误码测试更靠谱。Xilinx的IBERT核Integrated Bit Error Ratio Tester可以直接利用GTX的收发器做高速串行链路的误码测试不需要额外写逻辑。把IBERT配置成同样的线速率和参考时钟设置PRBS-7或者PRBS-31模式跑上10分钟误码率应该在10的负15次方以下才合格。如果误码率偏高检查方向包括差分走线阻抗是否匹配SFP连接器座的阻抗通常要求100欧姆差分交流耦合电容是否选对容量太小会衰减低频分量参考时钟的抖动是否过大观察GTX的txresetdone/rxresetdone是否有周期性复位SFP模块的供电是否干净万用表量一下3.3V电源纹波超过50mV就要考虑加磁珠或者加大电容这一轮排查下来绝大部分链路问题都能定位了。6.3 Aurora用户接口的背压处理Aurora核的用户接口是有流控的。当你连续向TX接口写入数据时如果对端接收来不及处理TX接口的tready信号会拉低此时必须暂停写入否则数据会丢。我在做图像数据打包时专门写了一个状态机当FIFO非空且tready为高时一次性发送一个完整的帧数据包发送过程中如果tready拉低状态机停在当前状态等tready恢复后继续发送。这比用背靠背写总线的方式稳得多至少不会出现半帧丢在链路里的情况。接收端同样要注意Aurora核的RX接口只要有数据就会往外吐如果你后级处理不及时要么打开通道流控让发送端暂停要么在RX接口后面接一个大容量的异步FIFO。我的习惯是两种都做FIFO吸收突发通道流控兜底长期满负荷。6.4 偶发链路Down的定位经验链路偶尔Down是调试中比较头疼的问题。如果你的链路长时间稳定但每几个小时或者几十小时掉一次线通常不是硬件问题而是协议层问题集中在以下三个地方Aurora核的复位逻辑不够健壮遇到瞬时错误后无法自动恢复。解决方案是在应用层定期检查channel_up信号一旦拉低就执行一次完整的GTX和Aurora复位序列而不是傻等自动恢复。光模块的接收灵敏度余量不足在长距离或者光路衰减偏大的场景下会产生偶发误码。建议检查DDM读到的接收光功率如果临近接收灵敏度阈值换一对高增益模块试试。GTX参考时钟受到周期性干扰例如DDR刷新操作或者PCIe总线活动产生的电源噪声耦合到时钟线上。这种问题最难定位但可以通过频谱仪或者示波器观察参考时钟的相位噪声来确认。我的建议是给Aurora通道设计一个可靠的复位状态机上电后先等GTX的resetdone再配置Aurora核再等channel_up如果channel_up拉低自动执行一套完整的复位序列并记录复位次数。有了这个保护偶发Down就不再是灾难性故障了。7. 从单链路到多链路CameraLink Full模式和并行扩展7.1 Full模式扩展的数据通路CameraLink Full模式的相机输出16对LVDS数据加2对时钟对应FPGA侧需要接两片DS90CR288A或者一片同时支持多链路的接收芯片。此时数据总量是Base模式的两倍GTX线速率要相应提升或者增加通道数。我的方案是使用Aurora双通道把Full模式的像素数据按奇偶帧或者奇偶行拆分到两个通道中传输接收端再按序拼接。这样做的好处是每个通道的线速率可以保持不变后端处理逻辑压力也小。拆分配置时要注意Aurora多通道核本身可以提供一个统一的用户接口数据位宽翻倍这种情况下不需要自己拆分直接把两片接收芯片的数据合并成一个128位宽的并行数据接到Aurora核的用户接口即可。这种方案在逻辑上更简单前提是两片芯片的数据时钟必须同源否则跨时钟域处理会让你怀疑人生。7.2 多路独立CameraLink转光口的组合拳如果你的系统是多台相机独立采集、独立传输那么更合适的方式是每路CameraLink独立对应一个GTX通道用独立的Aurora核例化多次。此时每个Aurora核可以独立复位和独立监控一路故障不会影响到其它路。代价是会占用更多的FPGA逻辑资源和时钟资源。做四路独立方案时GTX参考时钟可以共享但每个通道的Aurora核都需要单独初始化。上板调试时先逐路跑通再组合起来不然四路一起出问题根本无从排查。我在实践中还遇到过一个有意思的坑四路Aurora同时发起初始化时GTX的QPLL资源争抢导致部分通道锁定失败。后来我把四路的初始化序列改成串行——先让第1路完全up再启动第2路以此类推——问题就消失了。这也算是多通道方案里一个值得记住的经验。8. 工程交付物的组织和后续演进思路8.1 一套标准工程应有的文件结构标题里提到提供4套工程源码实际组织工程时要按组件和阶段拆分让接手的人能按图索骥。我的标准结构是这样prj/ ├── camera_link_rx/ # CameraLink接收模块包含LVDS接口、FIFO、时序检测 ├── aurora_link/ # Aurora 8B10B核封装包括GTX配置和用户接口封装 ├── frame_pack/ # 帧格式打包、解析模块 ├── ddr_interface/ # DDR控制器封装和数据搬运逻辑 ├── top/ # 顶层文件和约束文件 │ ├── top.v │ ├── top.xdc │ └── system_ila/ # 调试用的ILA例化文件 └── docs/ # 接口说明文档、时序图、调试记录每个模块内部需要有一个README说明模块的输入输出端口、时钟域、已知问题和修改记录。工程代码能不能快速被第二次使用完全取决于这些说明写没写清楚。光给代码不给文档别人拿到纯靠猜合作成本非常高。8.2 与PCIe架构结合的可能性这套CameraLink转光口方案做好了之后很容易扩展到PCIe采集卡架构FPGA负责CameraLink接收和光口发送同时通过PCIe接口把数据传给上位机显示。两者共用GTX资源但PCIe核和Aurora核会争抢GTX通道所以一般建议独立分配通道比如PCIe x1用lane0光口用lane1。PCIe的枚举和数据搬运和Aurora是完全独立的逻辑只要不共用GTX通道互不干扰。另外如果系统里已经有STM32H743这类MCU也可以把光口接收端解出来的图像数据再通过以太网转发出去实现采集端、传输端、显示端分离的分布式架构。不过这块内容展开就是另一个大话题了这里先提一个思路等有机会单独写一篇。8.3 升级换代时的注意事项如果下一代产品需要支持更高分辨率的相机比如4K60fps的CameraLink接口线速率就要大幅提升。此时需要评估是否从8B10B编码切换到64B66B例如Aurora 64B66B编码后者的编码开销只有约3%不到8B10B的四分之一。相应的GTX的线速率可能要升到10Gbps以上此时GTX就不再满足要求需要更换GTH或者GTY。不同收发器硬件资源、时钟架构和PCB布线要求都有变化选型时需尽早验证。做这类升级改动时我建议保留原有架构的数据帧格式不变这样发送端和接收端的应用层逻辑基本不用动只替换链路层和物理层能大幅缩短验证周期。好的架构设计不是一次写到位的而是允许用最小的代价替换它的一部分。
