1. 项目背景与需求分析1.1 为什么需要CameraLink转SFP光口工业相机领域摸爬滚打过的工程师应该都有同感CameraLink接口在机器视觉、医疗影像、军工检测这些场景里简直无处不在。但凡是搞过产线视觉检测或者远距离图像采集的八成都被CameraLink的传输距离限制折磨过。CameraLink是基于LVDS的并行差分传输方案Base配置理论速率也就2.04Gbps左右线缆长度受限于时钟频率跑满速时撑死5米实际工程上3米就开始心里打鼓。而SFP光模块走的是光纤传输单模光纤轻松跑10公里以上多模OM3也能跑300米这个距离差距直接把应用场景拉开了一个量级。我这次做的项目就是典型的CameraLink长距离传输诉求现场相机端固定后端采集处理端在几十米外的机柜里。原来用CameraLink线缆中继方案光电转换器加中继器一路堆过去不仅成本高链路中间的点还容易成为故障源。与其这么折腾不如直接用FPGA做一次彻底的信号转接——CameraLink进SFP光口出光纤直接把图像数据送到后端。1.2 项目核心需求拆解需求梳理下来其实很清晰就五个字稳定、低成本。但落到具体实现上就拆成了这些硬指标CameraLink接口全面兼容至少要做到Base配置最好能兼容Medium和Full配置方便后续扩展光口速率匹配不能有瓶颈CameraLink Base全速进来光口也要能全速送出去低延迟图像传输链路延迟要控制在微秒级不能给后端视觉算法造成额外时序压力稳定可靠7x24小时不停机运行光纤链路断开后能自动恢复不能动不动就死链路低成本实现直接用Xilinx FPGA自带的GT Transceivers硬核配上现成的SFP光模块不需要额外的PHY芯片这最后一条是方案选型的分水岭。如果走独立SerDes芯片加FPGA的组合电路设计复杂度会上升不少BOM成本也压不下来。直接用FPGA内部GT硬核等于把高速收发器的物理层全部免费集成进了逻辑里只需要在FPGA外围把SFP的金手指差分对连接到GT的参考时钟和收发通道上就完事。1.3 方案选型思考既然定了用FPGA自带GT Transceivers那上层的编解码协议用什么就成了第二个关键决策点。市面上有几种选择比如自己做8B10B编解码或者用Tri-Mode Ethernet MAC包一层TCP/IP但说实话都不够优雅。自己做8B10B不仅要处理时钟恢复、字符对齐、通道绑定这些问题还得自己设计链路层状态机工作量直接翻倍。走以太网协议栈延迟上去了不说逻辑资源占用也大得离谱。最后选定了Aurora 8B10B协议这个是Xilinx专为高速串行链路设计的轻量级协议天然适配GT Transceivers肯塔基直接给到完整参考设计。Aurora 8B10B的协议开销非常小主要就是通道初始化和绑定时插入几个控制字符正常传数据时几乎是零开销透传延迟也就是几个时钟周期的事。对于图像传输这种纯数据流应用Aurora 8B10B简直就是量身定做的。它不需要像网络协议那样做MAC地址解析、IP分片重组这些操作直接把有效数据分包流式发送到对端即可。2. CameraLink接口解析与FPGA对接2.1 CameraLink协议层级CameraLink规范从物理上分了三层。底层物理连接是MDR-26或SDR-26接口内部跑的是Channel Link技术——也就是把并行数据通过Serializer转成LVDS差分对传输。Base配置需要3对数据和1对时钟Medium配置加到5对数据加1对时钟Full配置则是8对数据加1对时钟。每对数据线上串行传输的数据位宽是有讲究的3对数据线对应21位并行数据3x75对对应35位5x78对对应56位8x7。为什么要乘7因为Channel Link协议里每7个串行比特位上就有1个时钟位串行化比是7:1。以Base配置为例相机端像素时钟跑到85MHz的时候每对LVDS线上的实际比特率就是85MHz x 7 595Mbps3对数据线加起来就是1.785Gbps。还有控制信号CameraLink里有4个相机控制信号CC1-CC4和2个串行通信信号SerTC/SerTFG这些在Base配置下通过第4对连接器针脚传输走的是单独的低速LVCMOS。2.2 硬件接口设计要点FPGA这边接收CameraLink信号中间需要一颗Channel Link接收芯片做LVDS转CMOS并行数据。市面上常见的就是DS90CR288A对应Base配置28位并行数据或者DS90CR286A24位并行数据。我当时用的是DS90CR288A接收端把3对LVDS差分线上解串后的21位数据加上1位时钟同步信号最终恢复出28位并行总线24位图像数据加4位同步信号。这里有个关键点解串芯片输出的像素时钟和并行数据是对齐的但不同芯片的建立保持时间参数有差异FPGA侧需要对输入时序做细致的约束检查。硬件设计上还有几个容易被忽略的坑CameraLink的LVDS共模电压范围是1.125V到1.375VDS90CR288A输入兼容这个范围但千万不能用普通LVDS接收器替换否则共模不匹配会出偶发误码像素时钟的走线长度要严格控制和3对数据线的长度差不要超过1mm否则高速下相位裕量不够SFP座子的差分走线要用交流耦合电容0.1uF的0402封装足够了位置要靠近连接器端2.3 图像数据与同步信号提取DS90CR288A输出28位总线和像素时钟。这28位包括24位图像数据D[23:0]和4位同步信号具体映射是D[23:16]对应红通道D[15:8]对应绿通道D[7:0]对应蓝通道D[27:26]对应行有效LVAL和帧有效FVALD[25]对应数据有效DVALD[24]对应保留位。这里最容易踩的坑就是数据通道的位序问题。CameraLink总线在解串芯片恢复后高字节和低字节的顺序跟实际色彩通道顺序不一定一致不同品牌的相机对CameraLink协议的支持还有细微差别。所以拿到板子第一步就是抓波形确认通道映射关系而不是急着一股脑往后端送数据。提取出来的FVAL、LVAL和DVAL三个信号组合起来就能准确圈出有效图像区域。如果相机输出的是非连续帧模式比如触发采集还得额外处理帧间隔和行间隔的动态变化确保SFP链路发送端的数据包结构不因此错乱。3. GT Transceivers Wizard与Aurora 8B10B核心实现3.1 GT Transceivers Wizard配置过程在Vivado里新建IP核工程选择GT Transceivers Wizard进入配置界面后我习惯按这个顺序来第一页选择收发器类型。我用的板子是7系列FPGA只有GTX资源如果是UltraScale系列就得选GTY或GTH通道速率上限不同配置界面也会有差异。GTX在7系列里最高能跑到12.5Gbps但我这个项目实际用不了那么高下面会说具体速率。第二页是协议预设Aurora 8B10B有一个专属的预设选项选上之后软件会自动填充大部分参数省事不少。预设里已经把8B10B编码、逗号对齐、通道绑定都勾上了。然后是线速率设置。这个参数必须根据CameraLink Base配置的实际数据流量来算。Base配置最大像素时钟85MHz数据位宽28位24位图像加4位同步有效数据率就是85M x 28 2.38Gbps。考虑到Aurora 8B10B协议本身有约20%的编码开销8B10B意味每8位数据变成10位在线上跑加上链路层还可能插入控制字符做时钟补偿我按30%的余量来估线速率定在3.125Gbps。参考时钟选125MHz还是156.25MHz决定因素就是能不能通过整数分频得到目标线速率。GT收发器内部结构是参考时钟经PLL倍频后驱动串行器。3.125Gbps除以125M参考时钟正好是25倍频结构非常舒服。选156.25MHz参考时钟也成立20倍频但VCO工作范围要确认覆盖。还有几个必须注意的参数TX/RX端接电阻和摆幅电压默认值一般是性能最优的不用动内部自回环Loopback和外部回环测试模式的使能默认关掉等调板的时候再用每个通道的极性控制和差分对交换功能先在配置里留着选项现场信号接反了可以不改板子直接逻辑里翻转3.2 Aurora 8B10B协议架构详解Aurora 8B10B协议的本质是点对点串行链路协议不涉及寻址和路由纯粹解决打包传输问题。协议在很多方面借鉴了Fiber Channel的8B10B机制控制字符定义也选了K28.5作为逗号对齐字符。协议数据流分两类字符数据字符D和特殊控制字符K。8B10B把8位数据编码成10位线路码其中12个控制码字被保留下来用于协议管理。Aurora用K28.5作为通道对齐和初始化序列标志用K27.7和K29.7等实现帧起始、帧结束和时钟补偿。Aurora 8B10B的顶层协议栈分四层物理层、数据链路层、传输层、应用接口层。Xilinx提供的IP核把这四层全封装了用户只需要在应用接口层做收发FIFO对接。就我个人的开发体验Aurora 8B10B最好用的一点是它内部自动完成了时钟补偿机制。两边板卡如果参考时钟源不是同一个晶振频率会有几十到几百ppm的偏差8B10B码流里就会慢慢积累误码。Aurora协议通过周期性发送时钟补偿序列CCClock Compensation来吸收这个频率偏差每多少个用户时钟周期自动插入一次CC字符接收端将这个序列丢弃不往用户接口交付。这个机制对于两个独立供电、独立晶振的板卡通信是生死攸关的。3.3 Aurora IP核接口信号解读Vivado里生成Aurora 8B10B IP核后最核心的就是用户侧接口信号user_clk_out这是IP核输出的用户时钟所有用户逻辑都得跑在这个时钟域下。它和GT收发器的内部时钟是同步的速率等于线速率除以10对于3.125Gbps就是312.5MHzs_axi_tx_tdata和s_axi_tx_tvalid/s_axi_tx_tready发送数据通道标准的AXI4-Stream协议握手信号必须按规范来_tvalid和_tready都拉高时一拍数据才算发送成功m_axi_rx_tdata和m_axi_rx_tvalid接收数据通道IP核把接收到的数据直接推给用户逻辑channel_up、lane_up、hard_err、soft_err这些都是链路状态指示信号channel_up拉高才代表Aurora链路建立成功用户逻辑里必须处理的一个问题是FIFO的空满和反压。由于CameraLink的像素时钟和Aurora的用户时钟是异步的中间必须架异步FIFO做跨时钟域处理。而FIFO的读侧接到Aurora发送通道的AXI-Stream接口如果FIFO读空或者Aurora通道未就绪发送方向就暂停。暂停期间如果对应的是行数据非有效区间那倒是无所谓的可如果刚好在一行有效数据的中间暂停接收端就会看到行数据被割裂。解决思路就是把CameraLink输出的整行有效数据缓存到FIFO里等攒够一整行再抬头发送请求。这样Aurora通道的短暂反压不会影响行内数据的连续性最多是行与行之间的间隙变长。后端恢复图像时按行同步信号重新拼接完全不受影响。3.4 发送端数据打包设计Aurora 8B10B发送端用户逻辑要做的就是把28位CameraLink并行数据组织成64位或32位AXI数据流。我这里把28位数据在Luminous本地做了一个位宽转换。8B10B的传输数据位宽可以配32位或64位我选的32位因为28位数据塞进32位里只需要补4位浪费最少。具体映射规则为[31:28]补零或者塞标志位[27:26]放FVAL和LVAL[25]放DVAL[24:0]放图像数据和保留位。需要解释的是这样安排让接收端只要看FVAL和LVAL两个信号位就能还原出同步时序不需要额外的sideband信息。而且Aurora IP的发送数据总线还允许通过tuser信号传递用户自定义信息。另一个设计点是把FVAL和LVAL的上升沿和下降沿信息打包成2位标志放到tuser上接收端就可以精确恢复出行和帧的边界连跨时钟域查找信号边沿的麻烦都省了。3.5 接收端数据还原设计接收端要做的事是发送端的逆过程。Aurora IP核收到数据后从m_axi_rx_tdata总线上解出32位数据拆回28位并行总线和有效信号然后喂给后端的图像采集卡或者数据处理单元。如果后端还是CameraLink接口的采集设备那就还得加一片CameraLink发送芯片比如DS90CR287把并行数据重新串行化成LVDS差分信号。这个方案适用于存量CameraLink采集设备不想动、只想中间串联一段光纤的场景相当于做了一个光电桥接器。如果后端是直接接FPGA的那就在FPGA内部完成时序重建输出VGA/HDMI或者DDR等接口省去CameraLink发送芯片把这个28位并行总线直接送入图像处理模块。我在第二套工程里做的就是后一种FPGA收到光口数据后直接做颜色空间转换、像素格式重排然后给到HDMI显示接口省掉了一片发送芯片的成本链路又精简了一级。4. SFP光模块接口与高速PCB设计4.1 SFP光模块硬件接口SFP封装的光模块是目前工业界最成熟的光通信模块形态金手指定义是标准化了的。FPGA侧和SFP座子相连的关键信号就三类第一类是高速差分收发信号。SFP的TD/-和RD/-直接接到FPGA的GT收发器通道上。注意TD/-是FPGA发出去的对应GT TXRD/-是FPGA收进来的对应GT RX不要接反了。第二类是低速控制信号。TX_DISABLE是发送禁用高电平有效正常工作时必须拉低。TX_FAULT是发送故障告警模块检测到激光器异常就会拉高FPGA侧应该引入中断或状态监控不是致命信号但建议监控起来。RX_LOS是接收信号丢失指示当没有光信号输入时拉高这个信号对链路诊断非常关键建议接到FPGA的一个普通GPIO或LED指示灯上。第三类是模块管理总线。I2C接口用于读写SFP内部的EEPROM里面有厂商信息、型号、序列号、波长、传输距离等参数。这个接口在调试阶段很值得读一下确认光模块的实际类型和速率等级避免买错。有些模块还支持DDM数字诊断功能通过I2C能读到光功率、温度、电压、偏置电流这些实时监控参数这些参数在很多商用环境里可以说是硬需求IBM甚至在其服务器技术规范里都写了必须支持DDM。SFP座子的其他引脚Mod_ABS和RS0/RS1也要处理好。Mod_ABS是模块在位检测模块插入时会拉低这个信号可以并一个LED指示模块插没插好。RS0/RS1是速率选择引脚通常直接悬空或按固定电平接标准速率下不需要动态控制。4.2 高速PCB走线与电源设计GT收发器对PCB的要求主要体现在阻抗连续、等长匹配、电源低噪声三个层面。差分对阻抗要求是100欧姆这个靠叠层设计和走线宽度控制。四层板的第二层做完整地平面顶层走高速差分线阻抗控制在5%误差范围内就已经合格了。差分对内等长是必须做到的长度差控制在5mil以内这个精度手工布线时稍微注意下就能实现。差分对之间的间距要拉开至少3倍线宽以上减小相邻对之间的串扰耦合。SFP座子和FPGA之间的走线距离越短越好但实际工程中布局受限走线绕一绕是常态。这时候就需要仿真配合。仿真能力不足的情况下保守方案是控制总走线长度不超过3000mil过孔不超过2个。3.125Gbps这个速率在FR4板材上信号质量还有足够裕量不需要上罗杰斯这类高频板材。电源是GT收发器最容易翻车的点。GT收发器的模拟电源如MGTAVCC对纹波极其敏感超过10mV的纹波都会直接在眼图上显现出来。MGTAVCC和MGTAVTT两颗电必须单独用LDO供电而且LDO输出要放足够容值的去耦电容。另一个高速设计的细节是参考时钟。GT的参考时钟输入有时钟信号质量要求优先用差分晶振输出LVDS或LVPECL送到FPGA的专用时钟引脚。我在自己的设计里选的是156.25MHz的差分晶振稳频精度做到正负25ppm启动稳定时间小于10ms这个指标对于Aurora链路来说是足够的。4.3 光模块选型与光路检查SFP光模块选型要考虑波长、模式、速率、传输距离四个参数。近程传输几百米内选多模850nm模块配合OM3多模光纤价格最低常见的有10G模块兼容1.25G用。远程传输几公里以上选单模1310nm模块配合单模光纤损耗更小但模块价格会高一些。速率选择上必须和你的GT线速率匹配。我前面定了3.125Gbps线速率对应的光模块速率等级选择3.2G或1.25G。这里有个坑千兆SFP模块标称1.25Gbps实际工作范围一般是100M到1.25G你强行跑3.125G是绝对跑不起来的。而万兆模块10G SFP能跑10G速率向下兼容性也还行在3.125G速率下工作完全没问题。我当时图省事直接用了SFP万兆模块虽然成本略高但性能和兼容性很稳。光纤链路检查的步骤如下先用光功率计测试两端光功率确认链路预算足够接收端光功率在模块的灵敏度范围内。发射光功率一般0到-3dBm接收端灵敏度一般-14到-20dBm只要光纤链路损耗不太大理论上是没有问题的。实测下来短距离几百米的多模链路衰减通常不到1dB信号余量非常充足。实盘时有个小技巧检查光路前用酒精棉清洁光纤端面和SFP接口的防尘帽内部灰尘和脏污会导致反射损耗增大反射光打回FPGA内部可能造成GT的CDR失锁光路本身是好的但link却一直起不来的问题有好几次就是脏污引起的。5. 4套工程源码设计与使用指南5.1 四套工程各自的定位和差异标题里承诺提供4套工程源码这个数量不是随便堆的而是覆盖率不同应用阶段的复用需求。从我自己的设计脉络来分四套工程分别是第一套是基础验证工程最小系统只做GT Autola和Aurora链路自环不包含CameraLink图像数据。这套工程的作用是上电后验证FPGA、SFP光模块、光纤链路是不是通的。逻辑侧只做移码循环把固定测试图案经过Aurora发送环回接收后比对。只要这个能过硬件链路就是健康的省得后面调图像数据时分不清是逻辑问题还是硬件链路问题。第二套是CameraLink转Aurora单向传输工程包含完整的CameraLink LVDS接收、异步FIFO缓存、Aurora发送。这套工程适合的点是发送端完整实现接收端只验证数据接收和CRC校验不涉及图像显示和时序重建。第三套是Aurora接收加图像还原工程它在第二套的接收端基础上把恢复出来的图像数据输出到HDMI显示接口。这套适合已经有光纤数据源、要做后端图像显示的场合。第四套是全功能双向传输工程包含了发送和接收两条完整链路支持双向图像和命令交互。这套复杂度最高可用于需要远程控制相机参数、上报运行状态等场景。四套工程本质上是一个迭代递进关系建议初次上手按一到四的顺序依次下载调试每套都验证通过后再进下一套。如果只是验证链路装第一套就够了然后直接换第四套做全功能。5.2 工程源码结构与关键文件说明每个工程在Vivado里的组织结构我都做了统一规划方便跨工程理解和移植rtl目录下按模块划分camera_link_rx、aurora_tx、aurora_rx、fifo、image_process、hdmi_out等子目录ip目录下存放生成的GT Wizard和Aurora IP核constraints目录下放XDC时序约束文件和管脚约束文件sim目录下放行为仿真testbench最关键的文件是aurora_link模块它把Aurora IP核的初始化和状态管理包了一层统一接口。这个模块里有一个状态机管理链路从复位、初始化、等待lane_up到channel_up的过程。每个状态都有超时保护比如等待lane_up超过10ms就自动重新初始化避免了链路建立失败后状态机卡死不动的情况。时钟管理也是复用模块输入板卡主时钟和参考时钟用MMCM/PLL产生所有需要的时钟域。CameraLink侧像素时钟可能存在一定频偏用一个独立的MMCM来做相位对齐比硬用全局时钟更稳。5.3 如何在Vivado里快速跑通工程拿到源码后按这几个步骤走基本半小时内能把工程跑起来第一步确认Vivado版本。我整套工程是用Vivado 2019.2做的高版本的2020.x和2021.x有兼容问题的话需要升级IP核Vivado会弹窗提示照做即可。第二步打开工程后先在Sources窗口展开IP核列表逐个检查IP核的生成状态。如果显示未生成右键选Generate Output Products等它跑完。第三步打开约束文件确认管脚约束和你的实际板卡匹配。板子型号不同、SFP座子引脚不同这个文件一定会需要改。改的时候注意GT位置约束比如MGTY和MGTZ的编号不能写错否则综合时会报错。第四步综合、布局布线、生成比特流。第五步下载验证。这里有一个非常实用的排查技巧如果工程里有逻辑分析仪ILA探针建议在channel_up、hard_err、soft_err这些关键信号上挂探针看链路状态机的实际运行轨迹。我调板时最常用的做法就是在线运行图上看Aurora的channel_up是瞬间拉高还是反复跳变如果反复跳变优先排查光路衰耗和参考时钟质量。5.4 工程资源占用与性能指标整个设计在Xilinx 7K325T上的资源占用大概是这样资源类型使用量百分比寄存器约1500014%LUT约1800017%Block RAM32个36Kb23%GTX Transceiver1个6%整套系统上电后初始化时间大约200ms其中GT PLL锁定时间占大头。光纤链路建立时间在Aurora协议下是几十微秒级别实际表现是channel_up信号在上电后1秒内稳定拉高如果光路干净10毫秒内就能完成。端到端传输延迟包括CameraLink接收解串、FIFO缓存、Aurora编码传输实测下来在5微秒级别满足绝大多数视觉检测系统的实时性要求。6. 调试过程中的高频问题与排查手册6.1 链路无法建立channel_up一直拉不高的排查这个现象几乎是每套Aurora工程都会遇到的第一道坎。常见原因按出现概率排序有这么几个光路衰减过大或者光纤收发接反。SFP模块的TX要接对端RXRX要接对端TX用一根跳纤直连的时候如果两端都是直通光纤TX到TX是连不上的。换成交叉跳纤或者调整一端模块方向就能解决。参考时钟没有起振或者频率不对。用示波器在FPGA的GT参考时钟引脚上量波形如果电平幅度不够GT内部的PLL是锁不上的。GT通道的差分极性接反了。SFP座子的TD/-和FPGA GT的TXP/TXN如果反了Aurora的对齐码字根本对不上表现在现象上就是lane_up一直为低。解决方式是改约束文件里的管脚定义或者在GT配置里打开极性翻转功能。还有一个容易被忽视的原因光模块速率等级不够模块实际上不支持你配置的线速率。前文说的用千兆模块跑3.125G就是这个典型坑换SFP模块立刻就好。6.2 链路能建立但传输过程中误码率偏高链路建立成功说明物理层基本通了但误码率偏高的话问题就出在信号质量上。先看眼图。用Vivado的IBERT工具可以直接在GT收发器上做误码率测试。IBERT能实时显示每个通道的眼图张开情况如果眼图开口很小或者有严重的码间干扰就说明高速通道质量不达标。可能原因是走线过长、过孔过多、阻抗不连续。再看电源。我遇到过一次场景FPGA的1.0V核心电源和MGTAVCC用的是同一路DC-DC负载波动大的时候GT误码率会突然飙升。改成独立的LDO供电之后误码率数据立刻回到了正常水平。还有参考时钟抖动。GT对参考时钟的相位噪声有要求如果用了质量很差的晶振即使输出频率是对的抖动超标也会恶化接收端的CDR性能。自查方法就是看参考时钟的频谱检查近端相位噪声是否异常。6.3 图像花屏、丢行、颜色错位的定位思路链路通了也传数据了但图像显示不对往往不是光路问题而是数据映射问题。花屏先看行同步信号。如果图像画面左右撕裂或者上下错位先确认FVAL和LVAL的恢复是否准确用ILA抓接收端还原出来的同步信号和发送端对比时序是否一致。颜色错位则基本可以断定是数据位映射问题。CameraLink的通道映射因相机品牌而异行数据进入FPGA后要做一次位重排把RGB顺序调整正确。这个调整逻辑放在一个单独的模块里方便按不同相机型号切换。丢行问题则更可能是FIFO溢出。行有效期间数据流量大FIFO深度不够或者读速度跟不上就会丢数据。补法就是加大FIFO深度或者把突发度降低让FIFO有更多缓冲余地。6.4 跨时钟域处理的细节陷阱CameraLink的像素时钟和Aurora用户时钟完全异步所有数据跨时钟域必须经过异步FIFO。这里有一个特别容易犯的错多个控制信号直接跨时钟域打两拍同步这在单比特信号上是对的规则但多比特数据总线绝不能这样处理。正确做法是数据走FIFO控制信号可以通过FIFO的almost_full和almost_empty信号来做反压而不是单独跨域。异步FIFO的深度选择也有讲究。传输方向是CameraLink输入到Aurora发送数据速率前者略高FIFO深度至少要能缓存2行图像数据才够安全。我用的51.2Kb FIFO深度在85MHz像素时钟下实测只有极端场景才会接近半满余量充足。6.5 工程落地时的验收标准工程完成后我习惯按这个清单做整机验收链路稳定性连续48小时满负荷图像传输误码率读数归零温度适应性系统在50度环境温度下连续运行12小时GT速率为3.125G时误码率不劣化上电重启恢复掉电重启10次每次channel_up都能在1秒内建立热插拔验证光纤热插拔5次每次断开后重新插入链路都能自动恢复图像质量测试图案比对无像素错误色彩还原准确无丢行丢帧现象凡是做过高速传输项目的人都知道验收才是最见功力的一关。小批量试产前这几项全过才敢把板子发出去。7. 后续扩展方向这套CameraLink转SFP的架构还可以往几个方向扩展。速率升级可以直接把GT线速率从3.125G提到5G或者10G只需重新配置GT Wizard和Aurora IP的线速率参数不用改动逻辑结构。配合SFP模块就能支持CameraLink Full配置更高速率的传输需求比如满配置的Full摄像头85MHz像素时钟也才6.8Gbps一个10G光口就能全部塞下。协议扩展方面可以在Aurora链路上增加上层的UDP封装能力把图像数据包成标准网络包这样后端的采集设备用网卡就能直接收到图像无需专用的CameraLink采集卡。这相当于把光纤链路做成了透明网络隧道。更进一步的还可以在FPGA内集成图像预处理功能。Aurora链路把原始图像送过来之后在FPGA上做坏点校正、增益调整、降噪滤波再把处理完的数据输出可以省掉后端的一台工控机。回看整个开发过程中最花时间的往往不是逻辑代码本身而是高速链路调试。经历过的那些误码、失锁、花屏回过头看都有清晰的原因和解决方法但当时是一个一个试出来的。这也是我想把这套工程源码整理开源出来的原因希望后来者能少踩一些我已经趟过的雷。根据我的个人经验如果你打算在现成板卡上跑这套工程第一步先看管脚配置是否匹配第二步跑第一套基础验证工程第三步再跑完整图像链路这三步稳扎稳打的话整个项目的交付周期能控制在两周以内。祝各位调板顺利一次点亮。