首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

基于千兆网的FPGA多通道数据采集系统设计(2)

基于千兆网的FPGA多通道数据采集系统设计(2)

1)MAC子层的功能。设计中直接调用Altera公司提供的三速以太网控制器IP核实现MAC子层的功能,该IP核提供了统一的寄存器接口,用户可以通过它来配置以太网最大帧长、源MAC地址、目的MAC地址和PHY地址等重要信息。如图4所示,发送数据时,MAC模块向数据帧添加以太网首部,并利用CRC算法添加32位的校验码;接收数据时,MAC模块同样要进行CRC校验,对于不正确的数据帧要予以丢弃,用户也可以通过配置寄存器决定是否将校验位一并送至上一层。


(2)UDP/IP协议栈的实现。相对于TCP协议的三次握手,UDP和IP协议面向无连接的性质使其在硬件上可以快速实现,至于连接的建立完全可以在应用层实现。



如图4所示,UDP和IP协议的功能在硬件上的实现有较多相同之处:对于上层发送的数据均需要添加相应的首部和校验和;对于下层接收的数据,检验校验和,并去除首部,然后才能送到上一层;由于首部中有该数据包的长度区域,所以无论是发送和接收,都需要将数据包全部缓存,才能确定其长度大小,相当于一种“存储-转发”的机制。



当然,UDP协议与IP协议在实现时也有不同的地方,主要体现在校验和的计算方法上。UDP协议的校验和是将首部和数据一起校验,而且这个首部不仅是8 Byte的UDP首部,还包括12Byte的伪首部。在UDP层计算校验和还用到了IP层的地址,但这违背了网络分层模型的理念。IP协议的校验和只计算IP数据包的头部,一般情况下只有固定的20 Byte.



2.3应用层协议处理

不同通道采集的数据按照规定的数据包长度进行打包,然后再发送到上面的以太网控制模块,需要专门的模块进行组织和调度,并添加对应通道的标签。同时,网络中也不只是设备到上位机方向的采集数据包,也有反方向的用于控制的命令包:首先要考虑的问题是设备从何时开始采集数据,何时停止采集,这都是要上位机发送命令来控制的;其次,对于丢失包的统计与处理,这一部分工作稍微有些困难,但无论是设备和上位机都可以完成,显然交给上位机处理比较适宜,然后上位机向设备发送带丢失包序号的短数据包,设备优先从DDR2缓存中找到该丢失的数据包,发往上位机。



系统中完成这些功能的模块相当于一个位于UDP/IP层之上的应用层协议,而这个协议的内容是由系统设计者所规定的,但必须为FPGA开发人员和上位机软件程序开发人员所共享,这样在不同机器上的对应层就有了一个可以互相通信的对等体(Peer)。这样制定应用层协议,不但增加了系统相关功能的保密性,还可以由开发人员自行裁剪应用层功能,灵活地协调软硬件应该负责的细节,最后敲定最简洁的实现方案。



3上位机软件的功能

由于本系统的硬件部分实现了UDP/IP协议栈的内容,上位机软件在开发时有了较多可利用的系统调用,主要是Socket(套接字)原语的使用。相对于硬件开发来说,软件开发方便实现一些复杂的功能和计算,所以在系统构想之初就刻意将一些较难实现的部分交由上位机软件来处理,主要是图像帧间隔的识别和重传包的统计。



关于数据包重传,硬件设备在传送各个通道的图像时,只选取一个合适的点开始采集图像,而不负责在数据包中添加图像帧的开始和结束等信息,因为这样不仅偏离了多通道图像和数据兼容的初衷,而且给FPGA程序的实现增加了困难,尤其是采集的数据要进出DDR2 SDRAM缓存,如果在这些纯数据中添加额外的标志数据,可能会打乱整个缓存区的布局。所以上位机只能根据接收的数据量来判断各个图像帧之间的间隔,然后无论显示或存储,都以帧为单位进行。



4系统设计注意事项

4.1 ARP包的响应与抑制

上位机在向设备发送UDP数据包之前,可能会先发送一个ARP包,请求设备的MAC地址。所以在FPGA程序中要能响应该数据包,并发送ARP回复,否则设备与上位机将不能通信。得到设备的MAC地址后,上位机会暂时将其保存,建立一个ARP表项;一段时间后,ARP表老化,会再次向设备发送ARP请求。



为了能正确响应ARP请求和回复,必须要清楚ARP数据包的格式。如图5所示,如果以太网帧“帧类型”区域的值为0x0806,则表示该帧后面的数据填充为一个ARP包。至于是ARP请求还是ARP回复,需要根据ARP首部的操作码来辨别:操作码为0x0001,则是ARP请求包;操作码为0x0002,则是ARP回复包。ARP请求包填入一个广播帧并发向网络中的所有主机,所以其以太网目的地址为广播帧地址0xffffffffffff,并且由于它的目标是请求目的主机的MAC地址,故图中“接收方MAC地址”区域没有确切值,可为任意6 Byte的填充;ARP回复包已经得到了所需的MAC地址,但是要注意,此时的发送方和接收方已经对调,相应区域的填写也应适当改变。



图4 用户数据打包/解包示意图


以太网协议规定的最短帧长为64Byte,这就要求其数据填充至少为46 Byte,如图4所示,而图5中的ARP字段共有28 Byte,所以无论是ARP请求还是回复,均应有18 Byte的填充数据。有些PC机会发送其他设备的ARP请求,即使此时只有一根直连线将设备与上位机相连。这时设备是不能响应该请求的,应当在MAC层和IP层之间就将这样的请求屏蔽,防止干扰正常的数据包传输。



图5 ARP包格式


4.2 Jumbo帧的利弊

以太网标准规定的最大帧长度为1 518 Byte,这包括IP层和UDP层添加的首部,一般发送的数据包也都应该限制在这一范围内。但千兆以太网有一种厂商标准的超长帧格式,目前还没有获得IEEE标准委员会的认可,它规定的帧格式与普通以太网帧相同,只是其数据填充区域可以突破原有限制,整个帧长度为9 000~64 000 Byte不等,即Jumbo巨型帧。



在本系统中采用Jumbo帧的好处:(1)可以适当提高网络带宽的利用率。这主要靠节省各层首部的添加得到。(2)减少操作系统因频繁响应网络设备的中断而带来的CPU资源的过多占用。这可以说是采用Jumbo帧的主要原因,因为要处理千兆以太网较高的数据率,无论上位机软件如何优化,CPU的占用仍然很高,这时如果能减少其他地方的CPU开销,将大幅增加软件的处理能力。



但Jumbo帧在使用时也有一些不利的地方。首先,目前很多PC机的网络适配器不支持Jumbo帧的传输,虽然Altera的以太网控制器IP核支持,但这不足以使两个设备进行通信;其次,Jumbo帧会长时间占用网络通道,这会影响那些对数据延迟敏感的设备和应用;第三,Jumbo帧的丢包意味着严重的灾难,一帧相当于十多个正常帧,这会将处理能力弱的PC机迅速引入重传的陷阱,丢包越来越多,直到网络带宽被全部占用,导致上位机软件崩溃。所以在考虑支持Jumbo帧之前,应先充分权衡这些优势与不足。5结束语


系统硬件设备与上位机软件配合工作,可以较好地完成双路彩色PAL制数据流的采集任务。通过实际测试与分析,采用Jumbo帧进行传输,有效地减少了软件运行过程中的系统中断数,从而最大限度地降低了CPU的占用。利用搭建起来的千兆以太网运行环境,可以扩展类似的高速数据传输应用。
返回列表