拿到一块带网口的FPGA开发板我最想干的一件事不是点灯玩而是让PC和FPGA之间能真正互发数据。听起来不就是往网口插根线嘛真做起来PHY、MAC、RGMII、ARP、UDP这一大串名词能把不少初学者直接劝退。这篇是“从近似0基础开始FPGA开发”系列的第七篇主要讲FPGA网络通信设计。看完并跟着走一遍之后你应该能具备这样的能力给板子上电插上网线PC端能ping通FPGA并且能够用UDP互相收发自定义数据。整个方案不依赖操作系统、不依赖软核CPU所有逻辑都在FPGA里面跑。这篇内容适合已经会写基本Verilog状态机、用过仿真工具、能独立完成一个简单工程的读者。如果你刚入门建议先把LED流水灯、按键消抖、UART收发这几个经典实验跑通再来啃网络会顺利很多。下面我按自己实际调试的思路来写尽量把每一步设计背后的原因、踩过的坑、以及能直接抄的代码框架都给你讲透。1. 先把整条网络通信链路看清楚做FPGA网络通信设计最容易犯的错是拿到例程直接烧结果电脑显示“网络电缆被拔出”或者“未识别的网络”然后又不知道从哪查起。这种问题的根子在于对整条链路没有全局认识。所以我建议动手写代码之前先花半小时把信号从网线到FPGA内部走一遍。从物理顺序来看网线上的模拟差分信号先到网络变压器一般集成在RJ45座子里经过电平转换后进PHY芯片PHY负责把模拟信号恢复成数字逻辑电平然后通过接口把数据交给FPGA。FPGA这边要做的事情有两类一类是MAC层负责识别以太网帧、生成CRC校验、添加或解析前导码另一类是上层协议例如ARP、ICMP、UDP负责让PC和FPGA之间在逻辑上“对话”。简单说PHY管物理层FPGA管数据链路层和网络层你要写的代码主要在FPGA侧。这条链路我可以再类比一下。PHY有点像电话线路的调制解调器它只负责把声波和比特之间互相转换不管你说的是什么语言FPGA里写的协议栈则是通信双方约定的“语言”只有语言一致对方才听得懂。所以调试的时候如果电脑ping不通你至少要能判断是哪一层出了问题——是物理层没起来还是MAC层CRC全错还是协议包头没拼对这个判断能力比背代码重要得多。1.1 三条路线我为什么选了最“笨”的一条很多初学者会去网上找例程结果发现FPGA做网络通信大致有三条路线。第一条是用Xilinx或Intel的专用Ethernet MAC IP核配一个外部PHY然后上层自己写协议。这种方案最“正规”但问题在于IP核内部细节被封装得很严实对新手来说像黑盒子出问题很难排查。第二条是用软核处理器比如MicroBlaze、NIOS II里面跑一个网络协议栈说白了就是用C语言写网络程序FPGA只是跑了一个CPU这对理解FPGA逻辑没有太大帮助。第三条是完全用Verilog自研一个精简MAC和精简协议栈外部PHY自己驱动帧结构自己拼CRC自己算。我最推荐的是第三条路也是我自己实践时用的方案。虽然听起来工作量最大但对学习的收益最高而且调试起来反而更可控因为每一段逻辑都是你自己写的出了错你能靠仿真和抓包快速定位。如果目标是产品化你当然可以用IP核或者软核可如果目标是弄懂FPGA网络通信设计到底怎么回事就必须自己亲手把每一层做一遍。那是不是要把完整的TCP/IP协议栈全写一遍完全不用。我们的目标是PC和FPGA通信不是让FPGA跑一个网页服务器所以只需要实现最小可用的子集ARP应答、ICMP回显也就是ping、UDP收发。这个组合足够覆盖绝大多数实验和项目需求而且逻辑量不大状态机也不复杂——如果你已经写过UART收发这部分代码量大约也就再增加三四百行。1.2 顶层架构一个最小可工作的网络通信系统需要哪些模块动手写代码之前我习惯先在纸上画一个框图明确模块边界和时钟域。否则写着写着数据流和时钟混在一起状态机很容易乱。对于这套最小系统我划分成了这些模块模块作用所在时钟域时钟管理MMCM/PLL产生125MHz、25MHz等时钟全局RGMII接口把PHY送来的4bit数据合并成8bit把要发送的8bit拆成4bit送出125MHz/25MHz接收FIFO跨时钟域缓冲给协议处理逻辑一个稳定的数据口125MHz - 100MHzMAC帧解析/组帧负责剥掉前导码、校验CRC、处理长度100MHzARP/ICMP/UDP处理识别并回应协议报文100MHz发送FIFO跨时钟域缓冲等待发送的报文100MHz - 125MHz为什么这里有两个时钟域PHY提供的接收时钟是125MHz千兆模式或25MHz百兆模式而协议逻辑最好跑在一个独立时钟上比如板载100MHz晶振经过MMCM出来这样后端的控制逻辑不会被PHY的时钟牵着走。两个时钟域之间用异步FIFO来衔接这是FPGA跨时钟域的常规做法。这里我要给新手一个非常朴素的建议不要试图一开始就做一个大而全的架构。先把RGMII接口和收包FIFO做通再逐步加上CRC校验、ARP应答、ICMP、UDP。每加一层都拿到板子上实测一次。一次集成太多模块出了问题你根本不知道是该查PHY配置、查时序还是查协议状态机。1.3 选型清单与目标设定我手上的开发板用的FPGA是Xilinx Artix-7系列板载PHY是瑞昱的RTL8211EG网口支持千兆接口正好是RGMII。这套组合非常典型很多开发板都类似如果你的板子用的是其他PHY比如百兆的LAN8720或国产PHY驱动思路也差不多区别主要在于MDIO寄存器地址和配置值所以要养成翻原理图和PHY数据手册的习惯。初始目标我设为三步。第一步PHY能link up至少能让PC端识别到网线已插入第二步FPGA能够正确响应ARP请求PC能看到FPGA的MAC地址第三步PC能ping通FPGA同时能通过UDP发送和接收数据。把这三步作为里程碑每个里程碑完成一张自检清单你会发现网络通信设计并没有想象中那么神秘。我自己在实际开发中还会固定一批参数FPGA的MAC地址设为D4:BE:D9:01:23:45随便选一个非广播的私用MAC不要和局域网内设备冲突即可IP地址固定为192.168.1.10PC端固定192.168.1.2子网掩码255.255.255.0不用设置网关。这套配置用网线直连不经过路由器能减少很多干扰。下面所有调试场景都基于这个环境。2. 硬件侧的功课RGMII时序与PHY配置FPGA网络通信设计的第一个门槛不是你写了多少协议逻辑而是RGMII接口能不能稳定收到数据。很多初学朋友在协议层折腾半天最后发现根源是RGMII时钟采样不对所有数据都是错位的。所以这一章我们先把硬件侧的细节吃透。2.1 从网口到FPGA信号到底经过哪些环节板子上的RJ45座子连着一个网络变压器变压器和PHY芯片之间是差分信号线PHY芯片再通过RGMII接口接到FPGA上。FPGA引脚出来就是普通的单端3.3V或1.8V信号一般包括TX_CLK发送时钟、TXD[3:0]发送数据、TX_CTL发送控制RX_CLK接收时钟、RXD[3:0]接收数据、RX_CTL接收控制MDC、MDIO用于配置PHY寄存器以及PHY复位引脚新手最容易误解的一点FPGA并不直接去处理网线上的差分信号和编码。千兆的编码、时钟恢复、自动协商这些脏活累活都由PHY芯片做了FPGA只是通过RGMII接口拿到已经恢复好的数字信号。所以如果你的PC上显示“网络电缆被拔出”问题大概率在PHY供电、复位、晶振或者网络变压器周边电路而不是FPGA逻辑。这里有一个判断技巧观察板载PHY的link指示灯。如果插上质量没问题的网线后link灯不亮或闪烁不停说明PHY工作不正常先查硬件。只有灯能够常亮才值得你继续调FPGA逻辑。这个顺序搞反的人特别多我曾经以为FPGA代码写错了硬是调了一个下午结果发现是网线是交叉线后来换了一根直连线立马link up。2.2 读懂RGMII接口的收发时序RGMII全称是Reduced Gigabit Media Independent Interface它最核心的特点是用DDR方式在时钟的上升沿和下降沿都采样数据。千兆模式下时钟是125MHz4根数据线加上双沿采样等效成为8bit数据x125MHz1Gbps百兆模式下时钟是25MHz带宽就是100Mbps。先看发送方向。FPGA作为发送端要把8bit数据拆成两个4bit在TX_CLK上升沿发送低4位TXD[3:0]同时TX_CTL表示发送使能在TX_CLK下降沿发送高4位TXD[7:4]同时TX_CTL上要额外编码一个TX_ER信号。不过在我们做全双工以太网的场景里TX_ER通常不用所以简化处理下降沿的TX_CTL保持和上升沿一样即可。接收方向反过来。PHY在RX_CLK的上升沿把低4位放在RXD[3:0]上在下降沿把高4位放在RXD[3:0]上RX_CTL同理。FPGA要做的是在两个沿分别采样再把两个半字节拼成一个字节。代码框架大概是这样// 接收RX_CLK上升沿采低4位 always (posedge rx_clk or negedge rst_n) begin if (!rst_n) begin rx_l 4d0; rxdv_l 1b0; end else begin rx_l rxd; rxdv_l rxdv; end end // 接收RX_CLK下降沿采高4位 always (negedge rx_clk or negedge rst_n) begin if (!rst_n) begin rx_h 4d0; rxdv_h 1b0; end else begin rx_h rxd; rxdv_h rxdv; end end assign rx_data8 {rx_h, rx_l}; // 拼成8bit assign rx_valid rxdv_l; // 数据有效标志不过实际工程里从下降沿采集的rx_h要先打两拍同步一下再和上升沿采集的rx_l合在一起否则两个半字节的时序可能错位。这个细节在很多教程里看不到但是上板调试时非常关键。如果发现收到的数据是乱序的可以先在这里找原因。发送方向也有类似问题我一般用ODDR原语或者直接调用厂商的DDR输出模块代码不多但能保证时序稳定。2.3 用MDIO接口把PHY调到“准备好”状态PHY芯片不是上电就能直接用的它内部有几十个寄存器需要通过MDIO接口读写。MDIO本质上是一个两线串行接口MDC是时钟MDIO是双向数据线协议格式类似SPI先发32位前导再发寄存器地址和读写标志最后收发16位数据。读PHY寄存器时PHY地址和寄存器地址由FPGA指定数据是PHY返回的写寄存器时数据是FPGA给PHY的。RTL8211EG的PHY地址一般可以在原理图上看到常见是0x01。如果你不确定可以连续读多个地址看哪个地址的ID寄存器能读出非0值。这里我给大家一个初始化流程拉低PHY复位引脚至少20ms然后拉高释放复位。等待至少100ms让PHY内部PLL稳定下来。读寄存器0基本控制寄存器确认bit15自动协商使能是否有值。如果不需要自动协商就直接写寄存器0为0x1000把PHY配置为1000M全双工模式。这样最可控。反复读寄存器1基本状态寄存器直到bit2为1表示链路已经link up。寄存器1的bit2就是链路状态位这个位为1的时候说明PHY已经和对面网卡协商成功此时网线插上后PC端的“网络电缆已拔出”提示就会消失。我把这个寄存器读回当成“网络初始化完成”的标志状态机里要等这个bit为1再启动接收逻辑。做MDIO控制状态机的时候我通常是先做一个功能简单的MDIO读写模块提供两个接口信号寄存器地址、读写数据、使能。上层通过控制这个模块来读写PHY。没有必要为每款PHY都重新学一遍协议因为MDIO帧结构是IEEE标准定义的各家PHY通用只是寄存器含义略有差异。2.4 时钟和复位最容易在板子上翻车的两个点我调试网络通信时花在时钟和复位上的时间比写协议还多。RGMII接口里面至少有两个时钟域在交互PHY提供的RX_CLK是接收时钟域FPGA本地产生的发送时钟是发送时钟域。如果你把RX_CLK直接拿去驱动协议状态机那协议逻辑就跟着PHY的参考时钟走了前端接收和后端处理都挤在一起后面加FIFO跨时钟域会很痛苦。我的做法是本地用一个MMCM从板载100MHz晶振产生一组干净时钟比如100MHz和125MHz。100MHz给协议处理逻辑用125MHz给RGMII发送时钟用。PHY接收部分的RGMII接口仍跑在RX_CLK上但数据在进入协议逻辑之前必须先进入异步FIFO做缓冲。这样协议逻辑始终只面对一个时钟逻辑更容易收敛时序约束也好写。复位方面很多板子的PHY模块是独立电源域复位时序比普通外设敏感。如果复位释放太快PHY内部还没完成初始校准后面链路就起不来。我踩过的坑是上电后FPGA复位释放后立刻去读PHY寄存器读回的全是0xFFFF后来加了延时等PHY初始化完成后再操作问题就消失了。建议在FPGA里做一个简单的上电复位计数器至少延时200ms再去初始化PHY。时钟复位都处理好了你再用ILAVivado逻辑分析仪抓RX_CLK和RXD波形应该和RGMII协议手册里的时序基本吻合。这一步通了后面MAC层协议才有意义。3. 单帧通信的地基MAC层与CRC32PHY把你的数据从网线“搬运”到了FPGA内部但FPGA收到的只是一串数据流这一章就开始处理串数据流里最有技术含量的部分识别以太网帧、校验CRC、组装发送帧。3.1 以太网帧的“翻译表”以太网帧有一定的固定格式FPGA要做的事情很简单按照格式把数据流拆开或者把数据装进去。一个标准的以太网帧组成如下字段长度说明前导码7字节每个字节为0x55用于收发时钟同步帧起始定界符1字节0xD5表示后面是真正的帧目的MAC6字节对方网卡的MAC地址源MAC6字节发送方自己的MAC地址EtherType2字节0x0806是ARP0x0800是IPv4Payload46~1500字节上层数据太短要补零FCS4字节对源MAC开始的整帧做CRC32得到的校验值接收方向前导码和SFD不是有效帧内容必须去掉。后面从目的MAC到Payload才是真正交给协议层处理的帧数据。发送方向则相反需要在数据前加上前导码和SFD数据不足46字节要补零到46字节最后追加4字节CRC。新手常犯的一个错误是把前导码也当成数据存进FIFO。这样上层协议在解析目的MAC时就会错位一个字节后面ARP、IP、UDP全部解析错误。我调试时抓包看到ARP请求一直接收不正常排查到最后才发现是前导码没剔除。还有个容易混淆的点是字节顺序。以太网帧里的MAC地址、IP地址、UDP端口都是按“高字节先发”的网络字节序。比如MAC地址D4:BE:D9:01:23:45在线上先看到D4再是BE。CRC算法则不同它是位流处理的字节内按LSB-first。这两个顺序的问题是网络协议实现最容易吃苦头的地方后面我会单独讲。3.2 CRC32起来复杂抓住三个关键点以太网FCS使用的是CRC32算法对从目的MAC到Payload结束的所有字节求校验值。某些初学者看到CRC就发怵其实以太网CRC32只需要抓住三个关键点第一多项式是0x04C11DB7。第二初始值是0xFFFFFFFF。第三输入数据每个字节按LSB-first方式送入算法也就是每个字节最低位先参与计算这一点和通常的字节流顺序不同。最后得到的32位结果要按位取反才是FCS字段。如果你用Verilog从零写并行CRC会比较枯燥。比较省事的方法是直接用Vivado的CRC Generator IP核配置CRC多项式为0x04C11DB7初始值为0xFFFFFFFF输入输出位序选LSB-first异或输出选0xFFFFFFFF数据宽度设8bit时钟数是字节数。这样每进来一个字节就能得到当前累计CRC值。这个IP核的延迟是固定节拍时序好约束也容易仿真比你自己写要靠谱很多。验证CRC是否写对有个特别实用的办法用Wireshark抓一个PC发出的标准ICMP包把源MAC、目的MAC、EtherType、IP头、ICMP数据全部提取出来喂给你自己的CRC计算模块算出来的4字节应该和这个帧的FCS一致。如果一致说明你的CRC算法、位序、字节序全部正确。在我没做这个验证之前CRC错误率接近百分之百。需要特别记住CRC的计算范围是源MAC开始到Payload结束不包括前导码和SFD。发送端在发完数据后再接着发送计算出的4字节CRC接收端读到FCS后要把自己累计的CRC和收到的FCS比较。如果发现CRC不对这帧就应该直接丢弃不能交给上层。3.3 接收状态机一帧数据是怎么被“拆”出来的接收方向的核心是一个状态机。为了可靠地拆出帧我会把FIFO写使能、帧长计数、CRC计算都放在同一个状态机里保证它们节拍一致。最基本的状态定义是localparam S_IDLE 3d0; localparam S_PREAMBLE 3d1; localparam S_DATA 3d2; localparam S_FCS 3d3; localparam S_DISCARD 3d4;IDLE状态等待rx_valid拉高。rx_valid拉高后进入PREAMBLE状态连续跳过7个0x55和1个0xD5。从SFD之后第一个字节开始进入DATA状态。DATA状态下每个节拍都把数据写入接收FIFO同时把字节送入CRC计算模块并累加帧长计数。当帧长计数等于目标长度时进入FCS状态连续收4个FCS字节和自己的CRC值比对。比对通过后这一帧才算完整接收成功。如果收到的帧长小于64字节这种叫做RUNT帧按照标准可以直接丢弃如果帧长超过1518字节属于超长帧也建议丢弃。这两种情况我在接收状态机里都会统一进入DISCARD状态清空FIFO再回到IDLE。写接收状态机容易踩的一个坑是在DATA状态中rx_valid可能中途拉低这种半截帧必须丢弃。很多例程不处理这种情况导致后面解析出完全不合理的协议头。我的做法是如果DATA状态中rx_valid变低立即进入DISCARD状态把FIFO清掉直到看到下一帧的前导码。接收链路做完后你在仿真里给输入一个完整的以太网帧收端状态机应该能正确输出MAC地址、EtherType、Payload到上层FIFO并且CRC标志为通过。这个仿真波形一定要亲眼看过再上板不然后面协议解析全是空中楼阁。3.4 发送状态机组帧、补零、插IFS发送方向和接收方向有些对称但有两个额外的重要细节补零和帧间隙。发送状态机首先要等待发送FIFO里有数据然后进入组帧流程先发7个0x55前导字节再发0xD5然后开始从发送FIFO读出目的MAC、源MAC、EtherType、Payload并逐个字节发送。同时这些字节要喂给发送CRC模块等到数据发完之后紧接着发送4字节的CRC结果。这里有个坑以太网规定数据帧长度至少是64字节不含前导和IFS也就是Payload如果短于46字节必须补零到46字节。很多初学者发一个短UDP包时CRC总是弹回来就是因为没补零。标准UDP无负载的包Payload只有8字节UDP头加上MAC和IP头也不够46字节所以发送状态机里要加一个数据长度判断不足46字节就往后补0。另一个细节是IFSInter Frame Gap即帧与帧之间的最小空隙。以太网要求两帧之间至少空出96 bit time换算成字节单位就是12字节。也就是说上一帧发完CRC后不能立刻发下一帧必须等至少12个字节的时间。我通常用一个计数器来实现发完CRC后进入IFS状态计数到12个发送时钟周期再回IDLE。如果忽略IFSPHY或者对端网卡可能把你发出去的所有帧当噪声处理现象就是单向完全不通。我自己写发送状态机时会把帧头和CRC发送部分都统一在一个主状态机里避免拆成多个小状态机导致状态混乱。代码结构上宁可状态多几个也不要打乱主流程。调试发送方向时可以在FPGA内部做一个“接收-发送回环”收到的帧直接丢给发送状态机发出去用PC抓包看能不能原样回来。这个测试能帮你把MAC层的收发链路独立验证好再去叠加协议逻辑。4. 自研精简协议栈ARP、ICMP到UDPMAC层打通以后FPGA已经能和PC在数据链路层对话了但PC的TCP/IP协议栈还不会理你。要让PC真正认同你这个设备还要在FPGA里面实现几个最小协议。这一章我把精简协议栈拆成ARP、ICMP、UDP三层来写每一层都能独立验证。4.1 为什么不要一上来就碰TCP很多人一听到“网络通信”就觉得必须做TCP但FPGA实现TCP的代价非常大需要维护连接状态、序列号、滑动窗口、超时重传、拥塞控制这基本就是一个简化版TCP状态机逻辑量不是初学者能短期搞定的。而UDP是无连接的只需要封装一个8字节的UDP头再配上IP头就能发送接收端也只要解析目的端口号就行逻辑量小一个数量级。绝大多数板级调试、数据采集、控制信号传输场景UDP的可靠性已经足够只要上层应用做好应答和重试即可。所以我做FPGA网络通信设计时内核选择是ARPICMPUDP。这样既能让PC认识你ARP又能被用户测试工具验证ICMP还能真正传业务数据UDP。等这套东西稳定了你才会理解TCP复杂的根源是什么再去啃TCP才有实际场景支撑。4.2 ARP应答先让电脑知道你在哪PC要往FPGA的IP地址发包首先得知道这个IP对应的MAC地址是什么于是PC会往局域网广播一个ARP请求谁的IP是192.168.1.10请把你的MAC告诉我。FPGA要做的事情就是收到这个请求后判断目标IP是不是自己如果是就回一个ARP应答包把自己的MAC地址填进去。ARP请求帧的EtherType是0x0806ARP数据部分长度为28字节其中最重要的是操作码字段请求是1应答是2。应答包的内容就是把请求包里的发送者MAC和IP与目标MAC和IP对调操作码改成2同时填充自己MAC作为发送者MAC目标MAC填成请求方的MAC。这里我推荐一个简化设计FPGA内部不需要维护完整的ARP表只需要记录最近一次收到的对方MAC和IP。因为PC在发任何IP包之前总会先广播ARP请求FPGA每次应答时就把请求方信息记录下来。之后要往PC发UDP时直接用这个记录下来的MAC地址作为目的MAC非常方便。ARP应答的实现可以做成一个独立小型状态机接收完成一帧后解析EtherType和操作码如果匹配ARP请求且目标IP是0xC0A8010A192.168.1.10则生成应答包写入发送FIFO。注意应答包的EtherType还是0x0806不是0x0800这个地方写错的话PC收到后根本不会交给IP协议栈处理。调试ARP时我习惯用Wireshark抓包。PC反复发送ARP请求而FPGA无应答多半是ARP应答状态机的目的MAC填错了或者IP比较错误。如果PC能通过ARP拿到FPGA的MACWireshark里就能看到一条完整的“ARP request - ARP reply”记录这是第一个要拿下的里程碑。4.3 ICMP与IP校验把ping通作为里程碑ARP通了以后下一步是让PC能够ping通FPGA。ping用的协议是ICMP报文封装在IP包里EtherType是0x0800IP头里的协议号是1。收到ICMP echo request类型8后要回一个ICMP echo reply类型0。这里你可能会想我只是把类型从8改成0再把校验和重算一下就行了吧网络确实是这样设计的。但有一个易错点ICMP校验和的计算范围是整个ICMP报文包括类型、代码、校验和字段算校验时置0以及后面的数据和填充计算方法是把所有16位字累加溢出回卷最后取反。通俗点说把原来收到的ICMP报文里类型改成0然后对整段用“16位都加起来超过FFFF就往低位加回去”这种方式求校验和。IP头本身的校验和也要处理。IPv4头部固定20字节它也有一个16位的头部校验和计算方法跟ICMP校验和一样。如果IP头校验和填错PC的协议栈会直接把这个包扔掉你抓包能看到ICMP reply已经发出来了但ping程序就是不通。这类问题在调ICMP时特别常见因为FPGA发的包已经进入网卡只是被协议栈上层丢弃了。我调试时用Wireshark观察过了这样一个过程FPGA发出了ICMP reply但PC ping超时后来单独把IP头的校验和和ICMP的校验和都核对了一遍才发现IP头校验和算错了一个字节。这里也建议大家拿一个Wireshark抓到的标准ICMP包用Python或者在线工具把校验和跑一遍对比你的Verilog计算结果确认无误再上板。如果ping通了你已经把IP层和ICMP层的关键逻辑跑通了PC的协议栈已经认可FPGA是一个正常的网络设备。这个里程碑对信心的提升非常大后续加UDP就是水到渠成的事情。4.4 UDP收发进入真正的数据传输UDP比ICMP简单一些只是多了端口号。UDP头8字节源端口2字节、目的端口2字节、长度2字节、校验和2字节。我做的简化实现里把UDP校验和直接置0因为UDP头如果不做计算接收方可以接受校验和为0的情况这样省掉一整块逻辑。接收方向MAC层把完整帧交给上层后先解析EtherType如果不是0x0800就丢弃。对IPv4包先看IP头协议号是不是17UDP再看看目的IP是不是本机IP如果是就继续解析UDP头根据目的端口把数据交给不同的应用模块。这时候你就已经拿到三个关键信息源MAC、源IP、源端口可以用于回发数据。发送方向我封装了一个简单的发送接口// 应用往发送模块写入数据指定目的IP和目的端口 // 模块自行封装 UDP头 IP头 MAC头生成完整帧这个发送模块内部会自动做以下几件事检查收到的目的IP是否就是刚才ARP学习到的对端IP如果是从ARP学习的MAC表里取目的MAC如果不是可以简单地把目的MAC填成FF:FF:FF:FF:FF:FF或者先通过ARP请求学习。我在最简系统里做了一个投机取巧的方式如果在ARP学习表里找不到对应条目就让发送模块直接丢弃并置一个错误标志应用层看到错误标志后可以自己决定重试。这套简化的逻辑对于学习完全够用。有了UDP收发你就可以做真正有用的实验PC端写一个Python脚本发一串数据到FPGA的某个端口FPGA把数据原样返回PC再打印收到的内容。这个回环程序是网络通信调试的“Hello World”它能同时验证接收、发送、协议封包三个环节。我建议大家先做纯回环再尝试在FPGA里把数据改成固定格式回发比如收到一帧就回一帧带计数的数据这样能直观看到FPGA逻辑确实在参与整个链路。5. 上板联调与问题排查实录前面每一章都在讲设计和实现这一章专门讲“出了问题怎么办”。我把自己的调试顺序、常见故障表、以及三个特别隐蔽的坑放在这里都是实际验证过的经验。5.1 我的调试顺序从link灯到PC端回显拿到一个新的网络通信工程我从不直接烧完整代码。我的顺序是这样的第一步观察PHY link灯。插网线如果灯不亮检查网线、PHY复位、供电、晶振。灯亮了说明物理层OK。第二步用MDIO读取PHY状态寄存器确认自动协商完成、link状态为up。这步可以在ILA里读返回。如果读不回来优先查MDIO时序和PHY地址。第三步烧一个RGMII回环逻辑把接收到的数据原样送到发送端也就是做一个“PHY收什么FPGA立刻发什么”的裸回环。PC端抓包应该能看到PC发出的包被原样弹回来。这个测试能验证PHY和RGMII接口收发都通。第四步把完整的MAC层和协议栈烧进去PC ping FPGA。如果ping通恭喜你已经拿下了FPGA网络通信设计的核心。第五步跑UDP回环脚本确认应用层数据通路。这套顺序的好处是每一步的失败都直接对应一个明确的范围。以前我喜欢把所有代码一次性烧上去结果出了问题根本不知道是PHY没配好、RGMII采样错、CRC算法错、还是ARP状态机错整整调了三天。后来改成这种渐进式调试“三板斧”加协议分层效率提高了很多。如果最后一步UDP回环失败优先去抓包看FPGA有没有发出ARP应答有没有发出ICMP replyUDP报文有没有离开FPGA抓包能看到每一层是否送达。PC端的网卡驱动力比较强有时甚至能在电脑已经识别异常的情况下继续收发包所以抓包结果比PC的提示更能说明问题。5.2 常见故障速查表我在做FPGA网络通信时把容易遇到的问题整理成了一个表给大家参考现象可能原因排查方法PC显示网络电缆未插入PHY未工作或网线问题查PHY复位、供电、link灯用直连网线MDIO读取寄存器全为FFPHY未初始化完成或MDIO时序不对延长复位后的延时核对MDC时序检查PHY地址抓包只有ARP请求无ARP应答ARP模块未匹配IP或状态机卡住ILA抓rx_valid和ARP状态确认IP比较值ping超时但Wireshark能看到ICMP replyIP头校验和或ICMP校验和错误用标准包对比校验和发送的数据在PC端乱码RGMII接口高低半字节拼反检查rx_h和rx_l的拼接顺序偶发丢包或丢帧FIFO溢出或跨时钟域没处理好加大FIFO深度检查读写时钟频率CRC校验一直失败初值、位序、取反或计算范围有误用Wireshark里的标准帧逐字节验证CRC短UDP包发不出去Payload不足46字节未补零发送状态机增加补零逻辑这张表并不是替代你思考而是告诉你问题的“高发区域”都在哪里。每次调试先看现象再对应排查能省下大量时间。5.3 三个特别隐蔽的坑最后分享三个我实际踩过、而且很隐蔽的坑希望能帮你少走弯路。第一个坑是PHY的RGMII时钟延迟问题。有些PHY芯片要求FPGA端对RX_CLK做一点相位偏移否则RGMII数据和时钟的建立保持时间不满足。如果你的开发板PHY没有内部延迟配置你会发现FPGA接收的数据“时好时坏”ILA抓包看起来明明有数据但解出来的字节总是错位。解决办法是查看PHY手册里关于RX Delay校准的说明或者用FPGA内部的IDELAY原语对数据或时钟做调整。如果板子的PHY自带delay模式要先把它打开。这个坑非常容易浪费一整天。第二个坑是法赫加粗校验的计算范围尤其是ARP包。做ARP应答时有些人把ARP的28字节数据也算进IP校验和结果完全不对。实际上ARP报文没有IP校验和它是直接封装在以太网帧里EtherType是0x0806。IP校验和只存在于IPv4包里而且只覆盖IP头。你在调试时如果发现ARP能通、IP包不通先想想是不是把不同协议的校验范围搞混了。第三个坑是IFS和发送间隔。FPGA发送多帧时如果帧间距小于12字节部分PC网卡会把后一帧视为错误包直接丢弃。很多初学者会怀疑自己的发送状态机发错了帧但实际只是IFS没做。我自己有一个习惯在发送状态机里把IFS计数器的值做成一个寄存器可以随时修改这样调试时不用重新综合直接改寄存器值就能测出来。同样的思路也适用于前导码字节数这样可以快速确认对端期待的标准值。做到这一步你手里已经有一套能稳定跑通的FPGA网络通信最小系统。我再结合个人体会说一句网络通信的难点并不在于Verilog代码本身而在于“你很难判断自己到底通没通”。网卡、PHY、FPGA、Wireshark这些环节互相配合稍有一点不对现象可能就是“超时”。所以养成用抓包和ILA交叉验证的习惯比记住任何代码都重要。后续不管是做高速数据采集、图像传输还是多板卡组网你都可以在这个框架上继续扩展底层这套链路仍然通用。
从零开始FPGA网络通信设计：RGMII、MAC与UDP协议栈实战
拿到一块带网口的FPGA开发板我最想干的一件事不是点灯玩而是让PC和FPGA之间能真正互发数据。听起来不就是往网口插根线嘛真做起来PHY、MAC、RGMII、ARP、UDP这一大串名词能把不少初学者直接劝退。这篇是“从近似0基础开始FPGA开发”系列的第七篇主要讲FPGA网络通信设计。看完并跟着走一遍之后你应该能具备这样的能力给板子上电插上网线PC端能ping通FPGA并且能够用UDP互相收发自定义数据。整个方案不依赖操作系统、不依赖软核CPU所有逻辑都在FPGA里面跑。这篇内容适合已经会写基本Verilog状态机、用过仿真工具、能独立完成一个简单工程的读者。如果你刚入门建议先把LED流水灯、按键消抖、UART收发这几个经典实验跑通再来啃网络会顺利很多。下面我按自己实际调试的思路来写尽量把每一步设计背后的原因、踩过的坑、以及能直接抄的代码框架都给你讲透。1. 先把整条网络通信链路看清楚做FPGA网络通信设计最容易犯的错是拿到例程直接烧结果电脑显示“网络电缆被拔出”或者“未识别的网络”然后又不知道从哪查起。这种问题的根子在于对整条链路没有全局认识。所以我建议动手写代码之前先花半小时把信号从网线到FPGA内部走一遍。从物理顺序来看网线上的模拟差分信号先到网络变压器一般集成在RJ45座子里经过电平转换后进PHY芯片PHY负责把模拟信号恢复成数字逻辑电平然后通过接口把数据交给FPGA。FPGA这边要做的事情有两类一类是MAC层负责识别以太网帧、生成CRC校验、添加或解析前导码另一类是上层协议例如ARP、ICMP、UDP负责让PC和FPGA之间在逻辑上“对话”。简单说PHY管物理层FPGA管数据链路层和网络层你要写的代码主要在FPGA侧。这条链路我可以再类比一下。PHY有点像电话线路的调制解调器它只负责把声波和比特之间互相转换不管你说的是什么语言FPGA里写的协议栈则是通信双方约定的“语言”只有语言一致对方才听得懂。所以调试的时候如果电脑ping不通你至少要能判断是哪一层出了问题——是物理层没起来还是MAC层CRC全错还是协议包头没拼对这个判断能力比背代码重要得多。1.1 三条路线我为什么选了最“笨”的一条很多初学者会去网上找例程结果发现FPGA做网络通信大致有三条路线。第一条是用Xilinx或Intel的专用Ethernet MAC IP核配一个外部PHY然后上层自己写协议。这种方案最“正规”但问题在于IP核内部细节被封装得很严实对新手来说像黑盒子出问题很难排查。第二条是用软核处理器比如MicroBlaze、NIOS II里面跑一个网络协议栈说白了就是用C语言写网络程序FPGA只是跑了一个CPU这对理解FPGA逻辑没有太大帮助。第三条是完全用Verilog自研一个精简MAC和精简协议栈外部PHY自己驱动帧结构自己拼CRC自己算。我最推荐的是第三条路也是我自己实践时用的方案。虽然听起来工作量最大但对学习的收益最高而且调试起来反而更可控因为每一段逻辑都是你自己写的出了错你能靠仿真和抓包快速定位。如果目标是产品化你当然可以用IP核或者软核可如果目标是弄懂FPGA网络通信设计到底怎么回事就必须自己亲手把每一层做一遍。那是不是要把完整的TCP/IP协议栈全写一遍完全不用。我们的目标是PC和FPGA通信不是让FPGA跑一个网页服务器所以只需要实现最小可用的子集ARP应答、ICMP回显也就是ping、UDP收发。这个组合足够覆盖绝大多数实验和项目需求而且逻辑量不大状态机也不复杂——如果你已经写过UART收发这部分代码量大约也就再增加三四百行。1.2 顶层架构一个最小可工作的网络通信系统需要哪些模块动手写代码之前我习惯先在纸上画一个框图明确模块边界和时钟域。否则写着写着数据流和时钟混在一起状态机很容易乱。对于这套最小系统我划分成了这些模块模块作用所在时钟域时钟管理MMCM/PLL产生125MHz、25MHz等时钟全局RGMII接口把PHY送来的4bit数据合并成8bit把要发送的8bit拆成4bit送出125MHz/25MHz接收FIFO跨时钟域缓冲给协议处理逻辑一个稳定的数据口125MHz - 100MHzMAC帧解析/组帧负责剥掉前导码、校验CRC、处理长度100MHzARP/ICMP/UDP处理识别并回应协议报文100MHz发送FIFO跨时钟域缓冲等待发送的报文100MHz - 125MHz为什么这里有两个时钟域PHY提供的接收时钟是125MHz千兆模式或25MHz百兆模式而协议逻辑最好跑在一个独立时钟上比如板载100MHz晶振经过MMCM出来这样后端的控制逻辑不会被PHY的时钟牵着走。两个时钟域之间用异步FIFO来衔接这是FPGA跨时钟域的常规做法。这里我要给新手一个非常朴素的建议不要试图一开始就做一个大而全的架构。先把RGMII接口和收包FIFO做通再逐步加上CRC校验、ARP应答、ICMP、UDP。每加一层都拿到板子上实测一次。一次集成太多模块出了问题你根本不知道是该查PHY配置、查时序还是查协议状态机。1.3 选型清单与目标设定我手上的开发板用的FPGA是Xilinx Artix-7系列板载PHY是瑞昱的RTL8211EG网口支持千兆接口正好是RGMII。这套组合非常典型很多开发板都类似如果你的板子用的是其他PHY比如百兆的LAN8720或国产PHY驱动思路也差不多区别主要在于MDIO寄存器地址和配置值所以要养成翻原理图和PHY数据手册的习惯。初始目标我设为三步。第一步PHY能link up至少能让PC端识别到网线已插入第二步FPGA能够正确响应ARP请求PC能看到FPGA的MAC地址第三步PC能ping通FPGA同时能通过UDP发送和接收数据。把这三步作为里程碑每个里程碑完成一张自检清单你会发现网络通信设计并没有想象中那么神秘。我自己在实际开发中还会固定一批参数FPGA的MAC地址设为D4:BE:D9:01:23:45随便选一个非广播的私用MAC不要和局域网内设备冲突即可IP地址固定为192.168.1.10PC端固定192.168.1.2子网掩码255.255.255.0不用设置网关。这套配置用网线直连不经过路由器能减少很多干扰。下面所有调试场景都基于这个环境。2. 硬件侧的功课RGMII时序与PHY配置FPGA网络通信设计的第一个门槛不是你写了多少协议逻辑而是RGMII接口能不能稳定收到数据。很多初学朋友在协议层折腾半天最后发现根源是RGMII时钟采样不对所有数据都是错位的。所以这一章我们先把硬件侧的细节吃透。2.1 从网口到FPGA信号到底经过哪些环节板子上的RJ45座子连着一个网络变压器变压器和PHY芯片之间是差分信号线PHY芯片再通过RGMII接口接到FPGA上。FPGA引脚出来就是普通的单端3.3V或1.8V信号一般包括TX_CLK发送时钟、TXD[3:0]发送数据、TX_CTL发送控制RX_CLK接收时钟、RXD[3:0]接收数据、RX_CTL接收控制MDC、MDIO用于配置PHY寄存器以及PHY复位引脚新手最容易误解的一点FPGA并不直接去处理网线上的差分信号和编码。千兆的编码、时钟恢复、自动协商这些脏活累活都由PHY芯片做了FPGA只是通过RGMII接口拿到已经恢复好的数字信号。所以如果你的PC上显示“网络电缆被拔出”问题大概率在PHY供电、复位、晶振或者网络变压器周边电路而不是FPGA逻辑。这里有一个判断技巧观察板载PHY的link指示灯。如果插上质量没问题的网线后link灯不亮或闪烁不停说明PHY工作不正常先查硬件。只有灯能够常亮才值得你继续调FPGA逻辑。这个顺序搞反的人特别多我曾经以为FPGA代码写错了硬是调了一个下午结果发现是网线是交叉线后来换了一根直连线立马link up。2.2 读懂RGMII接口的收发时序RGMII全称是Reduced Gigabit Media Independent Interface它最核心的特点是用DDR方式在时钟的上升沿和下降沿都采样数据。千兆模式下时钟是125MHz4根数据线加上双沿采样等效成为8bit数据x125MHz1Gbps百兆模式下时钟是25MHz带宽就是100Mbps。先看发送方向。FPGA作为发送端要把8bit数据拆成两个4bit在TX_CLK上升沿发送低4位TXD[3:0]同时TX_CTL表示发送使能在TX_CLK下降沿发送高4位TXD[7:4]同时TX_CTL上要额外编码一个TX_ER信号。不过在我们做全双工以太网的场景里TX_ER通常不用所以简化处理下降沿的TX_CTL保持和上升沿一样即可。接收方向反过来。PHY在RX_CLK的上升沿把低4位放在RXD[3:0]上在下降沿把高4位放在RXD[3:0]上RX_CTL同理。FPGA要做的是在两个沿分别采样再把两个半字节拼成一个字节。代码框架大概是这样// 接收RX_CLK上升沿采低4位 always (posedge rx_clk or negedge rst_n) begin if (!rst_n) begin rx_l 4d0; rxdv_l 1b0; end else begin rx_l rxd; rxdv_l rxdv; end end // 接收RX_CLK下降沿采高4位 always (negedge rx_clk or negedge rst_n) begin if (!rst_n) begin rx_h 4d0; rxdv_h 1b0; end else begin rx_h rxd; rxdv_h rxdv; end end assign rx_data8 {rx_h, rx_l}; // 拼成8bit assign rx_valid rxdv_l; // 数据有效标志不过实际工程里从下降沿采集的rx_h要先打两拍同步一下再和上升沿采集的rx_l合在一起否则两个半字节的时序可能错位。这个细节在很多教程里看不到但是上板调试时非常关键。如果发现收到的数据是乱序的可以先在这里找原因。发送方向也有类似问题我一般用ODDR原语或者直接调用厂商的DDR输出模块代码不多但能保证时序稳定。2.3 用MDIO接口把PHY调到“准备好”状态PHY芯片不是上电就能直接用的它内部有几十个寄存器需要通过MDIO接口读写。MDIO本质上是一个两线串行接口MDC是时钟MDIO是双向数据线协议格式类似SPI先发32位前导再发寄存器地址和读写标志最后收发16位数据。读PHY寄存器时PHY地址和寄存器地址由FPGA指定数据是PHY返回的写寄存器时数据是FPGA给PHY的。RTL8211EG的PHY地址一般可以在原理图上看到常见是0x01。如果你不确定可以连续读多个地址看哪个地址的ID寄存器能读出非0值。这里我给大家一个初始化流程拉低PHY复位引脚至少20ms然后拉高释放复位。等待至少100ms让PHY内部PLL稳定下来。读寄存器0基本控制寄存器确认bit15自动协商使能是否有值。如果不需要自动协商就直接写寄存器0为0x1000把PHY配置为1000M全双工模式。这样最可控。反复读寄存器1基本状态寄存器直到bit2为1表示链路已经link up。寄存器1的bit2就是链路状态位这个位为1的时候说明PHY已经和对面网卡协商成功此时网线插上后PC端的“网络电缆已拔出”提示就会消失。我把这个寄存器读回当成“网络初始化完成”的标志状态机里要等这个bit为1再启动接收逻辑。做MDIO控制状态机的时候我通常是先做一个功能简单的MDIO读写模块提供两个接口信号寄存器地址、读写数据、使能。上层通过控制这个模块来读写PHY。没有必要为每款PHY都重新学一遍协议因为MDIO帧结构是IEEE标准定义的各家PHY通用只是寄存器含义略有差异。2.4 时钟和复位最容易在板子上翻车的两个点我调试网络通信时花在时钟和复位上的时间比写协议还多。RGMII接口里面至少有两个时钟域在交互PHY提供的RX_CLK是接收时钟域FPGA本地产生的发送时钟是发送时钟域。如果你把RX_CLK直接拿去驱动协议状态机那协议逻辑就跟着PHY的参考时钟走了前端接收和后端处理都挤在一起后面加FIFO跨时钟域会很痛苦。我的做法是本地用一个MMCM从板载100MHz晶振产生一组干净时钟比如100MHz和125MHz。100MHz给协议处理逻辑用125MHz给RGMII发送时钟用。PHY接收部分的RGMII接口仍跑在RX_CLK上但数据在进入协议逻辑之前必须先进入异步FIFO做缓冲。这样协议逻辑始终只面对一个时钟逻辑更容易收敛时序约束也好写。复位方面很多板子的PHY模块是独立电源域复位时序比普通外设敏感。如果复位释放太快PHY内部还没完成初始校准后面链路就起不来。我踩过的坑是上电后FPGA复位释放后立刻去读PHY寄存器读回的全是0xFFFF后来加了延时等PHY初始化完成后再操作问题就消失了。建议在FPGA里做一个简单的上电复位计数器至少延时200ms再去初始化PHY。时钟复位都处理好了你再用ILAVivado逻辑分析仪抓RX_CLK和RXD波形应该和RGMII协议手册里的时序基本吻合。这一步通了后面MAC层协议才有意义。3. 单帧通信的地基MAC层与CRC32PHY把你的数据从网线“搬运”到了FPGA内部但FPGA收到的只是一串数据流这一章就开始处理串数据流里最有技术含量的部分识别以太网帧、校验CRC、组装发送帧。3.1 以太网帧的“翻译表”以太网帧有一定的固定格式FPGA要做的事情很简单按照格式把数据流拆开或者把数据装进去。一个标准的以太网帧组成如下字段长度说明前导码7字节每个字节为0x55用于收发时钟同步帧起始定界符1字节0xD5表示后面是真正的帧目的MAC6字节对方网卡的MAC地址源MAC6字节发送方自己的MAC地址EtherType2字节0x0806是ARP0x0800是IPv4Payload46~1500字节上层数据太短要补零FCS4字节对源MAC开始的整帧做CRC32得到的校验值接收方向前导码和SFD不是有效帧内容必须去掉。后面从目的MAC到Payload才是真正交给协议层处理的帧数据。发送方向则相反需要在数据前加上前导码和SFD数据不足46字节要补零到46字节最后追加4字节CRC。新手常犯的一个错误是把前导码也当成数据存进FIFO。这样上层协议在解析目的MAC时就会错位一个字节后面ARP、IP、UDP全部解析错误。我调试时抓包看到ARP请求一直接收不正常排查到最后才发现是前导码没剔除。还有个容易混淆的点是字节顺序。以太网帧里的MAC地址、IP地址、UDP端口都是按“高字节先发”的网络字节序。比如MAC地址D4:BE:D9:01:23:45在线上先看到D4再是BE。CRC算法则不同它是位流处理的字节内按LSB-first。这两个顺序的问题是网络协议实现最容易吃苦头的地方后面我会单独讲。3.2 CRC32起来复杂抓住三个关键点以太网FCS使用的是CRC32算法对从目的MAC到Payload结束的所有字节求校验值。某些初学者看到CRC就发怵其实以太网CRC32只需要抓住三个关键点第一多项式是0x04C11DB7。第二初始值是0xFFFFFFFF。第三输入数据每个字节按LSB-first方式送入算法也就是每个字节最低位先参与计算这一点和通常的字节流顺序不同。最后得到的32位结果要按位取反才是FCS字段。如果你用Verilog从零写并行CRC会比较枯燥。比较省事的方法是直接用Vivado的CRC Generator IP核配置CRC多项式为0x04C11DB7初始值为0xFFFFFFFF输入输出位序选LSB-first异或输出选0xFFFFFFFF数据宽度设8bit时钟数是字节数。这样每进来一个字节就能得到当前累计CRC值。这个IP核的延迟是固定节拍时序好约束也容易仿真比你自己写要靠谱很多。验证CRC是否写对有个特别实用的办法用Wireshark抓一个PC发出的标准ICMP包把源MAC、目的MAC、EtherType、IP头、ICMP数据全部提取出来喂给你自己的CRC计算模块算出来的4字节应该和这个帧的FCS一致。如果一致说明你的CRC算法、位序、字节序全部正确。在我没做这个验证之前CRC错误率接近百分之百。需要特别记住CRC的计算范围是源MAC开始到Payload结束不包括前导码和SFD。发送端在发完数据后再接着发送计算出的4字节CRC接收端读到FCS后要把自己累计的CRC和收到的FCS比较。如果发现CRC不对这帧就应该直接丢弃不能交给上层。3.3 接收状态机一帧数据是怎么被“拆”出来的接收方向的核心是一个状态机。为了可靠地拆出帧我会把FIFO写使能、帧长计数、CRC计算都放在同一个状态机里保证它们节拍一致。最基本的状态定义是localparam S_IDLE 3d0; localparam S_PREAMBLE 3d1; localparam S_DATA 3d2; localparam S_FCS 3d3; localparam S_DISCARD 3d4;IDLE状态等待rx_valid拉高。rx_valid拉高后进入PREAMBLE状态连续跳过7个0x55和1个0xD5。从SFD之后第一个字节开始进入DATA状态。DATA状态下每个节拍都把数据写入接收FIFO同时把字节送入CRC计算模块并累加帧长计数。当帧长计数等于目标长度时进入FCS状态连续收4个FCS字节和自己的CRC值比对。比对通过后这一帧才算完整接收成功。如果收到的帧长小于64字节这种叫做RUNT帧按照标准可以直接丢弃如果帧长超过1518字节属于超长帧也建议丢弃。这两种情况我在接收状态机里都会统一进入DISCARD状态清空FIFO再回到IDLE。写接收状态机容易踩的一个坑是在DATA状态中rx_valid可能中途拉低这种半截帧必须丢弃。很多例程不处理这种情况导致后面解析出完全不合理的协议头。我的做法是如果DATA状态中rx_valid变低立即进入DISCARD状态把FIFO清掉直到看到下一帧的前导码。接收链路做完后你在仿真里给输入一个完整的以太网帧收端状态机应该能正确输出MAC地址、EtherType、Payload到上层FIFO并且CRC标志为通过。这个仿真波形一定要亲眼看过再上板不然后面协议解析全是空中楼阁。3.4 发送状态机组帧、补零、插IFS发送方向和接收方向有些对称但有两个额外的重要细节补零和帧间隙。发送状态机首先要等待发送FIFO里有数据然后进入组帧流程先发7个0x55前导字节再发0xD5然后开始从发送FIFO读出目的MAC、源MAC、EtherType、Payload并逐个字节发送。同时这些字节要喂给发送CRC模块等到数据发完之后紧接着发送4字节的CRC结果。这里有个坑以太网规定数据帧长度至少是64字节不含前导和IFS也就是Payload如果短于46字节必须补零到46字节。很多初学者发一个短UDP包时CRC总是弹回来就是因为没补零。标准UDP无负载的包Payload只有8字节UDP头加上MAC和IP头也不够46字节所以发送状态机里要加一个数据长度判断不足46字节就往后补0。另一个细节是IFSInter Frame Gap即帧与帧之间的最小空隙。以太网要求两帧之间至少空出96 bit time换算成字节单位就是12字节。也就是说上一帧发完CRC后不能立刻发下一帧必须等至少12个字节的时间。我通常用一个计数器来实现发完CRC后进入IFS状态计数到12个发送时钟周期再回IDLE。如果忽略IFSPHY或者对端网卡可能把你发出去的所有帧当噪声处理现象就是单向完全不通。我自己写发送状态机时会把帧头和CRC发送部分都统一在一个主状态机里避免拆成多个小状态机导致状态混乱。代码结构上宁可状态多几个也不要打乱主流程。调试发送方向时可以在FPGA内部做一个“接收-发送回环”收到的帧直接丢给发送状态机发出去用PC抓包看能不能原样回来。这个测试能帮你把MAC层的收发链路独立验证好再去叠加协议逻辑。4. 自研精简协议栈ARP、ICMP到UDPMAC层打通以后FPGA已经能和PC在数据链路层对话了但PC的TCP/IP协议栈还不会理你。要让PC真正认同你这个设备还要在FPGA里面实现几个最小协议。这一章我把精简协议栈拆成ARP、ICMP、UDP三层来写每一层都能独立验证。4.1 为什么不要一上来就碰TCP很多人一听到“网络通信”就觉得必须做TCP但FPGA实现TCP的代价非常大需要维护连接状态、序列号、滑动窗口、超时重传、拥塞控制这基本就是一个简化版TCP状态机逻辑量不是初学者能短期搞定的。而UDP是无连接的只需要封装一个8字节的UDP头再配上IP头就能发送接收端也只要解析目的端口号就行逻辑量小一个数量级。绝大多数板级调试、数据采集、控制信号传输场景UDP的可靠性已经足够只要上层应用做好应答和重试即可。所以我做FPGA网络通信设计时内核选择是ARPICMPUDP。这样既能让PC认识你ARP又能被用户测试工具验证ICMP还能真正传业务数据UDP。等这套东西稳定了你才会理解TCP复杂的根源是什么再去啃TCP才有实际场景支撑。4.2 ARP应答先让电脑知道你在哪PC要往FPGA的IP地址发包首先得知道这个IP对应的MAC地址是什么于是PC会往局域网广播一个ARP请求谁的IP是192.168.1.10请把你的MAC告诉我。FPGA要做的事情就是收到这个请求后判断目标IP是不是自己如果是就回一个ARP应答包把自己的MAC地址填进去。ARP请求帧的EtherType是0x0806ARP数据部分长度为28字节其中最重要的是操作码字段请求是1应答是2。应答包的内容就是把请求包里的发送者MAC和IP与目标MAC和IP对调操作码改成2同时填充自己MAC作为发送者MAC目标MAC填成请求方的MAC。这里我推荐一个简化设计FPGA内部不需要维护完整的ARP表只需要记录最近一次收到的对方MAC和IP。因为PC在发任何IP包之前总会先广播ARP请求FPGA每次应答时就把请求方信息记录下来。之后要往PC发UDP时直接用这个记录下来的MAC地址作为目的MAC非常方便。ARP应答的实现可以做成一个独立小型状态机接收完成一帧后解析EtherType和操作码如果匹配ARP请求且目标IP是0xC0A8010A192.168.1.10则生成应答包写入发送FIFO。注意应答包的EtherType还是0x0806不是0x0800这个地方写错的话PC收到后根本不会交给IP协议栈处理。调试ARP时我习惯用Wireshark抓包。PC反复发送ARP请求而FPGA无应答多半是ARP应答状态机的目的MAC填错了或者IP比较错误。如果PC能通过ARP拿到FPGA的MACWireshark里就能看到一条完整的“ARP request - ARP reply”记录这是第一个要拿下的里程碑。4.3 ICMP与IP校验把ping通作为里程碑ARP通了以后下一步是让PC能够ping通FPGA。ping用的协议是ICMP报文封装在IP包里EtherType是0x0800IP头里的协议号是1。收到ICMP echo request类型8后要回一个ICMP echo reply类型0。这里你可能会想我只是把类型从8改成0再把校验和重算一下就行了吧网络确实是这样设计的。但有一个易错点ICMP校验和的计算范围是整个ICMP报文包括类型、代码、校验和字段算校验时置0以及后面的数据和填充计算方法是把所有16位字累加溢出回卷最后取反。通俗点说把原来收到的ICMP报文里类型改成0然后对整段用“16位都加起来超过FFFF就往低位加回去”这种方式求校验和。IP头本身的校验和也要处理。IPv4头部固定20字节它也有一个16位的头部校验和计算方法跟ICMP校验和一样。如果IP头校验和填错PC的协议栈会直接把这个包扔掉你抓包能看到ICMP reply已经发出来了但ping程序就是不通。这类问题在调ICMP时特别常见因为FPGA发的包已经进入网卡只是被协议栈上层丢弃了。我调试时用Wireshark观察过了这样一个过程FPGA发出了ICMP reply但PC ping超时后来单独把IP头的校验和和ICMP的校验和都核对了一遍才发现IP头校验和算错了一个字节。这里也建议大家拿一个Wireshark抓到的标准ICMP包用Python或者在线工具把校验和跑一遍对比你的Verilog计算结果确认无误再上板。如果ping通了你已经把IP层和ICMP层的关键逻辑跑通了PC的协议栈已经认可FPGA是一个正常的网络设备。这个里程碑对信心的提升非常大后续加UDP就是水到渠成的事情。4.4 UDP收发进入真正的数据传输UDP比ICMP简单一些只是多了端口号。UDP头8字节源端口2字节、目的端口2字节、长度2字节、校验和2字节。我做的简化实现里把UDP校验和直接置0因为UDP头如果不做计算接收方可以接受校验和为0的情况这样省掉一整块逻辑。接收方向MAC层把完整帧交给上层后先解析EtherType如果不是0x0800就丢弃。对IPv4包先看IP头协议号是不是17UDP再看看目的IP是不是本机IP如果是就继续解析UDP头根据目的端口把数据交给不同的应用模块。这时候你就已经拿到三个关键信息源MAC、源IP、源端口可以用于回发数据。发送方向我封装了一个简单的发送接口// 应用往发送模块写入数据指定目的IP和目的端口 // 模块自行封装 UDP头 IP头 MAC头生成完整帧这个发送模块内部会自动做以下几件事检查收到的目的IP是否就是刚才ARP学习到的对端IP如果是从ARP学习的MAC表里取目的MAC如果不是可以简单地把目的MAC填成FF:FF:FF:FF:FF:FF或者先通过ARP请求学习。我在最简系统里做了一个投机取巧的方式如果在ARP学习表里找不到对应条目就让发送模块直接丢弃并置一个错误标志应用层看到错误标志后可以自己决定重试。这套简化的逻辑对于学习完全够用。有了UDP收发你就可以做真正有用的实验PC端写一个Python脚本发一串数据到FPGA的某个端口FPGA把数据原样返回PC再打印收到的内容。这个回环程序是网络通信调试的“Hello World”它能同时验证接收、发送、协议封包三个环节。我建议大家先做纯回环再尝试在FPGA里把数据改成固定格式回发比如收到一帧就回一帧带计数的数据这样能直观看到FPGA逻辑确实在参与整个链路。5. 上板联调与问题排查实录前面每一章都在讲设计和实现这一章专门讲“出了问题怎么办”。我把自己的调试顺序、常见故障表、以及三个特别隐蔽的坑放在这里都是实际验证过的经验。5.1 我的调试顺序从link灯到PC端回显拿到一个新的网络通信工程我从不直接烧完整代码。我的顺序是这样的第一步观察PHY link灯。插网线如果灯不亮检查网线、PHY复位、供电、晶振。灯亮了说明物理层OK。第二步用MDIO读取PHY状态寄存器确认自动协商完成、link状态为up。这步可以在ILA里读返回。如果读不回来优先查MDIO时序和PHY地址。第三步烧一个RGMII回环逻辑把接收到的数据原样送到发送端也就是做一个“PHY收什么FPGA立刻发什么”的裸回环。PC端抓包应该能看到PC发出的包被原样弹回来。这个测试能验证PHY和RGMII接口收发都通。第四步把完整的MAC层和协议栈烧进去PC ping FPGA。如果ping通恭喜你已经拿下了FPGA网络通信设计的核心。第五步跑UDP回环脚本确认应用层数据通路。这套顺序的好处是每一步的失败都直接对应一个明确的范围。以前我喜欢把所有代码一次性烧上去结果出了问题根本不知道是PHY没配好、RGMII采样错、CRC算法错、还是ARP状态机错整整调了三天。后来改成这种渐进式调试“三板斧”加协议分层效率提高了很多。如果最后一步UDP回环失败优先去抓包看FPGA有没有发出ARP应答有没有发出ICMP replyUDP报文有没有离开FPGA抓包能看到每一层是否送达。PC端的网卡驱动力比较强有时甚至能在电脑已经识别异常的情况下继续收发包所以抓包结果比PC的提示更能说明问题。5.2 常见故障速查表我在做FPGA网络通信时把容易遇到的问题整理成了一个表给大家参考现象可能原因排查方法PC显示网络电缆未插入PHY未工作或网线问题查PHY复位、供电、link灯用直连网线MDIO读取寄存器全为FFPHY未初始化完成或MDIO时序不对延长复位后的延时核对MDC时序检查PHY地址抓包只有ARP请求无ARP应答ARP模块未匹配IP或状态机卡住ILA抓rx_valid和ARP状态确认IP比较值ping超时但Wireshark能看到ICMP replyIP头校验和或ICMP校验和错误用标准包对比校验和发送的数据在PC端乱码RGMII接口高低半字节拼反检查rx_h和rx_l的拼接顺序偶发丢包或丢帧FIFO溢出或跨时钟域没处理好加大FIFO深度检查读写时钟频率CRC校验一直失败初值、位序、取反或计算范围有误用Wireshark里的标准帧逐字节验证CRC短UDP包发不出去Payload不足46字节未补零发送状态机增加补零逻辑这张表并不是替代你思考而是告诉你问题的“高发区域”都在哪里。每次调试先看现象再对应排查能省下大量时间。5.3 三个特别隐蔽的坑最后分享三个我实际踩过、而且很隐蔽的坑希望能帮你少走弯路。第一个坑是PHY的RGMII时钟延迟问题。有些PHY芯片要求FPGA端对RX_CLK做一点相位偏移否则RGMII数据和时钟的建立保持时间不满足。如果你的开发板PHY没有内部延迟配置你会发现FPGA接收的数据“时好时坏”ILA抓包看起来明明有数据但解出来的字节总是错位。解决办法是查看PHY手册里关于RX Delay校准的说明或者用FPGA内部的IDELAY原语对数据或时钟做调整。如果板子的PHY自带delay模式要先把它打开。这个坑非常容易浪费一整天。第二个坑是法赫加粗校验的计算范围尤其是ARP包。做ARP应答时有些人把ARP的28字节数据也算进IP校验和结果完全不对。实际上ARP报文没有IP校验和它是直接封装在以太网帧里EtherType是0x0806。IP校验和只存在于IPv4包里而且只覆盖IP头。你在调试时如果发现ARP能通、IP包不通先想想是不是把不同协议的校验范围搞混了。第三个坑是IFS和发送间隔。FPGA发送多帧时如果帧间距小于12字节部分PC网卡会把后一帧视为错误包直接丢弃。很多初学者会怀疑自己的发送状态机发错了帧但实际只是IFS没做。我自己有一个习惯在发送状态机里把IFS计数器的值做成一个寄存器可以随时修改这样调试时不用重新综合直接改寄存器值就能测出来。同样的思路也适用于前导码字节数这样可以快速确认对端期待的标准值。做到这一步你手里已经有一套能稳定跑通的FPGA网络通信最小系统。我再结合个人体会说一句网络通信的难点并不在于Verilog代码本身而在于“你很难判断自己到底通没通”。网卡、PHY、FPGA、Wireshark这些环节互相配合稍有一点不对现象可能就是“超时”。所以养成用抓包和ILA交叉验证的习惯比记住任何代码都重要。后续不管是做高速数据采集、图像传输还是多板卡组网你都可以在这个框架上继续扩展底层这套链路仍然通用。
