Patent Application
20080162737
This application relates to Universal Serial Bus (USB) data transfer architecture and methods. More specifically, this application relates to USB data transfer architecture and methods for increasing data throughput in USB peripheral devices.
USB peripheral devices, such as data storage devices containing non-volatile memory, are commonly used in home and business computing environments for reliable data storage in a compact and portable package. This type of USB peripheral device may include a USB controller that utilizes a protocol handler to interface with a USB physical layer (PHY) device and a backend circuit that communicates with flash memory. When a host connected via the USB connector of the USB device wishes to write data to, or read data from, the USB device, the commands and data are presented with the appropriate USB protocols and in the appropriate formats according to an agreed upon standard. The USB standards are designed with theoretical maximum data transfer rates. Although the USB standard will theoretically support these maximum data rates, the performance of USB data storage devices may not actually achieve the maximum data rates due to limitations of the storage medium and associated circuitry.
A USB controller in a USB data storage device manages the transfer of data to and from the USB data storage device. Typically, the data is transferred in batches of a known length and handshaking messages are exchanged between the host and the USB device to manage timing and error checking during data transfer. One way to handle the data exchange in the USB peripheral device is for the USE controller to execute a number of firmware instructions on an internal microprocessor in response to processor interrupts generated as each of the batches of data is moved to or from buffers. Firmware involvement, however, can significantly impact data transfer performance. Each interrupt will delay other activities the internal microprocessor may be engaged in, or wake the microprocessor up from any temporary sleep or idle mode, and likely require time to identify, interpret and act on firmware instructions related to the interrupt. Accordingly, microprocessor activity in a USB controller can slow down the achievable data transfer rate and increase power consumption in the USB device.
In order to address the need for an improved USB controller architecture and method of transferring data, a USB controller with full transfer automation that can reduce or avoid the use of firmware and microprocessor overhead during certain data transfer functions is set forth.
According to a first aspect, a Universal Serial Bus (USB) controller for use in a USB peripheral device is disclosed. The USB controller may include a backend module having buffer memory configured to transfer data in or out of a mass storage media such as a non-volatile memory. In addition, a host interface module is in communication with the backend module and configured to communicate with a host. The backend module and host interface module are also configured to communicate with each other via hardware logic signals relating to a data transfer status within the USB controller during a USB bulk data transfer read or write operation.
In another aspect, a Universal Serial Bus (USB) peripheral device is described. The USB peripheral device may include mass storage media, such as non-volatile memory, adapted for receiving data from or providing data to a host and a USB controller. The USB controller may include a backend module having buffer memory configured to transfer data in or out of the mass storage media. In addition, the controller may include a host interface module in communication with the backend module and configured to communicate with the host, where during a USB bulk data transfer read or write operation the backend module and host interface module are configured to communicate with each other via hardware logic signals relating to a data transfer status within the USB controller.
Other features and advantages of the invention will become apparent upon review of the following drawings, detailed description and claims.
Referring now to
The USB device core 30 includes a media access control (MAC) controller 32 and a direct memory access (DMA) block 36. Each communicate with the CPU 24 via a microprocessor interface 40 to allow the CPU 24 to read and write to the USB device core 30 registers, to setup and trigger USB transactions and to respond to transaction events and status changes reported by the USB device core 30. The MAC controller 32 communicates with the physical layer interface 28 over the UTMI data path, parses all USB tokens received from a host and generates response packets. Additionally, the MAC controller 32 also is responsible for all error checking, check fill generation, USB handshake formats, ping and data response packets, and any signals that must be generated based on a USB timing requirement.
The DMA block 36 communicates with the MAC controller 32 and is responsible for moving all of the data to be transferred to and from the flash memory 26 in the USB peripheral device 10 between the USB device core and the buffer RAM (BRAM) in the BMU 20. In one implementation, the DMA block 36 communicates over a USB full transfer automation (FTA) interface with the BMU 20 in the USB peripheral device 10 to exchange hardware logic generated handshake signals when managing data transfers, such as USES bulk data in or out transfers (also referred to as bulk data read or write transfers, respectively). A data bus connection, such as a BVCI interface, connects the DMA block 36 with the CPU 24. Additionally, the DMA block 36 maintains context information and builds configurable FIFO buffers 42, 44 between the MAC controller 32 and the DMA block 36. These FIFO's decouple the system processor memory bus request from the tight timing required by the USB protocol itself and balance out differences in internal clock frequencies that affect the timing of data transfer between the DMA block 36 and the MAC controller 32. Multiple FIFO channels may be maintained for each of the active endpoints in the system. The size of the TX and RX FIFO buffers is determined based on the number of device endpoints supported and the worst case latency to acquire the bus and fetch a block of data.
In one implementation, the USB core 30 may be an IP core from Chipidea Microelectrónica S.A. of Lisbon, Portugal. Any of a number of other IP cores from other USB IP core providers may also be used. The HIM 18 also includes FTA registers 46 and an FTA logic module 48. The FTA registers 46 are configured to receive set up information for enabling a fill transfer automation mode where, as describe in greater detail below, the USB controller 16 can utilize hardware generated logic signals, rather than CPU activity via interrupts and firmware instructions, to manage movement of data blocks to and from BRAM. The FTA registers also maintain information such as current transfer status as hardware generated logic signals increment the number of completed data block transfers in an expected bulk data transfer. The FTA module 48 contains hardware logic for generating internal handshake signals when the USB controller 16 is operating in an FTA mode. An auxiliary interface 50 may contain auxiliary registers having firmware for use by the processor to handle various tasks such as CPU sleep or wake-up routines.
In order to implement full transfer automation in the USB peripheral device 10 and, accordingly, assist in increasing data speed and reducing power consumption, the USB peripheral device 10 includes several modifications to standard USB controller architecture to provide for additional internal handshaking in the USB controller 16 using hardware logic. These additional internal handshaking messages for communicating between the HIM 18 and the backend 52 may be implemented in hardware logic in the controller to remove the need for certain traditionally firmware implemented steps requiring the involvement of the CPU 24.
The USB standard supports four transfer/endpoint types: control transfers, interrupt transfers, isochronous transfers, and bulk transfers. As noted below, bulk transfers involve large bursts of data that are handled in fixed length blocks and can benefit most from the full transfer automation described herein. In one implementation, the USB controller 16 only invokes the full transfer automation described herein during a bulk data transfer task and utilizes any of a number of standard or known CPU-based transfer mechanisms for isochronous, control or interrupt endpoints.
With respect to bulk data transfers under the USB standard, three phases are provided as illustrated in
Referring to
When enabling the FTA mode of the USB controller 16 and populating the FTA registers 46 with data shown in the data table 76 of
Once the CBW message has been processed, where the dTD and dQH data has been set up and initial information in the FTA registers generated, the USB controller 16 is prepared to handle data transfer in FTA mode and eliminate or reduce firmware involvement in the bulk data transfer. As shown in
Upon completion of transfer of the first packet of data to the buffer, the HIM 18 triggers the MAC controller 32 to send an acknowledgement (ACK) 116 message to the host 12 because buf_rdy2 and buf_rdy1 are both “1” (high) at the beginning of the transfer. Concurrently, the FTA module 48 in the HIM 18 generates via hardware an “early release” signal pulse that is communicated back to the BMU 20 to inform the BMU 20 that the transfer of the data packet is complete. In response to this release signal, BMU 20 asserts buf_rdy2 as low representative of the fact that two or more buffers are not available. In turn, the BMU may then instruct the FIM 22 to begin writing this data to the flash memory 26.
The next out token from the host is received at the USB peripheral device 10 and the accompanying data packet transfer places data in the second of the two dedicated buffers in BRAM 56. The HIM 18 interprets the combination of buf_rdy1 and buf_rdy2 in its state table at the beginning of the transfer and sends out a NYET handshake message 120 to the host 12 (buf_rdy2=0, buf_rdy1=1). Concurrently, the HIM 18 sends another early release signal 122 (or the identical final release signal) to the BMU 20 in the backend so that the BMU 20 knows that the transfer has completed. Upon noticing this release, the backend 52, via the BMU 20, sends a buf_rdy1 low signal in addition to the already low buf_rdy2 signal to indicate to the HIM 18 that no buffers 58, 60 are currently available. The NYET message 120 conveys to the host 12 that the immediately prior data transfer was received, but that the host 12 might not send more information without first checking on the status. In the scenario of
In the example of
The HIM 18 utilizes the buffer availability signals of buf_rdy1 and buf_rdy2 to generate responses to OUT and PING tokens received from the host 12. A state table 130 of the USB handshake packets generated by the USB controller 16 in response to the three valid combinations of buf_rdy1 and buf_rdy2 signals for an OUT token and for a PING token is shown in
In the reverse direction, handshake signals from the HIM 18 to the BMU 20 in the backend 52 are also generated, the early release and final release signals are hardware generated logic signals that my be implemented as digital logic in the FTA module 38 of the HIM 18. The FTA module 38 bases the early release and final release handshake messages on different input information depending on whether the USB controller 16 is handling a bulk out data transfer, an example of which is seen in
Referring to
The early release hardware signal is generated by the FTA module 48. In this instance, the early release and final release hardware signals differ because the FTA module 48 derives the early release and final release signals separately. The early release signal is used by the BMU 20 to check buffer availability for prefilling transmit (read) data to the TX FIFO 44. If the BMU receives an early release signal when the buffer in BRAM is not ready, the BMU de-asserts the buf_rdy1 signal (i.e, the signal goes low) so that the HIM 18 is prevented from pre-fetching data from the buffer. In bulk in data transfers, the FTA module 48 generates an early release based on the logic signal generated in the MAC controller 32 when the HIM 18 starts sending read data from the TX FIFO 44 to the host 12. The final release signal confirms the early release and signals to the BMU that a packet may be finally released now that an ACK response has been received from a host. The final release signal is generated by the FTA module 48 based on a logic signal generated in the MAC controller 32 indicating receipt of the ACK from the host. Because these signals from the MAC controller 32 are generated in a different clock frequency domain than used by the FTA module 48, the FTA module also includes circuitry to convert the MAC controller 32 signals from the USB PHY clock domain of the MAC controller to the system clock domain in which the FTA module operates.
The first early release signal 132 in the bulk in transfer scenario of
At the conclusion of the USB bulk data in or out transfer, the FTA engine 48 automatically stops the transfer when the transfer size 86 is reached. A request for a CSW message is received from the host also at the end of a bulk transfer. In response, firmware prepares CSW and sends it back to the host also at the end of a bulk transfer. In response, firmware prepares CSW and sends it back to the host. This implementation does not block transfers to other endpoints while FTA enabled bulk data transfer goes on.
Illustrated in both the bulk out transfer and bulk in transfer scenarios is the use of hardware signals generated in the HIM 18 and in the BMU 20 that provide a hardware handshake to increase the ability for the USB peripheral device to read and write data. No firmware interrupts requiring CPU intervention are used or necessary for each burst of data. Transferring data in or out of the flash memory, and the USB peripheral device in general, without the need to engage and interrupt, avoids the time necessary for the interrupt to be triggered, read by the CPU, and acted upon. As logically follows, a CPU will not need to be active during this phase of data transfer and thus may save overall power usage by the USB peripheral device.
Another advantage of using hardware handshakes to communicate between the backend and the HIM regarding the availability of buffer space is that memory size in the buffer may be maintained at a lower level, freeing up the otherwise blocked out buffer memory for other uses. Additionally, without the need for interrupts and CPU intervention, the CPU overhead is reduced and CPU clock speed may be reduced in comparison to implementations where firmware is necessary to track data transfer and manage buffer space. A lower clock speed implementation based on the lower CPU overhead may also contribute to additional power savings.
Although examples have been provided of a backend 52 in a USB controller 16 where two buffers have been allocated to implement the FTA mode for bulk data transfer operations, in other implementations only a single buffer may be used. The buffer may be the size of a single data transfer block (packet) Alternatively, the USB controller and methods described above are equally adaptable to using more than two buffers in BRAM where each of the buffers may be the same size as a data packet. In other implementations, for example when running the USB peripheral in full speed mode or low speed mode (12 Megabits per second or 1.5 Megabits per second, respectively, rather than the 480 Megabits per second of high speed mode), the FTA mode of operation may be adjusted to account for the 64 byte data packet size supported in full speed or low speed modes. In yet other implementations, the USB peripheral 10 may be configured to behave as a host and utilize the same FTA mode for bulk transfer operations as described. Also, although specific data packet sizes were discussed, for example 512 bytes for high speed and 64 bytes for full and low speeds, this size of data processed by the back-end may be set for other lengths in accordance with the flash memory type selected for use in the backend of the USB peripheral device.
The entirety of the following concurrently filed (Dec. 31, 2006), commonly owned U.S. patent applications are incorporated herein by reference: “Selectively Powering Data Interfaces” (attorney reference number SDA-1076x); “Selectively Powered Data Interfaces” (attorney reference number SDA-1076y); “Testing Quiescent Current of Power Islands Using Respective Scan Chains” (attorney reference number SDA-1088x); “Power Islands with Respective Scan Chains for Testing Quiescent Current” (attorney reference number SDA-1088y); “Decoupling with Two Types of Capacitors” (attorney reference number SDA-1089x); “Chip with Two Types of Decoupling Capacitors” (attorney reference number SDA-1089y); “Internally Protecting Lines at Power Island Boundaries” (attorney reference number SDA-1090x); “Integrated Circuit with Protected Internal Isolation” (attorney reference number SDA-1090y); “Updating Delay Trim Values” (attorney reference number SDA-1091x); “Module with Delay Trim Value Updates on Power-Up” (attorney reference number SDA-1091y); “Limiting Power Island Inrush Current” (attorney reference number SDA-1092x); “Systems and Integrated Circuits with Inrush-Limited Power Islands” (attorney reference number SDA-1092y); “Programmably and Locally Detecting Power Valid” (attorney reference number SDA-1093x); “Systems and Circuits with Programmable and Localized Power-Valid Detection” (attorney reference number SDA-1093y); “Method for Performing Full Transfer Automation in a USB Controller” (attorney reference number SDA-1094x (10519/201)); “Method for Configuring a USB PHY to Loopback Mode” (attorney reference number SDA-1095x (10519/203)); “Apparatus for Configuring a USB PHY to Loopback Mode” (attorney reference number SDA-1095y (10519/204)); “De-Glitching Method” (attorney reference number SDA-1096x); and “De-Glitching Circuit” (attorney reference number SDA-1096y).
From the foregoing, a method and apparatus for implementing full transfer automation in a USB controller has been described. Four new hardware generated logic signals internal to a USB controller in a USB peripheral device have been provided for a handshake between a host interface module and a backend module. The internal handshake signals, generated via hardware logic rather than through use of firmware and microprocessor time, may improve data transfer speed and reduce power consumption by the USB controller.
It is therefore intended that the foregoing detailed description be regarded as illustrative rather than limiting, and that it be understood that it is the following claims, including all equivalents, that are intended to define the spirit and scope of this invention.
