FPGA实现CameraLink转SFP光口：Aurora 8B10B架构与工程实践-编程实验室

FPGA实现CameraLink转SFP光口：Aurora8B10B架构拆解与工程实现记录

做图像类FPGA项目的人，迟早会遇到CameraLink接口。工业相机、医疗设备、高速检测线，满世界都是CameraLink。但CameraLink有个很痛的问题：传输距离。线缆超过5米就开始心慌，10米基本属于玄学，电信号衰减、时钟抖动、地电位差，随便一个都能让你画面闪成雪花。而另一头，SFP光口轻轻松松跑几百米到几公里，速率还能干到几Gbps。所以CameraLink转SFP光口这个需求，在工业现场一直非常真实。

这篇博文就完整拆解我用Xilinx FPGA实现CameraLink转SFP光口的全过程，涉及GT Transceivers Wizard的线速率配置、Aurora 8B10B核的编解码机制、4套工程源码的组织方式，以及大量上板调试时才可能踩到的坑。适合已经有一定FPGA基础、正在做视频传输产品、或者正在被相机接口协议折磨的朋友。如果你只是刚会把LED点亮，这篇文章部分内容可能稍深，但思路部分仍然值得先看。

1. 整体设计思路：为什么是Aurora 8B10B，而不是别的

1.1 CameraLink转光口的本质是什么

先想清楚我们要干的活。CameraLink接口本质上是一组LVDS差分信号对：数据通道（在Base配置下是4对）+ 像素时钟对，再加上串行通信（SerTC/SerTFG）和相机控制信号（CC1-CC4）。像素时钟从一个低速的20MHz到最高的85MHz都有，数据速率由像素时钟直接决定。

正确地讲，CameraLink转光口要做的事情并不是“格式转换”那么简单，而是要解决两个问题：

把CameraLink的并行TTL/LVDS信号和像素时钟，打包成可以在高速串行链路上传输的连续比特流。
在接收端把这些比特流重新还原成CameraLink的时序，让后端图像采集卡感知不到中间经过了光纤。

所以这个项目从架构上看，天然就是两个大方向：发射端做CameraLink接收+打包+高速串行发送，接收端做高速串行接收+解包+CameraLink发送。

1.2 方案选型：Aurora 8B10B、自定义协议、SRIO三者对比

设计一开始最纠结的问题是：光口上的传输协议到底用什么？我当时列过一张对比表，这里直接放出来给各位参考：

方案	协议开销	实现难度	灵活性	适用场景
Aurora 8B10B	低（约20%）	低，直接用Xilinx IP核	中，帧格式需自己定义	点对点视频传输、无主机场景
自定义8B10B协议	低	高，需要自己写编解码和对齐逻辑	高	有特殊封装需求、不想被IP核限制
SRIO / PCIe	中高	很高	高	需要和CPU交互、多设备组网

最终选了Aurora 8B10B。一个核心原因是：Aurora是Xilinx官方免费提供的轻量级传输协议，聚焦在“可靠地把数据从A点搬到B点”，至于数据是什么含义，完全由用户上层定义。这种特性特别适合视频流场景——我们只需要一个稳定的管道，不需要像TCP/IP那样复杂的握手和重传机制。再加上8B10B编码天然解决了DC平衡和时钟恢复问题，对于跨设备的光口传输来说，硬件上最稳。

最重要的是，Aurora 8B10B IP核内部直接集成了GT Transceivers的适配逻辑。我们只需要配置好GT线速率和参考时钟，剩下的通道对齐、字节序处理、错误检测，IP核全包了。省下的开发时间不是一两天，而是一两个月。

1.3 4套工程源码为什么会是4套

很多人看到“4套工程”第一反应是：为什么不直接搞一个万能工程？

第一版我也是这么想的，做了个CameraLink Full配置+自适应线速率的超级工程，结果调试起来痛苦万分。问题不在于代码逻辑，而在于不同应用场景下的约束差异太大了。CameraLink有Base、Medium、Full三种配置，数据传输量差好几倍；光口速率从1.25G到6.6G甚至10G都有；参考时钟源在不同板卡上接的bank还不一样。一个工程想兼容所有场景，意味着大量的参数化和条件编译，出问题的时候排查链路极其困难。

