李 林

（江西師范高等專科學校物聯(lián)網(wǎng)學院，江西 鷹潭 335000）

0 引言

隨著傳感網(wǎng)絡(luò)、射頻識別技術(shù)、大數(shù)據(jù)技術(shù)和云計算能力的不斷發(fā)展，物聯(lián)網(wǎng)被廣泛地應(yīng)用于各行各業(yè)，可實現(xiàn)智慧交通、智能醫(yī)療、智慧農(nóng)業(yè)、智能電網(wǎng)、智能安防、智慧物流、智能家居和智能環(huán)境監(jiān)測等[1-8]?；谖锫?lián)網(wǎng)的環(huán)境監(jiān)測系統(tǒng)越來越復(fù)雜，集成度也越來越高。數(shù)據(jù)傳輸?shù)姆N類越來越多，傳輸?shù)臄?shù)據(jù)容量也越來越大。在環(huán)境監(jiān)測系統(tǒng)的前端，傳統(tǒng)數(shù)據(jù)傳輸通常采用串行通信（Universal Serial Bus, USB）總線接口、外圍設(shè)備互聯(lián)（Peripheral Component Interconnect, PCI）控制總線接口、局域網(wǎng)控制器（Controller Area Network, CAN）總線接口和ZigBee 無線通信技術(shù)等。USB2.0 總線的最高傳輸速率為480 Mbps，具有開發(fā)周期短、穩(wěn)定性較高等優(yōu)勢，且目前具有成熟的產(chǎn)品，但是其存在傳輸距離短的缺點，嚴格限制了連接設(shè)備之間的位置[9]。PCI總線結(jié)構(gòu)復(fù)雜，最高傳輸速率為266 Mbps，且在設(shè)備連接狀態(tài)時不能隨意進行熱插拔操作[10]。CAN 總線具有開發(fā)周期短、強大的抗干擾能力和實時性等特點，被廣泛地應(yīng)用在車載設(shè)備中。然而CAN 總線的通信速率最高只有1 Mbps，很難滿足大容量和高速率的數(shù)據(jù)傳輸需求[11]。ZigBee 技術(shù)是一項新型的無線通信技術(shù)，具有傳輸速率低、距離短、功耗低、成本低等優(yōu)點，被廣泛地應(yīng)用于傳感控制中[12]。隨著網(wǎng)絡(luò)技術(shù)的發(fā)展和普及，以太網(wǎng)已經(jīng)成為一種非常成熟的技術(shù)，千兆以太網(wǎng)技術(shù)已經(jīng)成為物聯(lián)網(wǎng)環(huán)境監(jiān)測系統(tǒng)研究的熱點和趨勢。與傳統(tǒng)的通信技術(shù)相比，千兆以太網(wǎng)最大的優(yōu)點在于傳輸速度快、傳輸距離遠，尤其是在傳輸距離和組網(wǎng)構(gòu)架等方面具有巨大的技術(shù)優(yōu)勢[13]。

本課題以XILINX 公司的FPGA 硬件作為平臺，利用FPGA 芯片資源的優(yōu)勢。設(shè)計了一套以FPGA 為硬件平臺，基于UDP（User Datagram Protocol, UDP）協(xié)議的千兆以太網(wǎng)環(huán)境監(jiān)測系統(tǒng)數(shù)據(jù)傳輸構(gòu)架。重點闡述了基于UDP 協(xié)議的千兆以太網(wǎng)數(shù)據(jù)傳輸系統(tǒng)構(gòu)架的實現(xiàn)方案，然后采用仿真軟件對該系統(tǒng)構(gòu)架進行仿真驗證，最后在實際的FPGA 硬件平臺上具體實現(xiàn)和完成功能性驗證，并給出了最終的硬件平臺實際測試結(jié)果。

1 系統(tǒng)整體控制邏輯設(shè)計

