ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

FPGA以太网1G/2.5G PCS/PMA IP核配置指南:时钟、环回与避坑实战

FPGA以太网1G/2.5G PCS/PMA IP核配置指南:时钟、环回与避坑实战 写这篇东西的起因是我去年又踩了一遍 1G/2.5G Ethernet PCS/PMA 这个IP核的坑。做FPGA开发久了都知道以太网这块“看起来简单用起来全是细节”尤其到了 Vivado 2023 时代IP核的配置页面虽然做得越来越友好但该踩的坑一个都没少时钟接错、环回模式选错、共享逻辑没处理好、约束不过、上板后link死活不亮……每个问题都能消耗你大半天时间。这篇博文就把我实际配置 1G/2.5G Ethernet PCS/PMA IP核Vivado 2023版的过程、踩过的坑、排障的思路完整写出来希望能帮正在做FPGA以太网开发的工程师少走弯路。这个IP核解决的核心问题是FPGA与外部PHY芯片或光模块之间的物理层对接。它内部集成了PCS物理编码子层和PMA物理介质附接子层对外是GT高速收发器或SelectIO引脚对内是GMII接口。简单说你的MAC层逻辑通过GMII把数据交给这个IP它负责8B/10B编码、时钟恢复、串并转换最后从GT引脚发出去。适合的人群很宽做以太网接口板卡、交换设备、工业控制、图像传输的FPGA工程师甚至包括刚入门想跑通一个千兆网口的同学。内容上我尽量做到“可以直接抄作业”也会把IP核配置背后的原理讲清楚因为只懂点按钮不懂原理换块板子还是会翻车。1. 为什么这个IP核看着简单用起来却容易翻车1.1 以太网链路里PCS/PMA到底在干什么先不急着打开Vivado配IP我建议每个做FPGA以太网的人先把链路位置搞清楚。一条完整的以太网物理层链路从MAC到网线大致是MAC → PCS → PMA → PMD物理介质相关子层。MAC负责组帧、地址过滤、CRC校验PCS负责8B/10B编码、自动协商、链路状态管理PMA负责并串转换、时钟数据恢复CDRPMD就是PHY芯片里的模拟前端或者光模块里的激光驱动。Xilinx的 1G/2.5G Ethernet PCS/PMA IP核说白了就是把PCS和PMA这两块打包成一个可配置的硬核/软核组合。它的内部结构里PMA部分通常直接调用GT transceiverGTP、GTH这类把FPGA内部的并行数据变成高速串行差分信号从引脚出去PCS部分则是可综合的逻辑负责编码和状态管理。内核对外暴露出GMII接口给MAC用对内通过GT与物理介质打交道。理解了这个分层后面看配置页里那些选项就会很清楚——原来每个选项对应的是某一层的某个功能。1.2 常见的三条实现路线为什么主流是GT-basedFPGA上实现以太网物理层大体有三条路。第一条是用独立的PHY芯片FPGA这边用RGMII/GMII接口跟PHY对接PHY芯片负责PCS和PMA这是大多数板卡的做法因为10/100/1000M自适应PHY芯片便宜又成熟。第二条是FPGA直接驱动光模块或变压器完全不用外部PHY这时候PCS/PMA必须由FPGA内部实现就是这篇文章的主角。第三条是FPGA里跑软核、利用SelectIO做低速PMA适合对速率不敏感、成本敏感的场景。做1G和2.5G绝大多数工程是GT-based这条路线因为GT本身就内置了高速串行收发所需的大部分模拟电路包括CDR、均衡器、时钟倍频性能和稳定性都远好于用逻辑拼出来的方案。而且Xilinx官方对GT-based的PCS/PMA有完整的支持调试手段也成熟。缺点是GT资源占用和功耗比SelectIO方案高但做以太网本来也没几个人在乎这点功耗。1.3 这篇指南适合谁能解决什么问题说句实在话这个IP核的官方文档PG047写得不算差但文档是“答案书”不是“避坑书”。文档不会告诉你“如果refclk消耗时钟不对仿真能过但上板link不亮”也不会告诉你“serial loopback和PCS loopback测出来的结果你该怎么解读”。这篇文章完全从工程角度出发我默认你已经会用Vivado建工程、会写简单的约束文件但对PCS/PMA这个IP还不太熟。如果你是完全零基础建议先补一下GT transceiver的基本概念否则看后面时钟和环回部分会有点费劲。2. 配置之前必须想清楚的三件大事2.1 SGMII和1000BASE-X怎么选打开IP核配置页第一个让人纠结的就是Physical Interface选SGMII还是1000BASE-X。这俩物理层编码其实都是8B/10B线速率也一样1G时都是1.25Gbps区别在应用场景和协商机制上。SGMIISerial Gigabit Media Independent Interface是MAC与PHY之间的一种串行接口标准设计目标是替代并行GMII让MAC和PHY之间用一对差分线传数据。它支持10/100/1000M速率自动协商速率协商是MAC和PHY之间通过SGMII特有的协商机制完成的。所以如果你的FPGA外接的是一颗带SGMII接口的PHY芯片比如常见的88E1512、RTL8211系列你应该选SGMII。1000BASE-X是真正的以太网物理层标准定义了通过光纤或者铜缆1000BASE-T之外的方式传输1000M以太网的完整物理层规范。它也有自动协商但协商的内容是双工模式和对端能力不像SGMII那样协商速率。FPGA对接光模块SFP/SFP或者直连背板SerDes时通常选1000BASE-X。这里有一个新手经常犯的错误板子上明明有PHY芯片却选了1000BASE-X模式结果发现跟PHY自协商永远对不上。记住一个口诀对PHY芯片选SGMII对光模块选1000BASE-X。这个选择决定后面很多行为错了就是白忙一场。2.2 时钟架构决定生死的不只是refclk以太网IP核的时钟比普通逻辑工程的时钟要复杂一些但也更规律。以1G SGMII模式为例整个时钟体系大致是外部差分参考时钟refclk通常125MHz进入FPGA后通过IBUFDS_GTE2原语接到GT的参考时钟引脚这是GT工作的基准。用户侧时钟user_clk数据通路时钟。1G模式通常是125MHz8位GMII接口2.5G模式通常是312.5MHz不对2.5G模式下内部数据位宽和时钟要看具体的配置但无论哪种IP核的例化模板里都会明确标出来。DCLKDRP时钟配置GT寄存器的时钟通常给62.5MHz或125MHz。我见过太多人只关心refclk把user_clk随便接个时钟就当回事了结果上板数据全乱。实际上GT经过CDR恢复出来的接收时钟才是决定Rx方向数据能否正确采样的关键而IP核内部会自动处理时钟域交叉用户侧只需要保证user_clk的频率和相位稳定即可。如果user_clk频率跟配置的线速率不匹配仿真可能看不出来上板后会有偶发错包、丢包非常恶心。2.3 速率模式与自适应协商的底层逻辑这个IP核最让人迷惑的是“速率”到底指什么。物理接口的线速率是固定的1G对应1.25Gbps2.5G对应3.125Gbps但“数据速率”会随协商结果变化。SGMII模式下PHY可能协商出10M/100M/1000M这时候IP核内部会自动切换时钟频率和数据位宽。所以配置页面里如果看到“Auto Negotiation”相关选项要知道它背后是有一套状态机在跑的。我强烈建议在项目最初就确定你的系统是否需要支持10/100M低速协商如果只是千兆直连直接把自动协商关掉强制1G全双工能省掉大量调试时间。如果必须支持自适应那么MDIO接口、状态寄存器读取逻辑、MAC侧的速率切换逻辑都要配套做好工作量会大不少。2.5G模式就没有什么协商了它就是固定速率物理层也不存在标准的自动协商过程。3. 照着做的完整配置流程Vivado 2023.x3.1 创建IP核关键页面逐页过一遍在Vivado 2023.x里左侧IP Catalog搜索“Ethernet PCS/PMA”会找到“1G/2.5G Ethernet PCS/PMA or SGMII”。双击后进入配置界面我按页把关键选项过一遍。Shared Logic那页选项是“Include Shared Logic in Core”和“Include Shared Logic in Example Design”。这个选项的意思是GT_COMMONGT的公共逻辑比如时钟管理、复位管理放在哪里。我的经验是单个IP实例就选“in Core”让IP自己把公共逻辑包含进去省事。多个IP实例共享同一个GT bank时选“in Example Design”只在一个IP里包含GT_COMMON其他IP共享避免重复例化导致DRC报错。选错会编译报错或者上板异常这个值得记一下。Line Rate直接选1G或2.5G。如果选2.5G注意物理接口选项里不会再给你SGMII的自适应功能它是2500BASE-X这种非标准扩展模式。Reference Clock多选125MHz。DCLK给62.5MHz或125MHz都行但必须跟实际接的时钟一致。另外有一个“Speed Selection”的选项SGMII模式下可以选择强制速率或者自适应这个我前面讲过按项目需求来。3.2 例化代码与时钟接法配置完生成IP打开例化模板会发现端口比想象中多。大致分几类GMII接口txd、txen、txer、rxd、rxdv、rxer、rx_clk、tx_clk、GT接口gtx_clk、rx_serdes_reset等、管理接口mdio、mdc、状态接口status_vector、reset_done。我重点提醒几个端口。tx_clk和rx_clk在GMII模式下tx_clk由IP核输出是125MHz1G模式你的MAC逻辑要用这个时钟把数据送给IP核而不是自己随便生成一个125M时钟。rx_clk同理是IP核根据接收数据恢复出来的你下发来的MAC逻辑要用这个时钟采样接收数据。这也是新手最容易问“为什么tx_clk不归我管”的原因。gtx_clk这个端口在SGMII模式下是需要外部输入的通常是125MHz接到GT的参考时钟引脚上。它和上面的tx_clk不是同一个东西——好多人第一次看例化模板直接懵其实就是refclk给GT做串行收发基准tx_clk是IP核分频/倍频后给MAC接口用的并行时钟。reset相关IP核有多个复位输入包括gt_reset、rx_reset、tx_reset等。我个人习惯用一个上电延时后的全局复位信号同时驱动它们并且保证复位释放时参考时钟已经稳定。如果复位时序不对表现为link状态反复跳变、寄存器读到状态不正常。3.3 管脚约束的常见错误和正确姿势约束是这IP核最容易翻车的环节。GT参考时钟不能想当然地约束到一个普通MRCC引脚必须约束到GT专用的参考时钟引脚。查你所用FPGA的封装引脚表找到MGTREFCLK引脚比如Artix-7A35T系列通常有MGTREFCLK0/MGTREFCLK1。注意每个GT bank的参考时钟引脚是固定的如果你把IP核的GT位置指定到了某个bankrefclk必须用这个bank的refclk引脚否则编译会报错或者上板不工作。另外一个高频错误是差分引脚约束。GT输出的是高速差分对比如TXP/TXN、RXP/RXN约束时要成对写并且注意电平标准。如果是跟PHY芯片对接电平标准通常是LVDS或LVPECL需要在约束文件里明确写出来。如果用默认的LVCMOS去约束差分引脚会直接报DRC错误或者虽然能编译过但上板后完全没信号。这里分享一个实操习惯每做完一步约束就立即跑一次Implementation别等全部做完再跑。因为GT相关的DRC错误信息量很大一次只解决一类错误会轻松很多。DRC RTSTAT-2这类报错基本都是IO标准或引脚位置违规把出错引脚列表导出来对着FPGA封装图逐个核对。4. 上板调试从环回测试到实际收发4.1 三种回环方式和它们的调试价值IP核配好之后建议别直接接对端设备先把环回测试跑通。调试以太网链路回环是最有力的工具而PCS/PMA这个IP核提供了几个层次的回环。第一种是GT的串行环回serial loopback也叫near-end PMA loopback。它把GT发送的数据在PMA内部直接返回给接收端不经过外部物理介质。这个环回验证的是GT的收发通道、时钟恢复、串并转换是否正常。在IP核里可以通过信号控制比如把tx_data发一串已知数据看rx_data能否原样回来。如果这个环回都不通先查电源、时钟、复位、GT配置别往下走。第二种是PCS环回在PCS内部把数据从发送方向绕回接收方向经过编码、编帧但没进GT。这个环回可以验证PCS的逻辑功能。通常IP核有对应的寄存器位需要通过MDIO或者DRP接口配置。实际调试时我习惯先跑PCS环回确认PCS逻辑没问题再跑串行环回确认GT没问题最后再接外部设备。第三种是外部环回把FPGA的TX差分对用短跳线直接接到RX差分对这种主要用于确认PCB走线和焊接到位。如果你发现串行环回通了但外部环回不通大概率是板级问题。4.2 用ILA抓包判断问题出在哪一段环回通了之后就要接真实业务了。这时候ILA集成逻辑分析仪是你最好的朋友。我的调试顺序一般是先在GMII接口抓MAC发给IP核的数据确认MAC工作正常再在IP核的状态寄存器里看link状态、接收错误计数最后在接收侧GMII抓IP核发给MAC的数据。如果发送方向一直有数据但接收方向看到rx_en和rx_dv始终拉不起来先看IP核的status_vector里的RX link status是不是1。如果RX link是0说明PCS没有完成同步继续往物理层排查GT参考时钟是否稳定、对方的发送端是否真的在发数据、双方速率是否匹配。如果RX link是1但收不到数据重点检查GMII接口两侧的时钟是否同源、MAC侧是否用了正确的rx_clk。另外一个我印象很深的场景数据能通但Ping有一定概率丢包。这种情况优先怀疑信号完整性其次是GT的RX均衡参数。Xilinx GT提供了RX均衡配置寄存器比如LPM和DFE模式的选择。在低速1G场景下默认配置一般够用但2.5G对信号质量更敏感如果链路比较长或者连接器质量一般可能要手动调整均衡参数。这个调整没有标准答案只能边试边看误码率。4.3 实际业务中的一些坑包间隔、CRC、MAC层配合物理层通了不代表以太网业务就通了。我在实际项目里遇到过几个跟IP核本身关系不大、但跟以太网协议配合紧密的问题。第一个是包间隔IPG不满足要求。以太网标准要求最小帧间隔96ns1G下是12字节时间。如果你的MAC逻辑在帧与帧之间间隔太短对端交换机可能直接丢包或者按错误帧处理。这个错误在FPGA逻辑里很隐蔽因为逻辑上看起来发送端一直在发数据没有报错但对端就是收不到。排查方法是用ILA抓GMII的tx_en信号测量两帧之间的间隔是否足够。第二个是CRC校验。PCS/PMA IP核不做CRCCRC是MAC层的活。如果你自研MACCRC计算逻辑一定要严谨。有时候物理层已经通了但对端一直报CRC错误除了软硬件接口问题还要检查MAC侧CRC算法是否包含了Preamble和SFD虽然标准里CRC不包含这两个但初学容易算错起点。第三个是MAC和PCS之间的速率匹配。SGMII支持10/100/1000M自动协商但这意味着MAC的时钟频率要跟着变。如果你的MAC逻辑只支持千兆而PHY协商成了百兆就会导致数据通路时通时不通。这个要么在代码里屏蔽掉低速能力要么在MAC侧做好速率适配逻辑没有第三条路。5. 避坑速查表与个人经验总结5.1 高频错误现象速查表我把这几年用这个IP核遇到的典型问题整理成一个表方便大家遇到症状时快速定位方向。现象可能原因排查方向Implementation报DRC RTSTAT-2IO标准约束错误、GT引脚位置错误检查GT refclk和差分引脚约束仿真正常上板link不亮refclk未接到GT专用引脚、复位时序不对检查硬件原理图到FPGA引脚的实际连接SGMII对接PHYPHY link不亮物理接口选成了1000BASE-X、MDIO配置错误换成SGMII模式检查MDIO读写时序串行环回通外部环回不通PCB走线问题、焊接虚焊、连接器接触不良排查硬件链路、量差分信号收发都通但ping丢包信号完整性问题、GT均衡参数不合适调整RX均衡设置、检查PCB走线质量对端一直报CRC错误MAC侧CRC计算错误、发送数据位序不对检查MAC逻辑字节序、CRC算法起点2.5G模式跑不出速率refclk频率不对、user_clk不匹配核对2.5G模式下的时钟配置5.2 几条写在最后的实操习惯最后分享几个我这个项目里养成的习惯其实都是老生常谈但每次都能救命。第一例化IP核之后先别急着写业务逻辑先用最简的环回工程把物理链路打通。很多人喜欢一步到位把MAC、DMA、CPU全写好了再联调结果出了问题根本不知道是哪一层的锅。我见过太多项目卡在“以太网不通”上查了半个月发现是IP核某个引脚没接对。第二GT相关的配置和约束尽量集中管理。比如GT位置约束、refclk约束单独写一个XDC文件做好注释。后期换FPGA型号或封装时只需要改这个文件不用满工程翻。第三多看IP核的status_vector和寄存器状态。很多工程师只关心收发数据对不对完全不看状态寄存器。其实IP核内部很多故障已经通过状态位反映出来了比如RX link down、RX not in table、RX disparity error。善用这些状态位能省很多折腾的时间。我在实际调试中最大的体会是FPGA以太网调试不怕慢怕的是没章法。先把链路分层把每层的验收标准定好一层层打通就不会慌。这个IP核整体来说是成熟稳定的绝大多数问题都出在配置细节和使用姿势上。希望这篇指南能帮你少踩几个坑把时间花在真正有挑战的业务逻辑上。
返回列表