網絡的興起和通信的飛騰都隨著軟件無線電思想與技術的發展，在這當中，值得我們注意的是協議棧開發的內容。現代數字通信系統中,越來越多地使用DSP等數字信號處理器結合高速AD、DA轉換器進行OSI 7層通信體系模型中物理層（信號的調制、解調）和數據鏈路層（信道編、解碼）部分的數據處理工作.近年來,數字信號處理理論發展迅猛,數字信號處理器工作頻率及能力不斷提高,數字通信系統中越來越多的工作能夠通過DSP來完成,因而DSP本身的程序結構也越來越復雜.由于通信信號（尤其是無線通信）本身具有很強的實時性、隨機性的特點,造成DSP的輸入數據缺乏規律性,一閃即逝,從而導致相應的處理程序出現了問題不易復現,且問題難于追蹤、捕捉,這就給DSP的程序設計與調試帶來了較大困難.針對這一問題,本文根據一般底層通信協議棧的數據處理方法,設計了一套適合于對底層進行協議棧開發和調試的數據采集與仿真系統,以達到追蹤、再現問題并查找程序缺陷的目的.

1 數據采集系統

數據采集系統主要完成從正在工作中的通信終端中采集數據的任務.

1.1 采集點的選擇

整個通信系統中有多個數據采集切入點可選,可以對中頻信號直接采樣,也可以對基帶信號采樣,還可以通過模擬系統中的AD數據接收時序,直接接收AD輸出數據.但前兩種采集點不能確保采集到的信號數據與DSP輸入數據完全一致,而模擬AD數據時序的方式則可能影響DSP與AD之間的主從關系,影響DSP協議棧的正常運行,而且各種外部中斷的采集也比較困難.因而最為穩妥的方式是DSP通過數據總線輸出其接收到的數據.這種方法的缺點是需要占用DSP少量資源,但這與協議棧運行相比,完全可以忽略不計,不計不會影響協議棧開發和本身的運行.

1.2 硬件連接

參考文獻[1]對各種數據采集系統進行了分析比較,并指出USB總線為數據采集卡與PC機較理想的接口,因此選用CY68013A作為USB接口芯片.采用1片FPGA進行DSP與CY68013A之間數據格式的轉換,CY68013A固件程序存放在E2PROM中,通過I2C總線連接.

其中,DSP除了輸出16位數據總線之外,還引出7位地址線（A0～A6）,用以區分不同的數據類型.FPGA須將DSP外部總線輸出的數據格式轉換為CY68013A外部GPIF可兼容的格式.

1.3 FPGA程序設計

