《電子技術應用》
您所在的位置:首頁 > 可編程邏輯 > 設計應用 > 無MCU的USB2.0設備控制器IP設計與驗證
無MCU的USB2.0設備控制器IP設計與驗證
來源:微型機與應用2013年第10期
袁志堅1,, 黃 魯2, 徐 駿2
(1. 中國科學技術大學 電子科學與技術系 集成電路實驗室, 安徽 合肥 230027; 2. 中國
摘要: 實現了一種無需MCU的USB2.0設備控制器IP核,。使用硬件電路代替?zhèn)鹘y(tǒng)單片機實現的MCU和固件功能,,支持高速(480 Mb/s)和全速(12 Mb/s)傳輸,。所設計的IP核在FPGA上經過了驗證,結果表明它可以作為獨立的模塊用于SoC系統(tǒng)中,。
關鍵詞: FPGA IP USB SOC MCU
Abstract:
Key words :

摘  要:  實現了一種無需MCUUSB2.0設備控制器IP核,。使用硬件電路代替?zhèn)鹘y(tǒng)單片機實現的MCU和固件功能,支持高速(480 Mb/s)和全速(12 Mb/s)傳輸,。所設計的IP核在FPGA上經過了驗證,,結果表明它可以作為獨立的模塊用于SoC系統(tǒng)中。
關鍵詞: IP; USB; SoC; MCU

    通用串行總線USB(Universal Serial Bus)是現今最為流行的計算機接口,,它是一種快速,、雙向,、同步、可動態(tài)監(jiān)測的串行接口[1],。目前大多數的USB設計都是經過系統(tǒng)集成,,采用現成的商用USB芯片進行開發(fā),并沒有涉及到IP(Intellectual Property)核的設計與開發(fā),。在SoC(System on Chip)開發(fā)中可以利用已有的IP核開發(fā)成果,,縮短系統(tǒng)芯片的設計周期,提高效率,。本文通過分析USB2.0協(xié)議,,實現了一個無需外置MCU(Micro Control Unit)的USB2.0設備控制器IP核,并進行了FPGA驗證,,可用于SoC的集成中,。
1 USB2.0設備控制器系統(tǒng)設計
    目前USB2.0設備控制器廣泛使用的系統(tǒng)架構是串行接口引擎SIE(Serial Interface Engine) +MCU模式,SIE負責解釋USB協(xié)議層的動作[2],。一方面,,SIE模塊將主機發(fā)送的信息解釋成后端功能設備能夠識別的信息;另一方面,,將功能模塊相關數據按照符合USB協(xié)議的格式發(fā)送給主機,。這種傳統(tǒng)的USB設備控制器設計核心是針對事務(Transaction)和信息包(Packet)的處理。對于關鍵的控制傳輸,,則需要外置單片機和固件的輔助,,因為這種傳統(tǒng)的USB設備控制器不能獨立完成USB與主機通信過程中最核心的枚舉過程。
    本文使用硬件電路代替?zhèn)鹘y(tǒng)單片機實現MCU和固件的功能,。整體框架如圖1所示,圖中實心箭頭代表應用與主機之間的數據流,。

    采用Top-to-Down(自頂向下)的設計結構將USB設備控制器劃分為以下主要功能模塊:
    (1)Init模塊:實現UTMI協(xié)議(USB 2.0 Transceriver Macrocell Interface(UTMI) Specification)的相關細節(jié),主要用于控制總線掛起/恢復模式與速度模式的切換,。
    (2)Packet模塊:對接收到的USB格式的信息包進行處理,,提取其中的數據,檢驗CRC,;對發(fā)送的數據進行封裝,,添加CRC檢驗位。
    (3)Transaction模塊:對USB定義的基本事務(transaction)類型(如IN,、OUT,、SETUP和PING等)按照協(xié)議規(guī)范處理。以上模塊實現SIE的功能,, 其事務處理流程如圖2所示,。

    (4)Serial模塊:例化調用其他模塊,同時對傳輸過程中的錯誤進行處理,。
    (5)Descriptor ROM和Control模塊:完成枚舉過程中的控制傳輸。

 


