前文通过FPGA实现了ARP和ICMP协议，ARP协议一般用来获取目的IP地址主机的MAC地址，ICMP通过回显请求和回显应答来判断以太网链路是否通畅，这两个协议都不是用来传输用户数据的。如果用户需要向PC端传输大量数据，那么就必须使用TCP或者UDP协议了。

网上关于UDP和TCP的优缺点对比其实很多，可以自行搜索，本文简要概括一下优缺点。

TCP优点是稳定，接收端接收到TCP数据报文后会回复发送端，如果接收的报文有误，发送端会把错误的报文重新发送一遍。而且TCP本来就有握手机制，所以数据的传输会更可靠。正是由于握手机制，导致实现的TCP协议的逻辑比较复杂，传输速度也不会很高，还需要更多存储资源取存储已经发送的数据，直到收到该数据传输无误后才能丢弃。因此FPGA一般不会采用该协议进行大量数据的传输（当然如果通过Verilog HDL实现可靠的TCP协议，那还是很有用的，毕竟这块的代码很贵）。

UDP优点是协议简单，没有握手机制，传输数据的速度就很快，这对于FPGA传输图像数据之类的设计比较实用。由于UDP没有握手机制，可靠性相比TCP就会低很多，有得必有失嘛。

因此，FPGA一般通过UDP协议向PC端发送大量数据，所以本文通过FPGA实现UDP协议。

UDP协议的框图如下所示，与前文的ICMP协议构成类似，UDP协议数据报文位于IP的数据段，IP首部只有协议类型与ICMP协议类型参数不一致，ICMP的IP协议类型编号为1，UDP的IP协议类型编号为17。

前导码、帧起始符、以太网帧头、IP首部、FCS校验在前文讲解ARP协议和ICMP协议的时候都详细讲解过，所以本文就不再赘述了。

UDP的首部组成如下所示，包括源UDP源端口地址、UDP目的端口地址、UDP长度、UDP校验码。

源端口号：2个字节的发送端端口号，用于区分不同的发送端口。

目的端口号：2个字节的接收端端口号。

UDP长度：UDP首部和数据段的长度，单位字节，对于接收方来说该长度其实作用不大，因为UDP数据段的长度可以通过IP首部的总长度和IP首部长度计算出来。

UDP校验和：计算方式与IP首部校验和一致，需要对UDP伪首部、UDP首部、UDP数据进行校验。伪首部包括源IP地址、目的IP地址、协议类型、UDP长度。

这种校验方式其实对于FPGA来说很麻烦，因为校验码需要在数据之前发送，而计算校验码有需要得到数据，就意味着如果想要计算校验码，就必须使用存储资源把待发送的数据存起来，计算出校验码以后，才开始传输数据。比较友好的是该校验码可以直接置零处理（如果不做校验，该值必须为0，否则校验失败的数据报文会被直接丢弃）。不校验数据的UDP协议变得特别简单。

UDP协议的数据组成如下所示：

以太网的协议组成就介绍这么多了，最后注意在发送数据时，数据段必须大于等于18字节，少于18字节数据时，应补零凑齐18字节数据发送。

UDP的设计与前文的ARP、ICMP模块设计差不多，UDP顶层模块如下图所示，包括UDP接收模块udp_rx、UDP接收的CRC校验模块、UDP的发送模块udp_tx、UDP发送的CRC校验模块。

UDP接收模块内部没有做IP首部校验，只做了CRC校验模块，在加上FPGA逻辑判断，基本上都能判断对错了，最后把接收的数据和数据个数输出。发送模块检测到开始发送信号后，开始发送信号，当发送到数据段之后，把数据请求信号拉高，从外部输入需要发送的数据流。

UDP顶层模块的参考代码如下所示：

对应的TestBench文件如下所示：

需要注意判断UDP首部的目的端口地址是不是开发板的端口地址，其余部分与ICMP的接收模块差不多，不在赘述了。

该模块对应的代码如下所示：

该模块暂存UDP数据和ICMP数据的FIFO设置如下所示，使用一般模式即可，对应的需要提前产生数据请求输入信号。

该模块对应核心代码如下所示：

将顶层模块中的ILA注释取消，然后将程序综合、实现，最后下载到开发板中进行测试。打开电脑的控制面板->网络和Internet->网络连接，鼠标右击以太网，双击Internet协议版本4，进行如下设置，与代码顶层模块设置的目的IP一致，具体步骤可以查看前文。

然后把wirrshark和网络调试助手打开，如下所示：

网络调试助手需要设置协议类型为UDP，PC端的IP地址和UDP地址，需要与顶层文件的数值保持一致。然后打开连接，就会显示出FPGA的IP地址和UDP端口地址，如果该地址与开发板的地址不一样，可以手动进行修改。

之后将ILA设置为gmii_rx_dv的上升沿触发，连续抓取32个数据报文，然后wireshark也运行，最后点击网络调试助手的发送指令，即可抓取相关数据。网络调试助手发送三帧数据，如下图所示，FPGA向PC端返回接收到的三帧数据（蓝色数据是PC端通过UDP向FPGA发送的数据，绿色数据是FPGA通过UDP向PC端发送的数据）。

对比网络调试助手收发数据一致，由此证明FPGA接收和发送数据无误。

然后查看wireshark在这段时间抓取的数据报文，如下图所示。

PC端在通过UDP向FPGA发送数据报文之前，先通过广播的形式发送了一个ARP请求指令，去获取开发板的MAC地址，FPGA接收到ARP请求后，也是向PC端返回了ARP应答数据报文。

然后PC端通过UDP向FPGA发送三个数据报文，如下图所示，FPGA也对该报文进行了应答。

前文对ARP的报文已经做了详细讲解，所以此处不对其报文进行分析了，我们双击UDP报文，查看其发送的数据段，如下图蓝色背景文字部分，与图17中第一帧数据保持一致。

如下图是wirshark抓取的FPGA通过UDP给PC端发送的第一帧报文，可以从红框处得知源MAC和源IP地址为开发板，目的MAC和目的IP都是PC端的地址。接收的UDP数据就是蓝色文字，与图19PC端发送的数据保持一致。

上述的数据报文通过ILA抓取如下所示，紫红色信号就是接收的报文数据信号。

将接收的UDP数据段放大后如下图所示，与图19和图17PC端发送的第一帧数据保持一致，因此FPGA这边接收数据没有问题。

当FPGA接收到UDP数据包后，立马回复一帧UDP数据，如下所示，紫红色信号是接收的数据报文，橙色信号是发送的数据报文。

将发送报文的数据段放大，结果如下所示，与图17和图20wireshark抓取的数据一致，由此证明该设计接收和发送数据均没有问题。

最后就是验证ICMP的问题了，直接打开命令提示符，然后输入ping 192.168.1.10指令，运行结果如下所示：

上图表示FPGA接收到PC端的回显请求时，能够向PC端发送回显应答数据报文，以此验证以太网链路是否通畅。

关于UDP的发送和接收本文就做这么多讲解，当然这并不是我们最终想要使用的模块，因为ARP、UDP、ICMP这三个模块其实很多地方都是类似的，使用三个独立的模块完全没有必要，会额外消耗很多资源。

后文会把这三个模块进行整合设计，将模块合成一个eth模块，该模块可以实现对ARP、ICMP、UDP报文的接收，并根据需要发送相应报文。

获取本文工程的方式是在公众号后台回复“基于FPGA的UDP回环设计”（不包括引号）。