CY68013A外部GPIF端口可作為數據輸入端口的僅有16位（FD0～FD15）,而DSP輸出的信息數據一共有23位(16位數據線D0~D15和7位地址線A0~A6),故而需要將多出的7位地址信息嵌入到數據中去.將1個16位數據拆分成2個,每個數據中的低8位(FD0～FD7)用于存儲原數據信息(D0~D7或D8~D15),高7位(FD8～FD14）存放地址類型信息（A0～A6）,最高位（FD15）用于標識當前數據中FD0～FD7是原數據的D0～D7或是D8～D15.CY68013A GPIF端口使用內部48 MHz時鐘,根據參考文獻[2],每個GPIF信號周期為20.83 ns,二者時鐘不同步,FPGA為了與高速設備兼容,需要使用更高的時鐘源.因此,為了保證GPIF能夠采集到RDY信號,FPGA輸出的信號至少需要保持1.5個GPIF信號周期.GPIF每次從外部讀取數據存入FIFO需要6個狀態,故而每個輸出數據間隔應大于6個GPIF信號周期.以TI公司C55系列DSP為例,主頻時鐘144 MHz,與FPGA連接的為EMIFS外部總線.

考慮到DSP輸出數據時鐘可能較CY68013A GPIF采集時鐘快,因而FPGA需要設計內置的FIFO存儲器,用于緩存DSP輸出的數據.

1.4 USB固件設計

由于CY68013A內置的8051內核時鐘周期較慢,不適于高速傳輸,因而采集程序中僅使用8051進行初始化配置,而不干預數據傳輸過程.CY68013A通過外部GPIF讀取數據存入FIFO中,FIFO滿時通過USB傳入PC機.采用Cypress公司提供的通用程序框架以及圖形化GPIF設計工具,編輯GPIF波形.USB總線選擇傳輸大量數據時比較常用的Bulk傳輸模式,硬件配置程序采用Cypress公司提供的程序模板,參考文獻[3]對該模板進行了詳細說明,這里不再贅述,程序框架與參考文獻[4、5]類似.

1.5 PC機接收程序

USB接口驅動程序可直接使用Cypress公司提供的ez-usb驅動.由于ez-usb驅動沒有提供高級的文件操作IO方式,因而需要調用比較底層的DeviceIoControl函數來處理.考慮到Bulk傳輸方式完全是由主機端（PC機）發起讀操作,從機端（采集板）只能被動地等待,而當CY68013A內置的FIFO寫滿之后,如果主機不能及時地發起讀操作,則FIFO不再接收數據寫入操作,因而會有少量的數據丟失.對于底層協議棧調試,這種少量的數據丟失可能引起程序流程錯誤,是不能接受的.因此PC機端接收程序應采用多線程處理方式,將接收USB數據的工作列為單獨的線程,并將其優先級設置為實時性最高的THREAD_PRIORITY_TIME_CRITICAL,防止接收數據過程被系統中其他進程打斷,以確保每次讀操作能夠及時發出.同時也要保證負責數據采集的PC機操作系統中同時運行的進程盡量少,關掉不必要的后臺進程.

PC機接收到的數據先存入臨時文件中,以備后續解析、仿真程序使用.臨時文件以字(16 bit)為單位存儲,每個數據用2個字來表示,低字節在前,與FPGA轉換后的數據格式一致。

2 仿真系統

仿真系統使用采集系統采集到的數據,再現通信終端中的協議棧運行狀態,便于開發者隨時檢查程序錯誤,對程序進行調試.

2.1 系統框架

要想再現底層協議棧運行狀態,除了保證協議棧開發的整體輸入、輸出一致外,最大的難度在于系統的定時,要能夠準確再現各種事件的發生時刻.基于軟件無線電技術的數字通信系統大都采用過采樣方式,AD/DA速率都比較高而且穩定,因而底層協議棧也大多以AD/DA的輸入、輸出中斷作為系統定時.當通信終端作為接收機時,底層協議棧需要以AD采樣數據作為其他部分（信道估計與均衡、解調、信道解碼等）的驅動數據;作為發射機時,DA輸出數據是底層協議棧的最終輸出結果,需要仿真程序進行驗證.故而仿真程序可以采用AD/DA中斷來劃分程序運行的最小時間片,其他各種事件的發生都通過中斷個數來計時,仿真程序通過判斷AD/DA數據的個數調用各程序函數來再現底層協議棧運行狀況及數據流向.這樣就可以在不增加開銷的情況下,盡最大可能保證仿真程序與實際DSP中運行的協議棧一致,方便再現問題.

2.2  輸出數據

根據1.1節所選擇的數據采集點,需在DSP的底層協議棧代碼中輸出仿真時所用的數據: (1)需要輸出的為前端AD/DA數據,以及底層協議棧與上層協議棧之間的交互數據,這是底層通信協議棧接收、發射信息時所需的輸入數據與最終的輸出結果; (2)其他外圍設備產生的中斷和輸入數據也會影響底層協議棧流程,是仿真時所必須的部分;(3)底層協議棧各任務掛起、運行、結束等狀態變化需要輸出,以保證仿真程序運行時刻與實際情況一致.另外,在2次AD/DA中斷之間會發生多次變化的全局變量也需要輸出,以彌補時間片劃分的不足.

2.3  數據解析

1.5節中所存儲的接收數據不方便直接用于仿真,需要進行格式轉換.根據2.1節中所述系統框架,所有事件通過AD/DA數據計時,故而除AD/DA數據外,其他類型數據需要記錄AD/DA數據個數信息,作為時間戳,因而可將所有數據分為兩大類:AD/DA數據和非AD/DA數據.為仿真方便,將這2種類型數據分別存放于2個文件中.在解析數據時,需要將1.3小節中為了與CY68013A兼容而通過FPGA拆分開的2個16位數據重新合并為1個,并將不同類型的數據分開.AD/DA數據一般長度固定,由AD/DA轉換器分辨率（位數）而定,例如,AD/DA數據為16位,每次中斷輸出1個數據,則解析后的數據格式如表2所示.

非AD/DA數據根據程序需求,長度不固定,可在協議棧開發的程序輸出數據中包含長度信息,也可在接收程序與輸出程序中提前規定好數據長度.例如,非AD/DA數據以字為單位,數據長度為N,則解析后的數據格式如表3所示.

由于底層協議棧需要兼顧外圍硬件控制,各種外部中斷比較多,很可能會打斷數據輸出,因而在解析數據時,需要考慮各種數據之間的嵌套.為此,可以對每種數據采用單獨的緩沖區,待解析到1條完整數據之后再存入文件中,同時還要保證文件中各種非AD/DA數據按照發生時間的先后順序排列.

2.4 系統仿真

系統仿真之前,首先要將運行于DSP中的底層協議棧代碼轉換為PC機上可運行的代碼,一般DSP大多采用C語言和匯編語言相結合的方式進行開發,C代碼基本上不需要進行大量修改,而匯編代碼需要根據其工作原理,轉譯成C代碼.系統仿真時采用2.3節中解析后的數據文件作為輸入,按照2.1節定義的仿真系統框架,以AD/DA數據為驅動,通過判斷非AD/DA數據的發生時刻（AD/DA數據計數值）來調動底層協議棧各部分任務運行,以達到再現協議棧運行狀況、調試程序的目的.有些硬件操作需要底層協議棧控制,仿真時可以按照"[發生時間] 硬件操作內容"的格式寫到文件中作為仿真程序的輸出.這樣通過查詢輸出文件,各種硬件操作的先后關系一目了然,更形象化,有利于發現硬件控制上的邏輯錯誤.

本文設計了一種專門用于底層協議棧開發的數據采集與仿真系統,利用USB高速傳輸特點以及物理連接的便利性,采用CY68013A進行數據傳遞,充分利用其GPIF資源,使用FPGA進行格式轉換.文中對仿真系統的整體框架和數據轉換細節進行了詳細說明.該系統可用于各種類型協議棧調試,便于追蹤、再現問題.經過實驗驗證,系統可承受100 Mb/s的實時數據流,在數字集群手持終端開發中進行了廣泛應用,不僅降低了協議棧的開發難度,而且縮短了開發周期,有很高的實用性.