2 硬件電路代替MCU和固件
2.1方案分析

    微控制器的主要功能是負責執(zhí)行固件框架程序,協(xié)助完成 USB的控制傳輸,。這一部分可以用單片機或者硬件電路實現,,目前常用單片機實現,優(yōu)點是設計簡單,、靈活,;缺點是單片機的速度比較慢,遠遠低于硬件電路,。
    使用硬件電路實現雖然設計復雜而且靈活度不如單片機,,但它的優(yōu)點是:(1)降低協(xié)議開銷,從而得到更快的傳輸速度,;(2)降低用戶使用開發(fā)周期,,因為使用硬件電路實現MCU功能,省去了后期固件和驅動程序的開發(fā);(3)不使用單獨的單片機,顯著地降低了成本。
2.2 MCU和固件功能模擬
    本設計中Descriptor ROM模塊用于存儲控制傳輸協(xié)議中需要用到的各種描述符,,模擬枚舉過程中固件的功能,。例如18 B的設備描述符定義如下:
    constant desc_dev: byte_array(0 to 19) := (
    X"12",  -- bLength = 18 bytes
    X"01",  -- bDescriptorType=device descriptor
    X"00", 
    X"02",  -- bcdUSB = 2.00
    X"02",  --bDeviceClass=CDC
    X"00",  -- bDeviceSubClass = none
    X"00",  -- bDeviceProtocol = none
    X"40",  -- bMaxPacketSize0 = 64 bytes
    VENDORID(7 downto 0),   -- idVendor
    VENDORID(15 downto 8),
    PRODUCTID(7 downto 0),  -- idProduct
    PRODUCTID(15 downto 8),
    VERSIONBCD(7 downto 0), -- bcdDevice
    VERSIONBCD(15 downto 8),
    X"01",  -- iManufacturer
    X"02",  -- iProduct
    X"03",  -- iSerialNumber
    X"01",  -- bNumConfigurations = 1
    X"00", X"00" ); -- 2 bytes padding
    ([注] byte_array是自定義的數組類型)
    Control模塊模擬MCU的行為,根據控制傳輸時主機請求的類型,,在Descriptor ROM中選擇相應的描述符返回給主機,。為了精簡工作流程,設計中按照“在保證傳輸正確的基礎上盡量減少中斷”的設計原則[3],,實現了設備控制器最大限度精簡指令,。根據USB2.0規(guī)定的標準設備請求的結構, Control模塊的主要工作流程圖3所示,。

    Control模塊代碼的結構主體是一個三重狀態(tài)機,。圖3是Control模塊簡化流程示意圖, 沒有標出差錯處理機制和其他細節(jié)??刂苽鬏斨?主機發(fā)送數據域長度為8 B的請求,,當Transaction模塊檢測到Setup類型傳輸時,通知Control模塊,,Control模塊檢測識別標準USB請求的8 B數據,,進行相應操作(如SetAddress、GetDesciriptor和GetConfiguration),。按照主機發(fā)送8 B請求的順序,,核心處理步驟如下:
    (1)檢測bmRequestType字節(jié),bmRequestType的D6~5位為00代表USB協(xié)議定義的標準請求(bRequest),。(2)檢查bRequest字節(jié),,USB支持11類的標準請求,此步驟可以確定請求的描述符類型,。(3)檢查wValue域(2 B),,低字節(jié)表示索引號,,用來選擇同一種描述符(例如字符串描述符和配置描述符)中具體某個描述符;高字節(jié)表示描述符的類型編號,。(4)檢查wIndex域,,在獲取字符串描述符時表示字符串的語言ID號。(5)最后檢查wLength,,表示數據過程(如果有時)所需要傳輸的字節(jié)數,。
    當Endpoint(端點)寄存器為“0000” (表示控制端點)且內部Dscbusy寄存器為‘0’(控制傳輸,但請求的不是描述符)時,,選擇發(fā)送給主機的數據是代表當前的Device(設備),、Endpoint和Interface(接口)狀態(tài)的數據;當Endpoint(端點)寄存器為“0000”(表示控制端點)且Dscbusy寄存器為‘1’時,,選擇wValue確定的描述符發(fā)送給主機,;其他情況發(fā)送的是來自應用系統(tǒng)(Application)的數據。
