从近似0基础开始FPGA开发已经写到第10篇了，前面的内容包括LED点亮、按键消抖、UART收发、SPI读写、数码管扫描这些常规操作，到这一篇开始接触真正有点“工程感”的东西——借助开源的verilog-ethernet工程，踏踏实实跑通一套UDP协议栈。这篇文章没有神化协议栈，也没有把它当成黑盒子，而是从近0基础的角度，把UDP协议栈的工程结构、模块功能、仿真验证掰开来看一遍，让你知道这玩意到底怎么用，以及为什么它能发能收。
verilog-ethernet这个开源工程在FPGA行业里讨论度挺高，它把UDP/IP协议栈做到了RTL级，不依赖硬核，也不依赖操作系统，纯靠FPGA逻辑完成MAC、ARP、UDP、ICMP的处理。和你常在STM32、Linux里用的协议栈完全不是一个路数——在FPGA里跑UDP，是直接用数字逻辑去拼帧、解析帧，每一比特都是时序，每一字节都有时钟。这篇文章会从网络分层的概念开始讲，然后拆一下工程的核心模块，再带你在Linux环境下用iverilog完成仿真，把一次真实的UDP来回抓出来看。适合手上有一块入门级FPGA板子，也适合想了解FPGA网络通信原理的开发者来参考。
1. 整体老线工程学习思路与模块地图
1.1 为什么选verilog-ethernet而不是直接调现成IP
很多人第一反应是：Vivado里有Ethernet IP核，Quartus里也有三速以太网IP，干嘛还要去啃开源RTL？这个问题我刚开始也纠结。商业IP核当然稳定，但有几个实际痛点：第一，IP核配置界面复杂，MAC和PCS/PMA层层嵌套，生成的代码动不动就几百个文件，新手很难理清数据从哪进来、又从哪出去；第二，IP核大多是黑盒子，综合后根本看不到内部逻辑，信号名也极其晦涩；第三，很多IP核是需要付费授权的，学习板自带的免费版本往往限制速率或端口数量。
verilog-ethernet这个工程最吸引人的点在于，它把整个链路拆得特别干净，TCP/IP协议栈里几个关键角色——MAC收发、ARP请求/应答、UDP打包/解包、ICMP回显——都做成了独立模块。你可以在一个顶层文件里看到所有模块的连接关系，每一段都是可以读懂的RTL代码。对于学习而言，“能读懂每一行”比“能用起来”重要得多，这也是我推荐它的主要原因。
而且这个工程不挑厂商。它是标准Verilog写的，至少可以用于Xilinx、Altera/Intel（现在叫Intel FPGA）以及高云、易灵思等国产FPGA平台。没有AXI接口绑死，没有vendor primitives，只要你板子上的PHY芯片支持GMII/RGMII标准，基本都能移植。这一点非常难得，我后来在一颗高云FPGA上也跑通了这套协议栈，只改了个别引脚约束和时钟频率。
1.2 从串口思维到网络思维的转变
如果你之前只做过UART、SPI、I2C这类低速总线，第一次接触以太网可能会有点懵。串口协议简单到什么程度呢？一帧数据就是起始位加数据位加停止位，没有包的概念，也没有目的地址和校验需求，发错丢了自己知道重发就行。但以太网不是这个玩法。
以太网定义了MAC帧的结构，TCP/IP协议栈又在这个上面定义IP报文、UDP报文、ARP报文。每一个报文都有固定字段，源地址、目的地址、类型、长度、校验，缺一不可。也就是说，你要在FPGA里发一个UDP包，实际上要完成这些事：
- 构造MAC帧头（目的MAC、源MAC、类型），类型字段需要填0x0800表示IPv4；
- 构造IP头（版本号、头长度、总长度、协议号17表示UDP、源IP、目的IP），还要算IP头校验；
- 构造UDP头（源端口、目的端口、长度、校验和，校验和可以直接置0，这是允许的）；
- 把所有字段按字节拼接，送入MAC发送模块，加上前导码和CRC校验。
同样，收到一个UDP包，你要做的是逆过程：先解析MAC帧头，检查目的MAC是否匹配；然后看类型是IPv4还是ARP；如果是IPv4还要继续解析IP头，检查协议号是不是UDP；最后才从UDP头里读出端口号，把payload送到用户接口。
这个过程如果用软件做，几行代码就写完了，因为CPU是顺序执行的，有for循环、有堆栈、有动态内存。但FPGA没有“循环”的概念，没有“函数调用”，里面只有寄存器、组合逻辑、状态机和FIFO。协议里的每一步都必须对应到一组状态转移。verilog-ethernet最大的贡献，就是把这个转换过程实现了出来，并且做得足够模块化，让你能顺着代码把协议走一遍。
1.3 工程目录与模块地图
我clone的是GitHub上alexforencich/verilog-ethernet仓库，当前比较通用的分支是master。整个工程rtl目录下文件很多，但真正核心的模块，对我们理解UDP通信流程来说，可以按功能分成这几组：
- 底层收发：
eth_mac_1g_rgmii_fifo、eth_mac_1g_gmii_fifo，这两个是带FIFO的MAC层收发器，前一个适配RGMII接口的PHY，后一个适配GMII接口的PHY； - 网络层解析：
eth_arbiter、eth_parser，一个是多路发送仲裁器，一个是接收解析器； - ARP相关：
arp_cache、arp_ctrl，负责ARP缓存表的管理和ARP请求/应答状态机； - UDP相关：
udp、udp_lite、udp_checksum_gen、udp_checksum_gen_16，负责UDP包的封装和解析； - IP相关：
ip、ip_arbiter，负责IP头的生成和校验、多端口复用； - 顶层封装：
eth_udp、eth_udp_tx、eth_udp_rx，这几个是把UDP收发逻辑打包好的简易接口，对我们学习最友好。
这里有个直接的切入路径。你不需要一上来就把所有模块都读懂，很多人面对几十个.v文件时直接放弃，就是因为想一口吃成胖子。正确的姿势是：先只看eth_udp_tx和eth_udp_rx这两个顶层封装，搞清楚发送侧从用户接口收到数据之后是怎么一步步封装成UDP包的，接收侧又是怎么一步步解析出payload的。等你把这两条主路径摸清楚了，再回头去看ARP、IP、MAC这些底层模块，会轻松很多。
2. 核心模块拆解与实操细节
2.1 发送通路：从用户数据到以太网帧
我们先走发送通路。eth_udp_tx这个模块，顶层输入信号最关键的有这几个：
clk：用户时钟，我用的100MHz；rst：复位信号（高电平有效）；s_axis_tdata：待发送的用户数据，位宽默认是8bit，可配置为16bit或32bit；s_axis_tvalid：数据有效标志；s_axis_tready：下游反压信号，告诉上游我能不能接收；s_axis_tlast：一帧数据的最后一个字节标志；m_axis_tdata、m_axis_tvalid、m_axis_tready：连接内部IP层发送接口的AXI-Stream信号。
看到这里你会理解一个关键点：FPGA的协议栈模块之间，大多用AXI-Stream接口互连。这种接口就是valid/tready握手，再加data和可选的tlast/tuser。握手规则很简单：一个数据拍只有在valid和tready同时为高时才能真正传输，tready可以拉低表示当前下游忙。很多新人第一次看到AXI-Stream会发怵，但实际上它就是带握手的流水线，你把这个逻辑捋顺了，后面看任何IP核都不会再有障碍。
eth_udp_tx内部做的事情，是替你把UDP头、IP头、MAC头都拼好。它有缓冲机制，先把用户数据存在内部FIFO里，然后从FIFO读出来，按顺序先发送MAC头，再发IP头，再发UDP头，最后发用户payload。你会发现这个模块并没有处理CRC，因为CRC校验在更底层的eth_mac_1g_*模块里完成，MAC层发送模块会在帧末尾自动附加4字节CRC。
了解位宽配置也很重要。我之前图省事，直接用8位数据通路，然后把所有MAC地址、IP地址用十六进制硬编码进去。后来尝试修改成32位位宽，省了很多时钟周期，因为一个时钟可以传4字节，但代价是各个头字段的对齐变得复杂了，比如IP头的总长度字段原本是字节流中第17、18字节的位置，在32位位宽下可能分布在两个不同的数据拍里，处理方式完全不同。这里我的建议是：学习阶段就用8位位宽跑通功能，不要上来就追求性能。
2.2 接收通路：解析MAC、IP、UDP头
接收通路对应eth_udp_rx模块。它从MAC层接收完整以太网帧，内部解析逻辑主要是一个大状态机，整个状态机的状态大致是这样走的：
- 等待前导码（MAC模块已经处理，用户层看不到）；
- 接收并缓存MAC目的地址、源地址；
- 解析以太网类型字段；
- 如果是IPv4，继续接收IP头，校验版本号、头长度、协议号；
- 如果协议号是UDP，继续接收UDP头，解析源端口、目的端口和长度；
- 把UDP payload通过AXI-Stream接口输出，同时在
tuser信号上带上端口号、IP地址等信息。
这个状态机其实就是软件协议栈里用if实现的逻辑，在FPGA里给换成了状态转移。读懂了它，你就理解了FPGA处理网络协议的通用套路。
接收侧有一个比较容易被忽略的内部细节：地址过滤。eth_udp_rx会根据你自己设置的本地MAC地址和IP地址，判断收到的帧是不是发给自己的。如果目的MAC不是广播地址（FF:FF:FF:FF:FF:FF）也不是本地MAC，整个帧会被直接丢弃。IP地址同理。所以如果你的测试工程一直收不到数据，先别急着查逻辑，检查一下自己设置的目的MAC对不对，这是非常常见的低级错误。
2.3 ARP模块的双重身份
ARP在整个协议栈里承担两个角色：一个是主动发起查询，比如你从FPGA往电脑发UDP，但不知道电脑的MAC地址，就需要发一个ARP请求，让电脑回一个ARP应答；另一个是被动响应，比如电脑ping FPGA（ICMP回显其实由eth_udp里的ICMP模块处理），或者电脑主动向FPGA发UDP，前提是先通过ARP知道FPGA的MAC地址，此时FPGA需要回一个ARP应答。
arp_cache是一个简易的MAC/IP地址缓存表，默认容量是4条，表的每一项存一对IP地址和MAC地址。arp_ctrl是状态机，维护这个缓存表的查询、更新、无效化。如果你在测试中发现FPGA发的第一个UDP包电脑收不到，但后面就正常了，很可能就是第一次发送时ARP缓存为空，FPGA先发了一个ARP请求，电脑收到后更新了缓存，第二个时刻才能正常发送数据。这不是什么神秘问题，而是协议流程的正常现象。很多网络调试软件（比如Wireshark）能看到这段交互过程，抓包一看就明白。
严格来说，FPGA里的ARP缓存实现非常简陋，和电脑操作系统里那种完整的ARP老化机制完全没法比。但这也正是开源工程的价值所在：给你看的是最精简、最核心的实现，让你不至于被琐碎的细节淹没。学习时抓住“请求-应答-缓存”这个主流程就够了。
2.4 跨时钟域与FIFO带来的稳定性保障
verilog-ethernet工程里，发送和接收数据通路上都加了FIFO模块，最典型的是eth_mac_1g_rgmii_fifo里面的axis_fifo_adapter。为什么要加FIFO？因为PHY芯片的时钟和FPGA逻辑侧的时钟往往不是同一个频率甚至不同相位，FIFO起到了跨时钟域缓冲的作用。MAC层收发数据时，数据要跟着PHY提供的RX时钟，而用户逻辑可能跑在自己独立的时钟域，频率还未必成整数倍关系，这时候如果没有FIFO做缓冲，数据直接跨时钟域基本必崩。
初学者容易忽略这些FIFO的存在，总觉得“我发一个字节，它就应该立刻出去”。实际上在百兆/千兆以太网环境下，数据流是连续的，而用户的业务数据往往是突发性的，FIFO天然肩负了“削峰填谷”的任务。这也是为什么很多商业IP核会围绕FIFO做一堆配置选项的原因。
我在实际测试中还发现一个和FIFO深度有关的坑：如果发送FIFO深度太小，当突发数据超出FIFO容量时，即便下游持续从FIFO读数据，上游也仍然会被反压，表现就是tready周期性拉低。此时如果用户逻辑没有正确处理握手信号，就会丢数据或者把数据顺序搞乱。好在这套开源工程的FIFO模块配置很灵活，默认深度用完没问题，你可以按需调整。
3. 仿真环境搭建与一次完整UDP往返测试
3.1 用iverilog搭建学习级仿真环境
商业仿真工具当然也可以用，比如Vivado自带的xsim或者Modelsim。但我个人非常推荐学习阶段用iverilog加GTKWave，原因是它足够轻量、免授权、启动速度快，还完美支持Verilog-2001和大部分SystemVerilog语法，非常适合跑这种中等规模的开源工程。尤其在看波形做调试时，GTKWave虽然界面朴素，但它是开源的，你用起来没心理负担，也不怕license过期，这点比商业工具舒服很多。
你需要先安装工具。Ubuntu/Debian下一条命令解决：
sudo apt-get install iverilog gtkwaveWindows系统可以到iverilog官网下载安装包，GTKWave也有Windows版。安装完后验证一下：
iverilog -V gtkwave --version能看到版本号就说明工具链没问题。接下来要把verilog-ethernet仓库clone下来，我用的是：
git clone https://github.com/alexforencich/verilog-ethernet.gitclone完成后，rtl目录下就是所有源代码。注意这个工程很多文件是SystemVerilog写的（.sv后缀），iverilog对SystemVerilog的解析能力算是够用，但遇到一些复杂的接口（interface）语法还是可能报错。不过eth_udp_tx、eth_udp_rx这个系列顶层模块是纯Verilog，直接用没问题。
3.2 编写UDP回环测试的testbench
我写了一个简单的testbench，目的很明确：模拟PC通过GMII接口向FPGA发送一个ARP请求，然后再发送一个UDP报文，同时观察FPGA是不是能通过GMII发送ARP应答和UDP回环数据。回环的意思是，FPGA收到UDP数据之后，原封不动把这个payload再作为新的UDP数据发送回电脑。这个思路最简单，也最能验证收发两条通路是否都正常。
Testbench里最核心的一段，是构造一个以太网帧并驱动到FPGA的GMII接收接口。注意GMII接口的标准时序是：先在rx_dv为高的情况下，每个rx_clk上升沿送一个字节数据到rxd上。前导码是7个字节的0x55，第8个字节是帧起始定界符SFD，值为0xD5，然后才是真正的MAC帧内容。
我摘一段UDP发包驱动的核心逻辑：
task send_udp_frame; // 假设已经完成ARP流程 // 目的MAC：10:11:12:13:14:15 send_byte(8'h10); send_byte(8'h11); send_byte(8'h12); send_byte(8'h13); send_byte(8'h14); send_byte(8'h15); // 源MAC：aa:bb:cc:dd:ee:ff send_byte(8'haa); send_byte(8'hbb); send_byte(8'hcc); send_byte(8'hdd); send_byte(8'hee); send_byte(8'hff); // 以太网类型：IPv4 send_byte(8'h08); send_byte(8'h00); // IP头开始，此处省略细节，仅示意 send_byte(8'h45); // version+ihl // 继续构造IP头... // UDP头 send_byte(8'h30); // 源端口高字节 send_byte(8'h39); // 源端口低字节 // payload send_byte(8'hde); send_byte(8'had); send_byte(8'hbe); send_byte(8'hef); endtask你肯定会问：每次都要手动构造这么多字段，不累吗？其实学习阶段就得这么干，因为只有亲手把字节一个个填进去，你才会对协议格式有肌肉记忆。后面写自动化脚本才不慌。如果你实在不想手写，工程自带了一个Python脚本py/udp.py可以生成完整UDP帧的十六进制文本，我后来就是靠这个与testbench配合，能省不少事。
3.3 观察波形：ARP请求与UDP回环
仿真跑完之后用GTKWave打开vcd文件，先把关键信号拖进来：rx_clk、tx_clk、rx_dv、rxd、tx_en、txd、udp_rx_hdr_valid、udp_rx_payload_axis_tdata、udp_tx_payload_axis_tvalid。逐一观察就能看到完整流程。
首先会看到FPGA发出一个ARP请求，arp_ctrl状态机从IDLE跳到SEND_REQUEST。接下来电脑回ARP应答，FPGA收到后在arp_cache里写入对应条目。然后我构造的UDP帧开始输入，此时eth_udp_rx模块内部状态机会依次经历MAC解析、IP解析、UDP解析三个阶段，能从udp_rx_hdr_valid信号捕获到一个脉冲，紧接着udp_rx_payload_axis_tvalid拉高，payload数据从udp_rx_payload_axis_tdata逐字节输出。
与此同时，回环逻辑把这些payload数据接到发送侧。eth_udp_tx模块开始忙碌起来，先从内部FIFO读出用户数据，然后拼接MAC头、IP头、UDP头，最后体现在GMII发送接口上，也就是tx_en拉高、txd上出现完整以太网帧。整个过程在波形上看起来就是两组“包”的输入输出节奏，节奏之间有一个几个周期的处理延时，这个延时主要花在FIFO写入、头字段拼接和校验计算上。
这里有个值得注意的观察点：接收UDP帧时，tlast信号和payload数据的对齐非常重要。如果tlast比最后一个有效数据晚了一个周期，接收端会认为帧还没有结束，导致整个包被丢弃。这个开源工程里，发送侧由eth_udp_tx负责把tlast放在正确位置，接收侧解析payload长度来确立tlast时机，两者配合得比较严密，你从波形上能看到tlast与最后一个数据同时有效的干净波形。
3.4 上板前仿真的边界：不要跳过综合视角
仿真通过并不代表上板一定能跑。很多人在仿真里验证了功能就急着去写约束文件，结果综合后动不动就报时序违例。这个工程虽然不难，但如果你在板子上把GMII时钟放到50MHz以上，又不加时序约束，那综合器就只能瞎猜路径延时，结果大概率跑不起来。
仿真验证的是“功能性正确”，而综合实现验证的是“时序性正确”。这两个维度在FPGA工程里缺一不可。所以我给自己定的习惯是，每个模块在仿真通过之后，至少做一个OOC（out-of-context）综合，看一下时钟频率能不能达到设计要求，内部FIFO有没有被优化掉，关键路径上的组合逻辑是否过长。只要某一级状态机的状态排队列太深，就有可能形成长组合逻辑链路，导致时钟频率上不去。
verilog-ethernet这套工程本身时序设计是比较好的，因为它经过了多个板卡的实测验证，所以一般不会有时候问题。但如果你改了位宽、加了逻辑，那就一定要重新做时序收敛检查，不要因为“开源工程”三个字就掉以轻心。
4. 常见问题与排查经验速查
4.1 数据收发完全不通，从哪里查起
遇到收发完全不通的情况，我推荐的排查顺序是：
- 先看PHY芯片的链路状态，link信号有没有拉高，如果没有，说明物理层都没通；
- 用示波器或逻辑分析仪看PHY的TX_CLK、RX_CLK有没有时钟输出；
- 检查复位时序，首先要保证PHY的复位引脚释放正确，FPGA内部协议栈的复位也要保持足够长时间；
- 用抓包软件（Wireshark）看电脑网卡有没有收到FPGA发来的任何数据，哪怕是乱帧也能说明MAC发送通路是活的；
- 如果电脑收到了数据但解析不出来，检查MAC地址、IP地址、端口号是否和FPGA内部配置一致。
如果是仿真阶段就完全不通，那要先看数据有没有从测试平台的驱动进去，用波形确认前导码和SFD是否正确。经常有人把SFD写成0x55，那MAC层会把帧开始位置认错，后面全乱套。
4.2 ARP一直请求不到应答
ARP请求发出去但没有应答，常见原因有三个。一是FPGA的源MAC或者源IP地址设置得和网络上其他设备冲突，导致ARP应答被网络里的其他设备干扰；二是目的IP地址写错了，电脑收到ARP请求后发现目的IP不对，根本不理会；三是电脑防火墙把ARP广播过滤了，虽然少见但确实存在，尤其是某些安全软件接管了网络协议栈之后。
这里我要单独提一个我踩过的坑：MAC地址的字节顺序最容易搞混。以太网传输是多字节字段按大端序，也就是高字节先传，但很多人直接把字符串“aa:bb:cc”翻译成字节数组时方向搞反了，结果报文里的MAC地址完全错位。ARP请求发出去之后，抓包看是能找到，但对端根本识别不了。处理方式是，把MAC地址的每个字节按顺序写进逻辑，不要在脑子里做“翻转”，写代码时严格按抓包工具显示的顺序来，就不会错。
4.3 UDP端口和校验和的坑
发送侧UDP校验和可以直接置0，这在IPv4协议里是合法操作，接收端也不会校验这段。但要注意，即使是置0，UDP头的长度字段不能错，UDP长度是指UDP头加payload的总长度，单位是字节。你如果少算一个头的长度，接收端会认为payload长度不对，数据包可能被截断或者被丢弃。
还有一个相对隐蔽的问题是，IP头的总长度字段是包括IP头本身在内的整个IP报文长度，而不是只算payload。很多人在手写帧的时候，IP总长度填的是payload数量，结果接收端一算，印象中应该更长的数据整体被截断了。这类错误用Wireshark抓包立刻能看出来，它会把“Length”字段标红。
4.4 时钟频率和约束策略
如果你在综合后遇到时序不收敛，建议先检查三处：跨时钟域FIFO有没有在约束文件里正确设置异步时钟组（set_clock_groups）；GMII/RGMII接口有没有对PHY时钟加input delay和output delay约束；复位释放逻辑有没有做异步释放同步采集。
初学者很容易在这上面耗费大量时间。我的经验是，先把所有不相关时钟用异步组隔离开，再对MAC接口加适当约束，80%的问题都能解决。如果你用的RGMII接口，还要再加上一个约束技巧：RGMII的RX数据是DDR采样，即上下沿都在采，需要IDELAY或者专门的DDR寄存逻辑，直接用GMII的流程去约束RGMII是行不通的。这个工程里eth_mac_1g_rgmii_fifo已经包含了ddio_in、ddio_out原语，你只要保证对应时钟和延迟约束到位即可。
4.5 仿真工具差异与平台适配细节
如果你是Vivado用户，直接用iverilog写好testbench之后也可以把rtl文件加到Vivado工程里做行为仿真，但需要留意源的扩展名。.sv文件在Vivado里默认会被识别为SystemVerilog，这没问题，但有些老版本的Vivado对interface语法支持不全，打开工程时会报错。如果只是想跑通UDP部分，建议只把eth_udp这个顶层和它依赖的几个核心模块加进去，别一股脑把整个rtl目录都加上，不然会拉进来一堆你可能根本用不到的模块，编译时间成倍增加。
在Quartus里操作类似。Quartus对SystemVerilog的支持也一般，如果遇到语法报错，优先检查是不是某些module使用了interface。遇到这种情况，可以先用iverilog验证功能，然后手动把需要的模块做一个“白名单列表”加入工程，其他模块不添加。这样既能控制编译范围，也能减少工具差异带来的麻烦。
最后聊一点实际体会
写到这里，verilog-ethernet的UDP协议栈学习主线算是过了一遍。这套开源工程给我的最大收获并不是某个模块本身，而是一种意识：网络协议不是只有软件才能实现，只要你能把协议的状态转移、字节拼接、校验计算转换成硬件逻辑，FPGA完全可以直接在物理层附近把网络包处理掉。这在图像采集、高速数据回传、工业控制这类对延迟敏感的场景非常关键。你不需要先把数据送到CPU走一遍协议栈，再决定如何去处理，而是可以在数据流经过FPGA的时候，用RTL直接完成组帧、过滤、转发，让CPU只做业务层面的决策。
我个人的体会是，学FPGA一定不能只停留在“点灯”和“流水灯”阶段，那不是FPGA的核心竞争力。真正让FPGA有价值的是它处理并行数据流的能力，而以太网协议栈恰好是一个特别好的实践载体。它既涉及状态机设计，又涉及跨时钟域处理，还涉及高吞吐数据通路的构造，一层层剥开之后你会发现，之前学的那些基础知识全部串起来了。
对于还想往下深入的朋友，我给你两个扩展方向：一个是想办法在发送FIFO里塞一些实际业务数据，比如把ADC采样结果直接打包成UDP帧发到电脑，这就是一个最简单的数据采集以太网上报系统；另一条是把接收侧的UDP payload按端口号做分发，比如端口5001收到的数据存到FIFO，端口5002收到的数据触发某个外设控制，从“回环”走向“真正处理”。等你把这两个小任务做完，你对FPGA网络通信的掌握程度，就和只调现成IP核的人彻底拉开差距了。