所以我干脆把工程拆成4套，每一套都针对一个典型使用场景做深度优化：

工程序号	适用场景	CameraLink配置	光口速率	说明
工程一	工业相机图像采集	Base（单通道）	2.5Gbps	最常见需求，像素时钟≤60MHz
工程二	高分辨率/高帧率相机	Full（三通道）	5.0Gbps	像素时钟≥60MHz，需要通道绑定
工程三	光纤自发自收测试	无需CameraLink	2.5Gbps	用来验证GT和Aurora链路，排除光路问题
工程四	远距离中继/扩展	Base	6.6Gbps	面向更长距离、更高可靠性的场景

这样拆分之后，每个工程结构清晰，调试问题的时候不会被无关逻辑干扰。工程三尤其重要，第一次上板调试的朋友务必先把回环工程跑通，再接入CameraLink数据，这是能让你少掉一半头发的方法。

2. GT Transceivers Wizard与Aurora 8B10B核心配置细节

2.1 线速率与参考时钟：先把账算明白

GT Transceivers是Xilinx系列FPGA内部的高速串行收发器，在7系列叫GTP/GTX/GTH/GTY，在UltraScale系列叫GTH/GTY。它们承担了把并行数据变成高速串行比特流的工作，是光口方案的物理层基础。而GT Transceivers Wizard这个IP核，则是用来配置这些收发器的参数。

但是在打开Vivado之前，几个关键数字必须先算清楚，否则后面全是坑。

第一个数字：线速率。线速率 = 有效数据带宽 / 编码效率。Aurora 8B10B的编码效率是8/10，也就是80%。CameraLink Base配置的像素时钟最高85MHz，数据位宽是64bit（8个字节，其中图像数据最多64bit，加上控制信号看具体封装）。那么有效数据带宽就是 85MHz × 64bit = 5.44Gbps。但实际工程中我们通常不会跑到这么满，一般留出20%左右的余量。所以2.5Gbps的线速率只能覆盖到55MHz左右像素时钟的场景，这也是为什么工程二需要Full配置+5G线速率。

第二个数字：参考时钟。GT的参考时钟和线速率之间有一个固定的分频关系。对于GTX收发器，通常是线速率除以某个数等于参考时钟。比如线速率2.5Gbps，参考时钟用125MHz：2500 / 20 = 125。这个“20”是GT内部固定的参数，不同器件可能略有差异，配置的时候需要对照数据手册确认一下PLL的反馈分频范围。

我当时用的一个Zynq-7000系列的板子，GTX参考时钟接在了MGTREFCLK0上，接了125MHz的晶振。选这个频率非常普遍，因为Aurora核官方例程就是围绕125MHz参考时钟设计的，资料多，出问题容易查。

2.2 GT Transceivers Wizard的几项关键选择

在Vivado里创建GT Transceivers Wizard IP核时，以下参数是我实测下来最影响成败的：

Protocol Stack：选择Start from Scratch，不采用预设协议模板。这样GT核会更干净，方便后面让Aurora核来控制它。
Line Rate：和前面计算的保持一致，建议打成固定值写在工程文档里。
Reference Clock：选择实际板卡上的时钟频率，不要贪方便乱选。GT核会产生一个低速user clock输出，这个时钟就是后面Aurora核和用户逻辑的工作时钟。
TX/RX Data Width：建议让GT核自动生成，由线速率和参考时钟决定，通常Aurora核会接管这个配置。
Encoding/Decoding：选择8B10B编码。如果你打算让Aurora核来处理编码，GT核里可以不需要选；但让GT核也选上8B10B并不冲突，因为Aurora核的编码器和GT核的编码器是串联关系，实际情况下最终只由一层的设置生效。

