企业官网建设流程全解析

1. 为什么UDP模块是FPGA网络开发的“第一道真实门槛”

很多人学FPGA，从点灯、按键、数码管开始，一路走到UART、SPI、I2C，甚至能用AXI总线挂个DMA搬数据——但一碰网络，尤其是UDP，立刻卡住。不是不会写Verilog，而是根本不知道该从哪下手：MAC层怎么接？ARP要不要自己做？IP头校验和怎么算？UDP校验和要不要填？收到包后怎么判断是发给自己的？更现实的问题是：你连一个能被PC ping通的IP地址都配不上去，Wireshark抓到的全是“Destination unreachable”或者干脆没反应。

我带过二十多个FPGA初学者项目，几乎所有人在这个节点上都会花掉2~3周时间反复改代码、调时序、查手册，最后发现不是逻辑写错了，而是对整个以太网协议栈的理解存在断层——他们把UDP当成一个“函数调用”，以为只要把数据塞进去、端口号填对，就能发出去；但FPGA里没有操作系统帮你封装底层细节，每一个字节都要你亲手拼、每一帧都要你亲自校验、每一个状态都要你明确控制。UDP模块不是孤立的代码块，它是FPGA接入真实网络世界的“物理接口+逻辑协议+时序边界”的三重融合体。

这个part.8之所以叫“从近似0基础开始”，是因为它不预设你懂TCP/IP分层模型，也不假设你熟悉Xilinx GMII或Intel Avalon-ST接口规范。我们从最原始的“以太网帧结构”开始拆解，用纯组合逻辑+有限状态机（FSM）实现最小可行UDP收发通路，所有代码可直接在Xilinx Artix-7（如Basys3）、Intel Cyclone IV（如DE0-Nano）上综合通过，资源占用控制在2000 LUT以内。重点不是炫技，而是让你看清：当一个UDP数据包从网线进来，经过PHY芯片、MAC核、IP层、UDP层，最终落到你的用户逻辑里，中间每一步发生了什么、谁在负责、哪些可以裁剪、哪些必须保留。比如，很多教程直接调用Vivado里的AXI Ethernet Subsystem IP核，结果一出问题就束手无策——因为你根本不知道IP核内部的RX FIFO深度是多少、ARP缓存条目怎么刷新、UDP校验和计算是在MAC前还是IP后完成。而本篇的设计，全部裸写，不依赖任何黑盒IP，所有信号流向、时序约束、跨时钟域处理都摊开讲透。

核心关键词“FPGA”“UDP”“代码设计”在这里不是并列关系，而是因果链：FPGA的并行性与确定性决定了UDP必须用硬件思维重写，而不是软件思维移植；UDP的无连接、轻量级特性恰恰匹配FPGA资源受限但实时性要求高的场景；而“代码设计”不是指语法正确，而是指状态机划分是否合理、数据路径是否避免锁存器、校验和计算是否满足时序余量、错误包丢弃策略是否防止FIFO溢出。后面你会看到，一个看似简单的“收到UDP包就点亮LED”，背后要处理至少7种异常状态：帧长不足46字节、FCS校验失败、IP版本非4、TTL=0、IP校验和错、UDP长度字段超限、目的端口不匹配——这些在Linux socket里被内核自动过滤的细节，在FPGA里全得你自己判、自己清、自己防。

2. UDP模块的整体架构设计与取舍逻辑

2.1 为什么放弃“完整协议栈”，选择“最小可行通路”

市面上很多FPGA UDP方案直接集成LiteEth、OpenCores的ethmac或Xilinx官方的Tri-Mode Ethernet MAC，动辄上万LUT，还带ARP、ICMP、TCP等冗余功能。但对初学者而言，这就像让刚学会握笔的人直接临摹《兰亭序》——字形结构没搞清，先被笔锋顿挫吓退。我们反其道而行之，构建一条“仅支持单播、固定IP/MAC、无ARP、UDP校验和可选”的极简通路，目标明确：让FPGA能稳定收发UDP包，且每个字节的来源和去向都可追溯、可调试、可修改。

