FPGA顶起来做CameraLink转SFP光口这件事说实话光看标题就知道是个硬仗。这个项目我前后折腾了不短时间从接口协议梳理、硬件选型到Aurora链路调通、图像数据回环验证每一步都踩过不少坑。今天把这套方案的完整思路、核心细节和实操过程整理出来包括4套工程源码的组织方式和技术支持里的门道给准备入坑或者正在调这个链路的兄弟们一个参考。很多人第一次看到“CameraLink转SFP光口”这个需求第一反应是“这不就是加个转换芯片吗”。真不是。CameraLink接口在工业相机里非常普遍但它本质是并行差分总线传输距离一般在3到10米左右速率从Base配置的2.04Gbps到Full配置的5.44Gbps甚至更高。而SFP光口是高速串行链路单通道速率可以从1G到10G以上用光纤传输可以轻松拉到几百米甚至几公里。两者的物理层、链路层、数据组织方式完全不同靠一颗简单的Level Shifter或者协议转换芯片根本做不了。真正靠谱的通用方案就是用FPGA作为中间桥梁把CameraLink的并行图像数据和控制信号通过GT Transceiver引脚转成高速串行数据再用Aurora8B10B这类纯逻辑的链路协议做编解码和打包传输。这个方案的本质是把“CameraLink的物理并行传输”降级为“FPGA内部的DVP并行总线”再升级为“SFP光口的高速串行传输”。FPGA在这里干了两件事第一作为CameraLink接口的宿主机接收相机端发来的并行数据和时钟解析出有效的像素数据和帧同步信号第二作为Aurora链路的发送端把打包好的图像数据送入GT Transceiver的TX端再经过SFP模块变成光信号发出去。接收端则走完全对称的流程。那为什么选用Aurora8B10B而不是其他高速串行协议比如IBERT、GTP原生模式或者自己写8B10B编解码这里有个很重要的选型逻辑。Aurora是Xilinx官方提供的轻量级链路协议专门解决FPGA与FPGA之间、或者FPGA与交换芯片之间的高速可靠传输。它自己搞定了通道绑定、时钟补偿、数据对齐、流量控制这些麻烦事对外只暴露一个类似FIFO的User Interface。用Aurora8B10B意味着你不用自己操心跨时钟域和字节对齐这种让人头大的问题而是把精力集中在图像数据的打包解包上。先说整个CameraLink转SFP光口系统的逻辑架构它其实可以拆成几条清晰的链路。CameraLink接口这个环节需要先说明白。CameraLink的Base配置使用4对LVDS数据信号Channel Link芯片把28位并行数据转换成4对串行差分对外加1对时钟差分对也就是X0、X1、X2、X3和XCLK。它把数据分成三个端口Port A、B、C来使用每个端口8位或者10位数据再加上LVAL行有效、FVAL帧有效、SPARE保留位这些控制信号最后还有一个串行通信口SerTFG和SerTC用于相机参数配置。这些信号在字节时钟通常是像素时钟下并行到达。FPGA要做的事情是在XCLK的上升沿把这些数据完整采样下来然后还原成可供后续模块使用的DVP时序。在FPGA端CameraLink解码后的数据本质上就是一串连续的像素流伴随的其实是三个关键控制信号帧同步对应FVAL、行同步对应LVAL、数据有效对应DVAL很多时候直接用LVAL内部产生。这跟普通的CMOS/CCD传感器DVP接口完全一致。所以你完全可以复用成熟的DVP图像采集逻辑来管理这部分数据。这里有一个特别容易出现误区的地方。很多人以为CameraLink的LVDS信号可以直接接到FPGA的普通IO上然后靠内部逻辑做差分转单端。这是不行的。CameraLink信号频率在50MHz到85MHz之间速率很高而且规范要求必须使用专门支持LVDS输入的引脚并且在硬件上结合电阻网络做端接。更常见的做法是用DS90CR288A这类CameraLink接收芯片把LVDS差分信号转成28位并行数据和时钟然后直接对接FPGA的普通IO。我们在工程源码里也是这么处理的FPGA侧处理的是已经解码好的并行信号而不直接碰LVDS。接下来是Aurora8B10B核的配置核心点。Aurora8B10B的配置有几个关键参数直接决定整条链路的带宽和稳定性。协议版本必须选Aurora 8B10B因为这是逻辑编码型协议不需要在GT Transceiver里开额外的PCS/PMA特性。链路层配置有两种选择一种是单通道也就是1 lane另一种是多通道绑定从2 lane到16 lane不等。通道数越多总带宽越大。以CameraLink Base配置为例像素时钟大多是75MHz单像素8位也就是图像数据率600Mbps左右算上编码开销和协议开销一个Aurora 8B10B通道在GT参考时钟125MHz下线速率为2.5Gbps有效带宽大概是2.0Gbps到2.2Gbps完全够用。如果你要处理CameraLink Full配置或者双Base相机输入那就要考虑2 lane或者4 lane绑定了。GT Transceiver Wizard的参数和Aurora核需要完全匹配。TX和RX的线路速率、参考时钟频率、数据位宽通常是2字节或4字节、内部PLL类型推荐使用QPLL或者CPLL看速率而定这些必须一致。举个例子如果你的Aurora核配置成线速率2.5Gbps、参考时钟125MHz、用户接口位宽16bit那GT Wizard里的TX/RX线速率也必须配成2.5GbpsGT参考时钟也必须给125MHz。有一点点参数错位导入工程后综合没问题但上板就是链路起不来。整个工程里最核心、也最值得说的是CameraLink数据如何适配到Aurora用户接口。这不是简单的把像素数据塞进FIFO然后读出来发出去里面有好几个关键步骤。第一步是像素重组。Aurora8B10B核的用户接口是32位或者16位的数据总线而CameraLink的像素数据是8位或10位对齐的。如果你直接把8位像素挂在32位总线上带宽浪费四分之三不说还会导致像素错位。所以需要一个打包模块把连续的8位像素数据按32位对齐方式拼接起来形成32位的“像素组”然后写入异步FIFO。这个打包模块本质上就是一个移位拼接逻辑核心代码逻辑就是用一个累加器统计已经收到的字节数每收满4个字节就产生一个32位的写请求。关键在于字节顺序要保持和相机输出的像素顺序一一对应否则图像会出现整体平移甚至颜色通道错乱。第二步是跨时钟域处理。CameraLink解码时钟像素时钟PIXCLK和Aurora核的用户时钟USER_CLK是异步的。这个时钟域转换必须通过异步FIFO来实现。FIFO的写侧时钟用PIXCLK读侧时钟用USER_CLK。这里有几个细节要特别注意FIFO的深度至少要能缓存几行图像数据这样在Aurora链路尚未启动或者对端还没有准备好接收时不会丢数据FIFO的几乎满信号要反馈给发送控制模块用来反压上游的写操作。如果反压不及时图像会出现撕裂或者丢帧现象。第三步是帧同步信号和行同步信号的传输。这个看起来很简单实际上踩坑最多。CameraLink接口里有FVAL和LVAL两个关键信号它们和像素数据是同步的。如果你在打包图像数据时把这些控制信号丢了那接收端就完全不知道什么时候是图像帧头、什么时候是一行结束。业内常用的做法是用开销极低的行标志符来替代在每一行数据的头部插入一个特殊的行起始字比如0xBC、行结束字比如0x7B、帧起始字0x5A和帧结束字0xA5。这种方式叫软帧格式不需要额外的边带信号线完全依靠数据流里的特征字来定界。接收端只需要在解包模块里检测这些特征字就能精确还原出DVP时序。这个方案在工程上非常实用尤其是远距离传输时你根本不可能把控制信号单独拉一根线过去。第四步是Aurora用户接口的握手机制。Aurora核的用户接口本质上是AXI4-Stream。发送端需要做TREADY和TVALID的握手管理。链路没有初始化完成时TREADY不会拉高这时候不管FIFO里有多少数据都不能发送。链路正常后发送模块要持续监控TREADY信号只有TREADY拉高且TVALID拉高时数据才真正被发送出去。很多人调Aurora失败不是链路起不来而是发送端没有正确处理握手导致数据堵在FIFO里出不去。这里有一个经验发送控制状态机建议设计成空闲、等待链路、发送数据、发送完成四个状态在发送数据状态里每次调用发送接口前必须等待tready信号为高然后拉高tvalid并输出数据发送完成后拉低tvalid并回到空闲状态。现在说硬件设计和板级链路这部分决定了你的工程能不能稳定跑起来。CameraLink转SFP光口的板卡核心架构是这样的CameraLink接口MDR 26pin或者SDR 26pin连接器连接相机经过DS90CR288A或等效芯片解码后并行数据接到FPGA的IO上FPGA内部完成图像打包和Aurora协议处理然后把串行差分对接到SFP光模块的TX和RX引脚。这里SFP光模块直接连接FPGA的GTX Quad引脚中间不建议再加任何转换芯片。选择GTX Quad时要注意不同Bank支持的参考时钟和引脚位置不同你必须查阅FPGA芯片的引脚手册把SFP模块的TX/RX差分对分配到和参考时钟在同一个Quad的GT引脚上。这个分配如果有误你这个工程布线布死都跑不起来。电源设计这块值得多啰嗦几句因为很多板卡莫名其妙跑飞或者链路不稳最后查下来都是电源纹波问题。GT Transceiver需要三路核心供电AVCC1.0V模拟电源、AVCCAUX1.8V模拟辅助电源、MGTAVCC1.0V收发器模拟电源。这些电源对噪声要求极高普通开关电源直接供电是绝对不行的至少需要用低噪声LDO做二级稳压并且每个电源引脚都要加足够多的去耦电容。GTP/GTX引脚的对地电容和上拉电阻也要按Xilinx的推荐电路来设计否则链路锁相环锁定不了。时钟方案上如果板卡上有多个SFP光口推荐用一个独立的可编程时钟芯片给所有GT Quad产生参考时钟比如Si5338或LMK系列。这样灵活性最高初期调试可以随意修改输出频率适配不同的Aurora线速率。如果你为了节省成本用固定频率的晶振那后续想改Aurora线速率就会很痛苦尤其是GT参考时钟和线速率是绑定的这种关系。以太网口的SFP模块选择有两个常见坑。第一SFP模块的类型和波长要匹配你的光纤。多模光纤用850nm的SFP-SX模块单模光纤用1310nm的SFP-LX模块选错模块光功率和接收灵敏度都不对链路可能根本起不来。第二SFP模块的速率等级要支持你的线速率。额定1.25G的千兆SFP模块你硬跑2.5G链路可能偶尔能起来但稳定性极差。建议选取支持2.5G以上的SFP模块。回到核心的原语配置和使用问题上。Aurora8B10B核在Vivado里创建后除了例化IP核代码你还需要仔细检查几个用户接口信号。PMA_INIT信号在复位后自动拉高等初始化完成后会拉低这表示GTX收发器完成初始化。LANE_UP信号拉高表示链路物理层已经完成同步。CHANNEL_UP信号拉高表示Aurora协议层已经建立连接。这三个信号是调试链路状态的必要观察点建议在ILA里全部引出来观察。工程里最常见的链路起不来问题第一步就应该看LANE_UP是不是已经拉高如果一直拉不高那问题一定在物理层时钟没有、复位异常、SFP光模块没插好、光纤收发光功率不对。在Aurora核配置界面还有一个Flow Control选项一般情况下建议关闭。CameraLink图像传输是流式大数据量传输流控机制会周期性发送控制消息占用额外带宽而且处理不好会造成图像数据堆积。关掉以后整个链路的带宽利用率更高时序也更好控制。还有一点值得单独说就是Aurora8B10B核支持Frame模式和Burst模式。Burst模式更适合我们这种无固定帧定时关系的数据流。在Burst模式下当用户数据准备好时只要TREADY拉高发送端就开始发送数据发送完成后链路空闲。这个模式简单可靠是图像传输场景的首选。Frame模式则必须要维护一个帧定界标志如果接收端不处理帧边界反而容易出错。所以在工程源码里全部统一使用Burst模式。接收端的数据还原是另一个容易出幺蛾子的环节。光口对端可能是另一个FPGA也可能是PC机上的光纤采集卡收到Aurora数据后解包出像素数据和帧起始特征字。接收端的解包模块做的事情是从数据流里找到帧起始字和行起始字然后按32位数据宽度恢复出8位像素序列生成对应的FVAL和LVAL信号再把这些信号送到下游的图像处理模块。这个过程同样需要异步FIFO做缓冲因为Aurora接收时钟域和下游图像处理时钟域往往不同。帧丢失和丢行这个问题必须展开说。在图像传输中帧丢失往往不是物理链路误码造成的而是接收端的FIFO溢出。比如发送端以75MHz时钟写入FIFO接收端下游图像处理模块可能因为忙于处理上一帧数据而暂停读取FIFO就会瞬间被塞满。这时候如果不做处理后面的数据就会丢失。解决思路有两个层面。简单层面是加大FIFO深度比如用一个行宽的4到8倍。更深层的方案是加入帧级背压当FIFO满时接收端可以向发送端发送反压信号这个需要自定义消息通道来实现比如在数据流里插入暂停帧标志但从工程复杂度看加大FIFO深度在绝大多数相机分辨率场景下就够用了。Aurora8B10B还有一个很多人会忽略的特性叫时钟补偿。因为GT收发器和远端设备之间的参考时钟不可能完全同源存在微小频率偏差长时间传输会在接收端产生数据缓冲溢出或为空。Aurora协议里有专门的时钟补偿序列Clock Compensation Sequence每隔一定周期会自动发送这个序列接收端根据序列做弹性缓冲调整。这个特性在IP核内部是自动完成的你不需要干预但你要确保GTX的RX Elastic Buffer配置正确。在Vivado的GT Wizard里不同的线速率会有对应的推荐设置使用默认推荐就行。关于完整工程源码的组织方式做一个梳理。这4套工程各自的侧重点不同可以按需求选择参考。第一套是单路CameraLink Base转单路SFP光口的单板方案也是最常见的一套。它包含完整的CameraLink解码模块、像素打包模块、异步FIFO、Aurora发送模块、SFP光口逻辑。这套源码的FPGA型号以Kintex-7或Artix-7系列为主适合工业相机数据传输和图像采集系统。调试时用两块板卡对连或者用一个SFP光模块环回TX直接接到RX就能完成验证。第二套是双路CameraLink Base转双路SFP光口方案本质上是第一套方案的扩展。它适合双相机立体视觉或者两台相机拼图的需求。工程里包含两套独立的Aurora发送链路每个链路的参考时钟共用一个GT Quad但使用不同通道。数据打包模块、FIFO模块、控制状态机在面积允许的情况下会分别例化确保两路视频流互不干扰。第三套是接收端方案也就是SFP光口接收、解码恢复出CameraLink并行数据或者直接恢复出DVP时序输出给后级。这套工程常用于对接已有的显示系统或者图像处理系统。接收端同样包含Aurora接收核、解包模块、字节位宽转换模块和FIFO。第四套是CameraLink Full配置转SFP光口方案这个就涉及PCIe、HDMI这些周边接口的协同工作了。Full配置的CameraLink接口有8对LVDS数据通道像素时钟更高数据量基本翻倍所以在FPGA内部需要把图像数据分成两个Aurora通道并行发送接收端再把两个通道的数据合并恢复。这对时序约束和链路同步要求更高工程里会包含多通道绑定Channel Bonding的Aurora配置。这几套工程的共同点是都包含了完整的XDC管脚约束和时钟约束文件这在实际移植时极其重要。很多人拿到一套FPGA工程后工程代码没问题但管脚分配和你自己的板卡完全不匹配光改引脚就要半天改完还发现某些关键引脚没有加约束导致时序收敛不了。所以我在每套工程里都单独做了管脚约束模板只需要按自己的板卡改物理引脚位置所有IO标准、BANK电压、时序例外都保持默认能省下大量不必要的调试时间。把关键代码片段放出来方便直接理解打包和解包的逻辑。发送端打包模块的核心是用状态机控制字节拼接过程。核心思路就是每个PIXCLK周期到来时把8位像素值写入一个32位移位寄存器字节计数加1凑满4个字节后产生一个有效的写使能信号将32位数据写入FIFO。代码逻辑大概是这样的always (posedge pix_clk or posedge rst) begin if (rst) begin byte_cnt 2d0; pixel_buf 32d0; end else if (fval lval dval) begin case (byte_cnt) 2d0: pixel_buf[7:0] pixel_data; 2d1: pixel_buf[15:8] pixel_data; 2d2: pixel_buf[23:16] pixel_data; 2d3: pixel_buf[31:24] pixel_data; endcase byte_cnt byte_cnt 1b1; if (byte_cnt 2d3) begin fifo_wr_en 1b1; end end else begin fifo_wr_en 1b0; end end这段逻辑是简化的实际工程中还要考虑行结束处不足4个字节的情况比如图像宽度不是4的整数倍行末尾会有1到3个无效字节。我习惯在行结束时补零对齐并在解包端根据发送的每行有效像素数来裁剪。这个有效像素数可以通过寄存器配置灵活应对不同分辨率的相机。接收端解包模块与之对称先检测帧起始字然后每收到一个32位数据按字节拆分成4个8位像素输出同时在输出端产生对应的行有效和帧有效信号。为了平滑输出还会用一个深度为4KB的FIFO做输出缓存。Aurora发送控制状态机的代码是这个工程里最容易被低估的部分。很多人的状态机写得粗糙tready没拉高就拉高tvalid结果数据总线上的内容根本不对。我在每个发送状态前都加了tready等待逻辑并且引入了超时保护。链路一旦因为误码或者远端掉线导致tready长时间不拉高超时计数器会触发复位状态机等待链路重新建立后再继续发送。这段逻辑实际应用中非常有用尤其是在光模块热插拔后链路恢复能力完全依赖它。// Aurora发送状态机 localparam IDLE 3d0; localparam WAIT_LINKUP 3d1; localparam WAIT_TREADY 3d2; localparam SEND_DATA 3d3; localparam SEND_COMMIT 3d4; always (posedge user_clk or posedge rst) begin if (rst) begin state IDLE; axis_tvalid 1b0; axis_tdata 32d0; end else begin case (state) IDLE: if (chan_up) state WAIT_TREADY; WAIT_TREADY: if (axis_tready) begin axis_tvalid 1b1; state SEND_DATA; end SEND_DATA: begin if (axis_tready) begin axis_tvalid 1b0; state SEND_COMMIT; end end SEND_COMMIT: state WAIT_TREADY; default: state IDLE; endcase end endAurora核例化时的初始化参数也需要注意。比如Aurora8B10B核需要配置消息周期默认的15.2微秒即可。接口宽度选择16bit还是32bit直接决定用户时钟频率。16bit位宽时用户时钟是线速率除以208B10B编码后是2字节为1拍所以用户时钟是125MHz匹配2.5Gbps线速率32bit位宽时用户时钟是线速率除以40也就62.5MHz。一般来说为了时序收敛和FIFO位宽匹配方便我习惯用32bit位宽。这个位宽配置一旦定了后续所有打包解包逻辑都要按这个位宽来设计中途改位宽是一件极其痛苦的事。时序约束这块也必须说清楚。CameraLink解码出来的并行时钟是输入时钟需要通过create_clock约束到对应的输入引脚。GT参考时钟在XDC里只能做约束不能随便加false path。Aurora核内部的时序由Xilinx自动约束你不需要干预但你自己的打包和解包逻辑需要加set_max_delay约束跨时钟域路径吗不需要。因为异步FIFO已经隔离了PIXCLK和USER_CLK的跨时钟域综合工具会自动识别FIFO两侧为异步时钟不需要额外添加跨时钟约束。需要注意的是如果你把FVAL、LVAL这些信号直接跨时钟使用而不经过FIFO或者同步器那就必须加set_false_path或set_max_delay约束否则很容易出现亚稳态问题。还有一个很常见的问题就是SFP光模块的信号检测和链路指示。SFP模块的TX_FAULT和RX_LOS信号是LVCMOS电平和FPGA IO电平匹配问题不大但逻辑上你要做处理。特别是RX_LOS为高时表示光信号丢失这往往是光纤未插好或者对端没发光。调试时RX_LOS信号可以直接接到LED指示灯上这个比看逻辑分析仪还直观。接下来问题排查这块一定要说调FPGA高速链路大多数时间都花在这里。第一个经典问题Aurora链路起不来LANE_UP死活不拉高。排查顺序是先看GT参考时钟有没有正确送入用ILA或者chipscope抓GT REFCLK的引脚电平如果配置了计数器监测的话也可以用示波器直接量FPGA的参考时钟引脚。然后再看复位时序Aurora核的复位信号必须低电平有效而且复位释放时GT的PLL需要一定锁定时间如果你复位脉冲太短PLL还没锁住就被释放了链路永远起不来。PMA_INIT信号在复位释放后需要大概几个毫秒完成GT初始化这个时间因芯片而异。最后再看SFP光模块本身用光功率计测TX端发光功率和RX端接收功率发端没光就是SFP模块坏了或者没配置好收端没光就是光纤跳线、法兰盘的问题。第二种情况链路起来了LANE_UP和CHANNEL_UP都拉高了但图像数据对不上。这时先减少数据量发送一个固定图案比如计数器值在接收端观察数据是否正确。如果固定图案对不上那就是打包解包的字节顺序不一致Aurora核例化时有一个“TX/RX Byte Swap”选项有时候需要开启这个选项才能对齐字节顺序。这个选项在Xilinx文档里有明确说明。如果固定图案对换成真实图像反而花屏那就是FIFO深度不够或者帧同步字检测逻辑有误。第三种情况最隐蔽图像偶尔丢帧、撕裂而且抓不到规律。这种问题大概率是FIFO溢出或者反压不及时。我用ILA在发送端同时抓FIFO的写使能和几乎满信号发现几乎满信号拉高后上游写操作仍然持续了一个时钟周期这一个周期就可能导致溢出。处理办法是把FIFO的几乎满信号提前两级触发给上游留出足够的反应时间。还有一种是跨时钟域写入时写数据已经发出但字节计数逻辑没等到最后一个周期就结束了这种问题需要仔细核对打包状态机的时序。第四种情况长时间运行后链路掉线而且不是光模块发热那种随机掉线是固定时间后掉。这个大概率是时钟补偿机制没生效。Aurora8B10B核的参考时钟如果精度不达标比如用了精度只有100ppm的普通晶振而另一端用的是50ppm的恒温晶振两边的频率偏差累积速度很快时钟补偿消息在特定周期内无法完全吸收偏差最终接收端RX缓冲溢出链路自动重启。解决方法也很简单换一个高精度的有源晶振或者可编程时钟源。在性能评估上这套方案的实际效果在同类型工业项目中是经受住考验的。CameraLink Base配置典型分辨率2048x2048、帧率60fps的时候像素时钟大概在100MHz左右数据速率约800Mbps。SFP光口2.5Gbps的链路利用率大概40%左右完全没有任何压力。如果你用的是CameraLink Full配置像素时钟达到150MHz数据速率约1.5Gbps用2个Aurora通道也就是5Gbps总带宽来传利用率也在60%以内。光纤传输距离用多模OM3光纤配合850nm模块50米没有任何问题用单模1310nm模块配合单模光纤10公里不在话下。这一点在实际项目中绝对够用了。最后如果你是自己想从零开始搭这个系统我建议按这个顺序来避免一上来就被复杂的工程搞懵。第一步先用最简单的FPGA板子和SFP光模块搭建一个Aurora环回测试。把TX通过光纤直接连到RX或者用一个SFP模块的环回模式用ILA观察LANE_UP和CHANNEL_UP信号确认GT物理链路正常。第二步实现一个计数器数据源通过Aurora发送到对端或者自己接收自己发送的数据在接收端ILA里查看数据是否正确。这一步确定Aurora核的收发通路没问题。第三步接入CameraLink解码模块用信号发生器或者真实相机送出图像确认DVP时序正确像素数据、FVAL、LVAL信号无误。第四步把像素打包模块接到Aurora发送端之前发送固定测试图案。接收端解包后和原始图案比对确保打包解包逻辑一致。第五步接入真实相机图像显示到显示器或者PC接收端确认图像完整、颜色正确、无丢帧。这个顺序是我自己总结出来的能帮助你快速定位问题出在哪一层。很多新手上来就把相机、FPGA、光纤、接收端全部连好结果图像花屏了根本不知道是CameraLink解码的问题还是Aurora传输的问题排查效率极低。我个人的经验是做这种FPGA高速接口项目八成时间都在和物理层较劲剩下两成才是逻辑问题。物理层稳了整个系统就稳了八成。Aurora8B10B这套架构的优势就在于一旦物理层稳定数据通路是纯逻辑问题调试起来非常快。所以重视GT参考时钟、电源、光模块这几个基础环节能让你少走非常多的弯路。这套方案现在已经在多个项目里稳定跑着了如果你也在做类似的东西欢迎照着这个思路搭一套试试重点是用好仿真和ILA来观察链路状态信号问题定位就能快得多。