基于物聯(lián)網(wǎng)的環(huán)境監(jiān)測系統(tǒng)主要完成對環(huán)境中各種類型信號的采集監(jiān)測，例如環(huán)境中的視頻圖像信號、溫濕度、煙霧數(shù)據(jù)信息、消防安全信號等。所有的這些信號首先通過相應(yīng)的傳感器進行采集，然后通過數(shù)據(jù)傳輸系統(tǒng)將數(shù)據(jù)傳輸至上位機進行回讀分析。根據(jù)物聯(lián)網(wǎng)環(huán)境監(jiān)測系統(tǒng)的工作流程，可劃分在FPGA 內(nèi)部系統(tǒng)的邏輯功能框圖如圖1所示。

圖1 環(huán)境監(jiān)測系統(tǒng)整體設(shè)計框圖

各類傳感器首先采集環(huán)境中相應(yīng)的信號，然后通過對應(yīng)的控制器將采集到的信號存儲在各自的數(shù)據(jù)緩沖器FIFO 中，再由數(shù)據(jù)存儲序列控制器通過相應(yīng)的控制算法將數(shù)據(jù)通過DDR3 控制器接口存儲到DDR3 硬件中。然后由千兆以太網(wǎng)控制器將存儲于DDR3 內(nèi)存中的數(shù)據(jù)取出來，通過以太網(wǎng)接口傳輸至上位機。在以太網(wǎng)數(shù)據(jù)傳輸過程中，主要涉及TCP/IP 協(xié)議中的數(shù)據(jù)傳輸層、網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層。通過FPGA 編程實現(xiàn)數(shù)據(jù)的處理和傳輸以及UDP 協(xié)議中相關(guān)的協(xié)議。對于物理層則采用商用的以太網(wǎng)PHY芯片來實現(xiàn)，這樣使得外部接口電路的配置相對簡單，從而降低了系統(tǒng)的開發(fā)難度。文章參考了國內(nèi)外有關(guān)的千兆以太網(wǎng)的設(shè)計經(jīng)驗[14]，完成了基于UDP協(xié)議的千兆以太網(wǎng)的設(shè)計和實現(xiàn)，以滿足目前大部分物聯(lián)網(wǎng)數(shù)據(jù)采集系統(tǒng)的實際需求。

2 以太網(wǎng)關(guān)鍵技術(shù)

2.1 UDP協(xié)議實現(xiàn)構(gòu)架

本系統(tǒng)中千兆以太網(wǎng)UDP 協(xié)議的內(nèi)部構(gòu)架方案如圖2 所示。主要包含了UDP 模塊（UDP 接收模塊和UDP 發(fā)送模塊）、MAC 層功能模塊（MAC 層數(shù)據(jù)接收模塊和MAC 層數(shù)據(jù)發(fā)送模塊）、IP 層模塊（IP 層發(fā)送模塊和IP 層接收模塊）、ARP 功能模塊（ARP 發(fā)送模塊和ARP 接收模塊）、ICMP 功能模塊和PHY 模塊等。其中，UDP 模塊主要實現(xiàn)UDP 的相關(guān)協(xié)議，具體包括數(shù)據(jù)的接收和發(fā)送。MAC 層模塊實現(xiàn)以太網(wǎng)數(shù)據(jù)鏈路功能，管理數(shù)據(jù)輸入輸出接口（Management Data Input/Output, MDIO），并對PHY 模塊的寄存器進行相應(yīng)的配置，來對PHY 的功能進行管理。對于PHY 模塊，則采用商業(yè)的以太網(wǎng)芯片來實現(xiàn)。

圖2 UDP協(xié)議內(nèi)部構(gòu)架

2.2 MAC層模塊

MAC 層由MAC 層發(fā)送模塊和MAC 層接收模塊兩部分構(gòu)成。MAC 層發(fā)送模塊按照標準以太網(wǎng)幀的格式組裝MAC 幀頭，然后再結(jié)合IP 發(fā)送層或ARP 發(fā)送層的數(shù)據(jù)形成一個完整的MAC 數(shù)據(jù)幀發(fā)送出去。MAC 層接收模塊將接收到的數(shù)據(jù)按照以太網(wǎng)的標準幀格式逐字節(jié)進行解析，根據(jù)接收到的類型字節(jié)進行相應(yīng)的判斷并存儲相應(yīng)的有效信息。

2.2.1 MAC 層接收

