Patent Description:
The technology of the disclosure relates generally to tunneling communication buses such as the Universal Serial Bus (USB).

Computing devices abound in modern society. At least part of the reason for the prevalence of computing devices is the myriad functions that they can provide. Such diverse functionality is frequently a result of niche circuitry incorporated into distinct integrated circuits (ICs) or devices. A number of different protocols have been developed to allow ICs or devices to communicate with one another. In many cases the protocols are specialized for the particular purpose resulting in plural communication links within the computing device including mobile computing devices such as smart phones and tablets. Recently, Universal Serial Bus (USB) <NUM> has been announced, which contemplates tunneling other protocols within the USB communication link. It is anticipated that USB <NUM> will readily accommodate most high-speed protocols using the primary transmit/receive differential pairs while providing a designated sideband link as well. While USB <NUM> designates the sideband link, there is room for improvement when using the sideband link for specific low-speed communication protocols. Attention is drawn to <CIT> relating to tunneling in USB power delivery. An electronic system includes a computer and a power adapter. The computer includes an embedded controller (EC) coupled to a computer power delivery (PD) controller. The power adapter includes a power adapter PD controller connected to a slave device and is configured to communicate with the computer over a communication link. The computer PD controller is configured to receive a command from the EC and, to transmit a universal serial bus (USB) vendor defined message (VDM) header and one or more vendor defined objects (VDOs) including the information of the payload of the transmit command. The power adapter PD controller responds to the one or more VDOs either by changing an output signal to the slave device connected to the power adapter PD controller, reports a state of a general purpose input/output (GPIO) pin of the power adapter PD controller, or changes the state of the GPIO pin. Further attention is drawn to <CIT>, relating to communications over a USB Type-C cable. A link control circuit is provided in a USB host to enable one or more communication circuits in the USB host to transmit and receive protocol-specific data over a sideband use, SBU, interface according to communication protocols that may or may not be USB compliant. In another aspect, the link control circuit is provided in a USB client to enable one or more communication circuits in the USB client to transmit and receive protocol-specific data over the SBU interface according to communication protocols that may or may not be USB compliant.

Aspects disclosed in the detailed description include tunneling over Universal Serial Bus (USB) sideband channel systems and methods. In particular, exemplary aspects of the present disclosure provide a way to tunnel I2C transactions between a master and slaves over USB <NUM> sideband channels. More particularly, a slave address table lookup (SATL) circuit is added to a host circuit. Signals from an I2C bus are received at the host, and any address associated with a destination is translated by the SATL. The translated address is passed to a low-speed interface associated with a sideband channel in the host circuit. Signals received at the low-speed interface are likewise reverse translated in the SATL. and then sent out through the I2C bus. Delays while I2C signals are propagating through a tunneling protocol may be accommodated by issuing a stretch command to a device expecting a response. In this fashion, low-speed I2C signals may be routed over the sideband channel through the low-speed sideband interface portion of the USB interface. Such routing permits the high-speed interface portion of the USB interface to remain dormant (e.g., potentially in a low-power mode) and prevents the need for additional pins and conductors to convey I2C signals to remote circuits.

Aspects disclosed in the detailed description include tunneling over Universal Serial Bus (USB) sideband channel systems and methods. In particular, exemplary aspects of the present disclosure provide a way to tunnel I2C transactions between a master and slaves over USB <NUM> sideband channels. More particularly, a slave address table lookup (SATL) circuit is added to a host circuit. Signals from an I2C bus are received at the host, and any address associated with a destination is translated by the SATL. The translated address is passed to a low-speed interface associated with a sideband channel in the host circuit. Signals received at the low-speed interface are likewise reverse translated in the SATL and then sent out through the I2C bus. Delays while I2C signals are propagating through a tunneling protocol may be accommodated by issuing a stretch command to a device expecting a response. In this fashion, low-speed I2C signals may be routed over the sideband channel through the low-speed sideband interface portion of the USB interface. Such routing permits the high-speed interface portion of the USB interface to remain dormant (e.g., potentially in a low-power mode) and prevents the need for additional pins and conductors to convey I2C signals to remote circuits.

Before addressing specific examples of using a USB sideband link to send I2C signals through a USB link according to the present disclosure, a brief overview of possible environments in which a USB communication link may exist is provided with reference to <FIG>, while a USB Type-C connector is illustrated in <FIG>. A discussion of the actual sideband channel begins below with reference to <FIG>, while the intersection of a USB connection and an I2C bus is discussed with reference to <FIG>. Exemplary aspects of sending an I2C signal over a USB sideband channel begins below with reference to <FIG>.

In this regard, <FIG> illustrates a computing system <NUM>. The computing system <NUM> may include a main computer housing <NUM> that contains a processor (not shown) and is coupled to a monitor <NUM>, a keyboard <NUM>, and a mouse <NUM> through cables <NUM>(<NUM>)-<NUM>(<NUM>). While not shown, other user interface elements may also be present and coupled to the main computer housing <NUM> through a cable. One or more of the cables <NUM>(<NUM>)-<NUM>(<NUM>) may be a USB Type-C cable. Further, the main computer housing <NUM> may be coupled to another computing device <NUM> such as a tablet through a USB Type-C cable <NUM>. While not illustrated, the computing device <NUM> may be a peripheral such as a virtual reality headset.

