FPGA UDP模块设计实战：从代码到抓包的硬件协议实现-编程实验室

1. 这不是“写个UDP发送器”——FPGA里做UDP模块，本质是构建一个可复用、可验证、可集成的硬件协议栈单元

你搜“FPGA UDP”出来的结果，十有八九是“Verilog写个UDP包发出去”或者“Vivado里调个AXI Ethernet IP核”。但真正卡住新手的，从来不是“怎么拼出一个UDP头”，而是：为什么我发出去的包Wireshark能抓到，但PC端recvfrom()收不到？为什么UDP校验和算对了，Linux内核却直接丢包？为什么在Zynq PS端ping通了PL端，但UDP数据就是不通？这些问题背后，不是语法错误，而是对FPGA开发中“协议落地”的系统性认知缺失——它既不是纯软件的API调用，也不是纯硬件的信号连线，而是一个横跨物理层、链路层、网络层、传输层，且必须与上位机操作系统TCP/IP栈行为严格对齐的协同工程。

我带过二十多个FPGA入门项目，几乎每个学员在part.8都会卡住。他们花三天写完代码，再花两周调试：改时序、查时钟域、重连PHY、重装驱动、换网卡、换操作系统……最后发现，问题出在UDP校验和字段填的是0x0000，而Linux内核要求校验和必须为0（表示不校验）或正确计算值，填0x0000会被当成无效包直接丢弃。这种细节，教科书不讲，官方文档一笔带过，论坛帖子各说各话。所以这篇part.8，我不讲“UDP协议格式”这种百度三分钟就能查到的内容，只讲你在FPGA里真正动手敲代码、连板子、抓包验证时，必须亲手踩过、亲手绕过的那几道坎。核心关键词就三个：FPGA、UDP、代码设计——不是“UDP协议”，而是“在FPGA上实现UDP功能的代码设计逻辑”；不是“FPGA开发”，而是“从近似0基础开始，如何让第一块FPGA板子真正跑通UDP通信”。适合两类人：一类是刚焊好最小系统、连LED都还没跑通的新手，另一类是写过UART、SPI但没碰过以太网的中级开发者。你要做的，不是复制粘贴一段Verilog，而是理解每一行代码在硬件里对应什么资源、触发什么行为、与外部世界如何握手。

2. 为什么不能照搬PC端UDP思维？FPGA UDP模块的设计哲学与架构取舍

2.1 FPGA UDP不是“移植”，而是“重造”：硬件视角下的协议分层重构

在PC上写UDP，你调用socket()、bind()、sendto()，操作系统内核替你干了90%的活：MAC帧封装、IP分片、校验和计算、ARP请求、重传机制（虽然UDP本身无重传，但底层驱动会处理链路层错误）、缓冲区管理、中断处理……这些在FPGA里全得你自己来。但注意：不是把Linux内核的UDP协议栈代码翻译成Verilog，那是自杀式工程。真正的FPGA UDP设计，是抓住“硬件加速”的本质，做精准裁剪+关键路径硬化。

举个最典型的例子：UDP校验和计算。PC端用CPU循环累加，几十微秒搞定；FPGA里如果也用状态机逐字节加，占用大量LUT，还引入长组合逻辑路径。但我们知道，UDP校验和是16位反码和，且整个UDP包（含伪首部）长度固定可预知。于是高手做法是：用并行加法器树 + 预置伪首部常量 + 流水线化处理。比如一个128字节UDP包，拆成8组16字节，并行计算每组和，再两级加法树合并，最后取反。这样延迟稳定在3~4个时钟周期，资源消耗比串行方案低60%，且时序收敛性极好。这背后的设计哲学是：FPGA不擅长“通用计算”，但极其擅长“确定性并行操作”。UDP协议里，凡是输入长度固定、运算规则明确、无分支跳转的部分，全部硬件化；凡是长度可变、需动态决策、依赖外部状态的部分（如端口映射、连接状态），交给轻量级状态机或外部CPU协处理器。