在MAC 接收層接收到數(shù)據(jù)的有效標志信號為高電平時，對以太網(wǎng)幀進行逐字節(jié)統(tǒng)計。當接收到有效信號時，開始進行字節(jié)計數(shù)，當幀數(shù)據(jù)的有效標志位信號為低電平時則停止計數(shù)。具體的實現(xiàn)步驟采用如圖3 所示的狀態(tài)機來實現(xiàn)。首先，在IDLE 狀態(tài)下判斷接收到的數(shù)據(jù)有效信號是否為高電平，若為高電平，則進入REC_PREAMBER 前導(dǎo)碼狀態(tài)，接收以太網(wǎng)幀的前導(dǎo)碼。之后狀態(tài)機跳轉(zhuǎn)到REC_MAC_HEAD 頭部接收狀態(tài)，此時將目的MAC 地址、源MAC 地址、以太網(wǎng)幀類型緩存起來，同時在此狀態(tài)下判斷接收到的前導(dǎo)碼是否正確，如果錯誤則進入REC_ERROR 錯誤狀態(tài)。否則進入REC_IDENTIFY狀態(tài)，并在此狀態(tài)判斷接收到的幀類型是IP 協(xié)議類型還是ARP 協(xié)議類型。若接收到幀類型數(shù)據(jù)為0X0800 則為IP 協(xié)議類型；若為0X0806，則為ARP 類型。其次，狀態(tài)機跳轉(zhuǎn)到REC_DATA 接收數(shù)據(jù)狀態(tài)，并將接收到的數(shù)據(jù)送到下游的IP 層模塊或ARP 功能模塊，與此同時將接到的數(shù)據(jù)進行CRC 處理，等待IP 層或ARP 層數(shù)據(jù)接收完畢，則狀態(tài)機跳轉(zhuǎn)到REC_CRC 狀態(tài)，接收CRC 校驗數(shù)據(jù)，將接收到的CRC 數(shù)據(jù)與在接收數(shù)據(jù)狀態(tài)計算得到的CRC 數(shù)據(jù)進行對比。根據(jù)比對結(jié)果判斷接收到的數(shù)據(jù)是否正確，正確則進入REC_END狀態(tài)，錯誤則進入REC_ERROR狀態(tài)。

圖3 MAC層接收狀態(tài)機

2.2.2 MAC 層發(fā)送

MAC 層發(fā)送模塊的功能是先根據(jù)標準以太網(wǎng)數(shù)據(jù)幀的格式生成以太網(wǎng)幀頭，然后再結(jié)合IP 層或ARP 層發(fā)送過來的數(shù)據(jù)形成一個完整的以太網(wǎng)幀發(fā)送出去。具體的狀態(tài)機實現(xiàn)流程如圖4 所示。一開始狀態(tài)機處于SEND_START 狀態(tài)，等待MAC 層發(fā)送準備信號mac_tx_ready。若接收的準備信號有效，則表明ARP 或IP 數(shù)據(jù)已經(jīng)準備好了，可以進行數(shù)據(jù)發(fā)送。此時狀態(tài)機跳轉(zhuǎn)到發(fā)送前導(dǎo)碼狀態(tài)SEND_PREAMBER，前導(dǎo)碼發(fā)送完畢之后，拉高數(shù)據(jù)發(fā)送請求信號，請求IP 或ARP 的數(shù)據(jù)，隨后進入到數(shù)據(jù)發(fā)送狀態(tài)SEND_DATA，等數(shù)據(jù)發(fā)送完畢后，進入發(fā)送SEND_CRC 狀態(tài)。在發(fā)送數(shù)據(jù)的過程中，同時需要進行CRC校驗。

2.3 ARP模塊

ARP 模塊主要包含ARP 請求模塊和ARP 發(fā)送模塊兩部分。ARP 請求模塊主要用于檢測接收到的ARP 是請求包還是發(fā)送包。ARP 發(fā)送包是根據(jù)接收到的ARP 請求包的類型來生成相應(yīng)的應(yīng)答幀信號。

圖4 MAC層發(fā)送狀態(tài)機

2.3.1 ARP 接收模塊

