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

　　图1所示即为本系统的总体结构，除了使用一块DDR2 SDRAM芯片之外，网络模型中物理层的功能由一块PHY芯片来完成。目前一般PHY芯片均能兼容10Mbit·s-1、100Mbit·s-1、1 000 Mbit·s-13种速率的以太网传输，并向上层提供多种接口，如MII、GMII、RGMII和TBI接口等，对于上位机一侧则直接是普通的RJ45网口插槽。物理层接收数据链路层的并行数据，并将其转换为原始的比特流;同时也将原始比特流转化成并行数据，提交给数据链路层。
　　2 FPGA模块功能
　　FPGA模块通过响应上位机的指令，完成数据采集、打包、传输、丢包重传等工作。所有工作的基础是MAC子层、网络层、传输层等OSI参考模型各层协议的可靠实现，每一层都按照标准接口向上一层提供特定服务，而把如何实现这些服务的细节对上一层加以屏蔽。

　　图2显示了系统FPGA模块的具体结构，以及各个子模块之间的关系。为缩短设计周期，提高设计质量，在模块中分别调用了Altera公司现有的以太网控制器IP核和DDR2控制器IP核资源。
　　2.1 DDR2读写控制
　　若不考虑网络中丢包的情况，数据一边采集，一边打包向上位机发送，是不需要外部存储器来缓存的。但是在实际测试中发现，目前普通配置的PC机无法承受千兆以太网的快速传输能力，丢包很常见，尤其是增加到多个通道时，设备向上位机的输出能力加大，丢包率也立即随之升高。所以，使用一片DDR2 SDRAM缓存各通道的数据是必要的。
　　设计中直接调用Altera公司提供的DDR2 SDRAM控制器，并选用一块它可以驱动的芯片来提高工作效率。芯片可使用的缓存空间是要重点关注的。每个通道都要分配固定的缓存区域，所以要将有限的内存空间作合理的划分。如果是图像数据，单个通道至少要有缓存两帧以上的空间。DDR2读写控制模块直接调用DDR2 SDRAM控制器IP核，但由于该IP核提供给用户端的接口使用不方便，需要按照其文档上介绍的时序来进行突发式读写。
　　本模块的功能主要是协调各通道采集数据的写入和读出。如图3所示，写操作时，各通道的数据首先用FPGA资源进行缓存，然后写入控制状态机通过轮询的方式依次检查各个通道已经缓存的数据量，如果足够突发写，则将其写入SDRAM芯片的相应通道块中，然后再检查下一通道;读操作时，读出控制状态机也依次检查各个通道写入SDRAM芯片的数据量，如果足够突发读，则将其读出，通过网络发送出去。

　　基于以上控制方式，设计对各通道的数据格式是不作限制，如图1中所示，可以是PAL、Camera Link、VGA等各种格式的图像或组合，只是在采集之前向上位机各个通道的数据信息。但需要说明的是，这些数据的带宽总和理论上不应超过千兆以太网的传输速率，这是采用轮询方式得以成功的前提。其实，如今普通PC机的处理能力远远不能达到这个限制，当速度到达100 Mbit·s-1时，上位机丢包就已经很严重。如果是将采集的数据在上位机上显示，多可能只有70～80 Mbit·s-1;如果还要将数据写入硬盘，那数据率则会更低，除了配备一块上好的硬盘之外，还需要在上位机软件的优化上多作努力。
　　2.2 以太网发送接收控制
　　本模块的功能就是MAC子层、网络层、传输层各层协议的具体实现，这些子模块作为数据传输的通道，需要具有一定的缓存和查错能力，同时为了能扩展其他协议，还必须保持相互之间的独立性。如图4所示，硬件设备接收数据的过程就是以太网帧经过每一层，去除各层的首部并核对校验，获得纯粹的用户数据;发送数据的过程就是用户数据每经过一层，添加相应的首部和校验，直到组成一个完整的以太网帧。
　　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地址，但是要注意，此时的发送方和接收方已经对调，相应区域的填写也应适当改变。

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