这里有个容易迷糊的点：Aurora 8B10B核在IP配置界面里本身就有线速率和参考时钟的设置，而GT Transceivers Wizard里也有。它们之间的关系是GT核是底层物理层，Aurora核是上层链路层。在Vivado里创建Aurora 8B10B核时，如果你勾选了“Include GT Transceivers Wizard”，那么Aurora核会自动帮你例化一个GT核，此时你只需要配置Aurora核的线速率，它会自动把参数传给GT核。但配合我调试的工程习惯，我通常会手动分开建立两个核：GT核负责物理层，Aurora核使用外部GT接口模式。这么做的好处是GT核的调试接口可以直接用ila观察，链路不通的时候能快速定位问题出在物理层还是链路层。

2.3 Aurora 8B10B核的接口形态怎么选

Aurora 8B10B IP核配置时有几种接口形态：Framing接口（帧接口）和Streaming接口（流接口）。

Framing接口：提供帧起始/结束信号，用户数据被组织成一帧一帧发送，适合数据包结构明显的场景。
Streaming接口：没有帧边界的概念，数据像是流水一样源源不断，适合视频流这种持续突发数据的场景。

我选择了Streaming接口。原因很简单：CameraLink送出来的图像数据是一行一行持续的，每行之间有行消隐，帧之间有帧消隐，但总的数据方向永远是从相机到采集卡，几乎不会反方向传大量数据。用Framing接口反而还要额外处理帧边界标识，增加了逻辑负担。

另外，Aurora核有一项“Little Endian”和“Big Endian”的字节序选项，这个必须和你的数据打包模块保持一致。图像数据如果这里搞反了，出来的画面颜色通道会两两对调，RGB会变成BGR，别问我怎么知道的。

2.4 时钟域：这个项目最容易被忽略的暗坑

CameraLink侧的工作时钟是相机给的像素时钟（PaClock），Aurora核侧的工作时钟是GT恢复出来的user clock。这两个时钟既不频率相同，也不相位相关，所有跨越这两个时钟域的数据，都必须经过异步FIFO。

这是整个项目里最容易出问题的地方。很多朋友上来就把像素时钟域的数据直接接到Aurora核的接口上，结果链路一跑起来就偶尔丢一拍，图像上出现一条横线。原因就是跨时钟域没有做异步处理。

异步FIFO的深度建议至少是图像一行数据的1.5倍，这样即使行消隐期间因为时钟频率抖动带来的瞬时累积差值，也不会瞬间写满或读空。我当时用的FIFO深度是2048×64bit，实测下来各种时钟抖动都能扛住。

3. CameraLink侧解码与数据映射实操剖析

3.1 CameraLink时序：先感动自己，再感动采集卡

CameraLink协议里最重要的是三组信号：FVAL（帧有效）、LVAL（行有效）、DVALID（数据有效），它们和像素数据D[0:27]一起，被封装到4对LVDS数据通道中，每像素时钟周期传输28bit数据。

Base配置下，一个像素时钟周期里CameraLink物理层实际传的数据是28bit，其中低24bit（D0-D23）是图像数据，高4bit是控制信号（FVAL、LVAL、DVALID、SPARE）。所以当我们在FPGA内部接收时，一个周期拿到的是28bit，但图像传感器通常输出的是8bit、10bit、12bit或16bit的像素深度，也就是说需要连续几个像素时钟的数据才能拼出一个完整的像素。

举个例子：一个8bit灰度相机，像素时钟每个周期输出8bit有效数据。那么28bit里面只有D[7:0]是图像数据，D[8:23]可能是接地的，也可能被相机厂商复用了。这个时候数据映射就很关键：如果直接把28bit塞进64bit的数据通路，接收端还原时就会错位。

更常用的做法是：在发射端把连续几个像素时钟的8bit数据拼接成64bit甚至128bit的Aurora帧，充分利用带宽。比如8bit灰度相机，4个像素时钟拼出32bit，再两个拼出64bit，效率100%，一点都不浪费。

3.2 从CameraLink信号到Aurora帧：数据打包的完整链路

