如果之前一直在点亮LED、调状态机的人第一次被要求让开发板通过网线和电脑通上数据第一反应往往是打开IP核手册或者去网上找现成的UDP协议栈代码。我也是这么走过来的。所以到了这个系列的第9篇文章我决定把“数据链路层代码设计”和“UDP通信测试”放在一起讲清楚为什么不能跳过MAC直接聊UDP以及当你手上只有一块带RGMII网口的FPGA开发板、一个网络调试助手和一个Wireshark时如何从零把一条以太网链路点通。这套流程面向的读者是已经掌握基本Verilog、熟悉同步FIFO/异步FIFO、对跨时钟域有概念但还没正经碰过网络协议的FPGA学习者。看完之后你不会得到一个完整的TCP/IP协议栈但你会拥有一个能跑通“PC到FPGA、FPGA到PC”双向UDP通信的最小闭环并且知道数据链路层每一帧里每个字节到底在干什么。后面再去碰Tri-Mode Ethernet MAC、AXI Ethernet、甚至自己撸TCP都是在这个基础上做加法。1. 为什么这个阶段要手写数据链路层而不是直接调用现成MAC IP核1.1 网络分层在FPGA里到底怎么切以太网通信默认要聊OSI七层模型但做FPGA的人不需要把每一层都背下来。实际工程里我们面对的分层非常朴素物理层由外置PHY芯片负责比如RTL8211、88E1512、YT8531这些它们把差分信号转成数字逻辑电平数据链路层也就是MAC层本来可以交给IP核也可以自己写IP层和传输层UDP/TCP更是灵活小流量可以纯逻辑处理大流量可以上软核处理器比如MicroBlaze配合LwIP。这里最容易被初学者忽略的一点是FPGA和PHY芯片之间的接口只是“物理媒介”它不负责理解以太网帧。真正判断一帧数据从哪开始、到哪结束、CRC对不对、目的MAC是不是自己这些都是MAC层要做的事情。所以当有人说“FPGA里做UDP通信”他其实说的是三件事写一个MAC层收发逻辑、写一个最小IP/UDP封装、再写一个和用户接口对接的FIFO或寄存器读写逻辑。数据链路层的基本功能在FPGA实现里其实非常具体功能教科书说法FPGA里对应实现帧定界识别帧的起止前导码/SFD检测状态机控制接收窗口差错检测CRC校验CRC32计算与比较错误帧丢弃介质访问CSMA/CD、帧间隙全双工下主要是IFG定时半双工才需要复杂处理接口适配与物理层交互RGMII/GMII收发、ODDR/IDDR原语记住这个对照表后面写代码的时候心里就有数了每一块逻辑都能对应到一个帧格式或时序要求不会瞎写。1.2 现成MAC IP核和手写数据链路层的取舍Xilinx Tri-Mode Ethernet MAC、Altera TSE这些IP核功能完整千兆、万兆、流控、VLAN、PTP全都有但配置项多到让人头皮发麻。初始化的寄存器序列、AXI4-Stream接口时序、时钟与复位策略、多通道DMA随便一个环节出错板子上的网口就是红叉。对“近似0基础”的学习者来说用IP核最大的问题不是不会用而是出了问题没法排查你不知道链路层状态机走到哪一步了也没法用波形去对帧格式。手写一个“够用版”数据链路层好处则是所有信号都可见。状态机就三个、计数器就那么几个抓出来一看就知道问题在哪。代价是功能边界必须缩得很小我建议第一版只做下面这些只支持全双工不做CSMA/CD和流控固定PHY速率优先百兆千兆放后面只有一个本地MAC地址不用查表不处理VLAN tag、巨型帧只封装IPv4和UDPARP先手动绑定IP首部校验和先算成常量UDP校验和直接置0。这样砍完之后代码量大概在几百行到一千行之间比MAC IP核的配置界面还容易理解。商业项目当然用IP核但学习阶段手写一遍的收益远大于节省的那点时间。1.3 我定义的“够用版”边界这个边界不止是功能上的还是调试策略上的。最典型的例子是速率选择。RGMII在千兆模式下TXC是125MHz的DDR信号时序约束要求input/output delay新手一旦约束没写对抓包就是满屏CRC错误。但如果先跑百兆TXC变成25MHz时序裕量大了很多先跑通链路层逻辑再说后面再把约束加上去升千兆。另一个要注意的边界是“不要一上来就追求UDP回显”。我见过不少朋友把目标定成“FPGA收到PC的UDP包原样回发”然后卡在ARP上三天。正确的学习路径是先让FPGA主动往PC发UDP包用Wireshark确认帧结构正确再去做PC到FPGA方向。每加一个功能就要有一个明确的验证手段这也是我把这章写进博文的原因。2. 写代码前必须吃透的三件事MAC帧、RGMII时序和CRC322.1 一帧数据从PHY到MAC要经历什么一条以太网帧在线上实际发送的内容比你在教科书上看到的“目的MAC源MAC类型数据FCS”要多8个字节前面还有7字节前导码每个字节都是0x55和1字节帧起始定界符SFD0xD5。前导码的作用是让接收端PHY恢复时钟和比特同步SFD表示后面开始就是真正的MAC帧。所以完整的一帧从PHY的角度看是这样的前导码7字节 AA AA AA AA AA AA AA线上比特流是55的LSB先发 SFD 1字节 AB对线上是0xD5的LSB先发抓包显示常常是AB 目的MAC 6字节 源MAC 6字节 类型/长度 2字节 数据 46~1500字节 FCS 4字节CRC32为什么数据域最少46字节因为以太网规定最小帧长是64字节从目的MAC开始到FCS结束。如果去掉14字节头、4字节FCS数据域最少就是46字节。你的UDP包如果不够长必须在数据域里补零。举个实际例子UDP数据只有“hello” 5个字节IP头20字节加UDP头8字节一共33字节MAC数据域空空如也只剩33字节这时就要补13字节零凑够46字节。很多第一次写发送逻辑的人漏了这一步结果PC端网络调试助手收到的是长度不足的畸形帧网卡可能直接丢弃。2.2 RGMII接口为什么是初学的首选RGMII现在几乎是所有千兆PHY的标配接口原因很简单引脚少。GMII需要8根数据线加4根控制线RGMII把数据线压缩到4根每根线上DDR方式传两个比特控制线也合并成一根TCTL/RCTL。虽然时序变严苛了但对初学者意味着布线容易、盯波形容易。接口约定是这样的TXC上升沿传低4位下降沿传高4位。比如你要发一个字节0xAB那么上升沿的时候TXD[3:0]放0xB下降沿的时候TXD[3:0]放0xA。控制线TCTL类似上升沿表示字节0或1有数据下降沿表示字节2或3有数据。这个“低半字节先发”的约定写代码的时候直接决定了你的拼接顺序。时钟速率上千兆TXC是125MHz百兆25MHz十兆2.5MHz。第一版强烈建议定在百兆或千兆其中一种并且和PHY的协商结果保持一致。多数PHY上电后默认支持千兆自动协商但如果你不写MDIO配置有些PHY会因为外部配置引脚不同而工作在奇怪状态。这里有个很实用的土办法看开发板原理图里PHY的中断/状态LED引脚接法link灯亮不亮能直接告诉你PHY是否协商成功。RX方向更需要注意RXC是PHY恢复出来的时钟不是FPGA生成的它和你内部逻辑时钟天然是异步的。所以接收侧所有信号都要经过IDDR采样后再做跨时钟域处理这个衔接点后面会专门说。2.3 CRC32的位序陷阱与查表法思路CRC32是数据链路层最容易翻车的地方翻车原因几乎都是位序。以太网CRC32虽然多项式也是04C11DB7、初值FFFFFFFF、结果异或FFFFFFFF但它的输入位序是LSB first也就是每个字节最低位先进入移位寄存器。这和很多软件库默认的“MSB first逐字节查表”不是一回事。如果直接把CRC算法原封不动搬进FPGA算出来的结果和线上跑的CRC永远对不上。处理办法有两种。第一种是硬件常用的“给输入字节逐位反转”也就是先把每个字节的bit0和bit7、bit1和bit6……兑换完再丢进标准CRC计算逻辑最后结果也做一次位反转并对FFFFFFFF异或。第二种是直接把CRC表按照LSB-first语义重做查表法在FPGA里可以展开成组合逻辑每一拍输入一个字节更新一次32位CRC寄存器。下面是一个按字节计算的示意代码实际工程里这个函数会被综合成一堆组合逻辑而不是循环function automatic [31:0] crc32_byte; input [31:0] crc; input [7:0] data; reg [31:0] c; integer i; begin c crc ^ {24b0, data}; // 注意data需要按位反转后再异或 for (i 0; i 8; i i 1) begin if (c[31]) c (c 1) ^ 32h04C11DB7; else c c 1; end crc32_byte c; end endfunction这段代码不能直接抄了就综合因为输入data的位反转没写但结构就是标准CRC32的线性移位过程。调到真正的以太网上你还需要处理CRC结果的发送顺序FCS字段是CRC寄存器最高字节先发然后依次到最低字节但每个字节内部还是LSB first。如果你对这块没把握最直观的办法是发固定数据然后对照Wireshark里显示的帧校验序列慢慢调总比自己推位序快。3. 发送通路设计组帧状态机、IP/UDP封装和发送FIFO3.1 发送侧模块划分与时钟域处理发送侧我觉得拆成三个模块就行udp_gen负责把用户数据打包成IP/UDP报文mac_tx负责加前导码、目的MAC、CRC和IFGrgmii_tx负责把字节转成RGMII时序。模块之间用字节流和valid握手。这里最容易被忽略的是时钟域。用户侧逻辑可能跑在100MHz、150MHz而RGMII的发送时钟TXC要么是125MHz要么是25MHz两个时钟并不同源。处理办法是加一个异步FIFO用户逻辑往FIFO里写mac_tx从FIFO里读。异步FIFO深度不用太大64字节或者256字节足够应付最开始的UDP通信后面的丢包问题也多半不是FIFO深度不够而是别的地方。3.2 发送状态机的状态定义与跳转发送状态机是整个发送通路的核心我习惯把状态拆成IDLE、PRE、MAC_HEAD、IP_UDP_HEAD、PAYLOAD、PAD、CRC、IFG。看起来状态多实际每个状态只做一件事从固定值、发送FIFO或CRC寄存器里取字节输出到rgmii_tx然后计数器加1。以发送一帧UDP数据为例字节流的顺序是这样安排的PRE连续发8个字节前7字节0x55最后1字节0xD5MAC_HEAD目的MAC 6字节、源MAC 6字节、类型2字节IPv4就是0x0800IP_UDP_HEADIP头20字节、UDP头8字节内容按网络字节序排列PAYLOAD从发送FIFO读用户数据每读一个字节CRC寄存器更新一次PAD如果前面的数据总长度没到46字节补零同时CRC继续更新CRC把CRC寄存器的4个字节依次发出IFG等够96个bit时间回到IDLE。写状态机的时候有个细节PAYLOAD阶段每一拍都在更新CRC但MAC_HEAD和IP_UDP_HEAD阶段也要更新CRC。也就是说CRC计算必须从目的MAC第一个字节就开始直到PAD结束中间不能断。这里通常用一个crc_en信号只要当前处于除PRE和CRC以外的状态就把当拍字节输入CRC模块。3.3 在MAC之上叠IP头与UDP头MAC层只认以太网帧它不知道IP和UDP是什么。所以我们还要在MAC帧的“数据”区域里塞一个完整的IP包。对一个最简单的UDP包来说IP头是20字节UDP头是8字节。IP头里需要关心的字段是版本和首部长度固定0x45总长度 20 8 UDP数据长度协议字段固定17表示UDP源IP、目的IP各4字节首部校验和是对这20字节按16位累加取反。UDP头里则是源端口、目的端口各2字节UDP长度 8 UDP数据长度校验和第一版直接写0。初学者最容易懵的是IP首部校验和。我第一版调试时偷了个懒既然源IP、目的IP固定UDP数据也固定长度那么整个IP头除了标识字段外全是常量校验和完全可以预先算好写死。只要你不改数据长度这个校验和就是对的。等后面要发变长数据再补一个16位累加器去实时计算。这样的渐进路线能让你先把链路层跑通而不是卡在校验和的实现上。另外还涉及一个大坑ARP。PC如果要主动向FPGA发UDP包它会先查ARP缓存查不到就发ARP请求问“192.168.1.10的MAC地址是谁”。如果FPGA不管PC永远只会发ARP请求UDP包根本不会到FPGA。最快速的解决办法是在PC上静态绑定ARParp -s 192.168.1.10 00:11:22:33:44:55这条命令需要管理员权限。绑定之后PC会直接把UDP帧发到指定MAC不再发ARP请求。这样做的好处是省掉一个ARP回复模块让第一版代码更短。但如果你想做成一个更通用的设备后面还是要补一个“检测到ARP请求就回复应答”的逻辑代码量其实不大核心就是构造一个操作码为2的以太网帧。3.4 一个最小发送模块的Verilog骨架我习惯用参数化的字节数组来做帧头把IP头20字节、UDP头8字节预先填好发送时按索引往外发。Verilog里定义常量数组不如SystemVerilog方便但也可以用localparam加函数或者直接用一个reg [7:0] hdr[0:27]在初始化时填充。下面是个简化骨架typedef enum logic [3:0] { IDLE, PRE, MAC_HEAD, IP_UDP_HEAD, PAYLOAD, PAD_CRC, IFG } tx_state_t; logic [7:0] tx_byte; logic [31:0] crc_reg; logic [15:0] byte_cnt; always_ff (posedge tx_clk or negedge rst_n) begin if (!rst_n) begin state IDLE; end else begin case (state) IDLE: begin if (tx_start) begin state PRE; byte_cnt 0; end end PRE: begin // 发前导码和SFD if (byte_cnt 8) begin state MAC_HEAD; byte_cnt 0; end end ... endcase end end这个骨架的细节不需要背关键是思路每个状态只干一件事字节计数器控制状态切换CRC使能信号跟发送数据同步。写完之后用仿真先跑一发对着自己画的帧格式图逐字节核对再去上板。这能省掉至少一晚上的调试时间。4. 接收通路设计拆帧、CRC校验和回显逻辑4.1 接收侧数据流与关键信号接收通路的设计思路和发送通路是对称的但有一处完全不同发送侧时钟是FPGA自己给的时序可控接收侧时钟来自PHY的RXC你只能接受。RGMII的RX信号在FPGA这边要用IDDR原语在每个时钟沿采集4bit拼成一个字节。拼的顺序和发送相反上升沿采到的是低4位下降沿采到的是高4位。从PHY到用户逻辑的完整数据流是rx_clk/rx_ctl/rxd[3:0] - IDDR - 拼接成8bit - 接收状态机 - 接收FIFO - 用户解析模块接收状态机的关键信号是rx_ctl。它在帧的期间一直为高从SFD之后到FCS结束之后拉低。PHY在复位刚完成、链路还没稳定的阶段可能有毛刺所以最好加一个简单的“连续几个周期rx_ctl为高才开始接收”的滤波逻辑否则状态机被毛刺带偏抓包全是错帧。4.2 接收状态机的设计要点接收状态机大体是IDLE等待rx_ctl拉高、检测到SFD后进入DATA、一直收到rx_ctl拉低结束。和发送状态机不太一样的是接收的时候数据可能随时断掉也就是rx_ctl并不是一个稳定可预测长度的信号。所以状态切换不能靠“固定的字节计数”而是要结合rx_ctl的电平来判断帧是否结束。边收边存的策略是这样的从MAC头开始每收到一个字节就写入接收FIFO同时并行计算CRC。帧结束时比较计算出的CRC和收到的FCS不一致就标记为坏帧。判断坏帧之后最简单的办法是不丢弃而是在FIFO的帧头额外存一个标志位由上层逻辑在读到这一帧时主动扔掉。这样虽然会占用一点带宽但对初学者来说最简单。另一个雷区是FIFO溢出。如果你的用户逻辑比如UART打印处理速度跟不上接收FIFO会被写满后面的数据全部丢掉。我建议在接收状态机里检查almost_full一旦接近满直接停止接收并把当前帧标记为坏帧。这不是最优做法但能保证不会因为FIFO溢出产生半截帧干扰上层解析。4.3 从以太网帧里把UDP数据拎出来接收FIFO里存的是从目的MAC开始的完整MAC帧前导码和SFD已经被状态机剥掉了。要做的事就是按顺序解析前12字节是目的MAC和源MAC第13、14字节是类型如果类型是0x0800继续解析IP头IP头里看协议字段如果是17UDP继续解析UDP头最后剩下的就是用户数据。这里要特别提醒字节序问题。网络上所有多字节字段都是大端也就是高字节在前。IP地址“192.168.1.10”在帧里就是C0 A8 01 0A端口5000在帧里就是13 88。如果你用16位变量直接赋值并把它当成一个整体发送很容易搞反高低字节。解决的办法是定义成字节数组按索引赋值不要依赖编译器帮你处理端序。回显模式是联调阶段最值钱的功能。它要求FPGA收到UDP包后把源MAC、源IP、源端口存下来然后作为回包的“目的地”把有效载荷原样发回去。这样一来PC发什么FPGA就回什么闭环成立。代码上就是接收模块多存几个寄存器发送模块在构造IP/UDP头时改用这些寄存器里的值。4.4 回显模式联调阶段的黄金测试方法回显模式之所以好用是因为它把接收和发送两条通路串成了一个闭环。PC端网络调试助手发送“hello”如果能收到同样的“hello”说明以下几件事同时成立PHY接收正常、MAC拆帧正确、IP/UDP解析正确、发送组帧正确、CRC计算正确。一旦哪一环出错你只需要看现象没回包优先怀疑接收解析回包内容乱了优先怀疑字节序完全没反应就从ARP查起。我自己的习惯是第一版先不做回显而是让FPGA每收到一帧就把收到的目的端口和源IP通过串口打印出来。这个“打印调试法”听起来土但在没有逻辑分析仪的情况下能帮你快速看到接收通路到底有没有工作。等串口能打印出PC的IP和端口号了再打开回显开关往往一次就通。5. 上板联调从网络调试助手到Wireshark的完整验证方法5.1 连接与PC端配置联调之前先做三件事开发板网口和电脑网口直连中间不要插交换机关闭电脑的WiFi避免系统把包路由到无线网卡给有线网卡设置一个静态IP比如192.168.1.2子网掩码255.255.255.0。FPGA侧的IP我习惯用192.168.1.10MAC地址随便分配一个不冲突的比如00:11:22:33:44:55。注意MAC地址不能是全0有些网卡驱动会直接丢这种帧。这里还有一个很容易被忽略的前置检查先开网络调试助手用两台电脑之间跑一次UDP收发。如果两台电脑互相都通不了别急着怀疑FPGA先把防火墙规则、网卡驱动这些环境问题排掉。这个过程五分钟但能帮你省掉后面两小时的无效调试。5.2 测试方向一FPGA主动向PC发UDP我强烈建议联调的第一个方向是FPGA主动发而不是PC发。因为FPGA主动往外发不依赖ARP只要发送组帧正确电脑网卡就会收到Wireshark里立刻能看到。具体做法FPGA内部用一个计数器或者按键触发固定每100ms发送一个UDP包目的IP是192.168.1.2目的端口5000数据内容是递增数或者“Hello FPGA”的ASCII码。PC端网络调试助手监听本地端口5000如果收到数据且内容正确FPGA到PC的反向通路就算通了。这时候打开Wireshark抓包过滤器直接写udp.port 5000。重点看三件事以太网层的类型是否是0x0800、源MAC和目的MAC是否和你设计的一致IP层的总长度和标识对不对、IP校验和是否被Wireshark报错UDP层的源端口、目的端口、长度是否正常。这一套看下来你对“FPGA里构造的UDP包在PC眼里长什么样”就有了直观概念。5.3 测试方向二PC向FPGA发UDP并回显PC发UDP给FPGA之前必须解决ARP。如果你已经在PC上执行了arp -s 192.168.1.10 00:11:22:33:44:55静态绑定这一步就跳过去了。如果没有FPGA必须能回复ARP请求否则PC会在发出ARP请求后一直等应答UDP数据永远发不出去。PC端的网络调试助手配置可以这样理解对UDP通信来说没有TCP那种固定“服务端/客户端”概念。PC的本地端口和远端端口都要填PC发出的UDP包源端口是本地端口目的端口是远端端口。假设PC本地端口设为6000、远端端口设为5001那么FPGA侧的回显逻辑就应该从收到的UDP包头里提取源端口6000然后回给PC的6000端口。这个“用接收包里的源信息作为回包目的信息”的思路就是回显能工作的关键。如果没有回显别急着翻代码。先在Wireshark里过滤arp or udp.port 5001 or udp.port 6000按这个顺序排查PC发ARP请求了吗如果发了FPGA回ARP了吗如果ARP通了PC发UDP了吗如果没发说明PC的ARP缓存可能还是没生效或者静态绑定被系统清理了。如果PC发了UDP但FPGA没回说明接收通路有故障回到第4章排查拆帧和解析逻辑。如果FPGA回了但PC助手没显示看看回包的源端口、目的端口是不是反了这是最常见的低级错误。5.4 Wireshark的关键过滤技巧Wireshark是这个项目里最值得信任的调试工具它会告诉你帧到底长什么样。常用的过滤条件就这么几个udp.port 5000只看端口为5000的包ip.addr 192.168.1.10只看和FPGA IP相关的包eth.addr 00:11:22:33:44:55只看指定MAC的帧arp单独看ARP交互frame.time_delta_displayed在列首右键添加这一列可以直接看到相邻两个包的时间差排查周期性发送非常方便。抓包时你会看到很多无关的包比如电脑自己的mDNS、NBNS、IPv6邻居发现、随机ARP请求这些都是正常噪声不要被干扰。用过滤器把它们屏蔽掉一眼就能看到自己的UDP包。这里有个经验Wireshark里如果每一帧都显示“Bad CRC”先别急着改代码。先用固定数据发一帧在Wireshark里对照Hex内容确认前导码、MAC头、IP头、UDP头、数据、FCS每一段是否和预期一致。很多时候“Bad CRC”是因为PHY或者网卡驱动做了校验和卸载抓包点看到的CRC是后来补算的而帧内容本身完全正常。分清这个问题能少走很多弯路。6. 调试路上躲不开的几个坑从网卡红叉到丢包排查6.1 网卡红叉、link灯不亮如果电脑插上网线后没有任何反应PHY的link灯不亮问题几乎肯定在物理层和PHY配置而不是你的MAC状态机。排查链路是这样的先量PHY核心供电和复位脚确认PHY没有一直处于复位状态再查PHY的参考时钟常见是25MHz晶振没有时钟PHY就是死的然后看RGMII的TXC是否有波形没有波形就说明FPGA没把125MHz或25MHz时钟送出来最后检查PHY的配置引脚有些板子需要拨码开关或电阻选择PHY地址和模式如果和默认值不一致PHY可能工作在错误的速率或接口模式。一个实用的建议是上板之前先烧一遍开发板自带的网口例程确认硬件本身没有问题。如果原厂例程连link灯都不亮那是硬件或PHY配置问题代码写得再对也没用。如果原厂例程能亮再换成你自己的工程问题就锁定在FPGA侧。6.2 Wireshark报Bad CRC但数据内容看起来正常这是所有手写MAC的初学者几乎都会遇到的一次磨难。数据内容全对帧格式也对着呢Wireshark却每一帧都报CRC错误。原因几乎都是CRC模块的位序处理不对或者CRC结果输出字节序不对。排查办法是把发送数据固定成一个好识别的模式比如第一帧发送00 01 02 03 ... 3F然后抓包。在Wireshark里把帧的Hex逐个字节抄下来自己写一段Python脚本对这个比特流重新计算一遍标准以太网CRC32。如果算出来的CRC和抓包里的FCS一致说明你的FPGA代码没问题问题在PC网卡的校验和卸载如果不一致就一字节一字节地对比看是字节计数差了一位还是CRC更新时机慢了一拍。我还想多说一句现在很多AI工具能帮你审查这类代码。你可以把CRC模块、接收状态机、发送状态机这些核心代码贴给AI让它按照“LSB-first CRC32、RGMII DDR时序、异步FIFO跨时钟域”几个常见出错点做静态检查。它不一定能取代你自己的判断但能帮你迅速圈定可疑位置。我自己就干过这事儿AI确实能发现一些边界条件漏判的问题比如接收状态机在rx_ctl突然拉低时没有回到IDLE。6.3 数据错乱、字节颠倒与端口号不对如果收到的UDP内容错乱但Wireshark不报CRC错误说明帧能通过校验问题出在数据内容的字节序上。最常见的是端口号不对想发给5000结果PC助手收到的是0x8813这种被拆反的值。原因就是代码里用16位变量直接构造端口号网络字节序要求高字节先发但拼接或赋值时把高8位和低8位搞反了。排查方法是发一个固定模式的数据比如0x12 0x34 0x56 0x78然后在Wireshark里查看这4个字节在UDP负载里的位置。如果变成0x78 0x56 0x34 0x12那就不是简单的字节序问题而是整帧被整体翻转了这往往发生在RGMII采样拼接时上下半字节顺序反了也就是上升沿和下降沿的数据拼反了。这个坑的频率比想象中高因为RGMII本身规定“上升沿传低4位”但有些PHY的实际行为会让人困惑最后还是要靠抓包实锤。6.4 丢包、吞吐上不去和后续优化方向第一版跑通双向UDP之后很多人会想试试连续大流量发送结果发现丢包率惨不忍睹。先说结论丢包不等于你的链路层写错了更可能是FIFO满、PC助手缓冲不足、或者用户侧处理不过来的问题。TCP有重传机制UDP没有所以UDP丢包是非常正常的现象。测试吞吐时还有个大坑iPerf3不能直接测FPGA。因为iPerf3需要先建立一个TCP控制连接光这个TCP栈就够你喝一壶了。想测FPGA的UDP吞吐不如自己写一个Python脚本循环发送UDP包并统计回显率或者直接用Wireshark的IO Graph看每秒收到的包数。这样你就把“上位机工具的限制”和“FPGA本身的性能”分开看了。如果确实想提高吞吐后面的优化方向基本是这几条接收FIFO改深比如从256字节加到几KB发送链路改成流水的CRC计算避免在CRC状态停留太久把用户逻辑改成双缓冲在读数据的同时准备下一帧再进一步就是上AXI DMA把FPGA里的数据直接搬到DDR绕开CPU。这个项目做到回显通了之后你再回头翻MAC IP核的用户手册那种感觉是完全不一样的。你至少知道它在底层给你封装了什么、那些配置项改的是哪个寄存器的行为。我个人的建议是这个最小链路不要求快但每一个字节都要对着Wireshark核对一遍把PC和FPGA之间能稳定互发UDP这事做到“条件反射”的程度。后面的千兆线速、TCP、PTP、甚至MIPI图像数据直接上以太网都是在它基础上做加法。
地级市科学技术水平2003-2024年)
