基于千兆網的FPGA多通道數據采集系統設計
3上位機軟件的功能
本文引用地址:http://www.104case.com/article/277032.htm由于本系統的硬件部分實現了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的占用。利用搭建起來的千兆以太網運行環境,可以擴展類似的高速數據傳輸應用。
fpga相關文章:fpga是什么
評論