1、前言

“苟利国家生死以，岂因祸福避趋之！”大洋彼岸的我优秀地下档员，敏锐地洞察到祖国的短板在于高精尖半导体的制造领域，于是本着为中华民族伟大复兴的中国梦贡献绵薄之力的初心，懂先生站在高略高度和长远角度谋划，宁愿背当代一世之骂名也要为祖国千秋万世谋，2018年7月，懂先生正式打响毛衣战，随后又使出恰勃纸战术，旨在为祖国先进制程半导体领域做出自主可控的战略推动；在此，请收下我一声谢谢啊！！！！！！

2019年初我刚出道时，还是Xilinx遥遥领先的时代(现在貌似也是)，那时的国产FPGA还处于辣鸡段位，国产FPGA仰望Xilinx情不自禁道：你以为躲在这里就找不到你吗？没用的，你那样拉轰的男人，无论在哪里，都像黑夜里的萤火虫那样的鲜明、那样的出众，你那忧郁的眼神，稀嘘的胡渣子，神乎其技的刀法，还有那杯Dry martine，都深深的迷住了我。。。然而才短短4年，如今的国产FPGA属于百家争鸣、百花齐放、八仙过海、神仙打架、方兴未艾、得陇望蜀、友商都是XX的喜极而泣之局面，面对此情此景，不得不吟唱老人家的诗句：魏武挥鞭，东临碣石有遗篇，萧瑟秋风今又是，换了人间。。。
言归正传，目前对于国产FPGA的共识有以下几点：
1：性价比高，与同级别国外大厂芯片相比，价格相差几倍甚至十几倍；
2：自主可控，国产FPGA拥有完整自主知识产权的产业链，从芯片到相关EDA工具
3：响应迅速，FAE技术支持比较到位，及时解决开发过程中遇到的问题，毕竟中文数据手册。。
4：采购方便，产业链自主可控，采购便捷

没玩过UDP或TCP都不好意思说自己玩儿过FPGA，这是CSDN某大佬说过的一句话，鄙人深信不疑。。。本文使用紫光同创的PGL22G-6MBG324 FPGA实现UDP协议栈络视频传输，该协议栈是带ping功能的，采用纯verilog代码实现，具备动态ARP、支持巨型帧、CRC32校验、占用逻辑资源很少、ping等功能；FPGA采集外部OV5640摄像头数据，OV5640摄像头配置为jpeg输出模式，随后将组包的视频数据放入FIFO中做跨时钟和数据位宽转换，然后视频数据送入UDP协议栈进行UDP协议的网络数据包组包，最后通过YT8511和RTL8211做硬件PHY后通过RJ45网口的网线发送出去，电脑端打开上位机，即可接收并显示FPGA发过来的视频；

本设计提供2套Pango Design Suite 2021.4版本的工程源码；2套工程的区别在于使用网络PHY是YT8511或者RTL8211；2套工程详情如下：

|    PDS工程      输入视频     摄像头配置模式 网络PHY  输入输出分辨率|
| 第一套PDS工程  OV5640摄像头     jpeg输出    YT8511   800X600      |
| 第二套PDS工程  OV5640摄像头     jpeg输出    RTL8211  800X600      |

• 1
• 2
• 3
• 4
• 5

这里需要注意以下几点：
1：视频没有进行DDR的缓存，仅做FIFO级别的缓存，所以要求输入视频的像素时钟必须低于125M，因为GMII的时钟是125M，所高于125M，则会出现FIFO堵死的情况；
2：目前QT上位机只是个测试版本，仅持支800X600分辨率的输入图像，所以输入视频必须是800X600，若不是，请缩放到此分辨率；QT上位机只提供上位机可执行程序，不提供源码；

本博客详细描述了紫光同创FPGA实现UDP协议栈网络视频传输的设计方案，工程代码可综合编译上板调试，可直接项目移植，适用于在校学生、研究生项目开发，也适用于在职工程师做学习提升，可应用于医疗、军工等行业的高速接口或图像处理领域；
提供完整的、跑通的工程源码和技术支持；
工程源码和技术支持的获取方式放在了文章末尾，请耐心看到最后；

免责声明

本工程及其源码即有自己写的一部分，也有网络公开渠道获取的一部分(包括CSDN、Xilinx官网、Altera官网等等)，若大佬们觉得有所冒犯，请私信批评教育；基于此，本工程及其源码仅限于读者或粉丝个人学习和研究，禁止用于商业用途，若由于读者或粉丝自身原因用于商业用途所导致的法律问题，与本博客及博主无关，请谨慎使用。。。