2.3 錯誤檢測和處理的改進
    USB規(guī)范中列出了種類繁多的錯誤的產生及其相應的檢測恢復方法,。對于傳統(tǒng)的SIE+MCU系統(tǒng),,傳輸過程中發(fā)生的任何錯誤都向外部MCU提出中斷,固件對規(guī)范中的錯誤類型應有處理及恢復機制[4],。例如Host發(fā)出 IN令牌包接收到數據以后,,必須及時地返回握手包,否則超時,。超時后,,MCU馬上產生中斷并選擇在下一個IN令牌包來時重傳上一次數據。這種處理的缺點是中斷頻繁,、效率比較低,。本設計中沒有使用MCU,對錯誤的檢測和處理均是在設備控制器內部進行,。由于省去了中斷請求與處理的延時,,對傳輸過程中發(fā)生的錯誤能夠得到高效的處理。例如對上述所提到的錯誤,,Serial選擇在下一個IN令牌到來時自動重傳上一次數據,,且最多嘗試3次,如果問題依舊存在,,作為線路故障處理,。這種處理方法能夠充分發(fā)揮硬件電路的高速優(yōu)勢。
3 系統(tǒng)仿真與FPGA驗證
    在驗證過程中,利用事務模型建立USB虛擬主機和應用模型完成系統(tǒng)功能仿真,然后綜合代碼,、設置引腳,、自動布局布線后下載到FPGA內驗證。本文選用Cypress公司的CY7C68000芯片作為前端的收發(fā)器(PHY)和Xilinx公司的Spartan-3E(XC3S500E -4PQ208C)芯片制作的 FPGA開發(fā)板作為驗證USB設備控制器IP核的平臺,。XC3S500E系統(tǒng)門數達50萬,可提供高達340 MHz的內部性能,。
    枚舉過程屬于控制傳輸,,一般分為3個階段,以Get_descriptor為例,,過程如下:
    (1)建立階段:如圖4所示,,USB主機首先發(fā)送來一個SETUP令牌包,PID為0x2d,,設備地址為0x00,端點0x00(控制端點),。后面緊跟一個DATA0的數據包,,PID為0xc3,后面的數據0x80、0x06,、0x00,、0x01、0x00,、0x00,、0x12、0x00表示這是一個Get_Descriptor標準設備請求的數據包,。其中PHY_TXVALID,、 PHY_TXREADY、 PHY_DATAOUT是符合UTMI定義數據發(fā)送接口信號,,PHY_RXVALID,、PHY_RXACTIVE、PHY_DATAIN是符合UTMI規(guī)范的數據接收接口信號,。

    (2)數據階段:主機發(fā)出一個IN包,,如圖5所示,PID為0x69,,設備收到IN包后用數據包DATA1(PID為0x4b)返回自己的設備描述符,,與前面定義的18 B設備描述符數據一致。主機收到正確的數據包后返回一個ACK握手包(PID為0xd2),,表示接收正確,。

    (3)狀態(tài)階段:主機發(fā)出OUT包,但與數據階段不同,,狀態(tài)階段所發(fā)數據包內容為空,。設備成功收到數據包后應答ACK握手包。
    本文實現了一種有別于傳統(tǒng)的MCU+SIE方案的USB2.0設備控制器IP核設計,。使用硬件電路代替單片機實現MCU和固件功能,,顯著地降低了系統(tǒng)硬件規(guī)模和實現成本。同時簡化了錯誤檢測和處理的流程,,有利于進一步提高USB傳輸速度,。FPGA驗證表明,,該方案實現的USB2.0設備控制器IP核有效可行,可以進一步完成ASIC設計,,使之作為獨立模塊添加到SoC系統(tǒng)中,。
參考文獻
[1] USB Implementers Forum, Inc. Universal serial bus specification(Rev 2.0)[EB/OL]. (2002-04-xx)[2013-01-24]. http://www.usb.org.
[2] 陳亮,袁志堅,,史大龍,,等.內嵌8051的USB2.0設備控制器IP設計[J]. 微型機與應用,2012,,31(17):28-30.
[3] [美]AXELSON J. USB開發(fā)大全[M]. 李鴻鵬,, 鄭瑞霞,陳香凝,,等譯. 北京:人民郵電出版社, 2011.
[4] 黃衛(wèi)華,,朱向東, 沈緒榜.一種高速USB設備控制器IP核的設計與實現[J]. 微電子學與計算機,, 2005,22(5):106-109.

此內容為AET網站原創(chuàng),,未經授權禁止轉載。