我最终实现的数据通路是这样的（以工程一Base配置为例）：

CameraLink接口芯片（DS90CR288A或兼容型号）先把LVDS信号还原成28bit并行数据和像素时钟，送入FPGA的IOB。
FPGA内部用一个双沿寄存器把28bit数据打拍同步到像素时钟域，经过一个简单的跨时钟域打拍电路，保证数据稳定。
数据进入异步FIFO，写时钟是像素时钟，读时钟是Aurora核的user clock。
从FIFO读出的数据按照协议要求拼接成64bit，送入Aurora核的TX接口。
Aurora核完成8B10B编码、加帧头、加CRC（可选），交给GT核变成高速串行差分对信号。
SFP光模块把电信号变成光信号，送进光纤。

接收端就是逆过程：光信号 → SFP → GT → Aurora核 → 64bit数据 → 异步FIFO → CameraLink发送逻辑 → 输出28bit数据和像素时钟 → 到CameraLink发送芯片（DS90CR287A）→ LVDS信号 → 后端设备。

整体链路看起来简单，但实际编码的时候你会发现，因为数据位宽不一致（28bit到64bit），需要做的位宽转换和字节对齐操作非常繁琐。这里有一个小技巧：可以在异步FIFO之前做位宽转换，也就是先把4个28bit数据拼成112bit，然后以112bit为单位统一处理。这样虽然FIFO的宽度变大了，但后续的字节对齐逻辑反而更好写，因为112bit刚好是8个14bit，映射关系非常整齐。如果你喜欢简单，也可以只存32bit，然后每个时钟处理一个32bit，剩下的交给状态机慢慢拼，代价是逻辑会复杂一点。

3.3 像素时钟和数据有效信号的同步策略

CameraLink相机输出的FVAL和LVAL信号，并不是标准的同步信号，它们的拉高拉低有可能发生在任何像素时钟沿。如果直接拿这两个信号当前沿触发，很容易因为亚稳态导致偶尔多采或少采一个像素。

我的处理方式是：不要把FVAL、LVAL当作同步信号，而是当成普通数据，采用两级寄存器同步，然后通过边沿检测生成有效脉冲。因为图像数据的有效与否是相对连续的，即使边沿检测有1个时钟周期的抖动，也不影响整帧图像的数据完整性。如果你比较强迫症，也可以把FVAL和LVAL一起放进数据包里作为标志位传出去，让接收端自己去解析。

另外一个值得注意的细节是DVALID信号在行消隐和帧消隐期间的行为。有些相机在消隐期DVALID会拉低，有些相机则保持高但数据无效。遇到这种相机，在发送端就必须把消隐期间的数据全部填充为某种特定值（比如全0或全FF），否则接收端会在消隐期也收到看似有效但实际无意义的数据，导致图像采集卡解析时出现固定位置的花屏。

4. 4套工程源码的架构划分与核心模块实现

4.1 工程目录怎么设计才能不让自己迷路

每次看到有人把整个工程的所有.v文件塞在同一个目录里，我都替他捏把汗。一个成熟的FPGA工程，目录结构应该让新加入的人（甚至三个月后的自己）一眼就能看清楚模块边界。

我这4套工程都遵循了下面这个标准的Xilinx工程目录结构：

prj/ ├── rtl/ │ ├── top/ │ │ └── top_cameralink_sfp.v │ ├── cameralink/ │ │ ├── cl_rx_decode.v │ │ ├── cl_pixel_assembler.v │ │ └── cl_tx_encode.v │ ├── aurora/ │ │ ├── aurora_link.v │ │ └── aurora_stream_wrapper.v │ ├── cross_clock/ │ │ └── async_fifo_wrapper.v │ └── common/ │ ├── data_packer.v │ └── data_unpacker.v ├── ip/ │ ├── gt_quad/ │ ├── aurora_8b10b_core/ │ └── async_fifo/ ├── constraints/ │ ├── pin.xdc │ ├── timing.xdc │ └── debug.xdc └── sim/ └── tb_cameralink_sfp.v