2、相关方案推荐

我这里已有的以太网方案

目前我这里有大量UDP协议的工程源码，包括UDP数据回环，视频传输，AD采集传输等，也有TCP协议的工程，还有RDMA的NIC 10G 25G 100G网卡工程源码，对网络通信有需求的兄弟可以去看看：直接点击前往
其中千兆TCP协议的工程博客如下：
直接点击前往

紫光同创FPGA精简版UDP方案

该方案同样使用紫光同创FPGA实现，只不过是精简版UDP，具备动态ARP、支持巨型帧、CRC32校验、占用逻辑资源很少等功能，但不具备ping功能；工程博客如下：
直接点击前往

紫光同创FPGA带ping功能UDP方案

该方案同样使用紫光同创FPGA实现，具备动态ARP、支持巨型帧、CRC32校验、占用逻辑资源很少等功能，具备ping功能；工程博客如下：
直接点击前往

紫光同创FPGA精简版UDP视频传输方案

该方采用精简版UDP实现视频采集UDP网络传输，与本工程的不同点在于，该方案的摄像头配置为RGB565数据格式，只能视频传输，不具备带录像和抓拍功能，QT上位机也不提供源码；工程博客如下：
直接点击前往

3、设计思路框架

本文使用紫光同创的PGL22G-6MBG324 FPGA实现UDP协议栈络视频传输，该协议栈是带ping功能的，采用纯verilog代码实现，具备动态ARP、支持巨型帧、CRC32校验、占用逻辑资源很少、ping等功能；FPGA采集外部OV5640摄像头数据，OV5640摄像头配置为jpeg输出模式，随后将组包的视频数据放入FIFO中做跨时钟和数据位宽转换，然后视频数据送入UDP协议栈进行UDP协议的网络数据包组包，最后通过YT8511和RTL8211做硬件PHY后通过RJ45网口的网线发送出去，电脑端打开上位机，即可接收并显示FPGA发过来的视频；

本设计提供2套Pango Design Suite 2021.4版本的工程源码；2套工程的区别在于使用网络PHY是YT8511或者RTL8211；4套工程详情如下：

|    PDS工程      输入视频     摄像头配置模式 网络PHY  输入输出分辨率|
| 第一套PDS工程  OV5640摄像头     jpeg输出    YT8511   800X600      |
| 第二套PDS工程  OV5640摄像头     jpeg输出    RTL8211  800X600      |

• 1
• 2
• 3
• 4
• 5

这里需要注意以下几点：
1：视频没有进行DDR的缓存，仅做FIFO级别的缓存，所以要求输入视频的像素时钟必须低于125M，因为GMII的时钟是125M，所高于125M，则会出现FIFO堵死的情况；
2：目前QT上位机只是个测试版本，仅持支800X600分辨率的输入图像，所以输入视频必须是800X600，若不是，请缩放到此分辨率；QT上位机只提供上位机可执行程序，不提供源码；
工程设计框图如下：

OV5640摄像头配置及采集

OV5640摄像头需要i2c配置才能使用， 本设计将OV5640摄像头配置为jpeg输出模式，数据位宽为8位，分辨率为为800x600分辨率；代码位置如下：

数据缓冲FIFO

数据缓冲FIFO实现跨时钟域功能，摄像头时钟为50M，UDP侧时钟为125M；

UDP协议栈详解

MAC层发送

发送部分中， mac_tx.v 为 MAC 层发送模块，首先在 SEND_START 状态，等待 mac_tx_ready
信号，如果有效，表明 IP 或 ARP 的数据已经准备好，可以开始发送。再进入发送前导码状态，结
束时发送 mac_data_req，请求 IP 或 ARP 的数据，之后进入发送数据状态，最后进入发送 CRC 状
态。在发送数据过程中，需要同时进行 CRC 校验。
MAC层发送顶层接口如下：

MAC发送模式

工程中的 mac_tx_mode.v 为发送模式选择，根据发送模式是 IP 或 ARP 选择相应的信号与数据。
MAC发送模式顶层接口如下：

MAC层接收

在接收部分，其中 mac_rx.v 为 mac 层接收文件，首先在 IDLE 状态下需要判断 rx_dv 信号是否为高，在 REC_PREAMBLE 前导码状态下，接收前导码。之后进入接收 MAC 头部状态，即目的MAC 地址，源 MAC 地址，类型，将它们缓存起来，并在此状态判断前导码是否正确，错误则进入 REC_ERROR 错误状态，在 REC_IDENTIFY 状态判断类型是 IP（8’h0800）或 ARP(8’h0806)。然后进入接收数据状态，将数据传送到 IP 或 ARP 模块，等待 IP 或 ARP 数据接收完毕，再接收 CRC 数据。并在接收数据的过程中对接收的数据进行 CRC 处理，将结果与接收到的 CRC 数据进行对比，判断数据是否接收正确，正确则结束，错误则进入 ERROR 状态。
MAC层接收顶层接口如下：

