DiiVA (Digital Interactive Interface For Video And Audio) is a bi-directional audio/video interface that allows uncompressed high-definition video, as well as multi-channel audio, high-bandwidth, and bi-directional data to be transferred over a single cable. In addition to uni-directional video channels, DiiVA implements a bi-directional hybrid data channel capable of transporting different types of data, including but not limited to audio data, control data, Ethernet data, and bulk data.
The USB (Universal Serial Bus) specification is widely used in order to establish communication between various devices and a host controller such as a personal computer, having now effectively taken the place of a number of previously implemented interfaces such as serial and parallel ports.
Methods and systems are needed for reliably transferring USB data over networks such as DiiVA.
The drawings disclose illustrative embodiments. They do not set forth all embodiments. Other embodiments may be used in addition or instead. When the same numeral appears in different drawings, it is intended to refer to the same or like components or steps.
In the present disclosure, methods and systems are disclosed for transfer of USB data and multi-media data over networks such as DiiVA which includes a bi-directional hybrid link as well as uni-directional links. DiiVA is a bi-directional audio/video interface that can allows uncompressed high-definition video, multi-channel audio, and high-bandwidth, bi-directional data to be all transferred over a single cable. In particular, DiiVA implements a bi-directional hybrid link capable of carrying audio, control, and bulk (Ethernet and USB) data, and status information. DiiVA also includes uni-directional video links dedicated to carrying noncompressed video pixel data and synchronization.
In some embodiments, DiiVA cable contain four twisted pairs, one of which is the hybrid link, and the remaining three of which comprise the uni-directional video links. DiiVA allows users to connect, configure and control a plurality of consumer electronic devices (including without limitation DVD players, digital video recorders, set top boxes, personal computers, camcorders, cameras, and home stereo systems, just by way of example) from their digital TV or other DiiVA node.
Full details regarding USB are available in references such as “USB 2.0 specification” and “USB 3.0 specification,” which are publicly available through the internet, and which are incorporated herein by reference in their entireties.
The techniques disclosed in the present disclosure may be used for the transfer of multi-media data and network management in any other system (i.e., system other than DiiVA) that includes the capability of both uni-directional and bi-directional data transfer over a single cable.
Illustrative embodiments are discussed. Other embodiments may be used in addition or instead.
In the embodiment illustrated in
The DiiVA network 210 includes at least one bi-directional DiiVA hybrid link 240, and transfers data through the link between the first DiiVA device 205 and the second DiiVA device 206, according to USB protocol.
The elements in the DiiVA network 210, including but not limited to the hybrid link 240, and the first and second DiiVA device 205 and 206, all include hardware such as a processor or controller configured to carry out the functions described in the present disclosure.
The network 210 is responsive to the USB host controller 220 to deliver contents for the USB protocol by transmitting through the hybrid link 240 at least one line state information packet and at least one USB data packet, between the upstream USB port 225 and the downstream USB port 226.
The first 205 and second 206 DiiVA device each include a USB PHY (physical layer) 232 connected to logical module 234 through an interface 236. The logical module 234 may be a transceiver having bi-directional connection and configured to carry and share multi-protocol data. In some embodiments, the interface 236 is UTMI (USB 2.0. Transceiver Microcell Interface) or ULPI (UTMI+Low Pin Interface). In other embodiments, interfaces other than UTMI or ULPI may be used.
In general, USB protocol relies on line state information, or the state of D+ and D−, and has limitations on turn-around time and the cable length. A DiiVA network, however, does not guarantee delivery time and thus take a long time.
USB protocol defines both minimum and maximum period of the turn-around time and the inter-packet delay. The minimum period can be controlled by buffering the USB data packet. But the maximum period cannot be easily met because DiiVA network has inherent network delay and also does not guarantee the inter-packet delay. This issue affects the bus turn-around timing in two ways. One is when USB host waits and the other is when USB device waits as shown in
In the present disclosure, DiiVA specific protocols for USB are described that overcome these limitations. Examples include without limitation The line state emulation, flow-control mechanism, and speculative ACK/NAK. By using these protocols, any USB host to any USB device point-to-point connection can be made through a DiiVA network. Multiple point-to-point connections also are possible under DCL management.
USB line state information is available only when the USB host and the USB device are physically connected. As shown in
In DiiVA, all of the line state information and generic USB packets are delivered in the form of hybrid link packet. In some embodiments of the present disclosure, line state information at the UTMI (or ULPI) interface 260 of USB host 220 and USB device 230 is delivered over the DiiVA network 210 by a hybrid link USB packet to the other side of the USB host 220 and the USB device 230. The line state information packet transmitted through the hybrid link 240 contains packetized line state information about one or more events.
Other than such source and destination information, the hybrid link USB packet contains a variety of USB related information. The SSINFO field of Hybrid Link USB Packet carries this information.
In the table shown in
Using the line state information packet described in conjunction with
In some embodiments, the upstream USB port 225 is the transmitting USB port and the downstream USB port 226 is the receiving USB port. In other embodiments, the upstream USB port 225 is the receiving USB port and the downstream USB port 226 is the transmitting USB port.
Enumeration in USB is a process of determining what device has just been connected to the bus, and what parameters (such as power consumption, number of endpoints etc.) it requires. The USB device enumeration process thus starts when a USB device is first connected to a USB host. The USB host assigns the device a unique address and sets up a configuration that allows the device to transfer data on the bus.
In this embodiment, a high-speed USB device is attached to a USB downstream port 515, as illustrated in step 510, namely USB device attach. A UD_FS_DEVICE_READY packet 518 is then sent to a USB upstream port 516. The USB host is attached, as shown in the step 520, namely USB host Plug In. VBus assertion in the USB upstream port 516 is detected. The USB upstream port 516 sends UU_VBUS_DETECT 524 to the USB downstream port 515 and the USB downstream port 515 deasserts VBus, as shown in the deassertion step, 525.
The USB upstream port 516 sends UU_VBUS_ENABLE 532 to the USB downstream port 515 and the USB downstream port 515 asserts Bus, step 522. The USB downstream port 515 detects J state, step 534, and sends UD_J_STATE 536 to the USB upstream port 516. The USB upstream port 516 detects USB Reset from the USB host, step 540, and sends UU_USB_RESET 542.
The USB downstream port 515 then detects K Chip in step 546, and sends UD_K_STATE 544. The USB downstream port 515 detects SE0 state and send UD_SEO_STATE 548.
In step 550, toggling K-J Chirps are detected and UU_K_STATE 552 and UU_J_STATE 554 are sent to the USB downstream port 515. Finally SOF is detected from the USB host in step 560, and high-speed enumeration is complete.
In other embodiments of the present disclosure, USB Full Speed enumeration and/or USB Low Speed enumeration may be performed. In these embodiments, performing Full Speed enumeration may comprise the acts of:
attaching a full-speed USB device to the downstream USB port, and sending an FS Device Ready event packet to the upstream USB port;
attaching the USB host controller, and when Bus is asserted, the upstream USB port sending Bus detect event packet to downstream USB port and disserting Bus in the downstream USB port;
the upstream USB port sending Bus Enable event packet to downstream USB port, and the downstream USB port asserting Bus;
the downstream USB port detecting J State, and sending J State event packet;
the upstream USB port detecting USB Reset from the USB host controller and sending USB Reset event packet; and
detecting J State in upstream USB port and sending J State Event packet to the downstream USB port; and detecting SOF packet from the USB host so that full-speed enumeration is done.
In other embodiments, Low Speed enumeration may be performed. In these embodiments, performing Low Speed enumeration may comprise the acts of:
attaching a low-speed USB device to the downstream USB port and sending a LS Device Ready event packet to the upstream USB port;
attaching the USB host controller, and when VBus is asserted, the upstream USB port sending VBus detect event packet to the downstream USB port and deasserting VBus in the downstream USB port;
the upstream USB port sends VBus Enable event packet to the downstream USB port, and the downstream USB port asserting Vbus;
the downstream USB port detecting K State, and sending K State event packet; the upstream USB port detecting USB Reset from the USB host controller and sending USB Reset event packet;
the upstream USB port detecting K state, and sending the K State Event packet to the downstream USB port; and
detecting SOF packet from the USB host so that low-speed enumeration is done.
In some embodiments, a USB Suspend and Resume operation may be performed. In these embodiments, the following acts may be performed:
detecting a 3 ms Idle State, and generating a 3 ms Idle event packet and delivering same to downstream port;
if previous speed was high-speed USB, upstream port checking whether 3 ms idle is suspend state or USB Reset according to USB specification and UTMI specification; and
if upstream USB port detects K State, upstream USB port generating K State event packet and going to Resume state.
During an IN transaction, USB host expects Data packet or handshake after IN is issued within maximum bus turn-around time. The OUT transaction requires the same constraint on the handshake after OUT/SETUP and Data is transmitted. To resolve this issue in USB host side, the USB Upstream-facing port in DiiVA device uses NAK with a flow control mechanism illustrated in
In the Setup Stage 610, an USB upstream port 625 receives SETUP and delivers the SETUP USB packet to a USB downstream port 626. The downstream USB port 626 buffers this SETUP until next DATA is available on the downstream USB port. Meanwhile, the upstream USB port 625 sends a speculative ACK even if ACK from USB device is not available. When the DATA arrives at the downstream USB port 626, the downstream USB port 626 starts to send SETUP and DATA and receives ACK.
In the Data/Status Stage 610, the IN transaction and OUT transaction occur as follows: the upstream USB port 625 receives IN and delivers to the downstream USB port 626. The downstream USB port 626 sends IN and get the response from the USB device. Meanwhile, the upstream USB port 625 first sends NAK for IN or OUT/DATA until DATA or handshake are available from the USB device.
At the USB device side, if the USB device sends NAK for IN or OUT/DATA and NAK arrives at the USB upstream port 625, the USB upstream port 625 unblocks the next coming IN or OUT/DATA and delivers to the USB downstream port 626 to send IN or OUT/DATA to the USB device again with NAK handshake to the USB host. If the USB device sends DATA for IN or ACK for OUT/DATA and DATA or ACK arrives at the USB upstream port 625, the USB downstream port 626 responds with ACK for IN transaction and delivers this DATA for IN or ACK for OUT to the USB upstream port 625. The USB upstream port 625 sends DATA for next IN available or ACK for next OUT/DATA available.
The USB upstream port 625 always responds with ACK for SETUP transaction because it is required to receive SETUP and DATA and responds with ACK according to USB Specification.
The USB downstream port 626 buffers OUT or SETUP until next coming DATA is available in the USB downstream port 626 to guarantee the inter-packet delay between OUT/SETUP and DATA.
USB supports a number of different types of data transfers: isochronous, interrupt, bulk, and control transfers. Isochronous transfers occur at some guaranteed data rate but with possible data loss, for example for real time audio or video. Interrupt transfers are used for devices that need guaranteed quick responses (bounded latency), such as pointing devices and keyboards. Bulk transfers are large sporadic transfers that use all remaining available bandwidth, but have no guarantees on bandwidth or latency, such as file transfers. Control transfers are typically used for short, simple commands to the device, and a status response, used, for example, by the bus control pipe number 0.
Instead of using flow control mechanism by sending NAK for IN or OUT/DATA, isochronous transfers use zero data and pipelines IN transaction scheme. For the first multiple isochronous INs, the USB upstream port responds with zero data, which is legitimate in the USB specification. This first IN is delivered to a USB downstream port and gets the DATA from an isochronous USB device. This first DATA is used to reply to the next isochronous IN when it arrives at USB upstream module. In this way, the USB host receives the delayed and pipelined isochronous DATA from the USB device.
If the USB host stops to send isochronous IN, the last remaining DATA packets are dropped.
An isochronous OUT transaction is delivered to the USB downstream port without NAK. The inter-packet delay between OUT and DATA should be maintained by buffering OUT until DATA is available in the USB downstream port.
To respond properly to the isochronous IN without NAK response, the USB upstream port should know which USB address and USB endpoint are used for isochronous transfer. To obtain this information, DiiVA USB should have the capability to decode the descriptor from the USB device.
Decoding descriptor can be done by analyzing the hybrid link USB packet, or the USB downstream port may have USB Host capability to enumerate and read out the descriptor from the USB device before connecting a USB upstream port to a USB downstream port. The descriptor decoding method is implementation-dependent and other implementations are possible.
According to the USB specification, high bandwidth isochronous IN endpoints must support data PID sequencing depending on the DATA size. Because DATA size from isochronous USB devices vary, the number of INs per micro frame is different in every frame. Therefore, the mechanism of simply delivering isochronous IN from the USB upstream port to the USB downstream port cannot meet USB specification.
DiiVA USB supports high bandwidth isochronous IN endpoints by the following method: only the first isochronous IN per micro frame is delivered. When the USB downstream port receives the DATA for isochronous IN, it itself should decide how many INs need to be sent based on the DATA PID. If first Data PID is DATA0, the USB downstream port behaves like above pipelined isochronous transfer scheme. If the first Data PID is DATA2, the USB downstream port generates two more same INs in the same micro frame. If the first Data PID is DATA1, the USB downstream port generates one more same IN. The USB upstream port should have enough buffer to accommodate the maximum DATA size per frame in high bandwidth isochronous endpoint.
In some embodiments, a method of delivering USB data through a hybrid link with an isochronous IN token may comprise the following acts:
the DATA packet using zero data and pipelining IN Data, wherein the number of states for IN DATA depends on latency of connection;
for first, or first multiple, isochronous IN packets, an upstream port responding with one or more zero data packets;
delivering said first, or first multiple, IN packets to a downstream port and receiving the DATA0 or DATA1 or DATA2 packet from an isochronous USB device;
pipelining these DATA packets to reply with isochronous IN packets;
if the USB host stops sending isochronous IN packets, dropping the last and remaining DATA; and
the upstream USB port finding out which endpoint and address are used for isochronous endpoint, by monitoring and decoding USB descriptor from DATA packet stream.
In some embodiments, a method of delivering USB data through a hybrid link with an isochronous OUT token may comprise:
sending an isochronous OUT transaction out to the downstream port, wherein the upstream port does not send according to USB protocol;
the downstream USB port buffering OUT packet until DATA0 or DATA1 or DATA2 or MDATA packet is available;
when DATA0 or DATA1 or DATA2 or MDATA packet is available, sending OUT packet and DATA0 or DATA1 or DATA2 or MDATA packet to USB device; and
the upstream USB port finding out which endpoint and address are used for isochronous endpoint by monitoring and decoding USB descriptor from DATA packet stream.
In the present disclosure, non-isochronous transfers of USB data may also be performed using DiiVA specific protocols. In some embodiments, USB data may be delivered with a non-isochronous IN token, by performing the following acts:
an upstream USB port receiving an IN packet and delivering same to downstream USB port;
a downstream USB port sending the IN packet and receiving a Data packet or a handshake packet from a USB device;
an upstream USB port sending NAK packet and blocking the next incoming IN packet with a NAK packet until the response from USB device is available;
if a USB device sends NAK packet for IN packet and NAK packet arrives at upstream USB port from downstream USB port, upstream USB port unblocking the next incoming IN packet and delivering to downstream port to send IN packet to USB device again;
if USB device sends a DATA0 or aDATA1 packet and the DATA0 or the DATA1 packet arrives in upstream USB port, the downstream port responding with an ACK packet and delivers the DATA0 or the DATA1 packet to the upstream port; and
the upstream port sending the DATA0 or DATA1 packet for the next available IN packet.
In some embodiments, USB data may be delivered with a non-isochronous OUT token, by performing the following acts:
an upstream USB port receiving an OUT packet and either a DATA0 or a DATA1 packet and delivering to a downstream USB port;
the downstream USB port buffering the OUT packet until the DATA0 or the DATA1 packet is available, and when the DATA0 or the DATA1 packet is available, sending the OUT packet and the DATA0 or the DATA1 packet to a USB device;
the upstream USB port sending a NAK packet for the OUT transaction and not delivering the next incoming OUT packet and DATA0 or DATA1 packet until the response from downstream USB port is available;
if the USB device sends a NAK packet for the OUT transaction and downstream USB port sends a NAK packet to the upstream USB port, the upstream USB port delivering the next incoming OUT packet and the DATA0 or DATA1 packet to the downstream port again; and
if the USB device sends an ACK packet, the upstream port sending ACK for the next OUT transaction.
In the present disclosure, transfer of USB data may be performed using PING packets.
In some embodiments, PING protocol is implemented when the USB host gets NAK for OUT transaction. In these embodiments, the USB upstream port responds with NAK and does not deliver the PING packet to the USB downstream port. The USB upstream port blocks PING and keeps sending NAK until the response for OUT transaction from the USB device is available.
If the USB device responds with ACK for OUT transaction, the USB upstream port responds with ACK for the next PING and also responds with ACK for next OUT transaction. This last OUT transaction is not delivered to the USB downstream port because the USB device already accepted the first OUT transaction.
If the USB device responds with NAK for the OUT transaction, the USB upstream port delivers the next PING to the USB downstream port.
If the USB device responds with ACK for PING and PING arrives at the USB upstream module, the USB upstream module responds with ACK for next PING and responds with ACK for next OUT transaction. This last OUT transaction is delivered to the USB device and is expected to be responded with ACK.
If the USB device responds with NAK for PING and PING arrives at the USB upstream port, the USB upstream port responds with NAK for next PING and PING is delivered to the USB device again. This step is repeated until the USB device responds with ACK for PING. And the scenario follows the above step when the USB device responds with ACK.
In sum, a method of delivering data through a hybrid link using a USB PING packet may comprise:
an upstream USB port responds with NAK packet to OUT transaction;
an upstream USB port responding with NAK packet, and delivering PING packet to a downstream USB port;
the upstream USB port not delivering PING packet, and continuing to send NAK packet until the response from USB device is available;
if a USB device responds with ACK packet for OUT transaction, the upstream USB port responding with ACK packet for the next incoming PING packet and responding with ACK packet for the next OUT transaction; wherein the last OUT transaction is not delivered to the downstream USB port;
if the USB device responds with NAK packet for OUT transaction and NAK packet is delivered to upstream USB port, the upstream USB port delivering next PING packet to the downstream USB port;
if the USB device responds with NAK packet with PING packet and NAK packet is delivered to the upstream USB port, the upstream USB port delivering the next PING packet to the downstream USB port;
if the USB device responds with ACK packet with PING packet and ACK packet is delivered to upstream USB port, the upstream USB port responding with ACK packet for next PING packet;
the next OUT transaction responding with ACK packet; and
delivering these OUT packets and DATA0 or DATA1 packets to downstream USB port to send to USB device.
In other embodiments, PING is used without a preceding OUT transaction. In these embodiments, the USB upstream port responds with NAK and delivers PING to the USB downstream port. The USB upstream port does not deliver PING and keeps sending NAK until the response from the USB device is available.
If the USB device responds with ACK for PING, the USB upstream port responds with ACK for next PING and also responds with ACK for next OUT transaction. In this case, this last OUT transaction is delivered to the USB downstream port unlike the first scenario because no OUT transaction is delivered to the USB device yet.
If the USB device responds with NAK for PING and PING arrives at the USB upstream port, the USB upstream port responds with NAK for next PING and delivers PING to the USB downstream port. This step is repeated until the USB downstream port gets ACK from the USB device. The acts when USB device responds with ACK, as described above, are then followed.
When the USB device responds with NYET for OUT Transaction, the DiiVA USB module considers NYET as ACK and the USB upstream port always sends ACK instead of NYET.
In sum, a method of delivering data through a hybrid link using a USB PING packet may comprise:
an upstream USB port responding with NAK packet and delivering PING packet to a downstream USB port;
the upstream USB port not delivering PING packet and continuing to send NAK packet until response from USB device is available;
if USB device responds with ACK packet for PING packet and ACK packet is delivered to upstream USB port, the upstream USB port responding with ACK packet for the next PING packet and responding with ACK for the next OUT transaction; and
delivering the OUT packet and DATA0 or DATA1 packets to downstream port;
wherein there is no preceding OUT transaction before the upstream USB port receives PING packet.
In some embodiments, USB address management in a DiiVA network may be performed as follows. A USB upstream port can be attached to any hub downstream port, and packets with various USB addresses can be broadcasted to the USB upstream port. The USB upstream port should be able to recognize which USB address is assigned to the USB upstream port and it should not respond to generic USB packets for any other USB Device.
After USB Reset is detected in the USB upstream port, the USB upstream port accepts only generic USB packet with USB Address 0. By monitoring and decoding SET_ADDRESS standard USB device request, the USB upstream port recognizes which USB address is assigned to the USB device in the USB downstream port.
After detecting SET_ADDRESS standard USB Device request, the USB upstream port only responds with generic USB packets with the newly assigned USB address. If USB Reset is detected in the USB upstream port, it resets the assigned USB address to 0 and waits for SET_ADDRESS standard USB device request again. Decoding SET_ADDRESS Device request is implementation specific.
In sum, a method of USB address management in a DiiVA network may comprise:
after USB Reset is detected in the upstream USB port, the upstream USB port accepting only packets that have USB Address 0.
the upstream port recognizing which USB address is assigned to the USB device in the downstream port by monitoring and decoding SET_ADDRESS standard USB device request;
after detecting SET_ADDRESS standard USB device request, the upstream port only responding with packets with new USB address which is assigned with SET_ADDRESS standard USB device request; and
USB Reset resetting the assigned USB address to 0 and waiting for SET_ADDRESS standard USB device request again.
In some embodiments, Keep-Alive forwarding in a DiiVA network may be performed as follows. When the enumeration state goes to LS_ENUM_DONE, the USB upstream port starts to monitor line state. When first toggling of line state is detected, it is considered as first Keep-Alive signaling. The USB upstream port sets the internal timer for T_KEEP_ALIVE and when it is expired, it starts to monitor line state toggling again to detect Keep-Alive. In some embodiments, T_KEEP_ALIVE is set to 0.98 ms. Keep-Alive signaling is delivered to USB Downstream Module through UU_KEEP_ALIVE.
In sum, a method of performing USB low speed Keep-Alive signaling in a DiiVA network may comprise:
after low-speed USB enumeration is done, the upstream USB port starting to monitor line state;
when first change of line state is detected, considered that to be the first Keep-Alive signaling;
the upstream USB port setting the internal timer for T_KEEP_ALIVE and when it is expired, the upstream USB port monitoring whether line state is toggling again, to detect Keep-Alive and deliver Keep Alive event packet to downstream USB port.
In the present disclosure, methods and systems have been described relating to the transfer of USB and multi-media data over DiiVA, and network management in DiiVA. The components, steps, features, objects, benefits and advantages that have been discussed are merely illustrative. None of them, nor the discussions relating to them, are intended to limit the scope of protection in any way. While certain embodiments have been described of systems and methods relating to USB data transfer over DiiVA, it is to be understood that the concepts implicit in these embodiments may be used in other embodiments as well. Numerous other embodiments are also contemplated, including embodiments that have fewer, additional, and/or different components, steps, features, objects, benefits and advantages. The components and steps may also be arranged and ordered differently. Nothing that has been stated or illustrated is intended to cause a dedication of any component, step, feature, object, benefit, advantage, or equivalent to the public.
In the present disclosure, reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” All structural and functional equivalents to the elements of the various embodiments described throughout this disclosure, known or later come to be known to those of ordinary skill in the art, are expressly incorporated herein by reference.
The present application is based upon, and claims the benefit of priority under 35 U.S.C. §119, to co-pending U.S. Provisional Patent Application No. 61/294,476 (the “'476 provisional application”), filed Jan. 12, 2010 and entitled “Multi-Media Data Transfer And Network Management Over A Cable Having Both Bi-Directional And Uni-Directional Links.” The content of the '476 provisional application is incorporated herein by reference in its entirety as though fully set forth. The present application is related to U.S. patent application Ser. No. 12/057,051, entitled “Bi-Directional Digital Interface For Video And Audio (DIVA),” filed Mar. 27, 2008, and U.S. patent application Ser. No. 12/636,063, entitled “Power Delivery Over Digital INTERFACE FOR VIDEO AND AUDIO (DiiVA),” filed Dec. 11, 2009. Both applications are incorporated herein by reference in their entireties.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/US11/21031 | 1/12/2011 | WO | 00 | 2/20/2013 |
Number | Date | Country | |
---|---|---|---|
61294476 | Jan 2010 | US |