本文主要是介绍紫光同创FPGA实现UDP协议栈网络视频传输,带录像和抓拍功能,基于YT8511和RTL8211,提供2套PDS工程源码和技术支持,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
目录
- 1、前言
- 免责声明
- 2、相关方案推荐
- 我这里已有的以太网方案
- 紫光同创FPGA精简版UDP方案
- 紫光同创FPGA带ping功能UDP方案
- 紫光同创FPGA精简版UDP视频传输方案
- 3、设计思路框架
- OV5640摄像头配置及采集
- 数据缓冲FIFO
- UDP协议栈详解
- MAC层发送
- MAC发送模式
- MAC层接收
- ARP发送
- ARP接收
- ARP缓存
- IP层发送
- IP发送模式
- IP层接收
- UDP发送
- UDP接收
- ICMP应答 (ping)
- CRC校验
- RGMII转GMII模块
- IP地址、端口号修改
- PHY
- QT上位机
- 4、PDS工程1:OV7725输入YT8511版本
- 5、PDS工程2:OV5640输入RTL8211版本
- 6、上板调试验证并演示
- 准备工作
- 动态ARP测试
- ping测试
- 图像接收显示测试
- 7、福利:工程代码的获取
紫光同创FPGA实现UDP协议栈网络视频传输,带录像和抓拍功能,基于YT8511和RTL8211,提供2套PDS工程源码和技术支持
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:视频没有进行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:视频没有进行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输入动态演示如下:
紫光同创FPFA-UDP-OV5640
7、福利:工程代码的获取
福利:工程代码的获取
代码太大,无法邮箱发送,以某度网盘链接方式发送,
资料获取方式:私,或者文章末尾的V名片。
网盘资料如下:
这篇关于紫光同创FPGA实现UDP协议栈网络视频传输,带录像和抓拍功能,基于YT8511和RTL8211,提供2套PDS工程源码和技术支持的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!