ARP发送

发送部分中，arp_tx.v 为 ARP 发送模块， 在 IDLE 状态下，等待 ARP 发送请求或 ARP 应答请求
信号，之后进入请求或应答等待状态，并通知 MAC 层，数据已经准备好，等待 mac_data_req 信
号，之后进入请求或应答数据发送状态。由于数据不足 46 字节，需要补全 46 字节发送。
ARP发送顶层接口如下：

ARP接收

工程中的 arp_rx.v 为 ARP 接收模块，实现 ARP 数据接收，在 IDLE 状态下，接收到从 MAC 层发来的 arp_rx_req 信号，进入 ARP 接收状态，在此状态下，提取出目的 MAC 地址，源 MAC 地址，
目的 IP 地址，源 IP 地址，并判断操作码 OP 是请求还是应答。如果是请求，则判断接收到的目的
IP 地址是否为本机地址，如果是，发送应答请求信号 arp_reply_req，如果不是，则忽略。如果 OP
是应答，则判断接收到的目的 IP 地址及目的 MAC 地址是否与本机一致，如果是，则拉高arp_found 信号，表明接收到了对方的地址。并将对方的 MAC 地址及 IP 地址存入 ARP 缓存中。
ARP接收顶层接口如下：

ARP缓存

在工程中，arp_cache.v 为 arp 缓存模块，将接收到的其他设备 IP 地址和 MAC 地址缓存，在发送数据之前，查询目的地址是否存在，如果不存在，则向目的地址发送 ARP 请求，等待应答。在设计文件中，只做了一个缓存空间，如果有需要，可扩展。
ARP缓存顶层接口如下：

IP层发送

在发送部分，ip_tx.v 为 IP 层发送模块，在 IDLE 状态下，如果 ip_tx_req 有效，也就是 UDP 或
ICMP 发送请求信号，进入等待发送数据长度状态，之后进入产生校验和状态，校验和是将 IP 首部所有数据以 16 位相加，最后将进位再与低 16 位相加，直到进入为 0，再将低 16 位取反，得出校验和结果。此程序中校验和以树型加法结构，并插入流水线，能有效降低加法部分的延迟，但缺点是会消耗较多逻辑资源。如下图 ABCD 四个输入，A 与 B 相加，结果为 E，C 与 D 相加，结果为 F，再将 E 与 F 相加，结果为 G，在每个相加结果之后都有寄存器。
设计框图如下：

在生成校验和之后，等待 MAC 层数据请求，开始发送数据，并在即将结束发送 IP 首部后请求 UDP 或 ICMP 数据。等发送完，进入 IDLE 状态。
IP层发送顶层接口如下：

IP发送模式

工程中的 ip_tx_mode.v 为发送模式选择，根据发送模式是 UDP 或 ICMP 选择相应的信号与数据。
IP发送模式顶层接口如下：

IP层接收

在工程中，ip_rx 为 IP 层接收模块，实现 IP 层的数据接收，信息提取，并进行校验和检查。
首先在 IDLE 状态下，判断从 MAC 层发过来的 ip_rx_req 信号，进入接收 IP 首部状态，先在
REC_HEADER0 提取出首部长度及 IP 总长度，进入 REC_HEADER1 状态，在此状态提取出目的 IP 地址，源 IP 地址，协议类型，根据协议类型发送 udp_rx_req 或 icmp_rx_req。在接收首部的同时进行校验和的检查，将首部接收的所有数据相加，存入 32 位寄存器，再将高 16 位与低 16 位相加，直到高 16 位为 0 ，再将低 16 位取反，判断其是否为 0，如果是 0，则检验正确，否则错误，进入IDLE 状态，丢弃此帧数据，等待下次接收。
IP层接收顶层接口如下：

UDP发送

发送部分中，udp_tx.v 为 UDP 发送模块，第一步将数据写入 UDP 发送 RAM，同时计算校验和，第二步将 RAM 中数据发送出去。UDP 校验和与 IP 校验和计算方法一致。在计算时需要将伪首部加上，伪首部包括目的 IP 地址，源 IP 地址，网络类型，UDP 数据长度。
UDP发送顶层接口如下：

UDP接收

