Side channel access through USB streams

A system may provide side channel access of a Universal Serial Bus (USB) device using USB streams. The system may include a USB interface with a USB device controller, an internal bus, a logical unit number (LUN) arbiter coupled between the USB controller and the internal bus, and a secondary interface coupled with the LUN arbiter. The system may include a plurality of storage devices coupled to the internal bus. The system may provide access to the storage devices via both the USB device controller and the secondary interface. The LUN arbiter may accept a plurality of USB streams (e.g., storage device access requests) from the USB device controller and at least one additional USB stream (e.g., storage device access request) from the secondary interface. The LUN arbiter may determine a priority of access between USB streams originating from the USB device controller and the secondary interface.

TECHNICAL FIELD

The present disclosure relates to systems and methods for use in a Universal Serial Bus (USB) environment, and more particularly, to improved systems and methods for side channel access of a USB device using USB streams.

BACKGROUND

USB environments are ubiquitous in modern electronics devices (e.g., servers, personal computers (“PCs”), tablet PCs, cell phones, automobile infotainment systems, personal gaming systems, toys, etc.). It is a “universal” interface that allows keyboards, monitors, printers, storage devices, cameras, phones, toys, games, and numerous other electronic devices to work on a single interface. With USB devices, particularly devices like card readers and similar, it is valuable to have a side channel into the device, using, for example, a separate interface, such as e.g. SPI, I2C, UART, etc., from which the downstream USB resource, for example a media card in the case of a card reader, etc., can be accessed directly. One approach is to require that such access be done through the upstream USB port, but this may complicate the logic and/or compromise system performance.

For example, in a USB device (such as a dual card reader) that does not support USB streams, only one USB packet can be processed at a given time, and any further packets are held off until processing of the current packet is completed. This means that if a side channel transfer comes into the system through the upstream USB port, then all USB packets must be held off, even if the physical resource (e.g., a memory card) is not being accessed.