这条通路包含5个核心层级（自底向上）：

• PHY接口层：对接标准RGMII（Reduced Gigabit Media Independent Interface），处理时钟域转换（TX_CLK/RX_CLK与系统主时钟异步）、数据对齐（nibble-aligned）、控制信号同步（rx_dv, tx_en）；
• MAC接收/发送引擎：解析/生成以太网帧（Preamble+SFD+DA+SA+Type+Payload+FCS），剥离FCS校验，提取有效载荷；
• IP层精简器：仅验证IPv4头部（Version=4, IHL≥5, TTL>0, Protocol=17），跳过分片重组、选项字段、TOS处理，直接提取UDP段；
• UDP层控制器：校验UDP长度字段（≥8）、计算/验证UDP校验和（可配置开关）、比对目的端口（硬编码为0x1234）；
• 用户接口层：提供AXI-Stream风格的valid/ready握手信号，将净荷数据流送入后续逻辑（如图像缓存、ADC采样缓冲区）。

这个架构的取舍依据非常实际：

• 去掉ARP：因为初学者实验环境通常是静态IP直连PC，用arp -s 192.168.1.100 00-11-22-33-44-55手动绑定MAC即可，省下200+ LUT和复杂状态机；
• 禁用IP分片：UDP本身不保证可靠传输，分片重组需要大容量RAM和复杂指针管理，而实际工业场景中UDP包长通常≤1472字节（MTU=1500-20IP-8UDP），直接丢弃超长包更安全；
• UDP校验和可选：RFC 768允许校验和为0（表示不校验），我们在调试阶段默认关闭，待通路稳定后再开启验证，避免因校验和计算错误导致包被静默丢弃；
• 固定MAC/IP：不实现DHCP客户端，所有地址在顶层模块例化时参数化（parameter MAC_ADDR = {48{1'b0}}），杜绝地址冲突和配置错误。

提示：这种“阉割式设计”不是偷懒，而是工程化思维的体现。FPGA资源永远紧张，而调试时间成本远高于逻辑资源成本。当你能用2000 LUT跑通UDP，再逐步添加ARP、ICMP echo reply、多端口监听时，每个新增模块的调试范围都是可控的。反之，若一开始堆砌全套协议栈，一个FCS校验失败可能牵扯PHY驱动、时钟同步、FIFO读写三个模块，根本无法定位。

2.2 状态机设计：为什么用两级FSM而非单一大状态机

UDP收发涉及多个时序敏感操作：RGMII接收需在RX_CLK上升沿采样，MAC帧解析需按字节流顺序识别SFD（0xD5），IP头校验和计算需跨4字节累加，UDP校验和需伪首部+UDP头+数据三段拼接。若用单一大状态机（如100+状态）处理全流程，代码臃肿、分支嵌套深、时序收敛难，且任意状态跳转都可能引入毛刺。

我们采用两级状态机分离关注点：

• 顶层FSM（Packet FSM）：管理帧级生命周期，共6个状态：IDLE（等待新帧）、SYNCING（捕获SFD后同步）、PARSING_IP（解析IP头）、PARSING_UDP（解析UDP头）、PAYLOAD_TRANSFER（转发净荷）、CLEANUP（清空状态、复位信号）；
• 底层FSM（Byte FSM）：在PARSING_IP和PARSING_UDP状态下启用，专用于逐字节解析头部字段，例如IP头校验和计算时，它会循环执行“读取2字节→累加→右移→进位处理”直到8字节校验和字段结束。

这种分层带来三大优势：

1. 时序隔离：顶层FSM运行在系统主时钟（100MHz），底层FSM在RGMII RX_CLK（125MHz for 1Gbps）下工作，通过双时钟FIFO桥接，避免跨时钟域亚稳态；
2. 可测试性强：可单独仿真底层FSM，输入预定义IP头字节流，验证校验和输出是否符合RFC 1071标准；
3. 扩展灵活：若后续要支持IPv6，只需替换PARSING_IP子状态机，顶层FSM逻辑完全不动。

实测对比：单一大状态机综合后关键路径延迟达9.2ns（超100MHz时序），而两级FSM关键路径压缩至6.8ns，时序余量提升35%。更重要的是，当某次抓包发现UDP包被误判为无效时，我能直接定位到Byte FSM在第3字节校验和累加时进位标志未清零，而不是在上百行状态转移代码里大海捞针。

2.3 数据路径设计：为什么用“乒乓FIFO”而非单一大FIFO

UDP净荷数据流速率取决于网络带宽（1Gbps RGMII理论峰值125MB/s），而用户逻辑（如图像处理模块）处理速度往往只有几十MB/s。若只用一个FIFO缓存，当用户侧ready信号拉低时，FIFO会迅速填满，触发溢出中断——此时MAC引擎若继续写入，将丢失后续数据包。传统做法是让MAC暂停发送，但RGMII协议不支持反压，强行停发会导致PHY层重传或链路中断。

我们采用双口RAM实现的乒乓FIFO机制：

• 设置两个独立FIFO（FIFO_A和FIFO_B），各深256字（2KB）；
• 当FIFO_A写满时，自动切换至FIFO_B接收新包，同时FIFO_A开始被用户逻辑读取；
• 切换由packet_end信号触发（即FCS校验通过且UDP校验通过），确保每个FIFO只存一个完整UDP包；
• 用户侧通过fifo_sel信号选择当前读取的FIFO，读完后拉高fifo_done通知切换。

这种设计规避了传统FIFO的“读写竞争”问题：

• 写操作永远只发生在当前激活的FIFO，无仲裁开销；
• 读操作只访问已锁定的FIFO，无需担心读指针追上写指针；
• 单包最大长度1472字节，2KB深度留有30%余量应对突发流量；
• 资源消耗仅增加1个双口RAM（约500 LUT），却换来100%丢包率下降。

注意：乒乓FIFO的切换时机必须严格限定在UDP包校验通过后。曾有学员把切换信号接在rx_dv下降沿（即帧结束），结果遇到FCS校验失败的坏包也触发切换，导致FIFO_B存入无效数据，后续用户逻辑解析崩溃。正确做法是：if (udp_valid && udp_checksum_ok) fifo_switch <= 1'b1;—— 只有双重校验都通过才切换。

3. 核心模块代码实现与关键细节解析

3.1 RGMII接收接口：如何解决时钟域交叉与数据对齐

RGMII v2.0规定：在1Gbps模式下，RX_CLK为125MHz，数据线rx_data[3:0]在时钟上升沿和下降沿各采样2位，即每个周期传输4位（nibble）。但FPGA内部逻辑通常运行在100MHz系统时钟，直接用rx_clk采样会导致跨时钟域问题。我们的解决方案是：用rx_clk采样后，立即用系统时钟同步，再通过格雷码计数器实现无亚稳态FIFO写入。

// RGMII接收核心逻辑（精简版） module rgmii_rx #( parameter SYS_CLK_FREQ = 100_000_000, parameter RX_CLK_FREQ = 125_000_000 ) ( input wire rx_clk, input wire rx_ctl, // rx_dv + rx_er 复用 input wire [3:0] rx_data, output reg [7:0] byte_out, output reg byte_valid ); reg [3:0] rx_data_sync; reg [1:0] rx_ctl_sync; // 第一级同步：rx_clk域采样 always @(posedge rx_clk) begin rx_data_sync <= rx_data; rx_ctl_sync <= {rx_ctl, 1'b0}; // 扩展为2bit便于后续解码 end // 第二级同步：系统时钟域采样（双触发器同步） reg [3:0] rx_data_meta, rx_data_reg; reg [1:0] rx_ctl_meta, rx_ctl_reg; always @(posedge sys_clk) begin rx_data_meta <= rx_data_sync; rx_data_reg <= rx_data_meta; rx_ctl_meta <= rx_ctl_sync; rx_ctl_reg <= rx_ctl_meta; end // 数据对齐：RGMII规定rx_data[3:0]在rx_clk上升沿为低nibble，下降沿为高nibble // 我们用rx_clk二分频生成采样使能 reg rx_clk_div2; always @(posedge rx_clk) rx_clk_div2 <= ~rx_clk_div2; reg [7:0] aligned_byte; reg byte_strobe; always @(posedge rx_clk) begin if (rx_clk_div2) begin // 上升沿：取低nibble aligned_byte[3:0] <= rx_data_sync; end else begin // 下降沿：取高nibble aligned_byte[7:4] <= rx_data_sync; byte_strobe <= 1'b1; end end // 将aligned_byte同步到sys_clk域 reg [7:0] byte_out_meta, byte_out_reg; reg byte_valid_meta, byte_valid_reg; always @(posedge sys_clk) begin byte_out_meta <= aligned_byte; byte_valid_meta <= byte_strobe; byte_out_reg <= byte_out_meta; byte_valid_reg <= byte_valid_meta; end assign byte_out = byte_out_reg; assign byte_valid = byte_valid_reg; endmodule

这段代码的关键在于：

• 双触发器同步：rx_data_sync先在rx_clk域采样，再经rx_data_meta→rx_data_reg两级寄存器同步到sys_clk域，将亚稳态概率降至10^-12量级；
• nibble对齐：利用rx_clk_div2在上升/下降沿分别捕获高低nibble，拼成完整字节，避免因PHY芯片采样相位偏差导致字节错位；
• strobe信号生成：byte_strobe仅在完整字节就绪时拉高，作为后续MAC解析的状态机触发条件，杜绝半字节干扰。

实操心得：不同厂商PHY芯片（如Marvell 88E1111、Microchip LAN8720）对RGMII时序裕度要求不同。我在Basys3板上用LAN8720时，发现rx_clk与rx_data的建立时间仅1.2ns，低于Xilinx Artix-7 IOB的2.1ns要求。解决方案是：在Vivado中添加IO约束set_input_delay -clock [get_clocks rx_clk] 1.0 [get_ports rx_data]，强制工具插入输入延迟缓冲器，将建立时间提升至2.3ns，问题彻底解决。

3.2 IP头校验和验证：手写组合逻辑 vs 调用IP核

IP头校验和是16位反码和（RFC 1071），需对IP头前20字节（不含校验和字段本身）两两相加，进位回卷。很多教程建议调用Xilinx LogiCORE IP中的Checksum Generator，但该IP核最小配置需占用300+ LUT，且输出延迟不可控（影响PARSING_IP状态机时序）。

我们采用纯组合逻辑流水线实现，仅用87个LUT：

// IP校验和计算器（20字节输入，16位输出） module ip_checksum_calculator ( input wire [159:0] ip_header, // 20字节 = 160bit output wire [15:0] checksum ); wire [15:0] sum16; wire [15:0] sum16_carry; // 步骤1：16位字拆分与初始累加 wire [15:0] w0 = ip_header[15:0]; wire [15:0] w1 = ip_header[31:16]; wire [15:0] w2 = ip_header[47:32]; wire [15:0] w3 = ip_header[63:48]; wire [15:0] w4 = ip_header[79:64]; wire [15:0] w5 = ip_header[95:80]; wire [15:0] w6 = ip_header[111:96]; wire [15:0] w7 = ip_header[127:112]; wire [15:0] w8 = ip_header[143:128]; wire [15:0] w9 = ip_header[159:144]; // 步骤2：三级树状加法器（避免长链延迟） wire [16:0] s0 = w0 + w1; // 17bit wire [16:0] s1 = w2 + w3; wire [16:0] s2 = w4 + w5; wire [16:0] s3 = w6 + w7; wire [16:0] s4 = w8 + w9; wire [17:0] t0 = s0 + s1; // 18bit wire [17:0] t1 = s2 + s3; wire [17:0] t2 = s4; wire [18:0] u0 = t0 + t1; // 19bit wire [18:0] u1 = t2; wire [19:0] final_sum = u0 + u1; // 最大19bit（10个16bit字相加） // 步骤3：进位回卷（将高位进位加到低位） wire [15:0] sum16_no_carry = final_sum[15:0]; wire [3:0] carry_bits = final_sum[19:16]; wire [15:0] sum16_carry = sum16_no_carry + {12'b0, carry_bits}; // 步骤4：取反得到校验和 assign checksum = ~sum16_carry; endmodule

这个设计的精妙之处在于：

• 树状加法器：将10个16位字的累加分解为三级并行加法（2→4→8→10），关键路径仅为3级加法器延迟（约1.8ns），远优于串行累加的10级延迟；
• 进位回卷硬件化：carry_bits直接提取final_sum[19:16]，避免用while循环（硬件不支持）；
• 资源极致优化：全部用LUT6实现，无触发器，综合后面积仅87 LUT，时序轻松满足200MHz。

注意：IP校验和验证时，必须先将IP头中校验和字段置0再计算。常见错误是直接对原始IP头计算，导致结果永远不等于0。正确流程：ip_header_temp[15:0] = 16'h0000; checksum_calc(ip_header_temp) == 16'h0000。

3.3 UDP校验和计算：伪首部构造与字节序陷阱

UDP校验和比IP复杂，需拼接“伪首部（12字节）+ UDP头（8字节）+ 净荷”。伪首部包含：源IP（4B）、目的IP（4B）、协议号（1B，UDP=17）、UDP长度（2B）。这里埋着两个致命陷阱：

• 字节序混淆：网络字节序（Big Endian）与FPGA内部小端存储不一致，IP地址192.168.1.100在网络上传输为0xC0A80164，但FPGA寄存器中若按{ip[31:24], ip[23:16], ip[15:8], ip[7:0]}存储，则无需转换；若按数组索引ip[0]存最低字节，则必须反转；
• 长度字段填充：UDP长度字段含头+数据共16位，但伪首部中该字段为网络字节序，且必须是UDP段总长（即使净荷为空也要填8）。

我们采用预构造伪首部RAM方案，避免运行时拼接开销：

// 伪首部生成（参数化IP地址） localparam SRC_IP = 32'hC0A80101; // 192.168.1.1 localparam DST_IP = 32'hC0A80164; // 192.168.1.100 localparam PROTO = 8'h11; // UDP localparam UDP_LEN = 16'h0008; // 最小长度（仅头） reg [7:0] pseudo_header [0:11]; // 12字节伪首部 always @(*) begin pseudo_header[0] = SRC_IP[31:24]; // 源IP高字节 pseudo_header[1] = SRC_IP[23:16]; pseudo_header[2] = SRC_IP[15:8]; pseudo_header[3] = SRC_IP[7:0]; pseudo_header[4] = DST_IP[31:24]; // 目的IP高字节 pseudo_header[5] = DST_IP[23:16]; pseudo_header[6] = DST_IP[15:8]; pseudo_header[7] = DST_IP[7:0]; pseudo_header[8] = PROTO; pseudo_header[9] = UDP_LEN[15:8]; // UDP长度高字节 pseudo_header[10] = UDP_LEN[7:0]; // UDP长度低字节 pseudo_header[11] = 8'h00; // 填充字节（确保12字节对齐） end

关键细节：

• UDP长度动态更新：实际UDP长度=8 + payload_len，需在PAYLOAD_TRANSFER阶段实时计算并更新pseudo_header[9:10]；
• 净荷长度对齐：若净荷字节数为奇数，需在末尾补0（RFC 768要求），否则校验和计算错误；
• 校验和为0的处理：当计算结果为0时，UDP规定校验和字段应填0xFFFF（全1），而非0，这是反码和的特性。

实测案例：某次调试中UDP包始终被PC端丢弃，Wireshark显示“UDP checksum incorrect”。排查发现pseudo_header[9:10]未随净荷长度更新，始终为0x0008，而实际包长为0x0020（32字节）。修正后问题消失。这印证了“硬件协议栈中，每一个字节都必须精确可控”的铁律。

3.4 用户接口设计：AXI-Stream握手协议的落地实践

UDP净荷最终要交给用户逻辑（如FIR滤波器、JPEG编码器），我们采用AXI-Stream标准（tvalid,tready,tdata）而非简单data/valid，因为：

• AXI-Stream天然支持背压（tready由用户侧控制），避免FIFO溢出；
• tlast信号明确标识包边界，用户逻辑可据此触发DMA搬运或中断；
• Xilinx IP Integrator中大量IP（如VDMA、AXI DMA）原生支持AXI-Stream，无缝对接。

// UDP净荷AXI-Stream输出模块 module udp_stream_out #( parameter PAYLOAD_WIDTH = 8 ) ( input wire clk, input wire rst_n, input wire packet_start, // UDP包开始（含UDP头后第一个字节） input wire packet_end, // UDP包结束（FCS校验通过） input wire [7:0] payload_byte, input wire payload_valid, output wire tvalid, output wire tready, output wire [7:0] tdata, output wire tlast ); reg [7:0] tdata_reg; reg tvalid_reg; reg tlast_reg; reg packet_active; // 状态机控制包边界 always @(posedge clk or negedge rst_n) begin if (!rst_n) begin packet_active <= 1'b0; tvalid_reg <= 1'b0; tlast_reg <= 1'b0; end else begin if (packet_start) begin packet_active <= 1'b1; tvalid_reg <= 1'b0; tlast_reg <= 1'b0; end else if (packet_end) begin packet_active <= 1'b0; tvalid_reg <= 1'b0; tlast_reg <= 1'b1; end else if (payload_valid && packet_active) begin tvalid_reg <= 1'b1; tdata_reg <= payload_byte; tlast_reg <= 1'b0; end else begin tvalid_reg <= 1'b0; tlast_reg <= 1'b0; end end end // 握手逻辑：仅当tvalid && tready时更新tdata assign tdata = tdata_reg; assign tvalid = tvalid_reg; assign tlast = tlast_reg; // tready由用户侧提供，此处仅为示例 // 实际应用中，tready信号来自下游IP（如AXI DMA的s_axis_tready） endmodule

这个模块的实战要点：

• tlast生成时机：必须在packet_end信号拉高时置1，且仅维持1个周期，否则下游IP会误判为连续包；
• tvalid与payload_valid解耦：payload_valid来自MAC引擎，可能因FIFO满而暂停，而tvalid受tready控制，两者异步，需用FIFO桥接；
• 宽度适配：若用户逻辑处理32位数据，可将4个payload_byte打包为tdata[31:0]，此时payload_valid需转换为字节使能信号tstrb[3:0]。

我在Zynq ZC702上对接VDMA时，发现VDMA的s_axis_tready信号在帧缓冲区满时会拉低，若udp_stream_out未正确响应，会导致tvalid持续高电平而tready为低，触发AXI协议错误。解决方案是在模块内增加ready_sync寄存器，用双触发器将tready同步到clk域，并在always @(posedge clk)块中严格遵循“tvalid仅在tready==1时置高”的规则。

4. 实操调试全流程与典型问题排查

4.1 硬件联调四步法：从PHY链路到UDP通路

FPGA UDP调试最怕“黑盒式失败”——Ping不通、Wireshark没包、LED不亮，却不知问题在哪一层。我们固化一套四步隔离法，每步都有明确验证手段：

第一步：PHY链路层验证（耗时<5分钟）

• 工具：万用表测PHY芯片link_status引脚（通常为高电平），示波器看rx_clk有无125MHz正弦波；
• 关键信号：rx_dv（接收有效）应随网线插拔频繁跳变，tx_en（发送使能）在FPGA发送时拉高；
• 常见问题：网线未用直连线（交叉线）、PHY供电电压错误（1.0V/1.8V/3.3V混用）、RGMII引脚约束错误（如rx_clk未分配到专用时钟引脚）；
• 验证通过标志：rx_dv在PC发送ping包时出现规律性脉冲（每次ping产生1个64字节帧，rx_dv高电平持续约512ns）。

第二步：MAC帧解析验证（耗时<10分钟）

• 工具：Vivado ILA抓rgmii_rx输出的byte_out信号，设置触发条件为byte_out==8'hD5（SFD）；
• 关键观察：抓到SFD后，后续字节应为0xFF,0xFF,0xFF,0xFF,0xFF,0xFF（DA）→0x00,0x11,0x22,0x33,0x44,0x55（SA）→0x08,0x00（Type=IP）；
• 常见问题：RGMII数据对齐错误（字节错位）、rx_ctl同步失败（rx_dv被误判为rx_er）、FCS校验未剥离导致净荷多4字节；
• 验证通过标志：ILA波形中连续抓到标准以太网帧结构，且byte_valid与rx_dv严格同步。

第三步：IP层通路验证（耗时<15分钟）

• 工具：ILA抓ip_parser模块的ip_version_ok、ip_checksum_ok、ip_protocol_ok三信号；
• 关键观察：PC ping包的IP头中Version=4、Protocol=1（ICMP），而UDP包Protocol=17；若ip_protocol_ok为低，说明PC未发UDP包；
• 常见问题：IP校验和计算错误（伪首部未置0）、TTL字段为0（被路由器丢弃）、目的IP不匹配（FPGA IP设为192.168.1.100，PC需设同网段）；
• 验证通过标志：ip_version_ok && ip_checksum_ok && ip_protocol_ok三信号在UDP包到达时同时为高。

第四步：UDP端到端验证（耗时<20分钟）

• 工具：PC端用iperf3 -u -c 192.168.1.100 -p 4660 -b 1M发UDP流，FPGA端ILA抓udp_port_match和udp_payload_valid；
• 关键观察：udp_port_match应与设定端口（如16'h1234）一致，udp_payload_valid随数据流规律拉高；
• 常见问题：UDP校验和开关不一致（PC端默认开启，FPGA端若关闭则udp_checksum_ok恒为低）、端口未映射（防火墙拦截）、MTU设置过大（PC端netsh interface ipv4 set subinterface "以太网" mtu=1500 store=persistent）；
• 验证通过标志：FPGA成功接收UDP净荷，tvalid持续输出，且led[0]随包到达闪烁。

这套方法将调试时间从“几天漫无目的试错”压缩到“1小时内定位故障层”，核心在于每步只验证单一抽象层，且有明确的物理/电气信号作为证据，而非依赖软件工具的模糊提示。

4.2 Wireshark抓包分析：读懂FPGA发出的每一个字节

Wireshark是FPGA网络调试的终极眼睛，但新手常被海量字段淹没。我们聚焦三个必查字段，直击FPGA逻辑缺陷：

字段1：Ethernet II > Destination

• 正常值：应为FPGA的MAC地址（如00:11:22:33:44:55）；
• 异常表现：显示Broadcast（ff:ff:ff:ff:ff:ff）或Unknown；
• 根本原因：MAC发送引擎中da寄存器未加载正确值，或tx_en信号在DA字段未写入时提前拉高；
• 解决方案：ILA抓mac_tx模块的tx_state和tx_byte，确认DA六字节在tx_state==DA0到DA5期间依次输出。

字段2：IPv4 > Header checksum

• 正常值：Good（绿色）；
• 异常表现：Bad（红色）或Unverified；
• 根本原因：IP校验和计算错误（如伪首部未置0）、IP头