搞FPGA图像传输的工程师十有八九都绕不开CameraLink接口。很多老一点的工业相机、医疗影像设备、军工光电系统输出接口都是CameraLink信号是LVDS差分对优点是带宽高、实时性好缺点是传输距离实在有限常规线缆也就三五米好一点的线能到十米左右。把CameraLink信号从设备间拉到几百米甚至更远最成熟的做法就是转光纤。这个项目做的事情简单说就是用Xilinx FPGA的高速收发器GT做物理层用Aurora 8B/10B协议做数据编解码把CameraLink相机的图像数据从电口换成SFP光口收发实现远距离、高帧率、低延迟的图像传输。整套方案包含4套可直接修改的工程源码覆盖了CameraLink Base、Medium两种最常见配置以及低延迟直通、带DDR3缓存两种不同架构。写这篇博文是想把这套方案从架构设计、IP选型到调试踩坑的完整过程记录下来给准备做类似接口转换项目的朋友一个参考。1. 项目全景CameraLink转光口到底在解决什么问题1.1 CameraLink接口的特点与带宽账CameraLink是工业相机领域的老牌接口标准由自动化图像协会推动本质是把并行图像数据经过LVDS串行化通过差分线对传输。低端一点用Base配置4对LVDS数据加一对时钟每个时钟周期能带28bit进阶用Medium配置8对数据每周期带80bit再往上Full配置是16对数据带宽翻倍。实际项目中Base配置跑1080P30Hz、12bit灰度是常见场景像素时钟在74.25MHz到85MHz之间。很多人容易忽略的一点是CameraLink的带宽要按“像素时钟×并行位宽”算不能只看标称的“28bit数据”。比如Base配置按85MHz像素时钟算数据率就是85M×28bit2.38Gbps换算成串行LVDS链路四对线每对约595Mbps。真实相机标称的“24bit RGB88860fps”或“8bit灰度120fps”就是在数据位和时钟频率两个维度上做取舍。这个带宽账在做后面光口线速率换算时非常重要我建议拿到项目第一步就是把相机的像素时钟、位宽、帧率三项列全。CameraLink最大痛点就是传输距离。因为LVDS电平摆幅小靠差分抑制共模干扰但走线长了高频衰减明显。我实际测过普通的CameraLink线缆Base配置在85MHz像素时钟下超过8米图像就开始出现偶发像素错误换好的低损耗线也就是十二米左右。工业现场设备经常要分散布置相机在设备端、采集主板在控制柜里一个车间隔几十米很常见这时CameraLink原生的电接口根本不够用。转光纤本质上就是把“电的CameraLink”打包成“光的数据流”距离从几米拉长到几百上千米同时光电隔离还能解决接地环路干扰这是很多项目选择转光口的直接原因。1.2 传输协议选型为什么用Aurora 8B/10B光口传输方案其实不少常见的有几类一是直接用GT收发器和自研协议开发量最大二是用Xilinx官方的Aurora 8B/10B三是用10G/25G以太网等网络方案。就CameraLink这种实时图像流而言Aurora 8B/10B是性价比最高的选择。Aurora是Xilinx提供的免费链路层协议跑在GT高速收发器上面帮用户把GT复杂的状态机、时钟对齐、初始化握手都封装好了。8B/10B编码的作用是保证数据流的直流平衡和足够多的跳变沿让接收端时钟恢复电路正常工作这一点对光模块传输特别重要。FPGA行业内很多朋友问过我为什么光口不直接用千兆网方案原因很简单千兆网MAC、IP、UDP协议栈要占用大量FPGA资源和CPU资源还会引入不可控的延迟抖动对图像实时传输不友好。Aurora则没有网络层负担用户接口就是一个简单的数据流延迟低、确定性强一帧图像进去、出来就是一致的。虽然Aurora 8B/10B不提供重传和纠错但图像传输场景本来就不怕偶发误码顶多一个像素花掉怕的是丢帧和不同步。把偶发误码控制在可接受范围完全可以通过光模块质量和线路预算来保证。Aurora支持多通道绑定Base做不过来的带宽可以通过绑定两路GT翻倍这为CameraLink Medium甚至Full留下了扩展空间。2. 系统总体设计与关键器件选型2.1 数据链路总体设计这套方案的完整链路分两块看数据从相机出发的路径是CameraLink相机 → LVDS解码DS90CR288A或FPGA内部接收 → 像素重组模块 → 异步FIFO缓冲 → Aurora帧打包 → GT发送通道 → SFP光模块 → 光纤接收端反过来光纤 → SFP光模块 → GT接收通道 → Aurora解帧 → 异步FIFO → CameraLink编码DS90CR287 → 后端设备关键点在于CameraLink像素时钟和GT用户时钟是异步的所以中间必须有一级异步FIFO做跨时钟域过渡。很多刚开始做接口转换的工程师会忽略这一点直接把像素数据硬塞进Aurora的用户接口结果图像随机错位。异步FIFO深度不需要很大普通128×32就够但一定要用标准格雷码同步指针的异步FIFO结构或者直接用Xilinx FIFO IP省心又可靠。后端为什么要用DS90CR287把LVDS再发出去因为很多工业相机后端接的是采集卡或显示器它们认的是CameraLink电信号光口只是中间的传输段。如果接收端对接的是我们自己的FPGA系统那也可以直接在后端FPGA里解Aurora帧、恢复行场同步信号不需要再转CameraLink。4套源码里我两种做法都做了工程一和工程二带CameraLink恢复输出工程三和工程四是FPGA直接对接后端用户可以按需选。2.2 CameraLink解码芯片方案还是FPGA裸解CameraLink接口进入FPGA这一步有两条路用DS90CR288A专用解码芯片或者直接用FPGA的LVDS缓冲器接收。两条路我都走过谈谈区别。用DS90CR288A芯片会把四对LVDS数据线解成28位并行TTL信号同时恢复出像素时钟。FPGA这边只要用普通IO把并行数据采进来就行逻辑简单、时序稳定。缺点是板子上多一片芯片、多一组供电BOM成本略高。对量产项目来说多几十块钱换来的可靠性是值得的。直接用FPGA接收不需要外部芯片利用FPGA的IBUFDS差分输入原语和ISERDES串转并功能理论上28bit数据加像素时钟都能在内部恢复。好处是省芯片、可灵活调整位宽坏处是对PCB走线、时钟约束、FPGA引脚要求高一旦板子布得不好LVDS信号质量差就会产生偶发Bit错误而且这类错误非常难排查。我自己的习惯是原型验证阶段用FPGA裸解方便改代码正式项目一律加解码芯片把问题范围缩小。给一段FPGA裸解时的Verilog写法作为参考主要是例化差分输入缓冲和异步FIFO写侧// LVDS差分像素时钟输入 IBUFDS #( .DIFF_TERM (TRUE), .IOSTANDARD (LVDS_25) ) u_ibufds_clk ( .I (cam_clk_p), .IB (cam_clk_n), .O (cam_clk_i) ); // 像素时钟经过BUFG后作为采样时钟 BUFG u_bufg_clk ( .I (cam_clk_i), .O (cam_clk) ); // 异步FIFO写侧例化参数按实际位宽调整 fifo_wr u_fifo_wr ( .wr_clk (cam_clk), .din (cam_data_28b), .wr_en (cam_data_valid), .wr_ack (), .full (fifo_full) );这里DIFF_TERM要按板子实际有没有端接电阻来设如果PCB上已经放了100欧电阻就不能再开DIFF_TERM否则等效并联阻抗不对信号反而变差。另一个细节是LVDS输入时钟对要用IBUFDS全局时钟BUFG不要直接用普通IO到逻辑否则像素时钟质量差会把整条链路带崩。2.3 GT线速率计算与参考时钟选择选GT线速率的依据就是前面算出的CameraLink原始数据率加上协议开销。以Base配置、85MHz像素时钟为例原始数据率2.38Gbps。Aurora 8B/10B的链路层要额外消耗一部分带宽8B/10B编码本身把有效位宽打了八折链路实际有效载荷大概是线速率×0.8再扣掉Aurora控制字开销。3.125Gbps线速率下可用净荷在2.4Gbps上下刚好比2.38Gbps原始数据率高一点点。所以要跑满85MHz的Base配置性价比最高的选择就是单路3.125Gbps如果客户相机像素时钟只有74.25MHz那2.5Gbps线速率也能勉强用但市面上便宜的SFP光模块基本都是1.25G/3.125G/4.25G这几个档位2.5G反而不容易买所以直接统一配3.125G。线速率定下来之后参考时钟频率必须是线速率的整数分之一这是GT的PLL分频关系决定的。3.125Gbps配125MHz参考时钟倍频系数25整数倍可以正常锁存如果硬要用148.5MHz这种视频常用时钟3.125/0.1485≈21.04不是整数GT根本配不出来。这个坑我见很多人踩过所以设计是在一开始就固定好CameraLink像素时钟是异步的跟光口参考时钟互不干扰光口参考时钟直接选125MHz或156.25MHz这种标准值别把视频时钟硬拉到GT上。如果工程升级到Medium配置8对LVDS数据全部用满85MHz像素时钟下原始数据率达到4.76Gbps。单路3.125G的净荷不够我倾向用双路GT绑定两路3.125G绑定后净荷约4.8Gbps到5.0Gbps算下来余量很小。为了稳妥工程二里我把约束放宽到双路3.125G只保证像素时钟≤75MHz的Medium相机能满负荷跑像素时钟更高的则建议升到四路或者换更高线速率的GTX器件。这个“带宽余量不要低于15%”的教训是实测出来的后面调试章节会详细说。2.4 Aurora 8B/10B IP配置建议Aurora IP的配置页里最关键的几个选项是线速率、参考时钟、通道数、接口模式。接口模式有Framing和Streaming两种区别在于Framing模式下用户数据包有开始和结束标志接收端能明确知道包边界Streaming模式下用户数据是连续流没有帧的概念。图像数据天然是分帧的所以我建议选Framing模式这样在接收端恢复图像时不需要额外设计帧头检测电路直接在用户接口的sof/eof标志控制下写入FIFO就行。Flow Control这个选项Aurora里的流控分为用户流控和原生流控。原生流控用于链路层自身的背压用户流控用于上层数据流控制。很多人在图像传输项目里会纠结要不要开用户流控我的答案是能不开就不开。流控会增加链路开销和延迟而且图像数据是连续流一旦上游相机不暂停流控信号只能让FPGA内部FIFO暂存不能真正减少数据量。与其靠流控背压不如把带宽预算做足、FIFO深度配够让整个链路处于“永不拥塞”的状态这是图像传输里最稳妥的设计思路。通道数方面Aurora支持1到8路通道绑定。绑定后IP内部会自动做字节对齐和通道去偏斜用户接口上表现为一个统一的数据总线带宽是单通道乘以通道数。工程二里我配置了两路GT绑定硬件上两个SFP口要接同一根多芯光缆的两根光纤或者收发各两根光纤。绑定模式下如果某一根光纤信号质量不好整条Aurora链路都起不来所以调试时优先保证单通道各自都稳定再开绑定。3. 四套工程源码的架构与适用场景这个项目我整理成4套相互独立的Vivado工程分别针对不同应用场景。很多人拿到源码第一反应是自己去翻代码但我觉得更高效的办法是先搞清楚每套工程解决什么问题再带着问题去看代码。3.1 工程一CameraLink Base单通道光口传输工程一是最基础也最常用的版本硬件上只需要一个SFP口、一片DS90CR288A解码、一片DS90CR287编码接收端用。FPGA逻辑分为三块CameraLink解码与像素拼接、Aurora帧打包、Aurora链路收发。CameraLink解码与像素拼接这部分重点是把28bit并行数据按CameraLink协议映射成我们需要的像素格式。CameraLink Base的28bit里面有24bit图像数据、3bit同步信号FVAL、LVAL、DVAL、1bit保留位。图像数据可能是RGB888三通道各8bit也可能是8bit灰度×3个像素点共用总线具体映射要看相机的像素格式配置。我在源码里用一个可配置的映射宏定义来控制切换像素格式时不需要改逻辑只改参数。Aurora帧打包模块是工程一的核心它把异步FIFO输出的图像字节流按自定义帧格式封装。自定义帧格式我设计成帧头2字节固定值0xF1 0xF2然后是行号、列号、像素位宽等图像参数信息再跟着整帧图像数据帧尾加一行奇偶校验字节。帧头在接收端的作用是确定图像帧边界行号列号用于接收端恢复同步信号校验字节用于发现传输过程中的误码。这个帧格式看起来简单但没有它接收端根本不知道一帧图像从哪开始、到哪结束恢复出来的画面会完全乱掉。3.2 工程二CameraLink Medium双通道绑定版工程二面向更高带宽的需求把CameraLink解码扩展到Medium配置。硬件上解码芯片换成DS90CR288A的两片并联或者用支持Medium的专用芯片FPGA内部同时接收两条LVDS数据链路合并成完整的80bit数据。Aurora侧配置两路GT通道绑定用户接口数据位宽相应翻倍通过Aurora内部对齐机制保证两路数据在接收端完全同序。双通道绑定有个容易被忽略的注意点两路GT必须使用同一个参考时钟、同一个GT QuadMGT Quad在同一个管脚区域内否则无法绑定。如果板子上两个SFP口分别接到了不同QuadAurora是绑不起来的。我在工程二的约束文件里把这一点写成了注释提醒后续二次开发的人不要乱挪管脚。从带宽上看工程二的实际数据瓶颈比很多人预想的要明显。单路3.125Gbps经过8B/10B编码和Aurora头开销后有效净荷大概在2.4Gbps两路绑定也就4.8Gbps到5.0Gbps。而Medium配置在75MHz像素时钟下的图像数据率简算约4.2Gbps加上DVAL/LVAL这些控制位后剩余余量在15%以内。所以工程二我明确建议客户按“≤75MHz像素时钟”来规划相机参数如果相机必须跑85MHz那就考虑换更高线速率的GTX器件或者用四路GT绑定这是工程二源码里注释最重的一段。3.3 工程三低延迟直通版工程三是给对延迟极其敏感的视觉定位、机械臂引导这类项目准备的。这类场景里相机到算法处理的时间每多1毫秒机械臂的动作节拍就要跟着慢所以设计原则是“能不打DDR就不打DDR能少一级FIFO就少一级”。工程三去掉了DDR3缓存只保留两级异步FIFO第一级在CameraLink解压后匹配像素时钟与逻辑时钟第二级在Aurora接口前匹配逻辑时钟与GT用户时钟。像素从相机进入FPGA到从光口发出总延迟实测能压制在几十微秒量级取决于帧行长度和直接用CameraLink线缆直连的延迟差别已经几乎可以忽略。当然低延迟是有代价的没有帧缓存意味着两端带宽必须精确匹配一旦相机瞬时速率超出了光口净荷能力FIFO就会溢出丢帧。所以在工程三的源码注释里我特别标注了“输入端持续突发时间不得大于某阈值”的约束实际使用中尽量降低相机帧率或分辨率让长期平均带宽低于光口净荷的80%。3.4 工程四带DDR3帧缓存版与工程三相反工程四的定位是应对带宽波动大、数据突发的场景。比如某些高帧率相机短时间内输出一大波数据然后停一阵或者相机的输出格式在运行过程中会动态切换瞬时带宽可能跳变。这种场景如果走直通链路FIFO肯定扛不住必须把整帧数据先写进DDR3缓存再由Aurora侧按稳定速率读出发送。工程四的逻辑结构大概是CameraLink解码 → 帧缓存写控制 → DDR3控制器MIG IP → 帧缓存读控制 → Aurora打包 → GT。帧缓存划分成两个Buffer轮流读写也就是俗称的双缓冲机制。一帧图像写完后读控制才能开始读这一帧写当前帧的时候读上一帧让两端解耦。这个架构下光口侧的输出速率完全由Aurora自身的字节流决定与相机输出速率无关所以稳定性最好代价是端到端延迟至少增加到一帧时间1080P60Hz大概16.7ms。对于动态分辨率、动态帧率切换的相机工程四是最稳的选择。切帧率瞬间不会丢帧最多是首帧延迟大一点。这套源码里还加了一个帧计数寄存器通过AXI-Lite接口读取方便上位机监控有没有丢帧调试时非常好用。4. 从零开始跑通这套方案的实操流程4.1 硬件准备与光模块选型板卡方面不管是买现成开发板还是自研板至少需要具备一个SFP笼子或者SFP笼子接普通千兆SFP光模块、一个可用的GT参考时钟源板上晶振或时钟芯片、CameraLink输入接口MDR26座子以及后端CameraLink输出接口。如果选工程四还需要一片DDR3颗粒或SO-DIMM条。光模块选型要特别注意速率匹配。很多朋友手头有现成的千兆SFP模块1.25Gbps拿来做3.125G的Aurora链路结果链路起不来。1.25G模块的内部激光器和驱动器带宽是按1.25G设计的跑3.125G信号完整性完全不够。工程里标准配置建议使用850nm多模SR模块这种模块实际能支持到4.25G甚至更高配多模光纤使用几十米到几百米都没问题。如果你要传几公里就要换1310nm单模模块和单模光纤同时确认激光器支持3.125G速率。千万别拿千兆模块硬跑3.125G这个错误我至少见过三次每次都查了半天才发现。4.2 Vivado工程搭建与关键IP参数创建工程时我建议按这个顺序操作先打开GT Transceivers Wizard按前面算好的线速率把GT通道配出来接着添加Aurora 8B/10B IP放上去之后IP核内部会自动调用一个GT封装或者让你绑定已有的GT Wizard配置Vivado版本不同会略有差异最后把Aurora的example design跑一遍确认它能正常工作再开始挂接自己的业务逻辑。在GT Transceivers Wizard里重点检查三处Reference Clock频率选125MHzLine Rate选3.125GbpsTX/RX数据位宽和Aurora要求的位宽一致。如果Aurora IP是独立添加的它内部会自己生成GT不需要你手动开GT Wizard如果采用GT Wizard手动配置再给Aurora引用那就要在Aurora的配置界面里选择“Use GTs from existing example/GT Wizard”这个选项。不同Vivado版本UI有差别但核心逻辑一致GT物理层参数线速率、参考时钟必须和Aurora逻辑层参数完全匹配。约束文件写好后综合实现前先做一次DRC检查。最容易漏的是复位时序约束和时钟域约束Aurora的example design自带的约束文件可以直接抄过来不要图省事删掉。如果自己写约束至少要给GT参考时钟创建input clock约束给Aurora用户时钟如usrclk创建生成时钟约束把TX/RX差分管脚约束到对应的GT pin上。4.3 上板调试四步法我调试这套方案从来不会一上来就接相机而是按下面四步来第一步跑IBERT眼图测试。Vivado里的IBERT example design会占用一个GT Quad通过JTAG或AXI接口可以读回误码率和眼图张开度。把SFP模块插好、光纤两端回环跑10分钟看误码率是否为零。这一步能筛掉80%的硬件问题SFP焊接、参考时钟、供电、光纤链路质量全都反映在眼图上。第二步跑Aurora example design回环。不加业务逻辑只把Aurora IP的example design跑起来检查channel_up和lane_up信号是否正常拉高。如果拉不高回到第一步继续查物理层。第三步接上CameraLink信号源。先用信号发生器或者相机输出固定纯色画面在FPGA里用ILA观察解码芯片输出的28bit数据和FVAL/LVAL/DVAL时序确认采集正确之后再观察Aurora发送侧和接收侧的帧数据。第四步整链压力测试。在这个阶段我会让相机跑最大分辨率、最大帧率然后持续跑一两个小时同时监控丢帧计数器和误码计数器。稳定不丢帧才算真正通过。这个四步法看起来慢实际上是省时间的。跳过第一步直接接相机一旦图像不稳定你很难区分是物理链路问题还是业务逻辑问题排查时间翻倍。5. 调试中踩过的坑与解决实录5.1 channel_up信号拉不高一套工程在客户现场部署时Aurora链路一直起不来channel_up在高电平上跳来跳去明显是不稳定状态。我先怀疑光模块换了模块还是一样然后怀疑参考时钟示波器量了125MHz晶振没问题最后把接收端的光纤从SFP模块上拔下来仔细看才发现发射端和接收端光纤插反了方向RX管子收到的是发射端发出的光没有收到环回信号。这个案例说明一个很基础但容易被忽略的点Aurora初始化握手的channel_up需要链路两端同时工作才能建立一端光路不通另一端永远是DOWN。所以调试时我建议先把光纤做成一个物理环回从同一个SFP口的TX出来进同一个口的RX如果这样channel_up能拉高说明FPGA侧没问题问题就在光纤链路或者对端如果环回都起不来先查GT配置和参考时钟。5.2 图像花屏最后发现是跨时钟域板子上电后图像能出来但是每隔几秒会闪一下花屏不是持续性的是随机的小面积马赛克。用ILA抓发送端数据看到的就是某个时刻FIFO输出数据出现一个跳跃。查了半天发现我直接用像素时钟去写Aurora用户接口而Aurora用户接口的时钟是GT恢复出来的usrclk两个时钟完全异步读写冲突导致FIFO偶发读写错误。解决办法是加异步FIFO并且保证FIFO读侧的数据准备好信号与Aurora用户接口的tvalid握手配合好。这个错误非常典型因为纯仿真环境下异步FIFO不报错只有上板跑数据才会随机暴露。代码里看起来没毛病实际上跨时钟域的问题从没消失过。5.3 工程二带宽算漏了丢帧严重工程二刚开始测试Medium相机画面丢帧很严重而且丢帧频率还跟图像内容有关画面变化快的场景丢得更凶。查到最后问题出在带宽预算上。我前面算的4.76Gbps原始数据率经过8B/10B编码后再加Aurora控制字开销实际需要的光口净荷比理论值多了约7%左右而我用的双路3.125G绑定理论净荷5.0Gbps算算好像有200Mbps余量但Aurora实际可用净荷还要再打折扣导致长期跑满带宽时FIFO溢出。后来我把相机的像素时钟从85MHz降到75MHz或者把GT线速率升到4.25G需要确认光模块支持问题就解决了。这也是我在工程二说明里强调“不要让平均带宽超过链路净荷的85%”的原因带宽预算不是数学题得给硬件留出余量。5.4 常见问题速查表把调试过程中客户和网友问得最多的问题整理成一个表方便大家快速定位见下面的表格。问题现象可能原因排查/解决办法channel_up一直为低光纤收发接反、参考时钟频率不对、光模块速率不支持先用光纤物理环回再查GT参考时钟最后换光模块channel_up不稳定跳动SFP模块供电不足、TX/RX信号完整性差检查模块电源退耦换更短的光纤用IBERT看眼图图像花屏/马赛克跨时钟域问题、像素拼接映射不对、LVDS信号质量差在解码输出端加ILA确认raw数据再往后查丢帧计数增加瞬时带宽超过链路净荷、DDR3带宽不足降像素时钟或分辨率检查FIFO深度看Aurora侧背压接收端图像整体偏移帧格式中行号/列号解析错误检查打包和解包的位映射参数是否一致偶发整行错位LVAL行同步信号在打包时被丢弃打包逻辑要保留LVAL状态接收端按行号恢复行同步5.5 几条独家实操心得最后说几个未必写在文档里、但对排查效率影响很大的习惯。第一光口调试一定要准备一根高质量短跳线最好是15cm以内的多模光纤专门用于回环测试别拿现场几十米的长线来做初始验证。第二Aurora和GT相关的寄存器不要手动乱配只要IP的example design能跑起来就不要去改底层参数否则问题会变得很难收敛。第三工程里一定要加一个顶层状态寄存器把这些关键信号打成bitmapGT的tx_reset_done、rx_reset_done、Aurora的channel_up、lane_up、FIFO的full、empty、DDR的calib_done调试时通过ILA或AXI一次抓齐少跑很多冤枉路。再补充一个非常实用的技巧给发送端加一个“固定测试图案”模式。只要拉一个引脚打包模块就会忽略CameraLink输入数据改发内置的渐变条纹和彩条。这个模式在联调时特别有用因为你能完全确定发送端的数据内容接收端显示出来是什么样子就能判断问题在发送链路还是接收链路。这个技巧看起来简单但四套源码里我都预留了这个功能实际给别人做技术支持时这个功能省了我无数远程沟通时间。把四套工程源码整体看下来其实每一套的代码量都不算大真正的复杂度都在协议的取舍和时序的处理上。CameraLink转SFP光口这个项目核心不在于“转”这个动作而在于对整个带宽账、跨时钟域、GT物理层和Aurora链路层的理解。我觉得值得参考的经验是先把物理层调稳再谈业务逻辑把带宽余量留足把调试观测点留全这个项目的成功率就已经有了八成。后续如果你要接更高速的相机方向无非是增加通道数、提高GT线速率、把Aurora升级到64B/66B甚至使用其他高速协议但整体的项目方法论是通用的。