这个结构把RTL代码、IP核、约束文件、仿真文件完全分开。Aurora核和GT核相关的代码集中在aurora目录和ip目录里，这样想换板卡或者换线速率时，只需要替换ip目录里的核配置，其余的上层逻辑完全不用改。

4.2 4套工程代码差异到底在哪里

很多人买工程或者下载工程时，最担心的是“源码虽然给了，但我不知道该用哪个”。这里我把4套工程的差异点明确写出来：

工程一（Base配置，2.5G）：

CameraLink Base模式，单Link，通道数1
像素时钟范围20MHz~60MHz
光口速率2.5Gbps，参考时钟125MHz
适用于绝大多数500万像素以内的工业相机
代码结构最简洁，建议所有新手先从这个工程开始理解

工程二（Full配置，5.0G）：

CameraLink Full模式，三Link，通道数3
像素时钟范围60MHz~85MHz
光口速率5.0Gbps，参考时钟125MHz
需要Aurora核配置为多通道模式（3通道聚合）
关键是三个Link的数据必须按顺序交错合流，接收端再逆序还原
适用于千万像素级别、高帧率相机

工程三（回环测试，2.5G）：

不需要CameraLink相机
板内自发自收（TX和RX短接）或光模块回环
GT核和Aurora核配置同工程一
核心代码是数据产生器和比对器
用于验证光路和链路层，排查设备问题

工程四（Base扩展，6.6G）：

CameraLink Base模式，单Link
但光口速率升到6.6Gbps
适用于只有Base接口但像素时钟特别高的相机
需要注意GT核的PLL配置，6.6G对PCB布线和SFP模块质量要求都更高

4.3 核心代码：CameraLink像素组装模块（简化版）

考虑到篇幅，贴一段像素组装模块的简化框架代码，展示数据拼接的基本思路：

module pixel_assembler #( parameter PIXEL_BITS = 8 )( input wire clk_pix, // 相机像素时钟 input wire rst_n, input wire clkin_fval, // 帧有效（两级同步后） input wire clkin_lval, // 行有效（两级同步后） input wire [27:0] clkin_data, // CameraLink 28bit数据 output reg [63:0] axi_data_out, // 64bit数据给Aurora output reg axi_tvalid, output reg pix_sof, // 帧起始标记 output reg pix_sol // 行起始标记 ); // 像素缓冲：连续4个像素时钟拼出32bit reg [31:0] pixel_buf; reg [1:0] pixel_cnt; always @(posedge clk_pix or negedge rst_n) begin if (!rst_n) begin pixel_buf <= 32'd0; pixel_cnt <= 2'd0; axi_tvalid <= 1'b0; end else begin case (pixel_cnt) 2'd0: pixel_buf[7:0] <= clkin_data[7:0]; 2'd1: pixel_buf[15:8] <= clkin_data[7:0]; 2'd2: pixel_buf[23:16]<= clkin_data[7:0]; 2'd3: begin pixel_buf[31:24] <= clkin_data[7:0]; axi_tvalid <= LVAL; // 行有效期间数据才有效 axi_data_out <= {pixel_buf[31:8], clkin_data[7:0]}; // 4像素拼32bit end endcase pixel_cnt <= pixel_cnt + 1'b1; end end endmodule

这段代码的核心思想非常直白：因为8bit灰度相机每个像素时钟只有8bit有效数据，所以连续采4个像素，拼成32bit，再加上32bit空闲空间，组成64bit一次发给Aurora核。实际工程里当然不会这么粗糙，至少还要考虑行有效信号与数据的对齐，以及消隐期间的填充值，但核心思想就是“攒够一拍就发出去”。

接收端的解包模块是逆向操作，把64bit拆成4个8bit，按顺序输出到CameraLink发送芯片的输入端。相比之下接收端反而更简单，因为Aurora核的RX接口已经有完整的数据对齐，你只需要控制FVAL/LVAL和数据的时序关系符合CameraLink规范即可。

5. 上板调试与典型问题排查实录

5.1 怎么判断“链路已经通了”