<FIG> illustrates a computing system <NUM> that may be a mobile computing device <NUM> such as a mobile phone or tablet that contains a processor (not shown) and is coupled to a virtual reality headset <NUM> through a cable <NUM>, which may be a USB Type-C cable.

While USB is commonly thought of as an external connection requiring manual manipulation (e.g., insertion or extraction) of a connector into a receptacle, USB <NUM> is being adopted in chip-to-chip communication. In this regard, <FIG> illustrates a computing system <NUM> (perhaps positioned within the main computer housing <NUM>) that may include a first integrated circuit (IC) <NUM>, which may be an application processor (AP) or the like, a second IC <NUM>, which may be a modem or the like, and a third IC <NUM>, which may be a baseband processor (BBP) or the like. The first IC <NUM> may include a control circuit <NUM> and a host circuit <NUM>. The second IC <NUM> may include a control circuit <NUM>, an endpoint circuit <NUM>, and a host circuit <NUM>. The third IC <NUM> may include a control circuit <NUM> and an endpoint circuit <NUM>. The host circuit <NUM> may be coupled to the endpoint circuit <NUM> through a first USB communication link <NUM>, and the host circuit <NUM> may be coupled to the endpoint circuit <NUM> through a second USB communication link <NUM>. It should be appreciated that the second IC <NUM> may be a slave relative to the first IC <NUM>, but may be a host relative to the third IC <NUM>. As these are IC level connections, there may be no connector or receptacle, but the pins and lines within the respective circuits are dictated by the USB Type-C standard, and the bus interfaces (not shown) may omit the receptacle/connector portion that is common on external USB connections. It should be noted that in both internal and external implementations, USB links are generally shorter than two meters (<NUM>). As better explained below in <FIG>, if the USB links are greater than <NUM>, a retimer chip may be used to boost signals on the USB link.

<FIG> illustrates a standard USB Type-C connector <NUM> having a top row <NUM> and a bottom row <NUM>, which are inverted mirror images of each other to allow insertion in either direction. The pin layout is summarized in Table <NUM> below.

Even where there is not an explicit connector or receptacle, a USB connection such as the USB communication links <NUM>, <NUM> will have pins and links corresponding to the pins of Table <NUM>. SBU pins <NUM> and <NUM> are designated by the USB standard as sideband use pins. Sideband signals are considered low-speed (e.g., approximately one megabit per second (<NUM> ~ <NUM> Mbs) or less) signals and may be used for an alternate mode under the USB standard. Accordingly, for the purposes of the present disclosure, low-speed is defined to be signals of less than <NUM> Mbs. The SBU pins <NUM> and <NUM> will be used by exemplary aspects of the present disclosure to send a low-speed protocol such as I2C through the USB link without using a high-speed portion of the link. In general, the sideband use will be low frequency, at least relative to the super-speed, high-speed, or full-speed contemplated on the primary data lines (e.g., D+, D-, TX1, TX2, RX1, RX2). The USB <NUM> specification contemplates using the sideband channel in a default Universal Asynchronous Receiver/Transmitter (UART) mode.

<FIG> illustrates a USB subsystem <NUM> having a host IC <NUM> and a slave or endpoint IC <NUM> coupled by a USB communication link <NUM>. The USB communication link <NUM> may be considered a multichannel bus that includes a high-speed link 406A and a low-speed link 406B, which may be the SBU link. The host IC <NUM> includes a host circuit <NUM> as well as a host control circuit <NUM>. Similarly, the endpoint IC <NUM> includes an endpoint circuit <NUM> and an endpoint control circuit <NUM>. It should be appreciated that the host circuit <NUM> may be or has a high-speed bus interface <NUM> that is configured to couple to high-speed lanes of the high-speed link 406A and a low-speed interface <NUM> that is configured to couple to the low-speed lanes of the low-speed link 406B. Similarly the endpoint circuit <NUM> may be or has a high-speed bus interface <NUM> that is configured to couple to the high-speed lanes of the high-speed link 406A and a low-speed interface <NUM> that is configured to couple to the low-speed lanes of the low-speed link 406B.

By way of additional explanation, an overview of an I2C system <NUM> that may include a USB link <NUM> is provided with reference to <FIG>. Specifically, the 12C system <NUM> may include an I2C master IC <NUM> that couples to a host I2C bus <NUM>. One or more host I2C slaves <NUM>(<NUM>)-<NUM>(N) also couple to the I2C bus <NUM>. The host I2C bus <NUM> may couple to the host IC <NUM>, which in turn couples to the USB link <NUM>. The USB link <NUM> may couple to the endpoint IC <NUM>, which in turn couples to endpoint or device I2C bus <NUM>. Additional device I2C slaves <NUM>(<NUM>)-<NUM>(M) may be coupled to the device I2C bus <NUM>. In some implementations, where the USB link <NUM> exceeds about <NUM>, the USB link <NUM> may include a retimer IC <NUM>, which is designed to boost the signals on the USB link <NUM>.