ARP 接收模塊主要實現(xiàn)ARP 數(shù)據(jù)的接收，具體的狀態(tài)流程圖如圖5 所示。一開始，系統(tǒng)處于IDLE狀態(tài)下，當接收到MAC 層發(fā)送過來的ARP 請求信號后，狀態(tài)跳轉(zhuǎn)到ARP 接收狀態(tài)，在該狀態(tài)下，系統(tǒng)根據(jù)ARP 數(shù)據(jù)協(xié)議報提取出接收到的信號的源MAC地址、目的MAC 地址、源IP 地址和目的IP 地址，并判斷檢測接收到的操作碼類型是ARP 請求信號還是ARP應(yīng)答信號。如果是請求信號，則再判斷接收到的目的IP地址和本機的IP地址是否匹配，如果匹配，則發(fā)出應(yīng)答請求信號，否則忽略該幀信號。如果是應(yīng)答信號，則再判斷接收到的目的IP 地址和目的MAC 地址是否和本機一致，如果一致，則發(fā)出匹配一致信號，表明接收到對方發(fā)過來的地址信息，并將接收到的MAC地址和IP地址存入到系統(tǒng)緩存中。

圖5 ARP接收狀態(tài)流程圖

2.3.2 ARP 發(fā)送模塊

ARP 發(fā)送模塊實現(xiàn)ARP 應(yīng)答幀信號的發(fā)送功能。具體的工作流程圖如圖6 所示。系統(tǒng)一開始處于IDLE 狀態(tài)，等待ARP 接收模塊過來的發(fā)送請求信號或ARP 應(yīng)答請求信號，之后系統(tǒng)進入請求或應(yīng)答狀態(tài)，并通知MAC 發(fā)送模塊數(shù)據(jù)已經(jīng)準備好了，然后等待MAC 數(shù)據(jù)請求信號，系統(tǒng)進入請求或數(shù)據(jù)發(fā)送狀態(tài)，按照ARP 協(xié)議幀的格式生成ARP 應(yīng)答信號，在發(fā)送數(shù)據(jù)時，若數(shù)據(jù)不足46 字節(jié)，則需要補全46字節(jié)發(fā)送。

圖6 ARP發(fā)送數(shù)據(jù)流程圖

2.4 IP模塊

IP 模塊根據(jù)功能劃分為接收模塊和發(fā)送模塊兩個功能模塊。接收模塊按照如圖7 所示的IP 協(xié)議報格式對接收到的數(shù)據(jù)進行解析。首先是解析協(xié)議報頭信息，根據(jù)接收到的報頭長度字段判斷報頭占據(jù)多少個字節(jié)，然后從中提取數(shù)據(jù)報所攜帶的一些關(guān)鍵信息；如IP 數(shù)據(jù)總長度、目的IP 地址、源IP 地址、IP 協(xié)議類型和報頭校驗和。根據(jù)接收到的IP 協(xié)議類型代碼判斷接收到的數(shù)據(jù)報是UDP 協(xié)議還是ICMP 協(xié)議，若協(xié)議類型代碼為0X01，為ICMP 協(xié)議；若協(xié)議類型代碼為0X11，為UDP 協(xié)議。接收IP 報頭的同時，對接收到的IP 報頭進行校驗和求解，然后將接收到的校驗和與求解的校驗和進行比較，若不一致，則丟棄該數(shù)據(jù)報。否則繼續(xù)接收數(shù)據(jù)，并且根據(jù)協(xié)議的類型與代碼將接收到的數(shù)據(jù)發(fā)送到ICMP 模塊或UDP模塊。發(fā)送模塊根據(jù)需要發(fā)送的數(shù)據(jù)類型（ICMP 或UDP）按照相應(yīng)的IP 協(xié)議報的格式生成相應(yīng)的IP 首部，形成一個完整的IP 數(shù)據(jù)報發(fā)送給MAC 層模塊。

2.5 ICMP模塊