我第一次做这个项目的时候，最痛苦的不是写代码，而是写完代码之后不知道它到底能不能用。后来养成了一个习惯：建立一个分阶段的验证流程。

第一阶段，只验证GT物理层。用IBERT（Integrated Bit Error Ratio Tester）核，或者用Vivado自带的Hardware Manager里的GT工具，把TX和RX短接（或者光模块回环），看误码率。误码率低于1e-15基本认为物理层OK。

第二阶段，验证Aurora链路层。跑工程三，自发自收。用计数器产生递增数据，接收端比对。如果比对全对，说明Aurora通道对齐、字节序、时钟恢复都没问题。

第三阶段，接入CameraLink数据。先用信号发生器模拟CameraLink的时序，不接真实相机。信号发生器产生固定的测试图案（比如彩条），看接收端能否还原出同样的图案。

第四阶段，接真实相机。这时候才会遇到真正的像素时钟抖动、行场消隐不规则、数据位宽不一致等问题。

这四个阶段走完，才敢说这个工程真正“能用了”。跳过任何一步，都会在后面的某个时刻让你花更多时间来填坑。

5.2 链路点不亮：先从物理层找原因

最常见的故障现象是什么？Aurora核的channel_up信号一直拉不高。这时候别急着查代码，先确认这些事：

光模块插好了吗？SFP笼子的锁扣有没有扣到底？光口防尘帽有没有拿掉？
光纤是单模还是多模？和光模块是否匹配？用了千兆光口但插了万兆光纤模块，也会点不亮。
GT参考时钟的引脚约束是否正确？参考时钟的频率实测是多少？
GT核的复位和Aurora核的复位时序是否正确？两个核的复位顺序有严格要求，通常是GT先复位完成，再释放Aurora核的复位。

如果你用XC7系列或Zynq-7000这类带GTP/GTX的器件，GTX的参考时钟输入引脚必须约束在对应的MGTREFCLK引脚上，不能随意接普通IO。很多第一次做光口的朋友会忽略这一点，看原理图时钟走线发现没走专用引脚，结果怎么配置GT核都不工作。

5.3 花屏和丢帧：多半在跨时钟域

假设物理层和链路层都OK了，channel_up拉高了，但接上相机后画面不对，要么花屏要么偶发丢帧，那问题十有八九出现在CameraLink侧的数据组装和跨时钟域处理上。

花屏的排查顺序我总结为：

先看行长度对不对。CameraLink相机每行像素数是固定的，如果发射端打包时行数据长度和接收端解包时预期的长度不一致，画面会出现斜条纹或错位。
再看FVAL/LVAL极性。有些相机的FVAL/LVAL是低有效，代码里默认高有效就会整屏花掉。
然后查字节序。颜色通道对调、图像左右或上下颠倒，基本都是字节序和位序的问题。
最后查异步FIFO的读写指针。如果FIFO在消隐期间没有做适当的复位或水位管理，积累的读写指针偏差会在长时间运行后导致溢出或下溢。

丢帧的另一个常见原因是：异步FIFO的写侧和读侧时钟频率有一个微小的、非整数倍的频率差（比如像素时钟60.0001MHz，Aurora user clock 125MHz），长期运行下来每几秒钟FIFO就会满一次。解决办法是在发送端检测FIFO的空/满状态，正常工作时满标志触发拉低tvalid，或者牺牲一两个像素的消隐周期来主动排空FIFO。

这个方法对动态画面影响很小，对静态测试图影响尤其小，但强烈建议不要在全帧数据都有效的情况下去丢数据，否则采集卡会报数据不连续错误。

5.4 时序收敛：当你的设计跑到85MHz就怂了

CameraLink Full配置下，像素时钟85MHz，对应的用户逻辑频率并不高，但GT和Aurora核的工作时钟（比如125MHz或156.25MHz）加上跨时钟域FIFO的读写，整体逻辑的时序压力还是有的。