In the absence of the present disclosure, there are areas of the I2C system <NUM> which create at least two implementation concerns for designers. In particular, as a first concern, in the absence of the present disclosure, I2C signals from the I2C master IC <NUM> to any one of the device I2C slaves <NUM>(<NUM>)-<NUM>(M) are tunneled through the USB link <NUM> on a high-speed link (e.g., through the superspeed channel). Given the general disparity between the high-speed lines and the low-speed requirements of I2C, such tunneling is inefficient. Further, such usage may require the high-speed line to remain active for longer periods of time, resulting in unwanted power consumption. Even if the D+/D- lines of the USB link <NUM> are used, there may be a conversion layer inside the host IC <NUM> as well as additional software and hardware on the device side to use the D+/D-lines of the USB link <NUM>. This situation leads to higher latency for I2C access and may require a specialized USB driver. As a second concern, control for any intermediate chips, such as the retimer IC <NUM>, is generally through I2C signaling. Currently, there is no way to extract the I2C signals from the USB link <NUM> at the retimer IC <NUM> to provide such signaling without having a full endpoint circuit (and another host circuit) within the chip. Again, in the absence of the present disclosure, the solution to this signaling requirement that avoids the additional endpoint/host circuity in the chip is to provide additional general purpose input/output (GPIO) pins at the host and at the retimer IC <NUM> along with additional conductive lines to couple these additional GPIO pins. Each pin comes with an additional cost both in terms of material and space. At a time when space and cost are prominent constraints, the addition of such additional GPIO pins is impractical.

Accordingly, exemplary aspects of the present disclosure provide a way to send I2C signals through sideband channels and particularly over the SBU links associated with SBU pins <NUM>, <NUM>. In particular, exemplary aspects of the present disclosure allow for I2C signals to be sent through a tunneling protocol over the SBU links. In this fashion, both concerns raised above are handled. Specifically, the low-speed links associated with the SBU channel are controlled independently of the high-speed links. Thus, traffic on the SBU links will not impact the low-power modes of the high-speed links resulting in net power savings. Further, the retimer IC <NUM> or comparable chip may be configured to receive and process signals on the SBU link without having to process the entirety of the signals on the high-speed links. This arrangement helps avoid the need for the additional GPIO pins and thus avoid the extra expense those pins entail and preserves space within a given chip to use for other purposes.

To provide the ability to send I2C messages over the SBU link, exemplary aspects of the present disclosure modify the host IC as set forth in <FIG>. Specifically, a host system <NUM> may include a host IC <NUM> that couples to an I2C bus <NUM>. An I2C master IC <NUM> is also coupled to the I2C bus <NUM>. Optional I2C slaves <NUM>(<NUM>)-<NUM>(N) may also be coupled to the I2C bus <NUM>. The host IC <NUM> may receive additional inputs from a display (e.g., DISPLAYPORT) source <NUM> at a display interface <NUM> and a Peripheral Component Interconnect (PCI) Express (PCIE) source <NUM> at a PCIE interface <NUM>. The host IC <NUM> may further include a host interface (I/F) adapter or interface <NUM>. High-speed signals such as DISPLAYPORT, PCIE, and the like are provided to a USB <NUM> port <NUM>, where they may be multiplexed by a bi-directional multiplexer <NUM> before being passed to the USB link through a USB high-speed interface <NUM>. The multiplexer <NUM> may also receive messages from an enhanced superspeed host IC <NUM> through a second bi-directional multiplexer <NUM>. A USB <NUM> host <NUM> may provide messages to a USB <NUM> interface <NUM>. The second multiplexer <NUM> may further handle messages from a USB <NUM> adapter <NUM> in the host IC <NUM>.

The present disclosure provides an I2C interface or adapter <NUM>, which is configured to couple to the I2C bus <NUM> and act as a slave (relative to the I2C master IC <NUM>). The adapter <NUM> further includes a slave address table list (SATL) <NUM> (i.e., a translation circuit) holding information about registers in slaves that lie on the other side of a USB link for "outgoing" messages and information about registers in the I2C master IC <NUM> or I2C slaves <NUM>(<NUM>)-<NUM>(N) for "incoming" messages. Messages received from the I2C bus <NUM> are processed by the adapter <NUM> using the SATL <NUM> and sent to a sideband channel interface <NUM>. The sideband channel interface <NUM> routes messages to a sideband interface <NUM>.

On the other end of the USB link a device <NUM> as illustrated in <FIG> may be provided. Alternatively, a pass-through device like a retimer IC <NUM> as illustrated in <FIG> may be provided. Still further, there may be cascaded devices in a system <NUM> such as illustrated in <FIG>. The device <NUM> includes a USB interface <NUM> configured to be coupled to the USB link and containing a USB <NUM> interface <NUM>, a high-speed interface <NUM> (which may have a superspeed interface, a full-speed interface, and a USB high-speed interface), and a sideband interface <NUM>. The USB <NUM> interface <NUM> is coupled to a USB <NUM> function IC <NUM>. The high-speed interface <NUM> may be provided to a multiplexer <NUM> that routes signals to a USB port <NUM> in a device router <NUM> or to a second multiplexer <NUM> associated with an enhanced superspeed function IC <NUM>. The second multiplexer <NUM> may also be coupled to a USB <NUM> adapter <NUM> in the device router <NUM>. The USB port <NUM> may be coupled to the USB <NUM> adapter <NUM>, a PCIE out adapter <NUM>, and a display out adapter <NUM>. The PCIE out adapter <NUM> may be coupled to a PCIE function IC <NUM>, and the display out adapter <NUM> may be coupled to a display IC <NUM> (e.g., a DISPLAYPORT IC).