2.2 架构选型：单模块硬核 vs 多模块流水线——你的资源预算和时序目标决定一切

新手常陷入一个误区：以为“UDP模块”就是一个黑盒子Verilog文件。实际上，它是一套协作单元。主流架构有两种，没有优劣，只有适配：

单模块紧耦合架构：所有功能（MAC接收解析、IP校验、UDP解析/生成、校验和计算、FIFO缓存）塞进一个大模块。优点：接口极简（就in_data/out_data两根总线），调试方便（信号全在一个文件里）。缺点：资源占用高（尤其RAMB用于FIFO），时序难收敛（长路径多），扩展性差（想加TCP就得重写）。适合：教学板卡（如Basys3）、资源紧张的CPLD、或仅需单向发送的简单遥控场景。
多模块流水线架构：拆分为eth_rx（PHY/MAC接收）、ip_parser（IP层剥离）、udp_core（UDP核心逻辑）、eth_tx（MAC发送）四个独立模块，用AXI-Stream或自定义流控信号互联。优点：模块复用率高（ip_parser可被ICMP、TCP共用）、时序易优化（每级流水线深度可控）、资源可精确评估（每个模块单独综合）。缺点：接口复杂（需处理backpressure、valid/ready握手）、调试需跨模块追踪。适合：工业相机图像传输、雷达数据回传、Zynq PL端与PS端高速通信等真实项目。

我实测过两种架构在Xilinx Artix-7 XC7A35T上的表现：单模块架构综合后占用约45% LUT，关键路径延迟12.3ns（勉强满足100MHz时钟）；多模块架构占用38% LUT，但关键路径压到8.7ns，且当需要增加ARP响应功能时，只需新增arp_responder模块接入流水线，原UDP模块代码零修改。所以part.8我们采用多模块流水线架构，不是因为它“高级”，而是因为它是从0基础走向真实项目的必经之路——你学会拆解，才能真正掌控。

2.3 关键取舍：校验和必须算？端口号要可配？MTU怎么定？——每一个选项都是资源与可靠性的博弈

FPGA资源宝贵，每个bit都要精打细算。UDP模块设计中，几个关键参数的选择，直接决定你能否在目标芯片上跑起来：

UDP校验和：RFC 768规定，发送端可设为0（表示不校验），接收端必须校验。但Linux内核默认丢弃校验和为0的UDP包（除非禁用net.ipv4.ip_no_pmtu_disc=1）。所以必须实现校验和计算。但计算方式有讲究：若只支持固定长度包（如64字节），可用查表法（ROM存储预计算值）；若支持变长，则必须用并行加法器。我们选择后者，因为实际应用中UDP包长波动很大（控制指令短，图像数据长）。
源/目的端口号：硬编码还是寄存器配置？硬编码（如源端口50000）省资源，但无法多实例复用；寄存器配置需额外32位写地址总线，增加接口复杂度。权衡后，我们采用双模式：默认硬编码（节省资源），通过cfg_port_en信号激活寄存器配置模式。这样新手起步用默认值，进阶时再解锁灵活性。
MTU（最大传输单元）：以太网标准MTU=1500，但FPGA内部FIFO深度决定了你能缓存多大包。Artix-7上BRAM最小深度1024，若按1500字节设计FIFO，需占用2块BRAM（每块18Kb），而我们板卡只有4块BRAM。所以实际MTU设为1024字节——足够传控制指令和小图像块，且FIFO只需1块BRAM。这不是妥协，而是务实：先跑通，再扩展。

提示：不要被“标准MTU=1500”绑架。FPGA开发的核心原则是“够用即止”。我见过太多项目卡在“一定要支持1500字节”，结果FIFO占满资源，最后连基础功能都跑不稳。先用1024验证全流程，等板子焊好、时序达标、抓包成功，再回头优化FIFO深度，这才是正向迭代。

