USB系統組成及模塊設計
3.3 USB協議層
協議層主要分成三個子模塊:解包模塊、打包模塊和協議引擎模塊。這一層主要是將經過串口接口引擎模塊過來的數據進行解包,剔除USB協議中的信息。同時將端點中要發(fā)送的數據,在協議引擎控制下進行相應的打包,然后通過SIE模塊傳送給USB主機。
3.3.1 解包模塊
本模塊主要將接收到的信息包數據進行解析,解析出包標識(PID),端點地址和USB設備地址以及包含在包中的有效數據。在解包時,對令牌包進行CRC5校驗,對數據包進CRCl6檢驗,若出錯則進行相應的出錯處理。從上面所述可知,任何包都有同步字段而同步字段在串口接口引擎模塊中已經除去了,因此本模塊不用關心同步字段。整個解包數據流如圖3所示。
整個解包過程如下:首先判斷接收的包是什么包,若為TOKEN包(0UT或IN或SOF或SETUP或ACK或NAK或STALL或PRE)則轉入到TOKEN包的處理進程,若為數據包(DATA0或DATAl)則轉入到DATA包的處理進程。在TOKEN包或DATA包中若發(fā)現數據有錯則丟棄此包并報錯。
3.3.2 打包模塊
根據PE送來的PID組織相應的信息包,把要發(fā)送的數據安排在相應的數據包,或者組織令牌包。發(fā)送令牌包時,不必產生CRC5校驗位。在發(fā)送數據包時,需要把有效數據的CRCl6校驗位放在末尾一起發(fā)送。這個模塊主要就是如何把協議層引擎模塊送過來的數據進行打包,打包的概念其實質就是把要發(fā)送的數據根據其相應的信息安排相應的發(fā)送順序。同樣打包的過程中也不用考慮同步字段,同步字段在串口接口引擎層加入。整個打包數據流如圖4所示。
3.3.3 協議層引擎模塊
在USB設備中,某一個時刻和主機通信的只能是一個端點,當前操作都基于這個端點地址。主機不能同時和幾個端點進行通信,端點的屬性在設備和主機剛開始連接時進行的枚舉過程中已經確定,保存在各端點對應的寄存器中,比如是IN還是OUT端點,是支持控制傳輸、批量傳輸還是中斷傳輸的端點等。協議引擎模塊是整個協議層的核心控制單元,控制了其他所有模塊的工作方式,根據當前端點的配置或當前狀態(tài)處理傳輸事務,并在傳輸事務中實時更新控制與狀態(tài)寄存器。他的功能包括:有效處理IN,OUT和SETUP事務,確定當前傳輸事務要操作的端點地址,正確應答各種包和管理數據的發(fā)送和接收,同時實現USB協議中的錯誤恢復機制。
3.4 端點控制模塊和端點模塊
端點模塊:端點其實就是USB進行通信時,用于存數據的緩沖區(qū),為了提高數據存取的速度,本IP核的端點設計成FIFO。端點控制模塊:主要是端點控制寄存器和端點狀態(tài)寄存器,此模塊中包含了USB IP核的頂層控制和狀態(tài)寄存器。如USB設備的狀態(tài)控制寄存器、設備地址寄存器、中斷屏蔽寄存器和中斷源寄存器等。為了增加靈活性,在設計時針對每一個端點分別設計了設置和功能相同但地址不同的寄存器,包括端點的控制狀態(tài)寄存器、中斷源寄存器、中斷屏蔽寄存器、緩沖區(qū)的指針寄存器。端點根據協議可以配置1到16個,在實際設計中根據本身系統需要可以對USB IP核配置端點數,增加了USB IP核端點可擴展性。
3.5 總線適配器模塊
此模塊是為了提高本IP核的可重用性而設計的。他主要包括WishBone總線接口、AMBA ASB總線接口和相應的配置寄存器。若使用于WishBone總線結構的SoC中,則在綜合前通過宏定義進行設置啟用WishBone總線接口,這樣整個USB IP核可以無縫接入WishBone總線結構的SoC中。若使用于AMBA ASB總線結構的SoC中,則在綜合前通過宏定義進行設置啟用AMBA總線接口無縫接入其SoC中。由于是在綜合前通過宏定義的,因此在實際綜合的時候,只會將宏定義的總線模塊綜合成實際電路,而不會兩個總線接口模塊都給綜合,節(jié)省資源。同時當此IP核要應用于其他的總線結構SoC中,如Altera的Avalon總線,則只要根據此總線協議再設計一個總線接口模塊,在綜合時啟用此總線接口模塊就可以將此IP核直接應用于此SoC中。因此本USB IP核對于不同總線的SoC利用總線適配器使具體較強靈活性,可重用性強。
4 FPGA驗證
本USB IP核已經應用于一款數據采集單芯片系統中。因此在進行FPGA驗證時,是將此IP核嵌入于此單芯片系統中進行的。此單芯片系統中嵌入UART模塊可與PC機的串口進行通信,此系統中的增強型8051MCU核對整個USB IP核進行相應的控制。FPGA驗證采用了Xilinx公司的ISE集成開發(fā)環(huán)境,在調試的過程中用了ChipSeope Pro軟邏輯分析儀。硬件平臺用Xilinx公司的Virtex4系列中XC4VLX60器件。
整個過程如下:
?。?)USB從設備與PC機的USB接口連接,此時USB從設備要完成設備枚舉的過程。
?。?)設備枚舉完成PC機會提示驅動程序還沒有裝,要求加載驅動程序在PC機上加驅動程序,USB的驅動程序直接與PC機的操作系統聯系,項目中的USB接口是在WindowsXP操作系統中調試的。
?。?)在驅動程序加載完成后,PC機會提示“現在可以正常通訊”,表明現在可以利用USB的應用層軟件進行通信了。
?。?)將數據從PC機的應用層輸入,通過USB接口發(fā)給嵌入USBIP核的數據采集SoC芯片,然后通過其中的SoC中UART將數據返回給PC機,經過比較兩者數據完全相同,驗證表明了此IP核的正確。
圖5是在進行IP核FPGA驗證時,設備枚舉階段PC的USB主機發(fā)送給USBIP核的幀開始(SOF)包。
?。?)USB從設備與PC機的USB接口連接,此時USB從設備要完成設備枚舉的過程。
?。?)設備枚舉完成PC機會提示驅動程序還沒有裝,要求加載驅動程序在PC機上加驅動程序,USB的驅動程序直接與PC機的操作系統聯系,項目中的USB接口是在WindowsXP操作系統中調試的。
?。?)在驅動程序加載完成后,PC機會提示“現在可以正常通訊”,表明現在可以利用USB的應用層軟件進行通信了。
?。?)將數據從PC機的應用層輸入,通過USB接口發(fā)給嵌入USBIP核的數據采集SoC芯片,然后通過其中的SoC中UART將數據返回給PC機,經過比較兩者數據完全相同,驗證表明了此IP核的正確。
圖5是在進行IP核FPGA驗證時,設備枚舉階段PC的USB主機發(fā)送給USBIP核的幀開始(SOF)包。
fs_clk為從PC機發(fā)過來的比特流恢復過來的12MHz的時鐘信號。rx_data表示收到的數據,如圖5所示在rx_valid高電平時,表明收到的rx_data是有效的,從圖中可以看出收到了十六進制數“A5—43—85”,此包正是PC機發(fā)給USBIP核的SOF包。rxdp和rx_dn是串口接口引擎模塊中的信號,他經過一個三態(tài)門與圖1所示的D+和D一相連接。由圖中可以看出,在“85”收到時,rxdp和rx_dn的波形表明收到了PC機發(fā)過來的兩個fS_clk時鐘周期的“SE0”表示包結束的信號。
5結語
本USBIP核在設計時,充分考慮到可重用性,其USB端點可進行相應的配置和擴展。同時針對目前SoC中常用的WishBone總線和AMBAASB總線結構設計了總線適配器,在綜合前進行相關的宏定義就可以無縫接入SoC中。本USBIP核在實際項目中,與MCU核以及其他的IP核集成于一款數據采集SoC芯片中,該數據采集SoC已經處于版圖后仿真階段,即將流片。
5結語
本USBIP核在設計時,充分考慮到可重用性,其USB端點可進行相應的配置和擴展。同時針對目前SoC中常用的WishBone總線和AMBAASB總線結構設計了總線適配器,在綜合前進行相關的宏定義就可以無縫接入SoC中。本USBIP核在實際項目中,與MCU核以及其他的IP核集成于一款數據采集SoC芯片中,該數據采集SoC已經處于版圖后仿真階段,即將流片。
評論