With continued reference to <FIG>, the sideband interface <NUM> is coupled to a sideband channel input <NUM> of the device router <NUM>. The sideband channel input <NUM> is coupled to an I2C out adapter <NUM>. The I2C out adapter <NUM> acts as a master for an I2C bus <NUM>, which is coupled to device slaves <NUM>(<NUM>)-<NUM>(M). While not shown, a second SATL may be present in the device router <NUM> at the 12C out adapter <NUM> or the sideband channel input <NUM> to handle messages intended for the I2C master IC <NUM> or I2C slaves <NUM>(<NUM>)-<NUM>(N) of <FIG>. Sideband messages arriving at the sideband interface <NUM> are provided to the sideband channel input <NUM> and processed to ascertain a destination. For messages intended for the device slaves <NUM>(<NUM>)-<NUM>(M), the messages are passed to the I2C out adapter <NUM> to be sent out on the I2C bus <NUM>.

As discussed above, there may be a retimer chip or retimer IC associated with a USB link where the USB link is greater than <NUM> or there is some other reason to boost signals on the USB link (e.g., electromagnetic interference). Such a retimer IC is controlled by I2C messages that may be sent in the sideband channel of the USB link to avoid having to provide additional GPIO pins. However, the retimer IC does not need to process any of the high-speed signals and accordingly may pass such high-speed signals through the retimer IC <NUM>, albeit amplifying the signals if desired. In this regard, a retinier IC <NUM> is illustrated in <FIG>. The retimer IC <NUM> may include a USB interface <NUM> configured to be coupled to the USB link and containing a USB <NUM> interface <NUM>, a high-speed interface <NUM>, and a sideband interface <NUM>. High-speed signals received at the USB <NUM> interface <NUM> and the high-speed interface <NUM> may have pass-through links <NUM> that couple the interfaces <NUM>, <NUM> to a second USB interface <NUM>' that may contain a USB <NUM> interface <NUM>' and a high-speed interface <NUM>'. While not shown, amplifier(s) may be associated with the pass-through links <NUM> to boost the high-speed signals.

The sideband interface <NUM> may couple to a sideband processor <NUM> that receives sideband signals and extracts any I2C messages therein to be used by an I2C control circuit <NUM>. Other sideband messages may be passed from the sideband processor <NUM> to a sideband interface <NUM>' in the USB interface <NUM>'. A sideband channel input <NUM> may be present to assist in this process.

Note that there may be systems where there are multiple cascaded devices on a single sideband chain. For example, such cascaded devices may be retimer chips. Such a system <NUM> is shown in <FIG> where a host system <NUM> is coupled to a device <NUM>, which in turn is coupled to a second device <NUM>. Note that there may be more intermediate devices <NUM> (not shown). Device <NUM> is substantially similar to device <NUM>, but uses its SATL <NUM> to determine if signals or messages should be placed on a downstream sideband link <NUM> or passed to an I2C out interface <NUM>.

Regardless of the specific system arrangement, there still must be a way to indicate to the destination that the signal includes an I2C command and address. The USB <NUM> specification relies on reading from and writing to registers for sideband communication. In particular, Table <NUM>-<NUM> of the USB <NUM> specification, reproduced as table <NUM> in <FIG>, identifies two hundred fifty-six (<NUM>) registers, but leaves many of these registers to "vendor specific" implementations. Exemplary aspects of the present disclosure take one of these registers <NUM> (e.g., register <NUM>) and define a two-byte command <NUM> (e.g., I2C_transport) as better illustrated in <FIG>. The first byte <NUM> defines a transport type (e.g., a command) and the second byte <NUM> defines transport data (if present). In an exemplary aspect, the possible commands in the first byte <NUM> include write commands <NUM> such as write_start <NUM>(<NUM>), write_stop <NUM>(<NUM>), write_response <NUM>(<NUM>), and write_data <NUM>(<NUM>) and read commands <NUM> such as read_start <NUM>(<NUM>), read_stop <NUM>(<NUM>), read_response <NUM>(<NUM>), and read_acknowledge <NUM>(<NUM>). The possible transport data in the second byte <NUM> may include write data <NUM> such as a write command and a slave address <NUM>(<NUM>), a null field <NUM>(<NUM>), an acknowledgment (ACK) or negative ACK (NACK) <NUM>(<NUM>), or actual data <NUM>(<NUM>) or read data <NUM> such as a read command and slave address <NUM>(<NUM>), a null field <NUM>(<NUM>), an ACK and data/NACK <NUM>(<NUM>), or a null field <NUM>(<NUM>). While these exemplary commands and arrangements provide the desired functionality, other arrangements may provide similar functionality and are within the scope of the present disclosure.