In a USB device that supports USB streams, the USB device controller will process N number of streams that come in sequentially. With USB streams, a new packet can be accepted into the device before the previous packet has been processed, up to the storage and processing capability of the device. This can be accomplished by having a central command arbiter that examines each USB packet and determines to which physical resource (e.g., memory card #1, memory card #2, CPU, etc.) that packet should be routed. By routing only to the physical resource that the packet is intended for, the logic in the physical resource can be simplified.

However, even with devices that support USB streams, a side channel access to one of the physical resources on the device will need to be processed by the CPU in order to determine the correct steering. On devices that do not support out-of-ordering processing of packets (which is most devices, as it is simpler not to support it), processing of all other packets must be held off until the side channel packet is correctly steered, so that the order of all packets is maintained. This requires communication and synchronization between the side channel logic and the USB device controller, which may be complicated to implement correctly.

Further, requiring the side channel access through the upstream USB port may not be acceptable to some users that either have to use (or want to use) a separate interface, such as SPI, I2C, UART, etc. to access the USB device. Allowing side channel access to the USB device via one of these separate interfaces can complicate the hardware and associated software routines. For example, implementing the functionality to multiplex read and write commands/data on such a side channel with the read and write commands on the USB upstream can be complicated to implement and often would result in a proprietary command and addressing scheme and/or additional hardware requirements (e.g., an additional arbiter layer that determines access priority as between commands originating from the USB host and commands originating via the separate SPI/I2C/UART/etc. interface).

SUMMARY

Therefore, a need exists for an improved USB environment that can provide efficient and simple side channel access that avoids the aforementioned complications.

According to an embodiment, a system is provided which may include a USB interface with a USB device controller and buffer memory. The system may further include an internal bus and a logical unit number (LUN) arbiter coupled between the USB device controller and the internal bus. The system may further include a secondary interface coupled with the LUN arbiter. In certain embodiments, the system may include a FIFO coupled between the secondary interface and the internal bus. In the same or alternative embodiments, the system may include a plurality of storage devices coupled to the internal bus, and each storage device may include a Small Computer System Interface (SCSI) command processing unit and a memory card controller. In the same or alternative embodiments, the system may include a plurality of endpoints coupled between the USB device controller and the LUN arbiter. In the same or alternative embodiments, the USB device controller may support USB streams and the LUN arbiter may be a USB stream arbiter. In the same or alternative embodiments, the LUN arbiter may be configured to accept a plurality of USB streams from the USB device controller and at least one additional USB stream from the secondary interface.

According to a further embodiment, a method is provided for providing side channel access to a first hardware resource in a system having a plurality of hardware resources, a USB device controller that supports USB streams, a logical unit number (LUN) arbiter, and a secondary interface. The USB device controller may receive a USB request to access the first hardware resource of the plurality of hardware resources. The secondary interface may receive a side channel request to access the first hardware resource of the plurality of hardware resources. The USB device controller may forward the USB request to the LUN arbiter, and the secondary interface may forward the side channel request to the LUN arbiter. The LUN arbiter may determine the order in which the USB request and the side channel request are forwarded to the first hardware resource.

According to a further embodiment, a system is provided which may include a USB device controller, an internal bus, and a side channel interface unit. The system may further include a logical unit number (LUN) arbiter coupled between (i) the USB device controller and the internal bus and (ii) the side channel interface unit and the internal bus. The system may further include at least one hardware controller coupled to the internal bus. The system may further include at least one processor. The at least one processor may be configured to generate first and second USB packets for accessing the at least one hardware controller. The at least one processor may be further configured to transmit the first USB packet to the USB device controller via a USB interface, and to transmit the second USB packet to the side channel interface unit by tunneling the second USB packet over a side channel interface communications protocol. Upon receiving the first USB packet, the USB device controller may forward the first USB packet to the LUN arbiter as a first USB stream. Upon receiving the second USB packet, the side channel interface unit may forward the second USB packet to the LUN arbiter as a second USB stream. The LUN arbiter may determine an access priority between the first and second USB streams. The at least one hardware controller may be accessed in response to the first and second USB packets.

DETAILED DESCRIPTION

According to various embodiments, a system that can provide enhanced side channel access of a USB device using USB streams can be provided.

Referring now to the drawings, the details of example embodiments are schematically illustrated. Like elements in the drawings will be represented by like numbers, and similar elements will be represented by like numbers with a different lower case letter suffix.

FIG. 1illustrates a block diagram of an example system that can provide enhanced side channel access of a USB device using USB streams, in accordance with certain embodiments of the present disclosure. As depicted inFIG. 1, system100may comprise hardware units102and104, having processors102aand104a, respectively. System100may further comprise USB device controller106coupled to endpoint buffers110and buffer memory112. System100may further include secondary interface108coupled to FIFO122. System100may further comprise logical unit (LUN) arbiter114having upstream ports126and128, and coupled to internal bus116via a downstream port. System100may further comprise Small Computer System Interface (SCSI) command processing units118aand118band memory card controllers120aand120bfor accessing memory cards124aand124b, respectively. Bus103may couple hardware unit102with USB device controller106, and may be capable of carrying USB-compliant signaling between hardware unit102and USB device controller106. Bus130may couple hardware unit104with secondary interface108, and may be capable of carrying signaling corresponding to a protocol supported by secondary interface108.FIG. 1depicts hardware unit140, indicating that it may be a separate hardware (e.g., different physical chips, boards, etc.) from hardware units102and104. This depicted hardware delineation is, however, merely exemplary. Different embodiments (e.g.,FIG. 2, described below) may provide for different hardware configurations. Further, while the embodiment depicted inFIG. 1includes two physical memory cards (124a/b) and corresponding memory card controllers (120a/b) and SCSI command processing units (118a/b), alternative embodiments may include any number of memory cards (e.g., 2, 3, 10, 16, etc.) and associated SCSI command processing units.

Processors102aand104amay comprise any system, device, or apparatus operable to interpret and/or execute program instructions and/or process data, and may include, without limitation, a microprocessor, microcontroller, digital signal processor, application specific integrated circuit (ASIC), or any other digital or analog circuitry configured to interpret and/or execute program instructions and/or process data. Processor102aof hardware unit102may be communicatively coupled to USB device controller106to provide signaling appropriate to implement/control a USB device. Processor104aof hardware unit104may be communicatively coupled to secondary interface108to provide signaling appropriate to implement/control the secondary interface (e.g., SPI/I2C/UART/etc.). Processors102aand104amay also be communicatively coupled to other resources (not shown), including memory (e.g., volatile, non-volatile, etc.), storage media (e.g., flash, EEPROM, solid state storage media, etc.), etc.

USB device controller106may comprise any system, device, or apparatus operable to implement a USB device controller interface, and may include, without limitation, an application specific integrated circuit (ASIC) or any other digital or analog circuitry (and necessary software/firmware) configured to implement a USB device controller interface. In certain embodiments, USB device controller106may be a device controller provided by Microchip Technology, Inc. (Microchip). USB device controller106may support USB streams (e.g., as introduced in version 3.0 of the USB specification). USB device controller106may be coupled to endpoint buffers110and buffer memory112. Endpoint buffers110may comprise any number of endpoints, up to the maximum allowed by the USB specification. Endpoint buffers110may be used to store USB commands while buffer memory112may be used to store data related to USB transactions handled by USB device controller106.

Secondary interface108may comprise any system, device, or apparatus operable to implement a secondary interface, and may include, without limitation, an application specific integrated circuit (ASIC) or any other digital or analog circuitry (and necessary software/firmware) configured to implement a secondary interface. Secondary interface108may be a Serial Peripheral Interface (SPI), an Inter-Integrated Circuit (I2C) interface, a Universal asynchronous receiver/transmitter (UART) interface, or any other non-USB communications interface suitable for implementing a side channel access interface. Secondary interface108may be coupled to FIFO122. FIFO122may be used to store USB commands and data related to side channel access USB transactions handled by secondary interface108.

Logical unit number (LUN) arbiter114may comprise any system, device, or apparatus operable to implement a USB stream arbiter, and may include, without limitation, an application specific integrated circuit (ASIC) or any other digital or analog circuitry (and necessary software/firmware) configured to implement a USB stream arbiter. LUN arbiter114may include upstream ports126and128coupled to endpoint buffers110and FIFO122, respectively. LUN arbiter114may support, via upstream port126, a plurality of USB streams originating from USB device controller106. LUN arbiter114may further support, via upstream port128, at least one additional USB stream originating from secondary interface108. A LUN is a unique identifier used to differentiate separate devices (each of which is a logical unit) as addressed by a SCSI, iSCSI, or Fibre Channel (FC) protocol.

SCSI command processing units118aand118bmay comprise any system, device, or apparatus operable to process SCSI commands issued on internal bus116, and may include, without limitation, an application specific integrated circuit (ASIC) or any other digital or analog circuitry (and necessary software/firmware) configured to process SCSI commands issued on internal bus116. In alternative embodiments, internal bus116may be an iSCSI, FC, or any other bus suitable to interface between the LUN arbiter and the memory card controllers120aand120b. Accordingly, whileFIG. 1depicts elements118aand118bas SCSI command processing units, these processing units may be iSCSI, FC, or other command processing units in alternative embodiments.

Memory card controllers120aand120bmay comprise any system, device, or apparatus operable to control memory cards124aand124b, respectively, and may include, without limitation, an application specific integrated circuit (ASIC) or any other digital or analog circuitry (and necessary software/firmware) configured to control memory cards124aand124b. In alternative embodiments, memory cards124aand124bmay be hardware resources other than a memory card (e.g., audio devices, etc.). Accordingly, whileFIG. 1depicts elements120aand120bas memory card controllers, these controllers may be configured to control hardware resources other than memory cards (e.g., audio devices, etc.).

In operation, system100may provide enhanced side channel access to a USB device using USB streams. Hardware unit102and processor102amay execute software and/or firmware generally operable to interact with USB device controller106via USB bus103(e.g., a USB host controller stack, etc.). Upon receiving USB packets via USB bus103, USB device controller106may forward (e.g., store) corresponding USB commands comprising USB streams to endpoint buffers110and may store corresponding data in buffer memory112.

At any time, hardware unit104and processor104amay execute software and/or firmware generally operable to initiate a side channel access of the USB device by transmitting data to secondary interface108via bus130. As disclosed previously, bus130may be an SPI bus, an I2C bus, a UART bus, or any other non-USB bus suitable for implementing a side channel access interface. Hardware unit104and processor104amay send a USB packet over bus130by tunneling the USB packet over the secondary interface protocol. In other words, a USB protocol may be overlaid on top of a SPI/I2C/UART/etc. protocol, which is counter-intuitive when not bridging USB to SPI/I2C/UART/etc. In effect, the reverse bridging function is done, which may be considered a very odd thing to do, as USB is considered the more capable and robust protocol to use. Upon receiving USB packets via bus130, secondary interface108unpacks the USB packets and forwards (e.g., stores) the USB commands and data as USB streams in FIFO122.

LUN arbiter114may receive USB packets via USB streams at upstream ports126(from USB device controller106) and128(from secondary interface108). LUN arbiter114may steer USB packets received at upstream ports126and128to the correct on-chip resource by determining which physical LUNs (e.g., memory card controllers120aand120binFIG. 1) the packet is destined for and directing the request contained in the USB packet to the correct LUN. Accordingly, LUN arbiter114may convert the request contained in a USB packet to a command (e.g., a unicast command) according to a SCSI, iSCSI, or Fibre Channel (FC) protocol, and may forward the converted request to internal bus116.

SCSI command processing units118aand118bmay receive commands from internal bus116and interface with memory card controllers120aand120b, respectively, (or other hardware controllers) to cause an access to memory cards124aand124b(or other hardware resources). The access of memory cards124aand124bmay be as a regular USB access (i.e., via USB device controller106) or as a side channel access (i.e., via secondary interface108).

FIG. 2illustrates a block diagram of an example system that can provide enhanced side channel access to a USB device using USB streams, in accordance with certain embodiments of the present disclosure.FIG. 2is, in nearly all respects, identical toFIG. 1.FIG. 2depicts an alternative embodiment in which processor203replaces the hardware units102and104ofFIG. 1. The embodiment ofFIG. 2also differs fromFIG. 1by the addition of element140a.

According to the embodiment depicted inFIG. 2, processor203may comprise any system, device, or apparatus operable to interpret and/or execute program instructions and/or process data, and may include, without limitation, a microprocessor, microcontroller, digital signal processor, application specific integrated circuit (ASIC), or any other digital or analog circuitry configured to interpret and/or execute program instructions and/or process data. Processor203may be communicatively coupled to USB device controller106to provide signaling appropriate to implement/control a USB device. Processor203may further be communicatively coupled to secondary interface108to provide signaling appropriate to implement/control the secondary interface. Processor203may also be communicatively coupled to other resources (not shown), including memory (e.g., volatile, non-volatile, etc.), storage media (e.g., flash, EEPROM, solid state storage media, etc.), etc. Thus, while processors102aand104aofFIG. 1were part of separate hardware units, processor203inFIG. 2initiates both the normal USB accesses and the side channel accesses.

Element140aofFIG. 2represents various alternative embodiments according to this disclosure. For example, in one embodiment, processor203may be a part of hardware unit140. In alternative embodiments, processor203may be part of a hardware unit that is separate from hardware unit140.

FIG. 3illustrates a flow chart of an example method300for providing enhanced side channel access of a USB device using USB streams, in accordance with certain embodiments of the present disclosure. According to one embodiment, method300preferably begins at step302. As noted above, teachings of the present disclosure may be implemented in a variety of configurations of systems100/200. As such, the preferred initialization point for method300and the order of the steps302-314comprising method300may depend on the implementation chosen.

At step302, systems100/200may initialize. For example, systems100/200may be powered on (via power source or connection to USB host), and USB device controller106, secondary interface108, and other components of systems100/200may initialize. At step304, systems100/200may receive a first USB packet via USB bus103. The first USB packet may represent normal USB traffic sent from a USB host in hardware unit102. At step306, systems100/200may receive a second USB packet on secondary interface108. The second USB packet may be received according to the communication protocol defined by the secondary interface (e.g., tunneling the USB packet over a SPI/I2C/UART/etc. interface). At step308, the USB device controller may forward the first USB packet to the LUN arbiter114as a USB stream. At step310, the secondary interface108may forward the second USB packet to the LUN arbiter114as a USB stream (i.e., the secondary interface may unpack the tunneled second USB packet in order to forward it to the LUN arbiter114via FIFO122). At step312, the LUN arbiter114may determine the priority of access between the first and second USB packets. In this context, if LUN arbiter114determines that the first and second packets are directed to different hardware resources, LUN arbiter114may determine that there is no contention between the requests contained in the first and second packets. At step314, the LUN arbiter114may access hardware controllers120aand/or120baccording to the priority determined for the first and second USB packets. For example, LUN arbiter114may issue commands on internal bus116that may be processed by command processing blocks118a/118b. In turn, hardware controllers120aand/or120bmay be accessed, resulting in access to memory card124aand/or124b.

AlthoughFIG. 3discloses a particular number of steps to be taken with respect to the methods depicted therein, that method may be executed with greater or fewer steps than depicted. In addition, althoughFIG. 3discloses a certain order of steps to be taken with respect to the methods depicted there, the steps may be completed in any suitable order. For example, step304may occur after step306. As another example, step308may occur after step310.

Using the methods and systems disclosed herein, a system that can provide enhanced side channel access of a USB device using USB streams can be provided. According to the disclosed embodiments, users may advantageously use existing hardware interfaces to perform a side channel access of a USB device. A side channel master (e.g., SPI, I2C, UART, etc. master) may speak like a USB host to any kind of USB downstream device which may be put onto the chip. Furthermore, according to the disclosed embodiments, a CPU residing on system140may be relieved of the burden of processing all side channel packets. Further, according to the disclosed embodiments, arbitration becomes centralized and therefore simpler and more consistent. For example, LUN arbiter114need only process USB packets, which may simplify the design and remove the need for proprietary protocols. As another example, in some embodiments, LUN arbiter114need only support one additional USB stream related to the side channel access, a simple modification to pre-existing USB stream arbiters. Still further, the disclosed embodiments will allow coherent out-of-order processing for side channel accesses.

Although the present disclosure has been described in detail, it should be understood that various changes, substitutions, and alterations can be made hereto without departing from the spirit and the scope of the disclosure as defined by the appended claims.