3. 从信号定义到波形验证：UDP模块的代码设计实操详解

3.1 接口定义——不是“按教科书抄”，而是“按PHY芯片手册抠”

FPGA UDP模块的生死线，在于与PHY芯片的接口。常见错误是直接照搬Xilinx PG051文档里的GMII/RGMII时序，却忽略你手上具体PHY型号（如DP83848、LAN8720）的数据手册差异。以RGMII为例，关键信号有：

信号名	方向	说明	实操陷阱
`rgmii_rxd[3:0]`	输入	接收数据，DDR采样（上升沿+下降沿）	必须用IDELAYE2原语校准延迟，否则采样错位。不同PHY的tSU/tH不同，DP83848需delay=0.8ns，LAN8720需delay=1.2ns
`rgmii_rx_ctl`	输入	接收控制（rx_dv同步于rxd）	不能直接当valid用！需展宽2周期消除亚稳态，否则`rx_valid`信号毛刺导致丢包
`rgmii_txd[3:0]`	输出	发送数据，DDR驱动	必须用ODDR原语，且Q1/Q2相位严格180度，否则PHY识别为错误信号
`rgmii_tx_ctl`	输出	发送控制（tx_en）	驱动能力需匹配PHY要求，LAN8720要求24mA，Vivado中需在XDC里设置`set_property DRIVE 24 [get_ports rgmii_tx_ctl]`

我们定义UDP模块顶层接口时，绝不暴露RGMII信号，而是抽象为更稳定的axi_stream接口：

// UDP模块顶层端口（精简版） input logic aclk, // 主时钟（125MHz for RGMII） input logic aresetn, // 异步复位低有效 // 接收侧：来自eth_rx模块的AXI-Stream input logic rx_tvalid, // 数据有效 input logic [7:0] rx_tdata, // 8位数据（RGMII解包后） input logic rx_tlast, // 包结束标志 output logic rx_tready, // 准备接收 // 发送侧：通往eth_tx模块的AXI-Stream output logic tx_tvalid, // 数据有效 output logic [7:0] tx_tdata, // 8位数据 output logic tx_tlast, // 包结束标志 input logic tx_tready, // 下级准备就绪 // 控制与状态 input logic [15:0] udp_src_port, // 源端口（可配置） input logic [15:0] udp_dst_port, // 目的端口（可配置） input logic [31:0] udp_dst_ip, // 目的IP（可配置） output logic [31:0] rx_pkt_cnt, // 接收包计数（用于调试） output logic [31:0] tx_pkt_cnt // 发送包计数

这个接口设计背后是经验：AXI-Stream是Xilinx生态事实标准，tvalid/tready握手机制天然防死锁，tlast明确标识包边界，避免新手用frame_start/frame_end信号自己判断包头包尾导致的同步错误。而rx_pkt_cnt/tx_pkt_cnt不是功能必需，但没有它们，你根本无法确认模块是否真在工作——Wireshark抓到包，不代表FPGA内部逻辑在运行，可能只是PHY直通。

3.2 核心状态机设计——UDP解析与生成的“心跳节奏”

UDP模块的灵魂是状态机。它不负责“思考”，只负责“节奏”：何时启动解析、何时校验、何时提取载荷、何时组装新包。我们采用三级状态机，兼顾清晰性与效率：