ICMP 模塊的主要功能是檢測主機和路由器之間的網(wǎng)絡(luò)是否連通、主機能否到達指定地點等，是TCP/IP 協(xié)議簇中的一個子層協(xié)議，包含在IP 數(shù)據(jù)段中。本課題要實現(xiàn)的ICMP 模塊首先是接收其他設(shè)備發(fā)送過來的ICMP 數(shù)據(jù)，然后判斷接收的類型是否是請求包，若為請求包，先將數(shù)據(jù)存入到RAM 中，并計算校驗和，判斷校驗和是否正確，若校驗和正確，僅進入ICMP 發(fā)送狀態(tài)，根據(jù)如圖8 所示的ICMP數(shù)據(jù)報文格式生成相應(yīng)的應(yīng)答包。此時生成的應(yīng)答包中，需要在MAC 層將請求包中的MAC 地址和IP地址互換，并且需要將ICMP 報文中的協(xié)議類型轉(zhuǎn)變成應(yīng)答類型。

圖7 IP協(xié)議報格式

圖8 ICMP報文格式

2.6 UDP模塊

UDP 模塊包含了發(fā)送和接收兩個模塊，主要以如圖9 所示的UDP 協(xié)議報格式完成UDP 數(shù)據(jù)的接收和發(fā)送。

1）UDP 接收模塊。完成UDP 數(shù)據(jù)有效性的檢測和數(shù)據(jù)的接收兩大功能。具體操作流程如下：

①校驗和計算。將接收到的UDP 首部和UDP 數(shù)據(jù)轉(zhuǎn)換成反碼運算求和，若UDP 的數(shù)據(jù)總數(shù)為奇數(shù)，則在數(shù)據(jù)尾部填充0X00 構(gòu)成偶數(shù)進行運算，最后將得到的求和結(jié)果再求反碼即可得到UDP 的校驗和。

②數(shù)據(jù)有效性判斷。根據(jù)上面解析得到的數(shù)據(jù)內(nèi)容，判斷接收到的數(shù)據(jù)是否為UDP 協(xié)議、目的IP地址與本機IP 是否匹配、目的端口號是否是本機的端口號。最后再判斷接收到的UDP 校驗和與計算的UDP 校驗和是否一致。若其中有一個不匹配，則判斷該幀信號為無效幀，做丟棄處理。

③數(shù)據(jù)接收。根據(jù)第二步數(shù)據(jù)的有效性判斷，若數(shù)據(jù)有效，去除接收到的數(shù)據(jù)中的IP 首部、UDP 首部，即可得到UDP 數(shù)據(jù)。

2）UDP 發(fā)送模塊。完成UDP 首部校驗和的計算、數(shù)據(jù)幀的組裝和發(fā)送功能。首先，將需要發(fā)送的UDP 數(shù)據(jù)緩存到RAM 中，當數(shù)據(jù)容量存儲到一定時再將數(shù)據(jù)讀出。其次，將需要發(fā)送的UDP 首部和數(shù)據(jù)轉(zhuǎn)換為反碼求和，對求和結(jié)果再次轉(zhuǎn)換為反碼運算即可得到需要發(fā)送的UDP 報首部校驗和。最后，將UDP 首部和數(shù)據(jù)按照如圖9 所示的UDP 數(shù)據(jù)報格式生成UDP 數(shù)據(jù)幀發(fā)送到IP 模塊。

圖9 UDP協(xié)議報格式

3 系統(tǒng)功能測試

系統(tǒng)軟件在設(shè)計完之后，為了驗證其邏輯功能的正確性，本文設(shè)計了如圖10 所示的仿真結(jié)構(gòu)，并采用Modelsim 仿真軟件進行功能驗證。系統(tǒng)仿真框圖主要由以太網(wǎng)模塊、數(shù)據(jù)發(fā)生器和數(shù)據(jù)接收器等組成。仿真中利用數(shù)據(jù)發(fā)生器生成需要發(fā)送的數(shù)據(jù)，將生成的數(shù)據(jù)通過以太網(wǎng)發(fā)送端口發(fā)送出去，然后再由以太網(wǎng)從接收端口回接數(shù)據(jù)，這樣就能夠?qū)λO(shè)計系統(tǒng)中的各個模塊進行完整的仿真。

圖10 系統(tǒng)驗證仿真結(jié)構(gòu)