To further assist in understanding exemplary aspects of the present disclosure, <FIG> and <FIG> illustrate a timeline <NUM> and signal flow diagram <NUM> of a write command from the I2C master IC <NUM> to a slave <NUM>. Specifically, the timeline <NUM> begins while normal UART sideband signaling <NUM> is occurring. At time <NUM>, the I2C master IC <NUM> generates a write command <NUM> using the I2C protocol (e.g., S=<NUM> to show a start condition, the address, and a <NUM> bit to show that it is a write command). The write command <NUM> is sent from the I2C master IC <NUM> to the adapter <NUM>. The adapter <NUM> uses the SATL <NUM> to generate a sideband write command <NUM> (e.g., using write_start <NUM>(<NUM>)) with the appropriate slave address as indicated in the SATL <NUM>. Meanwhile the 12C master IC <NUM> enters a stretch phase <NUM>. The sideband write command <NUM> is sent over the USB link and received by the device <NUM> and specifically at the sideband channel input <NUM>. The sideband write command <NUM> has the address extracted and generates an I2C write command <NUM> complying with the I2C protocol (e.g., S=<NUM> to show a start condition, the slave address extracted from the sideband write command <NUM>, and a <NUM> bit to show that it is a write command). The I2C write command <NUM> is sent over the I2C bus <NUM> to the addressed slave <NUM> and then enters a stretch. The device <NUM> sends a write response command <NUM> with an ACK. The sideband link may send normal UART signals during time <NUM> while the I2C master IC <NUM> sends data <NUM> before entering a stretch <NUM>. On receipt of the data <NUM>, the adapter <NUM> translates the data <NUM> using the SATL <NUM> and generates a write data command <NUM> that is sent to the device <NUM>. The I2C out adapter <NUM> sends the data out as signal <NUM> and generates a write response ACK signal <NUM>. The sideband link may return to normal UART signaling until the I2C master IC <NUM> sends additional data <NUM> (and enters a stretch). The additional data <NUM> is translated and sent out as a write_data command <NUM> by the adapter <NUM> to the device <NUM>. The device <NUM> then sends the data <NUM> to the addressed slave <NUM> before generating a write_response command <NUM> with an ACK. When the last data has been written and acknowledged, the I2C master IC <NUM> may send a write_stop command <NUM>, which stops the slave <NUM>.

<FIG> provides the signal flow diagram <NUM> corresponding to the timeline <NUM>. The signal flow diagram <NUM> begins with the I2C master IC <NUM> issuing the write command <NUM> to the adapter <NUM>. The adapter <NUM> uses the SATL <NUM> (block <NUM>) and signals <NUM> to the I2C master IC <NUM> to enter a stretch 954A. The adapter <NUM> further generates the sideband write command <NUM> and sends the sideband write command <NUM> to the I2C out adapter <NUM> in the device <NUM>. The sideband write command <NUM> has the address extracted and generates the I2C write command <NUM> complying with the 12C protocol. The I2C write command <NUM> is sent over the I2C bus <NUM> to the addressed slave <NUM> which responds with an ACK <NUM>. The I2C out adapter <NUM> sends a stretch command <NUM> to cause the slave <NUM> to enter stretch 958A. Meanwhile, the I2C out adapter <NUM> sends the write response command <NUM> with an ACK. The adapter <NUM> sends an ACK <NUM> to the I2C master IC <NUM>. The I2C master IC <NUM> then sends the data <NUM>. The adapter <NUM> sends a stretch command <NUM> and generates the write data command <NUM> that is sent to the device <NUM>. The I2C out adapter <NUM> sends the data out as the signal <NUM>. The slave <NUM> generates an ACK <NUM>. The I2C out adapter <NUM> commands <NUM> the slave <NUM> to enter a stretch 966A. Meanwhile, the I2C out adapter <NUM> generates the write response ACK signal <NUM>. The adapter <NUM> sends an ACK <NUM> to the I2C master IC <NUM>, which repeats the data steps as needed (generally <NUM>) or the I2C master IC <NUM> may send a write_stop command <NUM>, which causes the adapter <NUM> to send the write_stop command <NUM>, which causes a stop command <NUM> to be sent to the slave <NUM>.

Read commands work similarly as illustrated in <FIG> and <FIG>. Specifically, <FIG> illustrates a timeline <NUM> while <FIG> illustrates a signal flow diagram <NUM>. Specifically, the timeline <NUM> begins while normal UART sideband signaling <NUM> is occurring. At time <NUM>, the I2C master IC <NUM> generates a read command <NUM> using the I2C protocol (e.g., S=<NUM> to show a start condition, the address, and a <NUM> bit to show that it is a read command). The read command <NUM> is sent from the I2C master IC <NUM> to the adapter <NUM>. The adapter <NUM> uses the SATL <NUM> to generate a sideband read command <NUM> (e.g., using read_start <NUM>(<NUM>)) with the appropriate slave address as indicated in the SATL <NUM>. Meanwhile the I2C master IC <NUM> enters a stretch phase <NUM>. The sideband read command <NUM> is sent over the USB link and received by the device <NUM> and specifically at the sideband channel input <NUM>. The sideband read command <NUM> has the address extracted and generates an I2C read command <NUM> complying with the I2C protocol (e.g., S=<NUM> to show a start condition, the slave address extracted from the sideband read command <NUM>, and a <NUM> bit to show that it is a read command). The I2C read command <NUM> is sent over the I2C bus <NUM> to the addressed slave <NUM> and then enters a stretch. The device <NUM> sends a read response command <NUM> with an ACK and any data. The sideband link may send normal UART signals during time <NUM> while the I2C master IC <NUM> receives data <NUM> before entering a stretch <NUM>. On receipt of an ACK from the I2C master IC <NUM>, the adapter <NUM> sends a read acknowledgment <NUM> to the device <NUM>. The I2C out adapter <NUM> prepares additional data <NUM>, and sends a further read response signal <NUM>. The additional data <NUM> is provided to the I2C master IC <NUM> as a signal <NUM> from the adapter <NUM>, which responds with a further ACK, causing the adapter <NUM> to generate another read acknowledgment signal <NUM> and a read stop command <NUM>.

