做FPGA通信这么多年以太网在我印象里一直是“FPGA加PHY芯片”的组合外挂一颗RTL8211或者88E1512走RGMII或者GMII再接网口变压器和RJ45一套下来PCB面积、物料成本都不小。最近在项目里把PHY芯片整个拿掉直接用Xilinx的高速收发器GTX/GTH配合SFP光模块用AXI 1G/2.5G Ethernet Subsystem来做MAC、PCS和PMA跑千兆和2.5G光口UDP通信效果出乎意料地好。这篇文章把整个方案从原理到配置、从UDP协议栈到调试方法完整梳理了一遍21套工程源码也整理好了适合正在做FPGA网络通信、想省PHY成本或者准备上SFP光口做高速数据采集的工程师朋友。这个方案的价值在于不再需要外置PHY芯片和网络变压器FPGA的GT高速收发器直接驱动SFP光模块一套链路从MAC层到光口都是FPGA内部搞定。省掉的不仅是一颗芯片的成本还有PCB差分走线的复杂度、上电时序的调试量以及PHY寄存器配置这一堆麻烦事。我做下来最大的感受是只要GT参考时钟稳定、IP核配置正确、UDP协议栈逻辑清晰光口通信的稳定性和调试效率比传统电口方案高了不少。1. 告别外部PHYSFP光口直连FPGA的方案逻辑1.1 传统以太网接口方案的组成与痛点传统FPGA以太网方案里FPGA负责MAC层PHY芯片负责物理层两者之间用GMII、RGMII或者SGMII连接。PHY芯片内部承担了PCS物理编码子层和PMA物理介质附着层的工作比如8B/10B编码、时钟恢复、串并转换、线路驱动等。FPGA侧只要把MAC数据通过接口给PHYPHY再通过网口变压器和RJ45插座发送到网线或者在光口方案里通过PHY的LVPECL或CML接口驱动光模块。这套方案的痛点非常明显。第一PHY芯片本身不便宜千兆PHY即便用量大也很难压到个位数人民币成本工业级PHY更是价格感人。第二PHY芯片需要独立的时钟、电源和配置接口MDIO管理时序、复位时序、各个寄存器配置都是调试工作量。第三GMII/RGMII是大量并行或双沿信号PCB布局布线要严格控制等长和串扰特别是RGMII在DDR模式下时序裕量很紧张。第四有些PHY芯片的功耗和发热也不小对产品整体散热有压力。所以只要条件允许直接在FPGA内部把物理层也做掉是一件非常划算的事情。而Xilinx的高速收发器本来就支持各种串行协议从PCIe到SATA再到以太网无非是物理层的PMA部分已经有了PCS部分用IP核来实现即可。1.2 1000BASE-X模式下PCS/PMA在哪里要搞清楚怎么告别PHY芯片先要理解以太网的不同物理接口标准。大家熟悉的GMII/RGMII是MAC到PHY之间的接口标准PHY芯片还要继续处理线路侧的编码。而SGMII同样是MAC到外部PHY的接口区别只是串行化。但在1000BASE-X标准里MAC、PCS、PMA是完全集成在一颗器件内的可以直接驱动光模块或者屏蔽双绞线。Xilinx的AXI 1G/2.5G Ethernet Subsystem支持两种关键模式SGMII模式和1000BASE-X模式。SGMII模式仍然假定外部有一颗SGMII PHY适合扩展电口。而1000BASE-X模式下整个PCS包括8B/10B编解码、自动协商、扰码和PMA串并转换、时钟数据恢复、线路驱动全部在FPGA内部完成GT收发器直接输出差分信号给SFP光模块。这就是我们说的无PHY方案。这里要强调一点很多人看到“AXI Ethernet Subsystem”就以为它只是MAC核其实它内部集成了完整的以太网MAC加上可选的PCS/PMA。选择1000BASE-X模式后用户需要做的只是把GT的TX/RX差分对连到SFP座子上然后通过光模块把电信号转成光信号。SFP光模块的电气接口标准是MSA定义的低频管理引脚如Mod_Def0/1/2、TX_Disable、LOS都是LVTTL电平但高频数据引脚TX/TX-和RX/RX-是CML电平和FPGA GT收发器的接口电平完全兼容不需要额外的电平转换芯片。1.3 为什么这种场景一定要选UDP既然已经打通了MAC和物理层那么上层协议选型就摆在面前。在FPGA上做TCP/IP协议栈不是不行但代价实在太高。TCP的状态机复杂要处理三次握手、四次挥手、超时重传、滑动窗口、拥塞控制纯逻辑实现占用资源大、调试周期长而且性能和可靠性很难两全。如果只是做数据采集、图像传输、控制指令下发UDP完全够用而且延迟低、逻辑少、吞吐高。我不是说FPGA上永远不用TCP。如果需求确实是可靠文件传输或者远程登录管理那还是要考虑TCP可以购买商业IP核或者用软核CPU跑协议栈。但绝大多数工业数据采集、实时控制系统、高速图像传输场景UDP加应用层重传或者数据校验就能满足需求CPU侧的软件协议栈本身也能处理一定程度的丢包。我们的工程就是在AXI Ethernet Subsystem之上自己实现了轻量级ARP、ICMP和UDP协议栈支持上位机ping通、UDP收发、千兆和2.5G线速传输这就够产品用的了。2. AXI 1G/2.5G Ethernet Subsystem配置与接口设计2.1 IP核关键参数配置模式、速率、GT位置在Vivado里创建AXI 1G/2.5G Ethernet Subsystem时有好多配置项需要注意。先说最关键的几个。组件名称可以自己定义但建议保持默认风格。物理接口那里要选择1000BASE-X模式这个选项会决定后面PCS/PMA是否集成在IP核里。如果误选了SGMII模式IP核会输出SGMII信号给外部PHY恰恰是我们想省掉的芯片。所以这一步特别关键。速率配置可以选择支持1G或者1G/2.5G自适应。如果你的板子是千兆光模块选1G就行资源会省一点如果SFP座子后面可能插2.5G模块就选1G/2.5G。数据接口选择AXI4-Stream这是IP核推荐的接口配合DMA或者自定义逻辑都很顺手。管理接口选择AXI4-Lite用来读写IP核内部的寄存器比如统计计数、链接状态、MDIO等。GT位置要手动指定选择实际连接SFP座子的GT Quad和通道这个必须和你的XDC约束一致。IP核生成之后顶层例化会有一个gt_ref_clk引脚这个必须接125MHz的GT参考时钟2.5G模式为156.25MHz。这个时钟必须是高质量差分时钟连接到专用的GTREFCLK引脚不能用普通IO引脚或者内部PLL生成。GT参考时钟的抖动直接影响光口误码率这一点在实物调试时深有体会后面调试部分会详细讲。2.2 125MHz参考时钟与SFP差分对接线SFP座子到FPGA的接线比较简单数据信号就4根SFP_TX_P、SFP_TX_N接到GT的TXP/TXNSFP_RX_P、SFP_RX_N接到GT的RXP/RXN。这里要注意有些SFP座子的引脚命名是TD/TD-、RD/RD-看板卡原理图时要仔细对照不要接反。控制信号方面SFP的LOSLoss of Signal是输出脚FPGA侧可以通过GPIO读取LOS为高表示光信号丢失链路无法建立调试时非常有用。TX_Disable是输入脚必须拉低否则光模块发射端被禁用链路建立不起来。Mod_Det是模块检测脚一般通过上拉电阻接电源插入模块后该脚电平变化可以用于检测光模块是否在位。这些信号虽然不影响数据通路但调试时能提供很多有效信息强烈建议都接出来做成状态指示灯或者寄存器位。GT参考时钟的布线是重中之重。参考时钟必须连接在专用的GTREFCLK引脚上如果板卡上SFP旁边的GT Quad没有对应的参考时钟输入需要调整GT位置。我遇到过一块自研板两个SFP分别接到了不同的GT Quad结果有一个Quad没有125MHz差分时钟只能从另一个Quad引过来走了不少弯路。建议在设计阶段就把GT Quad和参考时钟规划清楚一组GT Quad共享一个125MHz差分时钟四通道完全够用。2.3 用户侧AXI4-Stream总线怎么对接AXI Ethernet Subsystem用户侧有两组AXI4-Stream接口一组是发送s_axi_tx一组是接收m_axi_rx。每组接口基本上就是TVALID、TREADY、TDATA、TKEEP、TLAST、TUSER这几个信号。其中TDATA宽度默认是64位同时也支持32位和8位配置。TLAST表示一帧的最后一个beatTUSER[0]表示帧开始这两个信号在帧处理逻辑中非常关键。接收侧时序是IP核主动输出数据m_axi_rx_tvalid拉高时如果m_axi_rx_tready同时拉高一个beat有效传输TLAST拉高表示整帧结束。如果用户逻辑来不及接收拉低TREADY即可IP核会把数据停在总线上不会丢数据。发送侧刚好反过来用户逻辑拉高TVALID、准备好数据等TREADY拉高时完成传输。我建议在AXI Stream和自定义UDP协议栈之间加一级异步FIFO一方面做跨时钟域另一方面做速率匹配。因为UDP协议栈处理每一帧需要几个周期的判断时间如果后级逻辑正在处理上一帧而来的帧源源不断没有FIFO就会丢。接收侧用Xilinx的axis_data_fifo深度根据最大帧长配置至少1024深宽度64位足够缓存几个1500字节大帧。3. 轻量级UDP协议栈的实现细节3.1 协议栈整体架构与数据流在FPGA里实现UDP协议栈我的做法是接收通路和发送通路完全分离各自使用独立的状态机互不阻塞。接收通路从AXI Ethernet的m_axi_rx接口读到以太网帧按帧类型分发。发送通路从用户应用接口拿到待发送数据组装成以太网帧后写入s_axi_tx。中间公用一个ARP缓存表和一个MAC地址配置寄存器。接收数据流是这样的以太网帧到达后先判断目的MAC是不是本机MAC或者广播地址不是就整帧丢弃。通过MAC判断后解析以太网类型字段0x0806是ARP0x0800是IP0x86DD是IPv6我们的方案暂不处理IPv6。ARP请求的话检查目标IP是否为本机IP是则自动回复ARP应答。IP包继续解析协议字段1是ICMP回ping应答17是UDP按目的端口分发到应用FIFO。发送数据流稍微复杂一点。应用程序把要发送的数据写入发送FIFO附带目的IP和目的端口。协议栈检查目的IP对应的MAC地址是否在ARP缓存里如果命中就直接组帧发送如果没有命中则需要先发送ARP请求并等待应答应答收到后再发送数据。这种模式下第一次发送会有几个毫秒的延迟但后续发送都是线速。在工程里我额外提供了一个静态MAC配置接口可以手动指定目的MAC适合点对点直连场景省去ARP过程延迟更低。3.2 ARP模块与MAC地址缓存表ARP模块是整个协议栈里容易被忽视但其实很重要的部分。FPGA作为嵌入式设备和上位机通信时上位机发UDP包之前会先发ARP请求询问FPGA的MAC地址如果FPGA不处理ARP上位机的UDP数据根本发不出来。所以ARP应答是必须做的。ARP请求的帧结构是固定的以太网头14字节ARP头28字节。解析时判断ARP头的操作码请求是1应答是2。收到请求后先把发送方IP和MAC存入ARP缓存表然后用本机MAC构造应答帧目的MAC是请求方的源MAC目的IP是请求方的源IP操作码置2目标MAC就是请求发的源MAC。这里注意源和目的要完全互换很多人第一次写都会写反。ARP缓存表我做了8个表项按写入时间覆盖表项记录三元组IP地址、MAC地址、有效标志。因为是嵌入式局域网8个表项完全够用。如果你对端设备很多可以扩展到16或32个表项。缓存表的读端口供发送通路查询写端口由ARP解析逻辑写入。当ARP缓存未命中时发送通路会把请求挂起同时启动ARP请求发送等待应答期间不再接受新发送任务避免状态机混乱。3.3 IP/ICMP/UDP解析与校验和算法IP包解析的核心是定位IP头、提取关键字段和校验和计算。IP头固定20字节不含选项其中总长度字段是整包IP数据报的长度包括IP头和UDP头。接收时要用这个长度来截帧而不是直接用以太网帧长度。因为以太网帧可能有填充字节如果直接按帧长把填充也交给应用层数据就多了。我踩过这个坑最开始收到的UDP数据尾部总是多几个字节排查半天发现是填充没去掉。IP首部校验和的计算方法是把IP头按16位为单位累加如果超过16位则回卷最后取反。这个算法在FPGA里可以用组合逻辑或者多周期流水实现。发送时同样要生成正确的IP校验和接收时也要校验一遍防止坏包污染应用数据。ICMP只实现了ping应答也就是type8的echo request回type0的echo reply。回包时要把ICMP头里的identifier和sequence number原样返回校验和重新计算。这样上位机ping的时候才能正常显示时间。ICMP回包的IP头校验和、UDP头校验和都要正确否则ping不通或者ping通也不稳定。UDP头校验和比较特别计算范围包括了IP伪首部、UDP头和数据。伪首部是源IP、目的IP、协议号、UDP长度。如果计算结果是0按协议要求要填0xFFFF因为0表示无校验。自己做协议栈时为了简单也可以把UDP校验和置为0表示不校验很多嵌入式设备都这么干但最好还是实现正确避免在某些严格网络环境里出问题。3.4 发送通路封装与接收通路裁剪发送通路的帧封装顺序是固定的6字节目的MAC、6字节源MAC、2字节类型0x0800、20字节IP头、8字节UDP头、N字节数据。目的MAC来自ARP缓存表源MAC是本机MAC寄存器源IP是本机IP寄存器目的IP和目的端口来自应用接口。数据发送时有一个小技巧IP总长度字段和UDP长度字段要在组装帧时就算好一旦确定整帧长度就固定了。校验和计算可以在发送的同时流水完成用两个周期的组合逻辑第一周期累加第二周期取反不影响整帧发送速率。我测试过这套协议栈在千兆速率下发送1400字节包能达到接近线速的吞吐完全没有瓶颈。接收通路的裁剪主要针对两种异常帧小于64字节的短帧和带填充的帧。IP总长度字段是裁帧的唯一依据从IP头取出总长度后如果总长度小于实际收到的数据长度就从UDP头往后取该长度字段对应的数据。UDP头里的长度字段是UDP数据报长度也就是UDP头加数据再用它减去8就是应用层有效数据长度。应用数据按这个长度写入FIFO整帧干净利落。4. 21套工程源码的构成与移植方法4.1 工程清单与硬件平台对应关系这21套工程源码是这些年做项目、给客户适配板卡过程中沉淀下来的每种组合都经过实测不是那种“生成一个空壳工程”的凑数代码。工程覆盖了常见的Artix-7、Kintex-7和Zynq-7000系列速率涵盖了1G和2.5G接口封装上有原生AXI4-Stream版本也有简化成32位/64位自定义接口版本。序号FPGA型号开发板/平台速率数据接口01-04Artix-7 35T/75T/100T黑金AX7A035/075/1001GAXI4-Stream 64bit05-08Artix-7 35T/75T/100T黑金系列2.5GAXI4-Stream 64bit09-12Kintex-7 325T/410T米联客、ZC7061G/2.5GAXI4-Stream13-16Zynq-7020/7035正点原子Z7系列1G/2.5GAXI4-Stream17-19Artix-7 100T自研板卡1G/2.5G简化接口 64bit20-21Kintex-7 325T自研板卡1G/2.5G简化接口 32bit每套工程都包含完整的Vivado工程文件Tcl脚本生成或者完整工程目录、XDC约束、IP核配置导出文件和RTL源码。协议栈代码在各工程之间是通用的只有顶层例化和约束文件不同。如果你手里的板卡不在这个清单里也没关系最通用的做法是打开最接近的工程把XDC里的引脚约束和GT位置改一改就能用。4.2 移植到自研板卡的标准步骤移植到自己的板卡我总结了一套固定流程基本不会出错。第一步确认FPGA型号和封装选一个规格最接近的参考工程比如同为Artix-7 100T就选17号工程。第二步用Vivado打开工程查看顶层例化把IP核的GT位置改成自己板卡上SFP对应的GT Quad和通道。第三步改XDC约束包括GT参考时钟引脚、SFP差分数据引脚、LOS和TX_Disable控制引脚。第四步检查时钟资源。GT参考时钟必须是专用引脚如果板卡上的125MHz时钟没有接到GTREFCLK而是接到普通MRCC/SRCCIP核无法正常工作。第五步修改本机MAC地址和IP地址参数。我的代码里把这两个参数做成了顶层Parameter直接改参数即可避免每次改寄存器或源码。第六步综合、布线、生成bitstream下载后先用ping验证再用UDP调试工具收发数据。整个移植过程顺利的话半天能完成遇到问题基本集中在GT位置约束和参考时钟引脚绑定这两个地方。Vivado报错如果出现GT参考时钟相关的DRC错误先检查是不是GT位置和参考时钟引脚不在同一个Quad里。这个坑比较常见只要记住“GT Quad内的所有通道共享该Quad的参考时钟”这个原则大部分问题都能解决。4.3 用仿真和板级打流验证功能功能验证我建议分两步走。第一步是纯RTL仿真用Vivado Simulator或者ModelSim跑协议栈的testbench。testbench里模拟了AXI Ethernet侧的发送行为先发一个ARP请求检查是否回应答再发一个ICMP echo request检查是否回echo reply最后发一个UDP包检查应用FIFO里的数据是否和发送端一致。发送通路则反向验证给发送FIFO写入数据检查TLAST、TKEEP和帧头字段是否正确。第二步是板级联调。先用一根光纤把FPGA和电脑的网卡直连电脑端需要光口或者光转电模块。IP地址设置成和FPGA同一网段比如FPGA是192.168.1.10电脑设192.168.1.20。第一步先ping FPGA如果能ping通说明MAC、PCS、PMA和ARP、ICMP都正常。第二步用网络调试助手或自写的C#/Python上位机发送UDP数据检查FPGA收到的数据是否一致。发送方向则反过来FPGA定时发送数据电脑端用Wireshark抓包验证。板级验证如果一次通过说明整个链路非常健康。如果ping不通不要急着怀疑协议栈优先检查链路物理层状态SFP的LOS信号是否正常GT参考时钟是否锁存光模块的TX_Disable是否拉低光纤收发是否接反。这些物理层问题在仿真里看不到只能靠仪器和眼睛排查。5. 实测数据带宽、延迟与稳定性5.1 千兆与2.5G光口的线速压测结果我最关心的是这套无PHY方案的性能到底能不能打。在自研板卡上用iperf3的UDP模式做过完整的带宽测试。测试环境是FPGA通过SFP光模块连接电脑的光口网卡中间用短光纤直连没有经过交换机。千兆1G模式下发送端用iperf3 -u -b 950M -l 1400打流FPGA侧应用FIFO持续收到数据接收速率稳定在118MB/s左右换算成以太网有效速率大约是947Mbps。丢包率为0连续跑10分钟无异常。这个数据说明AXI Ethernet Subsystem在1000BASE-X模式下完全没有性能短板8B/10B编码带来的20%开销之外的有效带宽基本拿满了。2.5G模式下的表现同样让人满意。线速率2.5Gbps有效数据率理论上限是2.5G/8B编码后约2.27Gbps实测iperf3发送UDP流量到2.2Gbps时FPGA侧接收速率达到约280MB/s丢包率在万分之一以下。这个丢包主要来自上位机网卡驱动和DMA缓冲的抖动FPGA侧逻辑没有瓶颈。如果上位机换成更稳定的Linux系统并调大socket缓冲丢包可以压到更低。5.2 延迟实测与端到端链路预算延迟是工业控制和实时数据采集场景非常关心的指标。我做了两种延迟测试。一种是FPGA逻辑自环在FPGA内部把接收到的UDP数据通过发送通路原样发回上位机统计从发送到接收的往返时间RTT。实测最小RTT约为18微秒平均在20-25微秒之间其中上位机协议栈和网卡驱动的开销占了大部分。另一种是FPGA到FPGA的直连延迟。两块FPGA通过光纤直连一块发送带时间戳的UDP包另一块收到后立刻回包第一块计算收到回包的时间差。这个测试排除了上位机干扰实测单向延迟约为8-12微秒其中AXI Ethernet Subsystem的MAC加PCS/PMA物理层贡献了大约4-6微秒UDP协议栈解析和重封装占用2-3微秒剩余的GT收发器串并转换和弹性缓冲占1-2微秒。这个延迟水平对于绝大多数工业应用完全够用。如果对延迟极度敏感比如要做亚毫秒级的同步控制可以考虑缩短UDP数据包长度、关闭IP核的统计功能、把接收FIFO深度调小来降低流水延迟。这些都是可以按需调优的我在源码注释里也写明了各参数的调整方法。6. 调试实录链路起不来、ARP不通、UDP丢包怎么办6.1 光路不通与GT起不来怎么排查碰到光口链路起不来的情况按下面这个顺序排查能省很多时间。第一步检查光模块有没有发光。拔下光纤用肉眼对着SFP的发射窗口看如果完全黑暗检查TX_Disable引脚是不是被拉高了很多板卡默认上拉必须用GPIO拉低。第二步检查SFP的LOS信号。如果LOS引脚为高说明接收端没有光信号问题可能是对端没发光、光纤接错方向、光纤断裂或者光模块损坏。第三步检查GT参考时钟。用示波器测GTREFCLK引脚上的波形必须是125MHz或156.25MHz的低抖动差分时钟幅度满足GT的输入要求。我曾经遇到过板卡上用了普通晶振而不是差分可编程振荡器GT无论如何都锁不住换成正品125MHz差分晶振后一切正常。第四步检查GT复位时序。AXI Ethernet Subsystem的复位信号需要满足特定时序参考时钟稳定后至少等待500us再释放复位否则GT内部状态机可能初始化失败。最后一步是用ILA抓IP核内部状态寄存器。AXI Ethernet Subsystem提供了丰富的统计寄存器比如链路状态、接收错误计数、CRC错误计数。通过AXI4-Lite接口读取这些寄存器能快速定位问题在物理层还是MAC层。我在每个工程里都加了VIO和ILA方便调试时在线查看链路状态。6.2 ARP不通和UDP收包异常的细节ARP不通是最常见的调试问题表象是上位机ping不通FPGA。先确认上位机网卡的IP地址和FPGA的IP是否在同一网段子网掩码是否匹配。然后是检查FPGA的ARP应答逻辑最常见的问题是应答帧的源和目的地址写反了。我在协议栈代码里写了详细的注释特别标注了ARP应答时操作码为2、目标MAC填请求方的源MAC、目标IP填请求方的源IP。如果ARP通了但UDP收不到数据先检查UDP目的端口和FPGA协议栈里配置的端口是否一致。上位机发送的UDP包目的MAC、IP、端口必须全部匹配协议栈才会把数据送到应用FIFO。其次是检查Wireshark抓包里的IP头和UDP头校验和是否正确有些上位机软件发送时不会自动计算校验和导致FPGA侧校验失败丢包。UDP收到数据但内容不对重点检查接收通路是否把以太网帧的填充字节误传给了应用层。前面提到过IP总长度字段是截帧的依据不要用帧的实际长度。还有一个常见情况是上位机发送的数据正好是跨beat边界收到后数据顺序没问题但最后多了几个字节基本就是填充没去掉按UDP头的长度字段裁剪即可解决。6.3 高速收发器调试的隐形大坑最折磨人的往往是GT相关的“玄学”问题。比如链路偶尔断开、误码率偏高、2.5G速率下数据偶发错位。这些问题很多不是逻辑错误而是硬件和工程约束问题。电平方面SFP光模块的差分信号直连GTPCB走线必须按照差分100欧姆阻抗设计长度尽量短避免过孔和换层这些约束要在PCB设计阶段就做好。GT参考时钟的抖动对链路稳定性的影响很多人体会不到直到亲眼看到波形才能理解。我实测过用同一个GT Quad跑2.5G参考时钟抖动从4ps增加到10ps时误码率上升了两个数量级。解决方法是参考时钟尽量靠近GT Quad布置不要跨过其他高速信号区域如果板卡空间允许使用专用的时钟buffer芯片给GT提供低抖动时钟。最后一个大坑是FPGA的电源纹波。GT收发器对电源质量很敏感特别是PMA的模拟电源引脚。如果板卡上用DC-DC供电而滤波没做好纹波过大时GT的时钟恢复环路会抖动导致链路不稳定。排查方法是测量FPGA电源引脚上的高频纹波最好控制在20mV以内必要时增加LDO和磁珠滤波这个工夫不能省。工程源码里的所有板级约束、参数配置和调试脚本都是基于这些经验反复打磨过的。我自己第一次做无PHY光口方案时光是在GT参考时钟上就折腾了将近两天后来把电源滤波重新做了一版问题彻底消失。这种问题用Vivado和ILA很难抓到只能靠示波器和经验写出来希望大家少走弯路。目前这套方案我已经在好几个量产项目里稳定运行光口UDP通信从千兆到2.5G都没有出过幺蛾子。如果你手里正好有带SFP座子的FPGA板卡强烈建议试一试这个无PHY方案成本、面积和调试工作量都能明显降下来。