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

 FPGA丰富的逻辑资源、充沛的I/O引脚以及较低的功耗，被广泛应用于嵌入式系统和高速数据通信领域。现如今，各大FPGA生产厂商为方便用户的设计和使用，提供了较多的、可利用的IP核资源，极大地减少了产品的开发周期和开发难度，从而使用户得以更专注地构思各种各样创意且实用的功能，而不是把大量时间浪费在产品的调试和验证中。

千兆以太网技术在工程上的应用是当前的研究热点之一。相比于其他RS-232或RS-485等串口通信，千兆以太网更加普及和通用，可以直接与Internet上的其他终端相连;相比于百兆网络，千兆以太网传输速度更快、传输距离更远，再结合UDP/IP协议栈，可以更方便地与上位机进行通信。

本文结合FPGA和千兆以太网灵活与快速的优势，设计了一个多通道并支持不同格式的数据采集系统。为了更好地为上位机软件所支持，搭建了一个简单的UDP/IP数据通道来完成数据到上位机的高速传输。同时，为了克服UDP这类不可靠的、面向无连接的协议带来的数据错误和缺失问题，使用一块DDR2SDRAM芯片来缓存各通道数据，在应用层制定了与上位机交互及丢包处理的通信协议，从而保证了采集数据到达上位机的可靠性。

1 系统总体结构

系统的设计目标是为了让不同通道、不同格式的数据都能通过同一个网络通道被快速无误地传递给上位机，由于设备与上位机运行状态的不同，采集数据速率的变化，甚至网线质量，使传输过程中的错误和丢包情况在所难免，所以需要有适当的机制和存储器缓存来保证传输的可靠性。

图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层之间就将这样的请求屏蔽，防止干扰正常的数据包传输。

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的占用。利用搭建起来的千兆以太网运行环境，可以扩展类似的高速数据传输应用。