<FIG> provides the signal flow diagram <NUM> corresponding to the timeline <NUM>. The signal flow diagram <NUM> begins with the I2C master IC <NUM> issuing the read command <NUM> to the adapter <NUM>. The adapter <NUM> uses the SATL <NUM> (block <NUM>) and signals <NUM> to the I2C master IC <NUM> to enter a stretch 1054A. The adapter <NUM> further generates the sideband read command <NUM> and sends the sideband read command <NUM> to the I2C out adapter <NUM> in the device <NUM>. The sideband read command <NUM> has the address extracted and generates the I2C read command <NUM> complying with the I2C protocol. The I2C read command <NUM> is sent over the I2C bus <NUM> to the addressed slave <NUM> which responds with an ACK <NUM>. The slave <NUM> further sends the read data signal <NUM>. The I2C out adapter <NUM> sends a stretch command <NUM> to cause the slave <NUM> to enter stretch 1058A. Meanwhile, the I2C out adapter <NUM> sends the read response command <NUM> with an ACK. The adapter <NUM> sends an ACK <NUM> to the I2C master IC <NUM>. The I2C master IC <NUM> then receives the signal <NUM> and sends an ACK <NUM>. The adapter <NUM> sends a stretch command <NUM> and generates the read acknowledgment <NUM> that is sent to the device <NUM>. The I2C out adapter <NUM> sends an ACK <NUM>, which may repeat <NUM> to send more data as needed. The I2C out adapter <NUM> sends a stretch command <NUM> to the slave <NUM>. When all the data is transferred, the I2C master IC <NUM> may send a read stop command <NUM>, which causes the adapter <NUM> to send the read stop command <NUM>. The I2C out adapter <NUM> then sends a stop command <NUM> to the slave <NUM>.

<FIG> illustrates a process <NUM> distilled from <FIG> for both read and write commands. The process <NUM> begins on power up of the I2C host adapter <NUM> (block <NUM>). The host adapter <NUM> monitors for whether the I2C bus <NUM> has started (block <NUM>). While the answer to block <NUM> is no, the process <NUM> continues to monitor. Once the I2C bus <NUM> has started and a message is sent, the adapter <NUM> checks the address of the message to see if the address is in the SATL <NUM> (block <NUM>). If the address is not in the SATL <NUM>, that means the message is for a slave <NUM>(<NUM>)-<NUM>(N) and the present disclosure is not needed. If however, the address is in the SATL <NUM> indicating a slave <NUM>(<NUM>)-<NUM>(M), then the adapter <NUM> sends a start stretch command to the I2C master IC <NUM> (block <NUM>) and determines if the command is a read or write command (block <NUM>).

With continued reference to <FIG>, and assuming that the command was a write command at block <NUM>, the adapter <NUM> sends an 12C_write_start command with the device address on the sideband link (block <NUM>). The adapter <NUM> then listens to see if an I2C_write_response has been received from the sideband link (block <NUM>). Once a response is received (e.g., an ACK), the adapter <NUM> stops the stretch and sends the ACK to the I2C master IC <NUM> (block <NUM>). The I2C master IC <NUM> sends data or a stop command (block <NUM>). If the I2C master IC <NUM> sends data, then the adapter <NUM> starts a stretch for the I2C master IC <NUM> and sends the data over the sideband link to be written to the slave (block <NUM>). If however, a stop is sent at block <NUM>, then the adapter <NUM> sends an I2C_write_stop command (block <NUM>).

With continued reference to <FIG>, and returning to block <NUM>, if a read command is received, the adapter <NUM> sends an I2C_read_start command with the device address over the sideband link (block <NUM>). The adapter <NUM> waits for a response (block <NUM>). If the response is a NACK, then the adapter <NUM> stops the stretch and sends the NACK to the I2C master IC <NUM> (block <NUM>) after which the process <NUM> returns to block <NUM>. If the response is an ACK with data, the adapter <NUM> stops the stretch and sends the data with the ACK to the I2C master IC <NUM> (block <NUM>) and then monitors for a response (block <NUM>) of an ACK or NACK from the I2C master IC <NUM>. If the answer is a NACK, then the adapter <NUM> sends the read not acknowledged over the sideband link (block <NUM>) and the process <NUM> returns to block <NUM>. If however, the answer at block <NUM> is an ACK, then the adapter <NUM> sends an I2C_read_acknowledged command (block <NUM>). The adapter <NUM> then monitors for a stop from the I2C master IC <NUM> (block <NUM>). If a stop is received, then the adapter <NUM> sends an I2C_read_stop command (block <NUM>), and the process <NUM> returns to block <NUM>. If however, no stop is received, the adapter <NUM> starts a stretch toward the I2C master IC <NUM> (block <NUM>) and returns to block <NUM>.

