Patent Publication Number: US-8539131-B2

Title: Root hub virtual transaction translator

Description:
BACKGROUND 
     1. Technical Field 
     Embodiments generally relate to root hub controllers. More particularly, embodiments relate to root hub controllers having virtual transaction translators. 
     2. Discussion 
     Root hub host controllers such as USB (Universal Serial Bus, e.g., USB Specification, Rev. 2.0, Apr. 27, 2000, USB 3.0 Specification, Rev. 1.0, Nov. 12, 2008, etc.) controllers can be used to connect computing systems to a wide variety of devices such as digital cameras, keyboards and mice. Indeed, a typical computing system might include multiple integrated USB ports, which can enable devices to communicate with the computing system through the root hub host controller. Certain devices, however, may have a maximum operating speed (e.g., processing frequency/rate) that is significantly less than the operating speed of the host controller. To limit the host controller&#39;s communication speed to that of the connected device could have a significantly negative impact on performance. Accordingly, the host controller may be equipped with an integrated transaction translator (TT) component that communicates through the software interface of the controller at relatively fast speeds and through the USB ports of the controller at slower speeds if the device(s) attached to those ports are slower devices. 
     In order to facilitate the translation capability, the software interface of the host controller may issue “split” tokens to the TT component. For example, when an OUT transaction is sent to an FS (full speed, 12 MHz) or LS (low speed, 1.5 MHz) device, the host controller driver and hardware may generate a Start Split (SSplit) token, an OUT token and data, and broadcast this information to all of the downstream ports via the TT component. Later, the host controller can issue a Completion Split (CSplit) token to the TT component, which may return an acknowledgement if the target device has acknowledged successful receipt of all data. The generation of the split tokens can consume bandwidth and power, and may require extra chip real estate. Moreover, the broadcasting of split token transactions to all downstream ports can limit the computing system&#39;s ability to communicate with multiple USB devices. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The various advantages of the embodiments of the present invention will become apparent to one skilled in the art by reading the following specification and appended claims, and by referencing the following drawings, in which: 
         FIG. 1  is a block diagram of an example of a host controller according to an embodiment; 
         FIG. 2  is a timing diagram of an example of an OUT transaction according to an embodiment; 
         FIG. 3  is a flowchart of an example of a method of conducting a transaction according to an embodiment; and 
         FIG. 4  is a block diagram of an example of a system according to an embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     Embodiments may provide for a system including a plurality of protocol engines having a first protocol engine with a dedicated first port. The first protocol engine can determine a first speed of a device in response to a coupling of the device to the first port, and transfer data at the first speed between the first protocol engine and the device via the first port. The system may also include software interface logic to transfer data at a second speed between the software interface logic and the first protocol engine, wherein the second speed is greater than the first speed. The data can be transferred between the software interface logic and the first protocol engine in a transaction in which no split tokens are exchanged. 
     Other embodiments can include a computer readable storage medium having a set of stored instructions which, if executed by a processor, cause a computer to determine a first speed of a device at a first protocol engine having a dedicated first port in response to a coupling of the device to the first port. The instructions may also be executed to transfer data at a second speed between software interface logic and the first protocol engine, and transfer data at the first speed between the first protocol engine and the device via the first port, wherein the second speed is greater than the first speed. The data can be transferred between the software interface logic and the first protocol engine in a transaction in which no split tokens are exchanged. 
     Embodiments may also provide for a method in which a first speed of a device is determined at a first protocol engine having a dedicated first port in response to a coupling of the device to the first port. A software notification can be received at software interface logic, wherein the notification includes a device context having a slot context and a transfer descriptor. The slot context may include a port number corresponding to the first port and the transfer descriptor can include data transfer information. The method may also provide for fetching data based on the data transfer information, and selecting the first protocol engine from a plurality of protocol engines based on the port number. A data transfer request and the fetched data can be dispatched at a second speed from a dispatcher module of the software interface logic to the first protocol engine, wherein the second speed is greater than the first speed. In addition, a state machine of the first protocol engine can be used to form a packet based on the transfer request and the fetched data from the dispatcher module. The packet may be output from the state machine and received at port control logic of the first protocol engine, wherein the port control logic has multi-speed functionality. The method can also provide for transmitting at the first speed the packet from the port control logic to the device via the first port, and transmitting an acknowledgement from the first protocol engine to the software interface logic in response to receiving an acknowledgement from the device. 
     Turning now to  FIG. 1 , a root hub host controller  10  is shown. The illustrated host controller  10  has software (e.g., device driver) interface logic  18  and a plurality of protocol engines  12  ( 12   a - 12   c ), wherein each protocol engine (“PE”) has a dedicated port (“P”)  14  ( 14   a - 14   c ) and the ports  14  are integrated into the host controller  10 . One or more devices (“D”)  16  ( 16   a - 16   c ) such as keyboards, digital cameras, mice, etc., may be coupled to the ports  14  in order to communicate with a computing system (not shown) containing the host controller  10 . In one example, one or more of the devices  16  has a maximum operating speed that is less than the operating speed of the host controller  10 . For example, the host controller  10  might operate at a speed of 5 Giga bit per second, wherein one or more of the devices  16  is classified as a full speed (FS) or a low speed (LS) device (e.g., having speeds of 12 Mega bit per second and 1.5 Mega bit per second, respectively). 
     Rather than employing an actual transaction translator (TT) component, which might require split tokens from software interface logic in order to identify speed mismatches and to establish the appropriate communication speeds, the ports  14  use the dedicated protocol engines  12  to determine and control the speed at which transactions are sent between the host controller  10  and the devices  16 . In particular, each illustrated protocol engine  12  can determine the speed of a device  16  upon connection of the device  16  to a port  14  prior to receipt of any notice, notification or token from the software interface logic  18 . Moreover, each protocol engine  12  can have a protocol engine state machine (“PESM”) and port control logic (“PCL”), wherein the state machines can process packets to be exchanged between the host controller  10  and the devices  16 , and the port control logic can have multi-speed (e.g., high speed, full speed, low speed) functionality. Thus, the protocol engines  12  might be collectively considered a “virtual transaction translator” having enhanced bandwidth capability, less power consumption, and smaller real estate requirements. In addition, by dedicating each protocol engine  12  to a port  14 , the illustrated approach also eliminates any need of the software interface logic  18  to broadcast transactions to multiple ports  14 . Accordingly, concurrent transfer of data between the host controller  10  and multiple devices  16  can be achieved. 
     The software interface logic  18  can have ring (e.g., notification) components  20  ( 20   a - 20   c ), which enable the software running on the computing system to alert the software interface logic  18  of commands, events, transfers, etc. via a doorbell array  22 . A given software notification might identify a device context  24  having a slot context and a transfer descriptor, wherein the slot context can include a root hub port number corresponding to the port connected to the device in question and the transfer descriptor includes other memory-related data transfer information. The illustrated software interface logic  18  also includes control components such as scheduling elements  28  and configuration registers  30 , and a prefetch buffer  26  to hold device contexts  24  and data for transfer. A dispatcher module  32  can fetch data from the prefetch buffer  26  based on the data transfer information in the transfer descriptors, select protocol engines based on the root hub port numbers in the slot contexts, and dispatch data transfer requests and fetched data to the protocol engines  12  at the speed of the host controller  10 . 
       FIG. 2  demonstrates in timing diagram  34  that the approaches described herein enable data to be transferred in transactions in which no split tokens are exchanged. In particular, a host controller with a “virtual TT” conducts an OUT transaction by issuing an OUT token and associated data to a target device without the need for the exchange of a SSplit token. Upon confirming successful receipt of the data, the target device can return an acknowledgement (“ACK”) packet to the host controller, wherein the host controller may notify the appropriate software without the need for the exchange of a CSplit token. The elimination of split tokens can provide more bandwidth for other transactions and/or a reduction in power consumption. Such advantages may be obtained for a wide variety of transactions such as IN transactions, setup transactions, and so on. 
     Turning now to  FIG. 3 , a method  36  of conducting a transaction such as an OUT, IN or setup transaction, is shown. The method  36  may be implemented in fixed-functionality hardware using circuit technology such as application specific integrated circuit (ASIC), complementary metal oxide semiconductor (CMOS) or transistor-transistor logic (TTL) technology, in executable firmware as a set of logic instructions stored in a machine- or computer-readable medium of a memory such as random access memory (RAM), read only memory (ROM), programmable ROM (PROM), flash memory, etc., or any combination thereof. Processing block  38  provides for detecting a coupling of a device to a port of a root hub host controller at a protocol engine dedicated to the port. The protocol engine may determine the speed of the newly connected device at block  40 , wherein the device might be a FS or LS device. Thus, the protocol engine can be aware of the device speed prior to receipt of any notice, notification or token from the software interface logic. Block  42  provides for notifying software interface logic of the host controller that the device has been connected. 
     Upon receiving the new device notification at block  44 , the software interface logic can notify the appropriate software (e.g., device driver) module at block  46 . Block  48  provides for determining whether a transaction exists at the software module. While in the illustrated example, the transaction may likely be a setup transaction, block  48  can check for other transactions such as OUT transactions, IN transactions, etc. The software module may construct a device context at block  50 , wherein the device context identifies a slot context and a transfer descriptor (“TD”). In one example, the slot context includes a root hub port number corresponding to the port to which the protocol engine is coupled, and the transfer descriptor includes data transfer information. Block  52  provides for notifying the software interface logic by ringing the doorbell to the host controller. 
     The software interface logic can receive the device context information at block  54 , wherein the dispatcher module of the software interface logic may fetch the corresponding device context into the local buffer if the device context is not already there. Block  56  provides for fetching the data based on the TD information. The dispatcher module can use the root hub port number to select the proper protocol engine at block  58 , and dispatch a data transfer request and the fetched data to the selected protocol engine at block  60 . The dispatching process may be conducted at the speed of the host controller and can involve a unicast transmission only to the selected protocol engine. Accordingly, data could be transferred between the software interface logic and another protocol engine having a dedicated port connected to a device, wherein the data is transferred between the other protocol engine and its device concurrently with the transfer of data in the illustrated example. 
     Block  62  provides for using a state machine of the protocol engine to form one or more packets, including headers and payload, based on the transfer request and the data from the dispatcher module. The state machine can transfer the packet(s) to the port control logic of the protocol engine at block  64 , wherein the packet(s) may be transmitted to the device via the port corresponding to the protocol engine at block  66 , at the appropriate device speed. An acknowledgement can be sent to the software interface at block  68  in response to receiving an acknowledgement from the device at block  70 . In particular, the packet(s) of block  66  can be transmitted to the device without the issuance of a SSplit token, and the acknowledgement of block  68  can be issued without any requirement of a C Split token. The acknowledgement may be forwarded to the software module via the software interface logic to complete the transaction detected at block  48 . 
       FIG. 4  shows a computing system  76 . The system  76  could be part of a mobile device such as a laptop, personal digital assistant (PDA), mobile Internet device (MID), wireless smart phone, media player, imaging device, etc., or any combination thereof The system  76  could alternatively include a fixed platform such as a desktop personal computer (PC) or a server. In the illustrated example, a processor  78  includes one or more cores  80  and an integrated memory controller (IMC)  80 , which provides access to system memory  82 . The system memory  82  could include dual data rate (DDR) synchronous dynamic random access memory (SDRAM, e.g., DDR3 SDRAM JEDEC Standard JESD79-3C, April 2008) modules. The modules of the system memory  82  may be incorporated into a single inline memory module (SIMM), dual inline memory module (DIMM), small outline DIMM (SODIMM), and so on. The processor  78  may also execute one or more drivers and an operating system (OS)  18  such as a Microsoft Windows, Linux, or Mac (Macintosh) OS. 
     The illustrated processor  78  communicates with a platform controller hub (PCH)  84 , also known as a Southbridge, via a bus. The IMC  80 /processor  78  and the PCH  84  are sometimes referred to as a chipset. The processor  78  may also be operatively connected to a network (not shown) through the PCH  84  and a network controller  86 . Thus, the network controller  86  could provide off-platform communication functionality for a wide variety of purposes such as cellular telephone (e.g., W-CDMA (UMTS), CDMA2000 (IS-856/IS-2000), etc.), WiFi (e.g., IEEE 802.11, 1999 Edition, LAN/MAN Wireless LANS), Bluetooth (e.g., IEEE 802.15.1-2005, Wireless Personal Area Networks), WiMax (e.g., IEEE 802.16-2004, LAN/MAN Broadband Wireless LANS), Global Positioning System (GPS), spread spectrum (e.g., 900 MHz), and other radio frequency (RF) telephony purposes. 
     The PCH  84  may also have internal controllers such as a USB root hub controller  72 , a Serial ATA (SATA, e.g., SATA Rev. 3.0 Specification, May 27, 2009, SATA International Organization/SATA-IO) controller, a High Definition Audio controller, etc. The illustrated PCH  84  may also be coupled to one or more devices  74 , which may include FS and LS user interface (UI) devices (e.g., joystick, keyboard, mouse, etc.) that enable a user to interact with and perceive information from the system  76 , and to storage, which can include a hard drive, read only memory (ROM), optical disk, flash memory (not shown), etc. 
     As already noted, the controller  72  can include a plurality of protocol engines having a first protocol engine with a dedicated first port, wherein the first protocol engine determines a first speed of a device in response to a coupling of the device to the first port. The first protocol engine may also transfer data between the first protocol engine and the device at the first speed via the first port. The controller  72  can also include software interface logic to transfer data between the software interface logic and the first protocol engine at a second speed, wherein the second speed is greater than the first speed. The plurality of protocol engines may also include a second protocol engine with a dedicated second port coupled to another device, wherein the software interface logic transfers data between the software interface logic and the second protocol engine at the second speed. The first and second protocol engines can exchange data with their respective devices concurrently and in transactions in which no split tokens are exchanged. 
     Thus, the above-described techniques enable host controllers to send transactions to a USB device through its root hub ports natively and can therefore eliminate the Split Protocol (Start Split and Complete Split transactions) with comparable scalability and expandability. The host controllers may also send different transactions to different ports in their detected USB speed. Such a solution can eliminate the broadcasting of packets to downstream ports and may improve overall USB system performance as the host controller can process multiple transactions concurrently. 
     Embodiments of the present invention are applicable for use with all types of semiconductor integrated circuit (“IC”) chips. Examples of these IC chips include but are not limited to processors, controllers, chipset components, programmable logic arrays (PLA), memory chips, network chips, systems on chip (SoCs), SSD/NAND controller ASICs, and the like. In addition, in some of the drawings, signal conductor lines are represented with lines. Some may be thicker, to indicate more constituent signal paths, have a number label, to indicate a number of constituent signal paths, and/or have arrows at one or more ends, to indicate primary information flow direction. This, however, should not be construed in a limiting manner. Rather, such added detail may be used in connection with one or more exemplary embodiments to facilitate easier understanding of a circuit. Any represented signal lines, whether or not having additional information, may actually comprise one or more signals that may travel in multiple directions and may be implemented with any suitable type of signal scheme, e.g., digital or analog lines implemented with differential pairs, optical fiber lines, and/or single-ended lines. 
     Example sizes/models/values/ranges may have been given, although embodiments of the present invention are not limited to the same. As manufacturing techniques (e.g., photolithography) mature over time, it is expected that devices of smaller size could be manufactured. In addition, well known power/ground connections to IC chips and other components may or may not be shown within the figures, for simplicity of illustration and discussion, and so as not to obscure certain aspects of the embodiments of the invention. Further, arrangements may be shown in block diagram form in order to avoid obscuring embodiments of the invention, and also in view of the fact that specifics with respect to implementation of such block diagram arrangements are highly dependent upon the platform within which the embodiment is to be implemented, i.e., such specifics should be well within purview of one skilled in the art. Where specific details (e.g., circuits) are set forth in order to describe example embodiments of the invention, it should be apparent to one skilled in the art that embodiments of the invention can be practiced without, or with variation of, these specific details. The description is thus to be regarded as illustrative instead of limiting. 
     The term “coupled” may be used herein to refer to any type of relationship, direct or indirect, between the components in question, and may apply to electrical, mechanical, fluid, optical, electromagnetic, electromechanical or other connections. In addition, the terms “first”, “second”, etc. might be used herein only to facilitate discussion, and carry no particular temporal or chronological significance unless otherwise indicated. 
     Those skilled in the art will appreciate from the foregoing description that the broad techniques of the embodiments of the present invention can be implemented in a variety of forms. Therefore, while the embodiments of this invention have been described in connection with particular examples thereof, the true scope of the embodiments of the invention should not be so limited since other modifications will become apparent to the skilled practitioner upon a study of the drawings, specification, and following claims.