仿真平臺搭建完成以后，對MAC 地址、IP 地址和端口號等信息進行設(shè)置。然后由數(shù)據(jù)發(fā)生器模塊對需要發(fā)送的數(shù)據(jù)進行設(shè)置。最后啟動仿真程序，對比數(shù)據(jù)發(fā)生器模塊發(fā)送的數(shù)據(jù)和數(shù)據(jù)接收模塊接收到的數(shù)據(jù)，若二者一致，則表明本文的設(shè)計方案合理且邏輯正確。仿真結(jié)果如圖11 所示，從仿真結(jié)果可以看出，發(fā)送端的數(shù)據(jù)在接收端都能夠完整地接收，所設(shè)計的系統(tǒng)構(gòu)架在功能上是完全可行的。

功能仿真完成以后，可以借助相關(guān)的工具在實驗室中的FPGA 板卡上進行性能測試和驗證。首先，需要對FPGA 板卡和上位機的物理地址、IP 地址和端口號進行設(shè)置。然后，上位機采用相應(yīng)的測試方法進行測試。第一步通過上位機進行PING 功能來測試網(wǎng)絡(luò)是否連通，測試結(jié)果如圖12（a）所示，從中可以看出網(wǎng)絡(luò)已經(jīng)連通；第二步采用網(wǎng)絡(luò)助手進行網(wǎng)絡(luò)結(jié)構(gòu)的收發(fā)功能測試，測試結(jié)果如圖12（b）所示，從測試結(jié)果可以看出，發(fā)送數(shù)據(jù)和接收數(shù)據(jù)完全保持一致，表明所設(shè)計的以太網(wǎng)收發(fā)模塊功能正常。

圖11 仿真測試結(jié)果

圖12 PING 功能和UDP 收發(fā)模塊功能驗證結(jié)果

最后，可以通過網(wǎng)絡(luò)抓包工具Wireshark 來觀察通信數(shù)據(jù)結(jié)構(gòu)，分析傳輸數(shù)據(jù)。還可以對測試數(shù)據(jù)的傳輸速率進行測試，確定所設(shè)計的系統(tǒng)是否滿足要求。還可以通過任務(wù)管理器中的網(wǎng)絡(luò)資源來對速度進行進一步的驗證，測試結(jié)果如圖13 所示。在0.087 917 s 的時間內(nèi)接收到了10 000 個數(shù)據(jù)包，每個數(shù)據(jù)包的數(shù)據(jù)為1 000 個字節(jié)，所設(shè)計的千兆以太網(wǎng)的實時數(shù)據(jù)傳輸速率為10 000*1 000*8/0.087 917=909.95 Mbps。在任務(wù)管理器窗口的聯(lián)網(wǎng)菜單中可以看到，網(wǎng)絡(luò)使用率為94.2%，網(wǎng)絡(luò)為千兆網(wǎng)，網(wǎng)速大約為950 Mbps，大于Wireshark 抓包計算最低速度。這是因為在任務(wù)管理器窗口計算網(wǎng)速的時候是將以太網(wǎng)數(shù)據(jù)幀的報頭也放在數(shù)據(jù)部分一起計算，這樣一來通過任務(wù)管理器的聯(lián)網(wǎng)菜單計算得到網(wǎng)速與Wireshark 計算相吻合，而且傳輸速度非常穩(wěn)定。

圖13 實際速度測試結(jié)果

4 結(jié)論

本課題以XILINX 的FPGA 硬件為平臺，設(shè)計并實現(xiàn)了基于UDP 協(xié)議的千兆以太網(wǎng)環(huán)境監(jiān)測系統(tǒng)數(shù)據(jù)傳輸構(gòu)架。首先，詳細介紹了UDP 協(xié)議千兆以太網(wǎng)的實現(xiàn)方式；其次，采用仿真軟件對所設(shè)計的系統(tǒng)構(gòu)架進行功能仿真；最后，在XILINX 的FPGA 硬件平臺上進行實際性能測試。測試結(jié)果表明：筆者設(shè)計的基于UDP 協(xié)議的千兆以太網(wǎng)傳輸邏輯是正確的，傳輸速率最高可達到910 Mbps，能夠滿足大部分物聯(lián)網(wǎng)數(shù)據(jù)采集系統(tǒng)的實際需求，具有良好的可維護性、移植性和實際的推廣價值。