The tunneling over USB sideband channel systems and methods according to aspects disclosed herein may be provided in or integrated into any processor-based device. Examples, without limitation, include a set top box, an entertainment unit, a navigation device, a communications device, a fixed location data unit, a mobile location data unit, a global positioning system (GPS) device, a mobile phone, a cellular phone, a smart phone, a session initiation protocol (SIP) phone, a tablet, a phablet, a server, a computer, a portable computer, a mobile computing device, a wearable computing device (e.g., a smart watch, a health or fitness tracker, eyewear, etc.), a desktop computer, a personal digital assistant (PDA), a monitor, a computer monitor, a television, a tuner, a radio, a satellite radio, a music player, a digital music player, a portable music player, a digital video player, a video player, a digital video disc (DVD) player, a portable digital video player, an automobile, a vehicle component, avionics systems, a drone, and a multicopter.

More generally, in this regard, <FIG> illustrates an example of a processor-based system <NUM> that can employ a USB subsystem such as that illustrated in <FIG>. In this example, the processor-based system <NUM> includes one or more central processing units (CPUs) <NUM>, each including one or more processors <NUM>. The CPU(s) <NUM> may have cache memory <NUM> coupled to the processor(s) <NUM> for rapid access to temporarily stored data. The CPU(s) <NUM> is coupled to a system bus <NUM> and can intercouple master and slave devices included in the processor-based system <NUM>. As is well known, the CPU(s) <NUM> communicates with these other devices by exchanging address, control, and data information over the system bus <NUM>. For example, the CPU(s) <NUM> can communicate bus transaction requests to a memory controller <NUM> as an example of a slave device.

Other master and slave devices can be connected to the system bus <NUM>. As illustrated in <FIG>, these devices can include a memory system <NUM>, one or more input devices <NUM>, one or more output devices <NUM>, one or more network interface devices <NUM>, and one or more display controllers <NUM>, as examples. The input device(s) <NUM> can include any type of input device, including, but not limited to, input keys, switches, voice processors, etc. The output device(s) <NUM> can include any type of output device, including, but not limited to, audio, video, other visual indicators, etc. The network interface device(s) <NUM> can be any devices configured to allow exchange of data to and from a network <NUM>. The network <NUM> can be any type of network, including, but not limited to, a wired or wireless network, a private or public network, a local area network (LAN), a wireless local area network (WLAN), a wide area network (WAN), a BLUETOOTH™ network, and the Internet. The network interface device(s) <NUM> can be configured to support any type of communications protocol desired. The memory system <NUM> can include one or more memory units <NUM>(<NUM>-N). While illustrated as being connected to the system bus <NUM>, in an exemplary aspect, the CPU(s) <NUM> are connected to the network interface device(s) <NUM> through a USB bus as described herein.

The CPU(s) <NUM> may also be configured to access the display controller(s) <NUM> over the system bus <NUM> to control information sent to one or more displays <NUM>. The display controller(s) <NUM> sends information to the display(s) <NUM> to be displayed via one or more video processors <NUM>, which process the information to be displayed into a format suitable for the display(s) <NUM>. The display(s) <NUM> can include any type of display, including, but not limited to, a cathode ray tube (CRT), a liquid crystal display (LCD), a plasma display, a light emitting diode (LED) display, etc..

<FIG> illustrates an example of a wireless communications device <NUM> which can include a USB subsystem operating according to exemplary aspects of the present disclosure. The wireless communications device <NUM> may include or be provided in any of the above-referenced devices, as examples. As shown in <FIG>, the wireless communications device <NUM> includes a transceiver <NUM> and a data processor <NUM>. The data processor <NUM> may include a memory (not shown) to store data and program codes. The transceiver <NUM> includes a transmitter <NUM> and a receiver <NUM> that support bi-directional communication. In general, the wireless communications device <NUM> may include any number of transmitters and/or receivers for any number of communication systems and frequency bands. All or a portion of the transceiver <NUM> may be implemented on one or more analog ICs, RF ICs (RFICs), mixed-signal ICs, etc..

A transmitter <NUM> or a receiver <NUM> may be implemented with a super-heterodyne architecture or a direct-conversion architecture. In the super-heterodyne architecture, a signal is frequency-converted between RF and baseband in multiple stages, e.g., from RF to an intermediate frequency (IF) in one stage, and then from IF to baseband in another stage. In the direct-conversion architecture, a signal is frequency converted between RF and baseband in one stage. The super-heterodyne and direct-conversion architectures may use different circuit blocks and/or have different requirements. In the wireless communications device <NUM> in <FIG>, the transmitter <NUM> and the receiver <NUM> are implemented with the direct-conversion architecture.