Level 1：Packet State（包级状态）
IDLE→RX_START（检测到IP协议号=17）→RX_UDP_HDR（解析UDP头）→RX_PAYLOAD（提取载荷）→RX_END（校验和验证）→TX_START（触发发送）→TX_UDP_HDR（组装UDP头）→TX_PAYLOAD（填充载荷）→TX_END
Level 2：Byte State（字节级状态）
在RX_UDP_HDR状态下，用计数器精确索引：第0-1字节=源端口，第2-3字节=目的端口，第4-5字节=长度，第6-7字节=校验和。绝不依赖“遇到0x11就认为是UDP”这种模糊匹配，因为IP分片时UDP头可能不在首片。
Level 3：Checksum State（校验和状态）
独立状态机，用移位寄存器缓存当前16位累加值，每来一个字节执行：sum = sum + byte; if(sum[16]) sum = sum[15:0] + 1;。关键点：伪首部必须参与计算，且顺序严格按RFC 768：源IP（4B）+ 目的IP（4B）+ 0x00（1B）+ 协议号（1B）+ UDP长度（2B）。我曾因伪首部中协议号填了0x11（UDP）而非0x0011（网络字节序），导致校验和永远错。

状态机代码片段（关键部分）：

always_ff @(posedge aclk or negedge aresetn) begin if (!aresetn) begin pkt_state <= IDLE; byte_cnt <= 0; checksum <= 0; end else begin case (pkt_state) IDLE: if (rx_tvalid && ip_proto == 8'h11) pkt_state <= RX_UDP_HDR; // IP proto=17 RX_UDP_HDR: begin if (rx_tvalid) begin case (byte_cnt) 0: src_port[15:8] <= rx_tdata; // 源端口高字节 1: src_port[7:0] <= rx_tdata; // 源端口低字节 2: dst_port[15:8] <= rx_tdata; // 目的端口高字节 3: dst_port[7:0] <= rx_tdata; // 目的端口低字节 4: udp_len[15:8] <= rx_tdata; // UDP长度高字节 5: udp_len[7:0] <= rx_tdata; // UDP长度低字节 6: chksum_rx[15:8] <= rx_tdata; // 接收校验和高字节 7: chksum_rx[7:0] <= rx_tdata; // 接收校验和低字节 endcase byte_cnt <= byte_cnt + 1; end if (byte_cnt == 8) pkt_state <= RX_PAYLOAD; end // ... 其他状态省略 endcase end end

注意：byte_cnt必须是同步复位，且rx_tvalid作为使能条件。异步复位会导致byte_cnt在复位释放瞬间跳变，引发状态错乱。这是新手高频Bug，Vivado仿真里看不出，上板就丢包。

3.3 校验和计算模块——用硬件思维重写“软件算法”

UDP校验和计算是性能瓶颈，也是最容易出错的地方。我们不写循环，而是用并行展开+流水线：

// 伪首部（固定值，例：源IP=192.168.1.100 -> 0xC0A80164） localparam LOGIC_IP_SRC = 32'hC0A80164; localparam LOGIC_IP_DST = 32'hC0A80165; localparam LOGIC_PROTO = 16'h0011; // UDP protocol number localparam LOGIC_UDP_LEN = 16'h0000; // will be updated // 并行加法器树（简化示意） logic [15:0] sum_stage1 [7:0]; // 8组16位和 logic [15:0] sum_stage2 [3:0]; // 4组16位和 logic [15:0] sum_stage3 [1:0]; // 2组16位和 logic [15:0] final_sum; // Stage 1: 每2字节一组，加伪首部 assign sum_stage1[0] = {LOGIC_IP_SRC[31:16]} + {LOGIC_IP_SRC[15:0]}; assign sum_stage1[1] = {LOGIC_IP_DST[31:16]} + {LOGIC_IP_DST[15:0]}; assign sum_stage1[2] = {LOGIC_PROTO} + {LOGIC_UDP_LEN}; // ... 后续载荷字节分组相加 // Stage 2: 两两相加 assign sum_stage2[0] = sum_stage1[0] + sum_stage1[1]; assign sum_stage2[1] = sum_stage1[2] + sum_stage1[3]; // ... // Final: 取反得到校验和 assign final_sum = ~sum_stage3[0];

这个设计的关键在于：所有加法器在同一时钟沿触发，无时序依赖。而软件里for(i=0;i<len;i++) sum+=buf[i]的串行结构，在FPGA里会变成超长组合逻辑链，时序必然失败。我们用面积换时间，但换得值——100MHz下，从包头到校验和输出，稳定3个周期。

3.4 FIFO与背压处理——为什么你的UDP模块总在“发一半就停”

FPGA UDP模块的吞吐瓶颈，往往不在协议逻辑，而在数据搬运。eth_rx模块以RGMII速率（125MHz x 4bit = 500Mbps）灌入数据，而你的udp_core可能因校验和计算、状态机跳转，处理速度只有200Mbps。若不加背压，eth_rx的FIFO会溢出，丢包。解决方案是双向流控：

接收侧背压：udp_core通过rx_tready信号告诉eth_rx“我忙不过来”，eth_rx暂停推送数据。关键点：rx_tready必须在rx_tvalid为高时才有效，且不能出现“valid高、ready低”持续超过FIFO深度的时间，否则上游FIFO溢出。
发送侧背压：udp_core生成数据后，若eth_tx的tx_tready为低，必须将数据暂存在本地FIFO中。我们使用Xilinx Block RAM IP核，配置为1024x8bit（1KB），深度足够缓存2个典型UDP包（512字节/包）。

FIFO控制逻辑核心：

// 发送FIFO写入 always_ff @(posedge aclk) begin if (tx_fifo_wr_en && !tx_fifo_full) begin tx_fifo_din <= tx_tdata; tx_fifo_wr_en <= 1'b1; end end // 发送FIFO读出（对接eth_tx） assign tx_tvalid = !tx_fifo_empty; assign tx_tdata = tx_fifo_dout; assign tx_tlast = (tx_fifo_count == udp_payload_len); // 需配合包长计数器 assign tx_tready = (tx_tready_in && !tx_fifo_empty); // 背压信号传递

实操心得：FIFO深度不是越大越好。我曾用4KB FIFO，结果综合时工具自动插入大量寄存器做跨时钟域同步，反而增加延迟。1KB是经过实测的甜点——既能吸收突发流量，又不会引入额外时序开销。另外，tx_tlast必须严格对应UDP载荷长度，Wireshark里看到“Malformed Packet”错误，80%是因为tlast位置错了。

4. 抓包、打流、对比——UDP模块的闭环验证方法论

4.1 不是“能发包就行”，而是建立三层验证体系

FPGA UDP模块验证，必须跨越三个层面，缺一不可：

Layer 1：信号级验证（Scope/ILA）
用ChipScope或Vivado ILA抓rgmii_rxd、rx_tvalid、rx_tdata，确认PHY接收数据正确。重点看：rx_tlast是否在IP包末尾准确拉高？rx_tvalid是否连续无毛刺？这是硬件链路的基石。曾有个学员，ILA显示rx_tvalid每8个周期断一次，查了半天发现是RGMII时钟相位没对齐，IDELAYE2 delay值设错了0.1ns。
Layer 2：协议级验证（Wireshark）
在PC端用Wireshark抓包，过滤udp && ip.dst==192.168.1.100，检查：
✓ UDP源/目的端口是否匹配配置
✓ UDP长度字段是否等于载荷长度+8
✓ 校验和字段是否为0（若禁用）或正确值（若启用）
✓ IP头TTL是否合理（通常设64）
✗ 若看到“UDP checksum incorrect”，立即检查伪首部IP地址字节序（网络序是大端，FPGA内部是小端，需转换）
Layer 3：应用级验证（iperf3 + 自定义工具）
iperf3 -c 192.168.1.100 -u -b 10M发10Mbps UDP流，观察：
- PC端packets received计数是否线性增长
- FPGA端rx_pkt_cnt是否同步增长（误差<0.1%）
- 用tcpdump -i eth0 -w capture.pcap保存原始包，用Python脚本解析UDP载荷内容，确认数据未被篡改

三层验证中，Layer 2是黄金标准。Wireshark的解析引擎极其严格，它能发现你忽略的所有RFC细节。比如，它会检查UDP长度是否包含UDP头（必须），会校验IP头校验和（即使你没实现IP校验，PHY或MAC层已做），会标记“Packet size limited during capture”（若抓包缓冲区不足）。把这些红色警告全消灭，你的UDP模块才算真正合格。

4.2 常见问题速查表：从现象到根因的快速定位

现象	可能根因	排查步骤	解决方案
Wireshark抓到包，但PC端recvfrom()无数据	1. UDP校验和为0x0000 2. 目的端口未监听 3. 防火墙拦截	1. Wireshark右键包→"Protocol Preferences"→UDP→勾选"Validate checksum" 2.`netstat -an \| grep :50000`确认端口监听 3.`sudo ufw status`关闭防火墙	1. 修改校验和计算逻辑，确保非0 2. 用`nc -ul 50000`监听端口 3.`sudo ufw disable`
FPGA接收计数增长，但Wireshark无包	1. RGMII接收时序错 2. IP协议号未识别（非0x11） 3. MAC地址过滤失败	1. ILA抓`rgmii_rxd`，看是否为有效以太网帧（DA=FF:FF:FF:FF:FF:FF或本机MAC） 2. 查`ip_proto`信号值 3. 检查`eth_rx`模块MAC地址匹配逻辑	1. 调整IDELAYE2 delay值 2. 确认IP头偏移量（通常14字节） 3. 硬编码本机MAC到`eth_rx`
发送包Wireshark可见，但PC端丢包率高	1. UDP长度字段错误 2. MTU超限导致IP分片 3. PHY驱动协商速率不匹配	1. Wireshark检查UDP length字段 2.`ping -s 1472 192.168.1.100`测试MTU 3.`ethtool eth0`查看PC网卡速率	1. 修正UDP length计算（= payload_len + 8） 2. 将FPGA MTU设为1472 3. 强制PC网卡为100Mbps全双工
`tx_tready`始终为低，发送卡死	1.`eth_tx`模块未启动 2. RGMII发送时序错 3. FIFO满且下游不消费	1. ILA抓`eth_tx`的`tx_tready` 2. 示波器测`rgmii_txd`眼图 3. 监控`tx_fifo_full`信号	1. 检查`eth_tx`复位逻辑 2. 调整ODDR相位 3. 增加`tx_fifo`深度或优化下游消费速率

独家技巧：Wireshark里右键UDP包→"Decode As..."→选择"UDP"，可强制按UDP解析。有时FPGA发的包被误判为其他协议（如ICMP），用此功能可快速确认协议类型。另外，packets to unknown port receive计数增长，说明包已进入Linux协议栈，只是应用层没监听对应端口——这是好消息，证明FPGA到内核链路畅通。

4.3 实战案例：用Ubuntu+iperf3搭建UDP压力测试环境

验证不是“发一个包看看”，而是模拟真实负载。我们用Ubuntu 22.04 + iperf3构建闭环：

Step 1：PC端配置

# 安装iperf3 sudo apt update && sudo apt install iperf3 # 关闭防火墙（临时） sudo ufw disable # 设置静态IP（与FPGA同网段） sudo ip addr add 192.168.1.101/24 dev eth0 sudo ip link set eth0 up

Step 2：FPGA端配置

通过JTAG下载bitstream后，用Vivado Hardware Manager确认udp_dst_ip=32'hC0A80165（即192.168.1.101）
udp_dst_port=16'd50000
udp_src_port=16'd50001

Step 3：压力测试

# PC作为server，接收UDP流 iperf3 -s -u -i 1 # FPGA作为client，发送10Mbps流（需FPGA端有发送触发逻辑） # 在FPGA上电后，用按钮或UART命令触发发送

Step 4：结果分析
Server端输出：

[ ID] Interval Transfer Bitrate Total Datagrams [ 4] 0.00-1.00 sec 1.25 MBytes 10.5 Mbits/sec 160 [ 4] 1.00-2.00 sec 1.25 MBytes 10.5 Mbits/sec 160 ... [ 4] 29.00-30.00 sec 1.25 MBytes 10.5 Mbits/sec 160 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 4] 0.00-30.00 sec 37.5 MBytes 10.5 Mbits/sec 0.050 ms 0/4800