有一次做个工程二，综合后时序报告显示Aurora核到FIFO读侧的逻辑建立时间违例，频率只能跑到约80MHz。查来查去发现问题竟然是FIFO的读数据输出直接接了一长串的组合逻辑，中间还穿过了两个MUX。

解决方式很经典：在FIFO输出和Aurora接口之间插入一级流水线寄存器，用工作时钟打一拍。多一个时钟周期的延迟，换来的是干干净净的寄存器到寄存器路径。画面显示上这个延迟根本感知不到。

另一个技巧是对GT和Aurora相关信号设置false path约束。GT的复位信号、状态信号，以及和用户逻辑完全无关的硬件状态信号，都不需要参与时序分析。不加这些约束的话，Vivado会在这些本不需要关注的路径上浪费大量布线资源，导致真正关键的路径反而无法收敛。

5.5 常见问题速查表

最后把调试过程中最常遇到的现象、原因和解决办法整理成表格，方便现场排查：

故障现象	可能原因	排查思路与解法
channel_up一直为低	光路不通、GT参考时钟错误、光纤类型不匹配	先看SFP指示灯，再查GT配置，用IBERT验证物理层
channel_up正常，但数据全错	字节序/位序不对，或Aurora核收发数据位宽配置不一致	发送固定测试图案（如0x5A5A），观察接收端数据变化规律
画面花屏、行错位	行长度不匹配，或打包时把控制信号混进了数据	确认每行像素数，检查FVAL/LVAL孤儿信号
偶发丢帧	异步FIFO溢出/下溢	加大FIFO深度，或者在消隐期间主动排空FIFO
颜色通道互调	CameraLink数据位映射错误	对照相机手册确认D[7:0]等的映射关系，检查数据拼接顺序
长时间运行后故障	未处理的跨时钟域问题，或FIFO未周期性复位	检查FIFO水位，必要时增加sof/sol同步机制
时序违约、频率上不去	组合逻辑过长，或未正确设置false path	插入中间寄存器，检查XDC约束

6. 工程源码使用建议与后续扩展方向

拿到4套工程源码之后，不要急着上板，先把每个工程的README看清楚，确认哪一套符合你的相机型号和SFP模块规格。上面4个工程我都提供了完整的XDC约束、IP核配置和仿真测试平台，Vivado版本在2018.3以上直接打开就能综合布线。

工程源码使用的几个关键步骤这里再强调一遍：

先跑工程三（回环测试），验证你的板卡光口基本环境。
再把工程一的Aurora核线速率改成你板卡SFP支持的速率，注意参考时钟频率要跟着线速率重新计算。
确认CameraLink接口芯片型号和原理图接线，核对数据位宽映射。
综合实现后，用Hardware Manager抓取channel_up和user_clk。channel_up拉高，就说明链路层OK了，此时再接相机。
接上相机后先跑低分辨率模式，再逐步提升像素时钟。

这个项目后续还有很多可以扩展的方向。比较推荐的两个方向：一个是把光口速率升级到10G以上，用Aurora 64B/66B核（就是Aurora 10G方向），吞吐率提升非常明显；另一个是加入DDR3/DDR4缓存，实现Image Buffer或者多路视频复用，让一套光纤方案同时传多个相机数据。如果做的是采集卡，还可以尝试在接收端加一个AXI4-S接口，把图像数据导给PS或者PCIe/H2C核，直接变成一张图像采集卡的数字通路。

我个人实际操作下来最深的体会是：CameraLink转SFP光口这个项目，真正难的其实不是FPGA代码本身，而是你把系统当作一个完整产品来设计的能力。时钟怎么规划、复位链怎么做、跨时钟域处理、物理层验证、端到端联调，每一步都要按部就班。Aurora 8B10B和GT Transceivers Wizard帮我们屏蔽了高速串行底层的大多数细节，但那些没有被屏蔽的部分，往往才是决定项目成败的关键。希望这篇博文能给正在这条路上摸索的朋友一些参考，少走一些我当年走过弯路。

FPGA实现CameraLink转SFP光口：Aurora 8B10B架构与工程实践