In the transmit path, the data processor <NUM> processes data to be transmitted and provides I and Q analog output signals to the transmitter <NUM>. In the exemplary wireless communications device <NUM>, the data processor <NUM> includes digital-to-analog-converters (DACs) <NUM>(<NUM>) and <NUM>(<NUM>) for converting digital signals generated by the data processor <NUM> into the I and Q analog output signals, e.g., I and Q output currents, for further processing.

Within the transmitter <NUM>, lowpass filters <NUM>(<NUM>), <NUM>(<NUM>) filter the I and Q analog output signals, respectively, to remove undesired images caused by the prior digital-to-analog conversion. Amplifiers (AMPs) <NUM>(<NUM>), <NUM>(<NUM>) amplify the signals from the lowpass filters <NUM>(<NUM>), <NUM>(<NUM>), respectively, and provide I and Q baseband signals. An upconverter <NUM> upconverts the I and Q baseband signals with I and Q transmit (TX) local oscillator (LO) signals from a TX LO signal generator <NUM> through mixers <NUM>(<NUM>), <NUM>(<NUM>) to provide an upconverted signal <NUM>. A filter <NUM> filters the upconverted signal <NUM> to remove undesired images caused by the frequency upconversion as well as noise in a receive frequency band. A power amplifier (PA) <NUM> amplifies the upconverted signal <NUM> from the filter <NUM> to obtain the desired output power level and provides a transmit RF signal. The transmit RF signal is routed through a duplexer or switch <NUM> and transmitted via an antenna <NUM>.

In the receive path, the antenna <NUM> receives signals transmitted by base stations and provides a received RF signal, which is routed through the duplexer or switch <NUM> and provided to a low noise amplifier (LNA) <NUM>. The duplexer or switch <NUM> is designed to operate with a specific RX-to-TX duplexer frequency separation, such that RX signals are isolated from TX signals. The received RF signal is amplified by the LNA <NUM> and filtered by a filter <NUM> to obtain a desired RF input signal. Downconversion mixers <NUM>(<NUM>), <NUM>(<NUM>) mix an output of the filter <NUM> with I and Q receive (RX) LO signals (i.e., LO_I and LO_Q) from an RX LO signal generator <NUM> to generate I and Q baseband signals. The I and Q baseband signals are amplified by AMPs <NUM>(<NUM>), <NUM>(<NUM>) and further filtered by lowpass filters <NUM>(<NUM>), <NUM>(<NUM>) to obtain I and Q analog input signals, which are provided to the data processor <NUM>. In this example, the data processor <NUM> includes analog-to-digital-converters (ADCs) <NUM>(<NUM>), <NUM>(<NUM>) for converting the analog input signals into digital signals to be further processed by the data processor <NUM>.

In the wireless communications device <NUM> in <FIG>, the TX LO signal generator <NUM> generates the I and Q TX LO signals used for frequency upconversion, while the RX LO signal generator <NUM> generates the I and Q RX LO signals used for frequency downconversion. Each LO signal is a periodic signal with a particular fundamental frequency. A transmit (TX) phase-locked loop (PLL) circuit <NUM> receives timing information from data processor <NUM> and generates a control signal used to adjust the frequency and/or phase of the TX LO signals from the TX LO signal generator <NUM>. Similarly, a receive (RX) phase-locked loop (PLL) circuit <NUM> receives timing information from the data processor <NUM> and generates a control signal used to adjust the frequency and/or phase of the RX LO signals from the RX LO signal generator <NUM>.

Those of skill in the art will further appreciate that the various illustrative logical blocks, modules, circuits, and algorithms described in connection with the aspects disclosed herein may be implemented as electronic hardware, instructions stored in memory or in another computer readable medium and executed by a processor or other processing device, or combinations of both. The devices described herein may be employed in any circuit, hardware component, integrated circuit (IC), or IC chip, as examples. Memory disclosed herein may be any type and size of memory and may be configured to store any type of information desired. To clearly illustrate this interchangeability, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. How such functionality is implemented depends upon the particular application, design choices, and/or design constraints imposed on the overall system.

Claim 1:
An integrated circuit, IC, (<NUM>, <NUM>) for tunneling I2C transactions between a master (<NUM>) and slaves (<NUM>), the IC comprising:
a first low-speed interface (<NUM>) configured to be coupled to a low-speed link (<NUM>), wherein the first low-speed interface comprises an I2C interface;
a translation circuit (<NUM>) associated with the first low-speed interface, the translation circuit comprising a slave address table lookup, SATL, circuit;
a second low-speed interface (<NUM>, <NUM>) configured to be coupled to a sideband link in a multichannel bus (<NUM>), the sideband link comprising sideband use, SBU, pins of Universal Serial Bus, USB, standard, wherein the second low-speed interface comprises a sideband interface in a USB interface; and
a control circuit (<NUM>) configured to:
receive a first signal from the first low-speed interface from the master (<NUM>);
use the translation circuit to generate a command having an address embedded therein, wherein the address is an address of a slave (<NUM>) translated using the SATL; and
send the command through the second low-speed interface across the multichannel bus to a remote IC, the remote IC comprising the slave (<NUM>).