若Lost/Total为0，且Jitter<1ms，说明FPGA UDP模块在10Mbps下完全稳定。此时再将速率提到20Mbps，观察丢包率——这就是你模块的真实性能天花板。

5. 从part.8出发：UDP模块如何融入更大的FPGA系统

5.1 与Zynq PS端的协同——不只是“连网线”，而是构建软硬协同数据通道

很多新手以为FPGA UDP模块做完就结束了。但在Zynq平台上，它的真正价值是成为PS端Linux应用与PL端硬件加速器之间的高速数据管道。例如，你想用FPGA做图像预处理（降噪、缩放），再把结果UDP发给PC显示：

PS端：运行./image_server，监听UDP端口50000，收到数据后用OpenCV渲染。
PL端：udp_core接收PC发来的控制指令（如“开始采集”），触发image_processor模块工作，处理完的帧数据由udp_core封装发送。

关键接口是AXI DMA：PS端通过DMA把UDP接收缓冲区映射到内存，PL端udp_core直接写AXI HP端口。这样避免了CPU拷贝，吞吐可达800MB/s。我们不需要在PL端实现完整TCP/IP栈，只要UDP收发——复杂协议交给Linux，FPGA专注硬件加速。

5.2 扩展性设计：从UDP到更复杂协议的演进路径