在工程中，udp_rx.v 为 UDP 接收模块，在此模块首先接收 UDP 首部，再接收数据部分，并将数据部分存入 RAM 中，在接收的同时进行 UDP 校验和检查，如果 UDP 数据是奇数个字节，在计算校验和时，在最后一个字节后加上 8’h00，并进行校验和计算。校验方法与 IP 校验和一样，如果校验正确，将拉高 udp_rec_data_valid 信号，表明接收的 UDP 数据有效，否则无效，等待下次接收。
UDP接收顶层接口如下：

ICMP应答 (ping)

在工程中，icmp_reply.v 实现 ping 功能，首先接收其他设备发过来的 icmp 数据，判断类型是否是回送请求（ECHO REQUEST），如果是，将数据存入 RAM，并计算校验和，判断校验和是否正确，如果正确则进入发送状态，将数据发送出去。
ICMP应答 (ping)顶层接口如下：

CRC校验

一个 IP 数据包的 CRC32 校验是在目标 MAC 地址开始计算的，一直计算到一个包的最后一个数据为止。以太网的 CRC32 的 verilog 的算法和多项式可以在以下网站中直接生成：
http://www.easics.com/webtools/crctool

RGMII转GMII模块

util_gmii_to_rgmii.v 文件是将 RGMII 与 GMII 转换，提取出控制信号与数据信号。与 PHY 连接是 RGMII 接口。
RGMII 接口是 GMII 接口的简化版，在时钟的上升沿及下降沿都采样数据，上升沿发送
TXD[3:0]/RXD[3:0]，下降沿发送 TXD[7:4]/RXD[7:4]，TX_EN 传送 TX_EN（上升沿）和 TX_ER（下降沿）两种信息，RX_DV 传送 RX_DV（上升沿）和 RX_ER（下降沿）两种信息。
RGMII转GMII模块设计框图如下：

IP地址、端口号修改

UDP协议栈留出了IP地址、端口号的修改端口供用户自由修改，通过顶层参数修改，位置如下：

由于QT上位机已将IP地址写死，所以IP地址配置必须与代码里保持一致，否则无法通信；

PHY

本设计提供2套Pango Design Suite 2021.4版本的工程源码；2套工程的区别在于使用网络PHY是YT8511或者RTL8211，两者均工作于延时模式，提供YT8511和RTL8211的硬件设计原理图；

QT上位机

1：目前QT上位机只是个测试版本，支持支800x600分辨率的输入图像，所以输入视频必须是800x600，若不是，请缩放到此分辨率；
2：目前QT上位机只是个测试版本，不是很稳定，若有时闪退或者无图像，请多次关闭后重新打开，QT上位机只提供上位机可执行程序，不提供源码；

4、PDS工程1：OV7725输入YT8511版本

开发板FPGA型号：紫光同创–PGL22G-6MBG324；
开发环境：Pango Design Suite 2021.4
输入：OV5640，分辨率为800x600；
输出：网口；
网络PHY：YT8511，延时模式；
工程作用：紫光同创FPGA实现UDP协议栈网络视频传输；
工程代码架构如下：

工程的资源消耗如下：

工程已经综合编译完成，如下：

5、PDS工程2：OV5640输入RTL8211版本

开发板FPGA型号：紫光同创–PGL22G-6MBG324；
开发环境：Pango Design Suite 2021.4
输入：OV5640，分辨率为800x600；
输出：网口；
网络PHY：RTL8211，延时模式；
工程作用：紫光同创FPGA实现UDP协议栈网络视频传输；
工程详情参考第4章节；

6、上板调试验证并演示

准备工作

连接开发板：

以PDS工程1–>YT8511版本工程为例进行上板调试；
修改本地电脑端IP地址为如下：

然后下载bit致开发板，即可开始测试；

动态ARP测试

打开CDM，做如下操作：


可以看到，PC已经识别并记录了FPGA网卡的ARP信息，并标记为动态；

ping测试

打开CDM，做如下操作：

单次ping还不够，直接上连续ping，如下：

图像接收显示测试

打开QT上位机，OV5640输入静态演示如下：

鼠标指针停留在QT上位机区域，按住鼠标右键不放，当出现小手掌图标时，表示此时已开始同步视频录制和图片抓拍，视频录制和图片抓拍保存在电脑本地的如下文件夹里：


打开QT上位机，OV5640输入动态演示如下：

7、福利：工程代码的获取

福利：工程代码的获取
代码太大，无法邮箱发送，以某度网盘链接方式发送，
资料获取方式：私，或者文章末尾的V名片。
网盘资料如下：