FPGA+GTX+Aurora 8B10B实现CameraLink转光纤方案详解

最近帮一个机器视觉项目调了一块CameraLink转光纤的板卡核心方案就是标题里这套FPGA做桥接CameraLink接口进来的图像数据经过Aurora 8B10B编码从GT Transceivers走SFP光口发出去对端再用同样架构还原成CameraLink信号给采集卡。板子调通之后不少同行来问这方案细节干脆把这套工程拆开写一篇讲清楚架构怎么搭、GT Wizard怎么配、Aurora IP为什么这么用、四套工程各自对应什么场景顺便把我调试时踩过的坑也一并列出来。如果你手里正好有CameraLink相机要拉远传输或者在做类似的高速串行图像传输项目这篇应该能帮你少走不少弯路。1. 项目核心链路与架构拆解1.1 为什么要把CameraLink信号搬到光口上CameraLink是工业相机领域很经典的接口标准Base配置下32位数据加4位相机控制信号像素时钟最高85MHz理论带宽折合下来大概2.72Gbps。这个速率做单相机采集绰绰有余但它有一个硬伤传输距离被铜缆限制得很死。标准CameraLink线缆一般只能跑7米左右超过这个距离信号完整性就会急剧恶化尤其是像素时钟跑到85MHz满速时稍微长一点的线缆就会出现花屏、闪行。很多产线场景里相机和控制室之间的距离动不动就是几十米甚至上百米拉CameraLink线缆根本不现实。常规做法是中间挂一台转接盒把CameraLink转成光纤再用光缆拉远。但这种成品转接盒价格不便宜而且只能做点对点固定转换灵活性很差。用FPGA自己搭一个CameraLink转SFP光口的桥接方案板子硬件成本低得多更重要的是协议和格式完全掌握在自己手里想怎么扩展都行甚至还可以在光口链路上叠加自定义的辅助数据通道。1.2 整条链路的数据流向拆解这个方案本质上是一个透明桥接系统。相机端进来的CameraLink信号经过电平转换和解串变成FPGA内部的并行像素数据FPGA把像素数据拼装成自定义帧格式经过Aurora 8B10B编码从GTX Transceiver的TX端送出到SFP光模块光模块再把电信号转成光信号走光纤。对端板卡用同样的流程反向操作SFP收光 → GTX RX恢复数据 → Aurora解码 → 还原CameraLink时序 → 送给采集卡。链路关键节点有三个。第一个节点是CameraLink物理层接入。CameraLink是LVDS差分信号FPGA不能直接接收必须用专用的解串芯片比如DS90CR288A把4对LVDS数据通道解成28位并行数据其中24位是RGB或灰度数据4位是帧有效、行有效和数据有效信号。发送端则用DS90CR287把并行数据重新串化成LVDS信号。这一步极容易出问题因为它同时处理了电气标准转换和串并转换两件事。第二个节点是FPGA逻辑层的帧格式封装。CameraLink像素数据是continuous流式的单纯把它塞进Aurora的用户接口还不够因为接收端必须能准确切分出每一帧图像的边界。所以要在发送端加入帧头、行号、校验码这些开销信息自定义一套轻量级的图像传输协议。这部分是整个工程里最依赖需求的部分不同分辨率、不同帧率、不同行场时序封装格式可能都要微调。第三个节点是Aurora 8B10B通道。从GT Transceivers Wizard生成GTX IP再在GTX之上叠加Aurora 8B10B IP核完成8B/10B编解码、通道对齐、时钟补偿这一类高速串行协议底层工作。用户只需要面对一个简单的AXI4-Stream接口往里面丢数据就完事。1.3 四套工程源码的总体设计思路这四套工程不是同一个项目的四个拷贝而是针对不同硬件平台和不同应用场景做的适配版本。我按FPGA芯片型号和应用角色把它们分成两类一类是Aurora主站Master方向的用于把单个或者多个CameraLink相机的数据发送到光纤上另一类是Aurora从站Slave方向的用于在接收端把光口数据还原成CameraLink信号再接给采集卡。主站方向的工程里CameraLink解串进来的数据经过两三个FIFO做跨时钟域缓冲再进自定义协议封装模块输出到Aurora IP的用户接口。从站方向则反过来Aurora IP解码出来的数据先进协议解析模块把帧头行号这些东西剥掉恢复出原始像素流再按CameraLink要求的时序重新排列经过DS90CR287芯片接出去。四套工程之间共享的代码模块占比很高比如FIFO读写控制、跨时钟域处理、CRC校验这些都是同一套RTL代码直接复用。差别主要体现在两个地方一是Aurora配置参数比如线速率、通道数、参考时钟频率不一样二是CameraLink端接的引脚和时序约束不一样。2. CameraLink接口接入的设计细节2.1 CameraLink协议要点从Channel Link说起要调好CameraLink桥接不能只FPGA逻辑好还得对物理协议有概念。CameraLink底层用的是National Semiconductor现在归TI的Channel Link技术核心思想就是源同步传输发送端用一个锁相环把并行数据串化成高速LVDS差分对同时把源时钟也差分发出去接收端从源时钟里恢复出并行数据。以Base配置为例DS90CR287把28位并行数据24位图像数据加4位视频控制信号转换成4对LVDS数据线加1对时钟线每对数据线上串行跑7个bit。DS90CR288A在接收端做反操作用PLL从差分时钟里恢复出28位并行数据。这带来的直接问题是FPGA里看到的像素时钟频率和CameraLink源端发的像素时钟频率并不是完全一致的。前者是后者经PLL恢复出来的存在几ppm到几十ppm的频偏这在跨时钟域处理时必须考虑到。另外CameraLink的3.3V LVDS信号和FPGA的bank电压经常不匹配很多用户直接把CameraLink线缆接到FPGA引脚上结果LVDS电平根本识别不了。稳妥做法是中间加电平转换或耦合电容或者直接用支持LVDS的bank并在约束文件里正确设置IOSTANDARD比如LVDS_25和DIFF_TERM。2.2 解串芯片DS90CR288A的关键接线与配置DS90CR288A本身是纯硬件芯片不需要配置寄存器上电就按固定模式工作。但外围有几个点必须注意。第一它的差分时钟输入必须干净晶振或时钟芯片出来的信号要经过AC耦合电容再进芯片耦合电容值一般用0.1uF。第二它的PLL需要一个参考时钟通常直接由接收到的差分时钟提供不需要额外供给。第三它的输出使能引脚和电源时序要先确认好如果上电顺序不对输出端可能出现一段时间的不定态直接灌进FPGA的逻辑里会造成FSM误跳转。实际工程里我习惯在DS90CR288A和FPGA之间加一个电源域隔离解串芯片的VCC如果是3.3V而FPGA的bank是1.8V两者之间不能直连。注意看芯片手册DS90CR288A输出实际上是LVTTL电平不是LVDS所以3.3V供电时不能直接接1.8V的bank。这种情况要么用电压转换芯片要么选择支持3.3V输入的bank。很多板卡原理图设计时没注意这点导致FPGA引脚输入钳位烧坏。2.3 跨时钟域处理把恢复时钟域的数据安全搬进Aurora时钟域CameraLink解串后的像素数据是跟着解串芯片恢复出来的PIXCLK走的而Aurora IP的用户接口时钟是从GT收发器的恢复时钟或者协议输出的user_clk走的两个时钟完全不同源频率也不一样。Cameralink典型像素时钟在40MHz到85MHz之间Aurora的user_clk则取决于线速率和通道数可能是62.5MHz、80MHz、125MHz甚至更高。所以发送方向必须做异步FIFO缓冲。FIFO写时钟用PIXCLK写使能是像素有效信号读时钟用Aurora user_clk读使能由发送控制状态机控制。要注意FIFO深度的计算PIXCLK在85MHz、帧率为60fps、分辨率为1080p时单帧有效像素大概207万对应约24.4ms的写入时间突发数据量约2.07M*16bit33Mbit。如果Aurora通道速率和写入速率差距很大FIFO深度不够会出现溢出丢帧。一般工程里保险做法是FIFO深度留到一帧数据的1.5倍以上但同时要考虑FPGA内BRAM和URAM的资源占用使用Xilinx FIFO IP时打开Show-Ahead模式可以减少一个周期的读延迟。接收方向刚好反过来Aurora恢复的数据是跟着GT的RXUSRCLK走的而DS90CR287发送要求的像素时钟一般是由FPGA内部PLL直接生成的所以要从Aurora user_clk域再搬到本地像素时钟域同样需要异步FIFO。这个FIFO的深度反而可以小一些因为数据是均匀到达的不像CameraLink源端那样一帧一帧突发。但要注意接收端必须保证FIFO不能读空一旦读空图像时序就会出现空洞表现为图像往下掉行或者滚动。3. GT Transceivers Wizard与Aurora 8B10B链路的工程化实现3.1 GT Wizard参数选择的实战依据GT Transceivers Wizard本身只是生成一个参数化的收发器底层里头的选项每个都影响最终行为。我这个项目用的是Xilinx 7系列FPGA的GTX在Vivado工程里打开GT Wizard主要关注这些参数线速率Line Rate的选型要和光模块匹配SFP光模块通常支持1.25Gbps、2.5Gbps、4.25Gbps、6.6Gbps等常用速率。CameraLink Base模式原始数据带宽计算方式像素时钟x32位比如85MHzx322.72Gbps但Aurora 8B10B的编码会带来20%的开销实际编码后线速率需要不小于2.72x1.253.4Gbps。考虑到光模块常见档位选3.125Gbps更现实对应的有效净荷带宽是2.5Gbps加上帧头和校验开销后仍然盖得住CameraLink Base输入。如果要做Medium或Full配置的CameraLink接入一路3.125Gbps就不够了需要扩展成多通道Aurora或者提高线速率到6.6Gbps以上。参考时钟的选择也很关键。GTX的参考时钟频率必须和线速率相关不能随意给。7系列GTX在3.125Gbps线速率下参考时钟可以选125MHz线速率/25或者156.25MHz线速率/20。Vivado的GT Wizard会自动给出几个合法的参考时钟选项直观理解就是参考时钟经过GTX内部的PLL倍频到线速率。选125MHz配3.125Gbps是我最常用的一套组合因为125MHz是网络设备通用频率板级设计好做晶振好买。Aurora 8B10B协议里还有一个叫DCLK的概念是用户时钟和GT收发器之间的时钟域接口。Wizard会自动计算一般不建议手动去改除非你特别清楚自己在干什么。3.2 Aurora 8B10B IP核配置中容易被忽略的选项Aurora 8B10B IP核在7系列FPGA里属于免费IP生成的时候有几个选项必须认真看。首先是通道数LANES。单通道就是一条GTX多通道会做通道绑定和通道对齐。CameraLink Base对单个Aurora通道的压力不大单通道就行如果做Full配置的CameraLink需要同时传3路8位数据加控制信号建议用2通道Aurora做负载均衡或者干脆加大线速率。然后是数据接口宽度。Aurora用户接口是AXI4-Stream常见配置是2字节或4字节。对于图像数据我喜欢用4字节因为处理32位像素排列比较方便。注意接口宽度变大会直接改变用户时钟频率这个要和GT参考时钟、FIFO读写端时钟严谨对上Vivado生成IP时会给出接口时钟频率调试时用这个时钟做约束不能想当然。流控制Flow Control建议打开。Aurora的流控制分两种用户流控制和协议流控制。协议流控制是Aurora底层做时钟补偿用的必须开用户流控制是可选的用于处理接收端来不及消费数据的反压。在图像传输场景里有些设计师认为反正图像数据是均匀到达的不需要流控但是碰到突发数据比如多相机切换就会出问题建议还是打开反压信号直接接在FIFO的prog_full上实现简单成本低。Aurora还有一个容易被忽略的“热插拔”选项Hot Plug。开了这个选项之后链路即使在没有对端的情况下也不会因为RX丢失而挂死这个特性对板卡级的调试帮助很大。如果不开单板测试时Aurora状态机可能长时间卡在一个错误状态很影响定位问题。3.3 自定义帧格式设计别直接裸传CameraLink数据很多人第一次做相机桥接时总是想直接把CameraLink的像素数据和有效信号全部塞进Aurora的用户接口接收端再原样恢复出来。看似简单实际却扛不住实际链路错误和带宽波动。比如Aurora是8B10B编码的偶发的误码会把数据打乱而下游相机采集卡通常只认行场同步信号一旦收到错误的数据整帧花屏甚至SDI锁不住。我在这个工程里的做法是在FPGA内部给图像数据做一层协议封装。每次帧有效信号到来时先发送一个固定字段的帧头里面包含帧计数、图像宽高、校验字节然后是每一行的行头包含行号和行长最后是图像数据本体。接收端按状态机解析帧头行头把数据重排成CameraLink时序输出。这样带来的好处是接收端可以在链路偶尔出错时做到丢帧而不崩时序就是宁可丢一帧也不能把错数据硬塞给采集卡。工程里的FSM用One-Hot编码状态跳转带超时保护防止数据流异常导致挂死。3.4 为什么选择Aurora而不是自研GTX封装逻辑GTX裸收发器其实也能直接用把用户数据经过8B10B编码后直接发出去不也是一条高速链路吗确实可以但Aurora 8B10B的价值在于节省了大量协议层面的打磨。Aurora自带通道对齐、时钟补偿、错误检测和热插拔功能这些功能如果自己用RTL写没有两三个月调不出来。时钟补偿尤其难搞GT收发器的恢复时钟和本地参考时钟之间总有频率偏差长时间跑链路如果不做补偿缓冲区就会溢出或下溢丢数据就是必然的。Aurora底层用特定的控制字符周期性做补偿用户完全不感知。Aurora协议的另一个实际好处是调试方便。Vivado里做ILA抓Aurora IP的接口信号可以直接通过chipscope观察通道初始化状态、错误标志位、接收数据是否正常。如果自己封装GTX这些状态都得自己拉出来复杂度和工作量都上去了。我的核心观点是能用成熟方案解决的高速串行问题不要自己造轮子节省下来的精力放在上层协议和图像处理上价值更大。当然如果你有极致的吞吐率需求或者要做Aurora不支持的组网拓扑那另说。4. 四套工程源码的版本划分与应用场景4.1 主站发送工程用于相机端到光纤的数据转发第一套工程是Aurora Master发送端硬件平台是XC7K325T光口一个SFP支持单路CameraLink Base输入。它拿到的输入信号是DS90CR288A解串后的并行数据和PIXCLK输出是光纤信号。这套工程用来做单个CameraLink相机的长距离传输是标配像素时钟跑满85MHz时一帧1080p60图像传输完全没有带宽压力。主站工程内部主要有四个模块像素数据同步与FIFO缓冲模块、自定义帧头生成模块、Aurora 8B10B IP核模块、GTX Transceiver模块。另外还挂了一个ILA调试核方便在调板时观察FIFO的水位、Aurora链路状态和帧发送计数。这套工程的顶层引脚约束文件里标明了CameraLink三个MDR26连接器的引脚分配SFP模块的TX_P、TX_N、RX_P、RX_N也都有现成的XDC约束基本拿到就能用。4.2 从站接收工程用于光纤到CameraLink采集卡的数据恢复第二套工程是Aurora Slave接收端同样基于XC7K325T但逻辑和主站完全镜像。光口进来的数据经过GTX恢复Aurora解码帧解析状态机剥掉协议头恢复出像素数据和行场有效信号再通过DS90CR287芯片输出CameraLink差分信号直连采集卡。这套工程的难点不在Aurora侧而在于恢复出的像素时序要和CameraLink采集卡期望的时序完全一致。CameraLink对PIXCLK的上升沿、数据建立保持时间都有要求DS90CR287的输出时序直接由前端并行数据和PIXCLK决定。所以FPGA内部如果用PLL调整相位必须保证PIXCLK的抖动和相位噪声控制在可接受范围内。我在工程里给PIXCLK加了MMCM做相位对齐默认用0度相移但保留了一个动态相移接口方便调试时微调。4.3 小封装器件适配版本XC7A100T/XC7Z010等第三套和第四套工程分别针对XC7A100T和XC7Z010这两款小资源FPGA做了移植。为什么要出小封装版本因为不是所有应用场景都需要XC7K325T这种大芯片的资源很多场景只需要一个简单的中继器或者单路桥接大芯片成本高、功耗大、布板面积也大。XC7A100T的GTX资源和逻辑资源足够跑单路Aurora 8B10B加一个CameraLink Base通道用在单板转接盒方案里非常合适。这两套小资源版本做了一些裁剪ILA核缩减到最小FIFO深度根据实际分辨率动态调整去掉了多余的辅助功能模块只保留链路透明转发的必须逻辑。资源占用情况大概在LUT使用率40%左右、FF使用率30%左右、BRAM使用率60%左右GTX只用了1个。如果你对功耗和成本比较敏感可以考虑在量产方案里直接用这两套小资源版本。4.4 拿到源码后如何快速移植到自己的板卡移植的时候不要想着把整个工程一股脑换到新板子上那样会碰得头破血流。正确路径是先锁定Aurora配置和GT参考时钟频率是否和你的板卡一致再核对CameraLink芯片型号和FPGA引脚约束最后检查你板卡的时钟方案是否支持。通常需要修改的地方只有三处XDC引脚约束文件、时钟管理模块里PLL/MMCM的输入频率配置、Aurora IP核的参考时钟频率。这三处改完绝大多数工程都能正常综合出比特流。Vivado版本也是一个坑。如果源码是用Vivado 2018.3做的而你用2020.2打开大概率会提示IP核需要升级。升级本身不难但升级后Aurora和GT Wizard的配置参数有概率被重置这时候一定要重新检查线速率、通道数、参考时钟这几个关键参数是否和原工程一致。我建议在条件允许的情况下尽量用和源码一致的Vivado版本打开省时省力。5. 系统上板调试与常见问题排查5.1 上板调试步骤从GTX眼图到Aurora链路再到图像拿到板卡第一步先不着急烧录完整工程。建议先用Vivado自带的IBERTIntegrated Bit Error Ratio Tester测一下GTX通道的物理层质量。IBERT会把GTX配置成一个高速误码仪直接在SFP光模块回环或光纤回环的情况下测误码率。如果IBERT阶段就出现大量误码说明光模块焊接、电源纹波、参考时钟质量和PCB走线这些硬件问题还没解决这时候去调FPGA逻辑完全是浪费时间。IBERT能顺利跑到零误码之后再烧录Aurora测试工程做单板回环测试把光模块的TX和RX用一根短跳纤短接或者用SFP的loopback模式验证Aurora链路能否建立连接并持续收发数据。抓Aurora状态机信号确认LINK_UP拉高同时观察收到的数据是否和发送端一致。如果这一步过了整条高速串行链路就没大问题了。最后再接入CameraLink信号源用真实相机或者信号发生器给CameraLink端灌测试图观察对端采集卡能否正确锁同步和显示图像。这个阶段出现花屏、滚动条、黑屏多半是协议封装的时序问题或者跨时钟域FIFO配置问题重点查帧头行头的时序约束有没有满足。5.2 两类最容易踩的实际故障与排查实录我调试中最常碰到的一类问题是Aurora LINK一直没有拉高。排查时先拿示波器看SFP的TX差分信号是不是有波形如果完全没有输出问题大概率出在GTX参考时钟上常见原因是参考时钟频率配错或者PLL没有锁定。Vivado里可以直接读GTX的QPLL状态寄存器如果QPLL locked一直是0就去查时钟约束和硬件焊接。如果TX有波形但RX端LINK起不来优先查RX端信号眼图是否正常常见原因是SFP光模块速率不匹配或光功率太低可以通过gtx的RX眼图监视器确认。另一类高发问题是图像传输出现间歇性丢行或闪烁。这种问题源头往往不是GTX链路而是FIFO溢出或下溢。丢帧丢行是图像数据吞吐不均匀导致的FIFO深度不够就会在图像突发高峰时溢出。一个经验判断方法把FIFO的写计数和读计数同时挂到ILA里跑一帧图像看差值变化如果差值接近FIFO深度上限说明深度不够如果差值在很小范围波动但仍有丢帧那就该检查读使能的时序是不是被反压信号打断了。5.3 PCB布局布线经验谈高速串行链路的PCB布局对FPGA工程能否稳定跑起来影响极大。SFP光模块到FPGA的GTX收发引脚差分走线阻抗必须控制到100欧姆对内等长控制要严格差分对内误差一般控制在5mil以内对间误差控制在50mil以内。GTX的参考时钟走线要远离其他高速数字信号最好包地处理。电源平面要给GTX收发器和光模块留足够的退耦电容尤其是1.0V的GTX供电纹波要控制在30mV以内纹波太大GTX眼图就会劣化误码率上升。另外SFP光模块的功耗虽然不算大但电流瞬变很快如果电源设计不好会有明显的电源跌落直接影响GTX的TX输出眼图和RX灵敏度。有条件的话建议给SFP单独一组LDO或DC-DC供电不要和FPGA的GTX供电混在一起。5.4 常见问题速查表问题现象可能原因排查方向上电后GTX QPLL未锁定参考时钟频率错误、晶振未起振、PCB走线问题检查输入时钟波形、查看QPLL状态寄存器Aurora LINK_UP一直为低链路对端未连接、光模块速率不匹配、RX信号眼图差检查SFP模块、核对Aurora参数、IBERT测物理层图像花屏但Aurora链路正常协议封装帧头时序不对、跨时钟域FIFO读写错位用ILA抓帧头行头数据、检查FIFO水位变化图像间歇性丢帧CameraLink源端带宽突发大于FIFO缓冲能力增加FIFO深度、降低Aurora开销、检查像素有效信号质量长时间运行后图像偏色CameraLink解串芯片锁相环失锁或信号抖动重现现象时抓PIXCLK波形、检查MDR26连接器接触光模块温度过高SFP模块热设计不足、供电设计不合理优化散热、检查模块额定功率这些问题是项目里真实出现过且能稳定复现的排查思路按表格顺序走基本能在半天内定位到具体原因。6. 源码交付使用建议与后续扩展方向6.1 拿到源码后的标准化验证流程如果你手里已经有这套四版工程源码不要急着直接改代码先做一轮完整的原样验证。准备一块和目标板卡匹配的开发板按照README里的要求下载比特流用一根光纤把主站和从站连起来再接一个CameraLink相机和采集卡确认整套链路能跑通。这里有个细节很多开发板的SFP是SGMII电平标准而这套工程用的是直接GTX到SFP的接法两者在电气上是兼容的但SFP的管脚定义和I2C管理接口的接线可能会不一样。拿到源码第一件事是比对SFP的引脚约束和实际板卡原理图发现不一致马上改不要等到烧录后才发现。原样验证通过之后再开始做定制修改。移植新板卡时先从最小改动做起只改约束文件和时钟频率跑通后再加入自己的业务逻辑这样出问题时定位范围小调试效率高。6.2 从CameraLink单路到多路复用的扩展思路这套架构不只是能跑CameraLink转光口。Aurora通道的净荷带宽在3.125Gbps线速率下大约2.5GbpsCameraLink Base满速数据也就2.72Gbps原始编码前实际有效数据还到不了这个值所以链路上是有余量的。如果一台相机不够用可以在发送端用时分复用方式把两个相机的数据交替打包到一个Aurora通道里接收端按帧号分发给下游。需要注意的瓶颈在于发送端FIFO的深度和协议开销的分配接口侧用一个小状态机控制数据源轮询每个源固定发一行就切换接收端按行号分类。这样做的最大好处是省去了一路SFP和一路GTX整个系统的器件成本直接降一截。如果考虑更高带宽的CameraLink Full配置也可以在现有架构基础上扩展为双通道Aurora每个通道传输一部分数据接收端在FIFO层做通道合并。需要付出的代价是FPGA内要多消耗一个GTX通道并且发送端要做数据切分逻辑切分粒度以行为单位这样接收端即使两个通道间有不同延迟也能完整恢复出原始帧。6.3 其他图像接口在这套架构上的可复用性Aurora 8B10B这套链路架构其实具备很好的通用性。把CameraLink前面的解串芯片换成HDMI接收芯片给RGB并行数据或者LVDS接口接收芯片给并行的视频数据后面的一整条Aurora链路完全不用动发送端只需要调整FIFO写控制和帧格式适配一下不同的像素时钟和数据位宽就行了。同理如果做DLP或微显示器驱动把Aurora链路收到的数据解出来给显示控制芯片的并行接口也是顺理成章的事。这套工程对学习FPGA高速串行传输也有参考价值。GT Wizard配置、Aurora用户接口时序、跨时钟域FIFO设计、硬件回环测试方法这些内容是FPGA高速接口开发的核心基础。很多朋友看协议手册看到头大但动手跑通了这套源码再去回看手册就会清晰很多因为每个抽象的概念都在具体工程里有了真实对应。踩过几次坑之后我的体会是这类高速图像桥接项目的核心难点并不在FPGA逻辑本身而在时钟和物理层的严谨对待。CameraLink端的像素时钟、Aurora用户时钟、GT参考时钟这三者之间的频率关系和相位关系一旦出错表现出来的现象千奇百怪排查起来非常痛苦。所以做这类项目我的习惯是先把时钟关系图画清楚再动手写代码。这套架构的优势就是把成熟的高速串行协议和灵活的FPGA逻辑结合在了一起需要快速交付时工程化程度高需要二次定制时又留有足够的扩展空间。