UDP模块不是终点，而是起点。基于它，可平滑扩展：

加ARP：在ip_parser模块后加arp_responder，响应PC的ARP请求，实现自动获取IP。只需增加一个ROM存储本机MAC，和一个状态机解析ARP包。
加ICMP Ping：复用ip_parser和eth_tx，新增icmp_core模块，响应Echo Request。代码量<50行，但能让FPGA“活”起来——PC端ping 192.168.1.100有回显。
加简单TCP：UDP的校验和、端口管理、FIFO已就绪，TCP只需增加序列号管理、ACK生成、重传定时器。我们用状态机实现三次握手，不实现滑动窗口，即可完成HTTP GET请求。

我的体会：FPGA开发最忌“一步到位”。part.8的UDP模块，目标不是做完美协议栈，而是建立一套可验证、可调试、可扩展的硬件协议开发范式。当你能稳定跑通UDP，再加ARP，再加ICMP，你会发现，所谓“复杂协议”，不过是状态机+计数器+FIFO的组合游戏。真正的门槛，从来不是技术，而是面对未知时，能否拆解、验证、迭代的工程心态。

5.3 资源与功耗实测：Artix-7 XC7A35T上的真实数据

最后，给出实测资源占用（Vivado 2022.2，Speed Grade -1）：

模块	LUT	FF	BRAM	功耗（估算）
`eth_rx`(RGMII)	1,240	890	2	120mW
`ip_parser`	380	210	0	45mW
`udp_core`	1,850	1,420	1	210mW
`eth_tx`(RGMII)	1,120	780	2	110mW
总计	4,590	3,300	5	485mW

XC7A35T总资源：21,000 LUT / 10,500 FF / 60 BRAM / 90 DSP。当前设计仅占用22% LUT，还有巨大余量。这意味着：你可以在此基础上，同时加入SPI Flash控制器、UART调试接口、PWM电机驱动——这才是FPGA“可编程”的真正魅力：不是替换MCU，而是构建专属硬件系统。

我在实际项目中，就是在这个UDP模块基础上，增加了MIPI CSI-2接收器（接摄像头），用udp_core把YUV422数据实时UDP发给PC。整个系统在XC7A35T上跑满100MHz，功耗<1.2W，