Arbitration signaling within a multimedia high definition link (MHL 3) device

An apparatus for interfacing with a multimedia communication link comprises a half-duplex translation layer circuit operating in half-duplex and a full-duplex link layer circuit to communicate over a control bus of the multimedia communication link in full duplex. The apparatus further comprises an arbitration circuit communicatively coupled between the half-duplex translation layer circuit and the full-duplex link layer circuit, the arbitration circuit to control data flow between the half-duplex translation layer circuit and the full-duplex link layer circuit. The arbitration circuit provides interface and signaling rules for transmitting packets from the half-duplex translation layer circuit to the full-duplex link layer circuit, receiving packets via the full-duplex link layer circuit at the half-duplex translation layer circuit, and resolving conflict arising due to bidirectional data flow at the arbitration logic.

TECHNICAL FIELD

The disclosed embodiments relate generally to Multimedia High Definition Link (MHL) standards, and more specifically to methods and devices that provide backward compatibility between MHL 3 devices and legacy MHL software.

BACKGROUND

Under the legacy MHL 1/2 protocol, a local MHL device communicates with a peer MHL device using a legacy MHL (MHL 1/MHL 2) link. The legacy link, in turn, has a half-duplex legacy control bus that enables exchange of control packets between the local and peer MHL devices. Thus, in the legacy MHL 1/2 configuration, the local MHL device, the peer legacy device, as well as the legacy MHL control bus are all configured to operate in half-duplex.

Under the MHL 3 protocol, a local MHL 3 device communicates with a peer MHL 3 device using an MHL 3 link. The MHL 3 link, in turn, has a full-duplex control bus that supports concurrent bi-directional exchange of control packets between the local and peer MHL devices. Thus, a link layer of an MHL 3 device that communicates with the full-duplex MHL 3 control bus operates in full-duplex. However, a full-duplex link layer is not typically compatible with legacy components of a MHL device, such as translation layer circuitry and software, that were originally designed to communicate over a half-duplex link layer. This incompatibility can cause an expensive redesign of these components to ensure compatibility with a half-duplex link layer.

SUMMARY

Accordingly, some embodiments provide a device for interfacing with a multimedia communication link having a multimedia bus and a control bus. The device includes a full-duplex link layer circuit to communicate, in full duplex, over the full-duplex control bus of the multimedia communication link. The device further comprises a half-duplex translation layer circuit to transmit and receive data through an interface in half-duplex and communicatively coupled to the full-duplex link layer. The device further comprises an arbitration circuit (alternatively referred to herein as a converter or arbitration logic) communicatively coupled between the interface of the half-duplex translation layer circuit and the full-duplex link layer circuit. The arbitration circuit is configured to control data flow between the half-duplex translation layer circuit and the full-duplex link layer circuit. In some embodiments, the arbitration circuit is configured to provide interface and signaling rules for transmitting packets from the half-duplex translation layer to the full-duplex link layer, for receiving packets via the full-duplex link layer at the half-duplex translation layer, and for resolving conflict arising due to bidirectional data flow at the arbitration logic.

In some embodiments, the arbitration circuit receives a transmission request from the half-duplex translation layer circuit and a receive request from the full-duplex link layer circuit. Responsive to the transmission request and the receive request, the arbitration circuit grants the receive request and holds the transmission request until a receive transaction associated with the receive request is completed.

In some embodiments, the arbitration circuit receives a data receive request while in a data transmission state. Responsive to receiving the data receive request while in the data transmission state, the arbitration circuit aborts the data transmission state and grants the data receive request.

In some embodiments, while the arbitration circuit is in a data transmission state, if the arbitration circuit fails to receive a transmission grant from the full-duplex link layer circuit within a pre-determined period of time, the arbitration circuit generates an interrupt signal causing a reset of protocol states of the full-duplex link layer and/or of the half-duplex translation layer circuit.

In some embodiments, while the arbitration circuit is in a data receiving state, if the arbitration circuit fails to receive a transmission grant from the full-duplex link layer circuit within a pre-determined period of time, the arbitration circuit generates an interrupt signal causing a reset of protocol states of the full-duplex link layer and/or of the half-duplex translation layer circuit.

In some embodiments, while the arbitration circuit is in a data transmission state, if the arbitration circuit fails to receive a handshake signal from a peer device via the full-duplex link layer circuit within a pre-determined period of time, the arbitration circuit generates an interrupt signal possibly requesting further diagnosis at a higher or upper system level.

In some embodiments, the arbitration circuit comprises a state machine that controls flow of data between the half-duplex translation layer circuit and the full-duplex link layer circuit.

In some embodiments, the device further comprises a half-duplex link layer circuit to receive and transmit data over the control bus in half duplex and a multiplexing circuit configured to selectively connect the half-duplex link layer or the arbitration logic to the interface of the half-duplex translation layer circuit based on capabilities of a peer device connected to the control bus.

DESCRIPTION OF EMBODIMENTS

FIG. 1is a high-level block diagram of a system100for data communications, according to one embodiment. The system100includes a source device110communicating with a sink device115through one or more interface cables120,150,180. Source device110transmits multimedia data streams (e.g., audio/video streams) to the sink device115and also exchanges control data with the sink device115through the interface cables120,150,180. In one embodiment, source device110and/or sink device115may be repeater devices.

Source device110includes physical communication ports112,142,172coupled to the interface cables120,150,180. Sink device115also includes physical communication ports117,147,177coupled to the interface cables120,150,180. Signals exchanged between the source device110and the sink device115across the interface cables pass through the physical communication ports.

Source device110and sink device115exchange data using various protocols. In one embodiment, interface cable120represents a High Definition Multimedia Interface (HDMI) cable. The HDMI cable120supports differential signals transmitted via data0+ line121, data0− line122, data1+ line123, data1− line124, data2+ line125, and data2− line126. The HDMI cable120may further include differential clock lines clock+127and clock−128; Consumer Electronics Control (CEC) control bus129; Display Data Channel (DDC) bus130; power131, ground132; hot plug detect133; and four shield lines844for the differential signals. In some embodiments, the sink device115may utilize the CEC control bus129for the transmission of closed loop feedback control data to source device110.

In one embodiment, interface cable150represents a Mobile High-Definition Link (MHL) cable. The MHL cable150supports differential signals transmitted, for example, via data0+ line151, data0− line152. Data lines151and152form a multimedia bus for transmission of multimedia data streams from the source device110to the sink device115. In some embodiments of MHL, there may only be a single pair of differential data lines (e.g.,151and152). Alternatively, a plurality of differential data lines is provided to enable transmission (e.g., concurrently) of multiple differential signals on the multiple differential data lines. Embedded common mode clocks are transmitted through the differential data lines.

The MHL cable150may further include a control bus (CBUS)159, power160and ground161. The CBUS159is a bi-directional bus that carries control information such as discovery data, display identification, configuration data, and remote control commands. CBUS159for legacy MHL (MHL 1/2) operates in half duplex mode. On the other hand, CBUS159for MHL (MHL 3), alternatively referred to as an enhanced CBUS (eCBUS), operates in full duplex. In some embodiments, the eCBUS is single ended and provides single-ended signaling capability over a single signal wire. Alternatively, the eCBUS is differential ended (between differential lines eCBUS+ and eCBUS−) and provides differential-ended signaling capability over a differential pair of signal wires. An MHL 3 device (referred to herein as a local device) has the capability to interface with another MHL 3 device (referred to herein as a peer device) over a full duplex enhanced CBUS. For example, the source device110may be the local device if it is transmitting control information to the sink device115. Alternatively, the sink device115may be the local device if it is transmitting control information to the source device110.

Additionally, in the event that a local MHL 3 device needs to communicate with a legacy MHL device over a legacy MHL link or to operate with legacy MHL software, the local MHL 3 device has the capability to downgrade to a legacy operational mode from the MHL 3 mode. For example, a local MHL 3 device has the capability to interface with a peer MHL 1/2 device over a half-duplex CBUS.

Embodiments of the present disclosure relate to a system and MHL 3 device architecture for preserving backward compatibility with legacy MHL while allowing reuse of existing circuits and software that were used for legacy MHL. The MHL 3 device is configured to interface with a peer MHL 3 device over an MHL 3 link that includes a full-duplex enhanced control bus (eCBUS), as well as interface with a legacy MHL device over a legacy MHL 1/2 link that includes a half-duplex control bus (CBUS) and with legacy MHL software.

FIG. 2is a detailed view of a computing device200suitable for use as the source device110or sink device115fromFIG. 1, according to one embodiment. The computing device200can be, for example, a cell phone, a television, a laptop, a tablet, etc. The computing device200includes components such as a processor202, a memory203, a storage module204, an input module (e.g., keyboard, mouse, and the like)206, a display module207(e.g. liquid crystal display, organic light emitting display, and the like) and a transmitter or receiver205, exchanging data and control signals with one another through a bus201.

The storage module204is implemented as one or more non-transitory computer readable storage media (e.g., hard disk drive, solid state memory, etc), and stores software instructions that are executed by the processor202in conjunction with the memory203. Operating system software and other application software may also be stored in the storage module204to run on the processor202.

The transmitter or receiver205is coupled to the ports for reception or transmission of multimedia data and control data. Multimedia data that is received or transmitted may include video data streams or audio-video data streams, such as HDMI and MHL data. The multimedia data may be encrypted for transmission using an encryption scheme such as HDCP (High-Bandwidth Digital-Content Protection).

In one embodiment, a representation of circuits within the receiver source device110or sink device115may be stored as data in a non-transitory computer-readable medium (e.g. hard disk drive, flash drive, optical drive). These representations may in the form of, for example, behavioral level descriptions, register transfer level descriptions, logic component level descriptions, transistor level descriptions or layout geometry-level descriptions.

FIG. 3illustrates a block diagram of a local legacy MHL device300configured to interface with a peer legacy MHL device via a legacy MHL (MHL 1/MHL 2) link.

In some embodiments, the local legacy MHL device300is a source device (e.g., source110ofFIG. 1). In alternative embodiments, the local legacy MHL device300is a sink device (e.g., sink115ofFIG. 1). The local legacy MHL device300includes a translation layer310and a legacy link layer320.

The local legacy MHL device300communicates with a peer legacy MHL device via a legacy MHL (MHL 1/MHL 2) link. The legacy link, in turn, comprises a half-duplex legacy control bus (CBUS340) for exchange of control packets between the local and peer devices. In other words, in the configuration described with reference toFIG. 3, the interface cable150explained with reference toFIG. 1supports legacy MHL 1/2 communication protocol and the CBUS159is a half-duplex legacy control bus. Thus, in the legacy MHL configuration, the local legacy device300, the peer legacy device, as well as the legacy control bus are all configured to operate in half-duplex.

The translation layer310communicates in half duplex over CBUS340and is configured to generate and receive control information. By virtue of being half duplex, the translation layer310is configured to perform either one of packet data transmission or packet data receipt at any given time through its internal interface to the link layer320, but not both concurrently. In other words, the translation layer310can support packet data transmission from the local device300to a peer device by obtaining a packet from software at the local device300, processing the packet, and providing the packet to the legacy link layer320for further transmission to the peer device. Alternatively, the translation layer310can support packet receipt at the local device300from a peer device by performing the reverse operations—obtaining a received packet from the legacy link layer320, processing the packet, and providing the packet to software at the local device300. However, the translation layer310cannot support both packet data transmission and packet data receipt concurrently since it operates in half-duplex.

Similarly, the legacy link layer320is also half-duplex. Functions of the link layer include providing link layer protocol commands, link layer flow control, bit timings, and packet timings at the local device300for transfer of packet data across the control bus340. By virtue of being half-duplex, the legacy link layer320is configured to perform either one of packet transmission or packet receipt at any given time, but not both concurrently. Thus, since the translation layer310and the link layer320are both half-duplex, the interface or communication between them is seamless—when the link layer is in receive mode, so is the translation layer; when the translation layer is in transmit mode, so is the link layer. Furthermore, the control bus340is also half-duplex, enabling seamless communication between the local device and the half duplex control bus. Upon detecting an incoming packet on the control bus340, the half-duplex link layer320and translation layer310are in receive mode. In the absence of an incoming packet on the control bus340, the half-duplex link layer320and translation layers310may operate in transmit mode to transmit a packet to the peer device over the control bus340.

FIG. 4illustrates a block diagram of a local MHL 3 device400, according to some embodiments.

The local MHL 3 device400is configured to communicate with a peer MHL 3 device over an MHL 3 link. In order to preserve backwards compatibility with legacy MHL 1/2 devices, the local MHL 3 device is also configured to communicate with a peer MHL 1/2 device over a legacy MHL (MHL 1/2) link.

As explained with reference toFIG. 3, the legacy MHL (MHL 1/MHL 2) link includes a half-duplex legacy control bus (CBUS). In contrast, the MHL 3 link includes a full-duplex enhanced control bus (eCBUS). Thus, the local MHL 3 device has the capability to interface with both a half-duplex legacy control bus (CBUS) as well a full-duplex enhanced control bus (eCBUS). In other words, CBUS440ofFIG. 4may correspond to a half-duplex legacy control bus (CBUS) such as CBUS340explained with reference toFIG. 3. Alternatively, CBUS440may correspond to a full-duplex enhanced control bus (eCBUS).

As shown inFIG. 4, local MHL 3 device400comprises a half-duplex translation layer410, a half-duplex link layer420, a full-duplex link layer430, a multiplexer (MUX)450, a converter (arbitration logic)460, software465and a microprocessor470. The full duplex link layer430includes a time division multiplexer (TDM)480and serializer-deserializer (SerDes)490.

In order to preserve backwards compatibility with legacy MHL software that interfaces with the half-duplex translation layer of the legacy MHL device (such as the legacy translation layer310ofFIG. 3), the translation layer410of the local MHL 3 device is also half-duplex. Therefore, as explained with reference toFIG. 3, the half-duplex translation layer is configured to perform either of packet transmission or packet receipt at any given time, but not both concurrently.

To interface with both a half-duplex legacy control bus (CBUS) and a full-duplex enhanced control bus (eCBUS), the local MHL 3 device includes both a half-duplex link layer420as well as a full-duplex link layer430. MUX450connects the half duplex translation layer410either to the half duplex link layer420or to the full duplex link layer430. The half-duplex link layer420is selected when interfacing with a half-duplex legacy control bus (CBUS) and the full duplex link layer430is selected to interface with the full-duplex enhanced control bus (eCBUS). Stated differently, the multiplexing circuit (MUX450) is configured to selectively connect the half-duplex link layer420, or the full-duplex link layer430via the arbitration logic460to the interface of the half-duplex translation layer410. In some embodiments, this selection is based on capabilities of a peer device connected to the control bus440. If the peer device uses a legacy MHL (MHL 1/2) protocol, the MUX450selectively connects the half-duplex link layer420to the interface of the half-duplex translation layer410. On the other hand, if the peer device uses an MHL 3 protocol, the MUX450selectively connects the full-duplex link layer430(via the arbitration logic460) to the interface of the half-duplex translation layer410.

When interfacing with the half-duplex legacy control bus (CBUS), the half-duplex link layer420operates in conjunction with the half-duplex translation layer in a manner analogous to that described with reference toFIG. 3.

However, when interfacing with the full-duplex enhanced control bus (eCBUS), the communication (signaling) between the full-duplex link layer430and the half-duplex translation layer410is mediated or arbitrated by converter (arbitration logic)460. Since the enhanced control bus (eCBUS) and the full-duplex link layer430both have full-duplex capability, they can both support concurrent bi-directional data flow (transmission and reception). However, the translation layer410merely has half-duplex capability and can therefore support only either transmission or reception, but not both, at any given time. Thus, if the half-duplex translation layer410were directly connected to the full-duplex link layer430, a conflict could result at the interface of the two. To resolve such conflict, to arbitrate flow, schedule sequencing, and enforce signaling rules for packet exchange between the two layers, the converter (arbitration logic)460is provided at the interface of the half-duplex translation layer410and the full-duplex link layer430.

The half-duplex translation layer circuit410controls flow of control information between a local device400and a peer device. Specifically, the half-duplex translation layer circuit410generates flow control packets and control data packets that are transmitted to the link layers420and430. The half-duplex translation layer410also receives flow control packets and control data packets from the link layers420and430. The half-duplex translation layer circuit410only operates in half-duplex, meaning that it can either transmit or receive data through its internal communication interface to the MUX450, but cannot do both at the same time.

The half-duplex translation layer circuit410can select one among several different logical data channels, such that only one logical data channel has access to the control bus440at a time. Examples of logical data channels in MHL include DDC (Display Data Channel) and MSC (MHL Sideband Channel). Each logical data channel follows a different flow control protocol for transfer of a different type of control information. Each logical data channel may use different flow control packets. For example, DDC may use seven different flow control packets. MSC may use eighteen different flow control packets.

The link layers420and430implement link layer protocols for sending and receiving data between the local and peer devices across the CBUS440. The link layer protocols specify schemes for framing translation layer data (e.g. encoding, protocol, arbitration, flow control, bit timings, packet timings) into link layer packets. For example, the link layer430may generate link layer packets that include 2 sync bits, 2 header bits, 1 control bit, 8 data or command bits for translation layer data, and 1 parity bit. The link layer430also decodes incoming packets from the CBUS430.

Additionally, the link layer430controls timing and synchronization of packets transmitted across CBUS440using a TDM (Time Division Multiplexer)480and SerDes (serializer-deserializer)490. TDM480divides the use of CBUS440into time slots, some of which are for transmitting CBUS related data and some of which are for receiving CBUS related data. SerDes490converts parallel data bits from the TDM480into serial data bits for transmission over the control bus440, and vice versa.

Arbitration logic460communicatively couples the half-duplex translation layer410to the full-duplex link layer430. The arbitration logic460mediates data exchange between the half-duplex translation layer410and the full-duplex link layer430.

Various signals exchanged at the arbitration logic460are illustrated inFIG. 4. To initiate packet transmission to a peer device, the translation layer410sends a transmit request (Xmit_req) together with the packet (Xmit_pkt) to the arbitration logic460. Arbitration logic460, in turn, propagates the transmit request (Xmit_req) together with the packet (Xmit_pkt) to the link layer430. When the link layer430is ready to handle transmission of data, it grants access (Grant) to the arbitration logic460and immediately propagates the packet (Xmit_pkt) to the link layer430. The peer device may receive the transmitted packet in good (e.g., error-free) or bad (e.g., error-ridden) condition, depending on which, the local device400may receive (from the peer device) an acknowledgement (ACK) or a negative acknowledgement (NAK). Responsive to receiving the peer ACK or peer NAK, the arbitration logic460then transmits, respectively, a transmit done (Xmit_done) or a transmit fail (Xmit_fail) signal to the translation layer410.

On the other hand, upon receiving a packet receive request (RcvReq) from a peer device, the arbitration logic determines whether the translation layer410is capable of supporting packet receipt. The packet receive request (RcvReq) is accompanied with a corresponding received packet (Rcv_pkt) from the link layer430. Upon determining that the translation layer410is not in a transmit state, the arbitration logic460propagates the receive request (RcvReq) and the received packet (Rcv_pkt) to the translation layer410.

The arbitration logic460may also run an error check (e.g., a CRC or cyclic redundancy check) on a received packet and return (to the link layer430) an ACK or NAK to confirm whether the received packet did or did not pass the error check, respectively. The link layer430may, in turn, provide the ACK or NAK to the peer device. The arbitration logic460may, under the condition of error check passing, propagate the receive request (RcvReq) to the translation layer410along with the received packet (Rcv_pkt).

A conflict can occur in certain situations where the half duplex translation layer410is configured to transmit data to the peer device, and the peer device also attempts to transmit data to the local device400(as will be explained further with reference toFIGS. 5A-5B, 6A-6B and 7). In such situations, the arbitration logic460resolves conflict arising at the half-duplex translation layer410due to concurrent bidirectional data flow at the full-duplex link layer430by using transmitting either a transmit hold (Xmit Hold) signal or a transmit abort (Xmit Abort) signal to translation layer410. For example, arbitration logic460uses a transmit hold (Xmit Hold) signal to resolve conflict arising from concurrently or substantially concurrently occurring transmit request (Xmit_req) and receive request (Rcv_req). As another example, arbitration logic460uses a transmit abort (Xmit Abort) signal to prevent a packet receive request from being propagated from the link layer430to the translation layer410when the translation layer410is already in a transmit state and is transmitting data, thereby preventing a conflict arising at the translation layer due to concurrent transmit and receive requests.FIGS. 5A-5Billustrate a first conflict resolution scenario where a packet transmit request and a packet receive request arrive concurrently or substantially concurrently (within a specified time interval of each other) at the arbitration logic.FIGS. 6A-6Billustrate a second conflict resolution scenario where a packet receive request arrives at a local MHL device (From a peer MHL device) during ongoing packet transmission.

As described above, the arbitration logic460therefore provides interface and timing rules for: (i) transmitting packets from the half-duplex translation layer to the full-duplex link layer, (ii) receiving packets via the full-duplex link layer at the half-duplex translation layer, and (iii) resolving conflict arising at the half-duplex translation layer due to bidirectional data flow at the full-duplex link layer.

Additionally, the arbitration logic460facilitates exception handling (as will be explained further with reference toFIG. 8) by providing functionality that prevents arbitration logic460from waiting for over a specified interval or wait time for one or more of the abovementioned signals. Arbitration logic460optionally includes a counter or timer that estimates a measure of wait time while the arbitration logic awaits a signal from the full-duplex link layer430. When the wait time exceeds a specified threshold, the arbitration logic460sends an interrupt signal to microprocessor470which in turn signals the half duplex translation layer410and/or the full duplex link layer430and/or software465to reset their respective states (e.g., to an idle state, to restart the previous transmission, and so on). The Interrupt signal when provided to the microprocessor470potentially indicates a hardware issue or problem. Software465can collect diagnostic information and analyze the hardware issue at a system level to determine approaches to remedy the hardware issue.

FIGS. 5A-5Binclude block diagrams illustrating a first example of arbitration signaling performed at a local MHL 3 device, according to some embodiments. The arbitration signaling illustrated inFIGS. 5A-5Bresolves conflict arising at the half-duplex translation layer410due to bidirectional data flow at the full-duplex link layer430arising from concurrent or substantially concurrent transmit and receive requests.

FIG. 5Aillustrates a scenario where a packet transmit request (Xmit_req) and a packet receive request (RcvReq) arrive concurrently or substantially concurrently (within a specified time interval of each other) at the arbitration logic460. Since CBUS440and link layer430are both full-duplex, they can both support bi-direction packet transfer. However, the translation layer410is half-duplex and can therefore only support data transfer in any one direction at a time. Thus, arbitration logic460mediates or resolves the conflict that arises at the translation layer410from the concurrent or substantially concurrent bidirectional transmit and receive requests illustrated inFIG. 5A.

As shown inFIG. 5B, responsive to detecting the conflict ofFIG. 5A, arbitration logic460sends a transmit hold (Xmit Hold) signal to translation layer410. Upon receiving the transmit hold, the translation layer410suspends (e.g., temporarily, for a specified period of time) its transmission state. In other words, when the two requests (Xmit_req and RcvReq) arrive simultaneously at the arbitration logic460, the receive request is served first and the transmit request is temporarily ignored until packet receipt is completed. After packet receipt is completed, the arbitration logic460verifies or checks whether the transmit request (Xmit_req) is still asserted by the transmission layer410. Upon determining that the transmit (Xmit_req) is still asserted, the arbitration logic460serves the transmit request (Xmit_req) immediately following completion of packet receipt.

FIGS. 6A-6Binclude block diagrams illustrating a second example of arbitration signaling performed at a local MHL 3 device to resolve conflict arising at the half-duplex translation layer due to bidirectional data flow at the full-duplex link layer. The arbitration signaling illustrated inFIGS. 6A-6Bresolves conflict arising at the half-duplex translation layer410due to bidirectional data flow at the full-duplex link layer430arising from receive request received at the local device400during ongoing packet transmission.

FIG. 6Aillustrates a scenario where a packet receive request arrives at a local MHL device (from a peer MHL device), during an ongoing packet transmission. In other words, as shown inFIG. 6A, translation layer410enters a packet transmission state and starts to transmit a packet (Xmit_pkt) to the arbitration logic460. During this packet transmission state (e.g., before completion of the packet transmission state or before receiving a peer ACK or NAK), the arbitration logic460receives a packet receive request (RcvReq) from the link layer430, resulting from an incoming packet from the peer device. As explained above with reference toFIG. 5A, although CBUS440and link layer430are both full-duplex and can therefore both support bi-direction packet transfer, the translation layer410is half-duplex and can therefore only support data transfer in any one direction at any given time. Thus, arbitration logic460mediates or resolves the resulting conflict.

As illustrated inFIG. 6B, responsive to detecting the conflict ofFIG. 6A, arbitration logic460sends a transmit abort (Xmit Abort) signal to the translation layer410. The transmit abort signal causes the translation layer410to cease packet transmission from the translation layer410to the arbitration logic460. Additionally, the arbitration logic460de-asserts the transmit request to the link layer430(e.g., to local TDM480of the link layer430) to indicate that further outgoing packet transmission would be stopped. Then, the arbitration logic services the packet receive request (RcvReq). Upon completion of packet receipt, arbitration logic460checks whether the transmit request (Xmit_req) is still asserted by the translation layer410. Arbitration logic460may resume (e.g., restart) packet transmission responsive to whether or not the transmit request (Xmit_req) is still asserted by the transmission layer410.

In some embodiments, the arbitration logic460comprises a state machine that controls the flow of data between the half-duplex translation layer and the full-duplex link layer. Accordingly,FIG. 7includes a state transition diagram illustrating states through which the arbitration logic460of a local MHL 3 device300transitions during packet transmission, packet receipt, and during conflict arising due to bi-directional data transfer.

When the local device400initiates packet transmission to a peer device, the arbitration logic460(which is typically in ‘Arbitration/Idle State’705) receives a transmit request (Xmit_req) from the translation layer410. Responsive to receiving the transmit request (Xmit_req), arbitration logic460transitions to the ‘Transmit States’710illustrated inFIG. 7. In other words, arbitration logic460initiates packet transmission by entering the ‘Packet Transmission State’715(e.g., including transmitting a header and a higher and lower byte of packet data). The local device400stops transmission to await a response from the peer device. During this time, the arbitration logic460enters a Stop Transmission state720where it stops transmission and awaits an ACK or NAK from the peer device. The peer device may receive the transmitted packet in good (e.g., error-free) or bad (e.g., error-ridden) condition, depending on which, the local device400may receive (from the peer device) an acknowledgement (Peer ACK) or a negative acknowledgement (Peer NAK). Responsive to receiving the peer ACK or peer NAK, the arbitration logic460enters, respectively, a ‘Transmit Done’725or a ‘Transmit Fail’730state. This marks the completion of the ‘Transmit States’710and the arbitration logic460re-enters the ‘Arbitration/Idle State’705where it awaits further commands from the translation layer410or the link layer430.

On the other hand, upon receiving a packet or a packet receive request from a peer device, the arbitration logic460(which is typically in ‘Arbitration/Idle State’705) receives a packet or packet receive request (RcvReq) from the link layer430. Responsive to receiving the transmit request (Xmit_req), arbitration logic460transitions to the ‘Receive States’740illustrated inFIG. 7. Specifically, arbitration logic460enters a Packet Receive and CRC check745during which the arbitration logic460receives the incoming packets and runs an error check (e.g., a CRC or cyclic redundancy check) on the received packet. Responsive to the arbitration logic460determining that the received packet does pass the error check (CRC Good), arbitration logic460returns (to the link layer430) an ACK signal by entering the ‘Send ACK’ state750. On the other hand, responsive to the arbitration logic460determining that the received packet does not pass the error check (CRC Bad), arbitration logic460returns (to the link layer430) an NAK signal by entering the ‘Send NAK’ state755. This marks the completion of the ‘Receive States’740and the arbitration logic460re-enters the ‘Arbitration/Idle State’705where it awaits further commands from the translation layer410or the link layer430.

When the arbitration logic460receives concurrent transmit and receive requests (Xmit_req+RcvReq), the arbitration logic460(which is typically in ‘Arbitration/Idle State’705) transitions to a ‘Transmission Hold’760state, where arbitration logic460temporarily ignores a transmit request to serve the receive request by entering the ‘Receive States’740described above. Arbitration Logic460may determine that the transmit and receive requests are concurrent if the arbitration logic receives the Xmit_req and the RcvReq signals within a specified time interval of each other, regardless of the order in which in the Xmit_req and the RcvReq are received. Upon completion of the ‘Receive States’740, the arbitration logic640returns to ‘Arbitration/Idle State’705to verify whether the transmit request (Xmit_req) is still asserted (e.g., by the translation layer410). Responsive to the transmit request (Xmit_req) being asserted, arbitration logic460enters the ‘Transmit States’710to process or service the transmit request (Xmit_req). This conflict scenario is further explained with reference toFIGS. 5A-5B.

In the scenario where the local device400initiates packet transmission to a peer device and the arbitration logic460(which is typically in ‘Arbitration/Idle State’705) enters the ‘Transmit States,’ while in one or more of the ‘Transmit States,’ the arbitration logic may receive a packet or packet receive request (RcvReq) from the link layer430. Responsive to receiving the packet receive request (RcvReq) while in a ‘Transmit State’710the arbitration logic460enters an ‘Abort Transmission’ state760and de-asserts the transmit request to the link layer430(e.g., to local TDM480of the link layer430) to indicate that further outgoing packet transmission would be stopped. In some embodiments, an aborted packet from ‘Abort Transmission’ state760is treated by half-duplex translator layer equivalently to a failed packet from ‘Transmit Fail’730state. Arbitration Logic then enters the ‘Transmission Hold’ state770where arbitration logic460temporarily ignores transmit request from the translation layer410to serve the receive request by entering the ‘Receive States’740described above. ‘Transmission Hold’ state770explicitly changes the mode of arbitration logic460from transmission (e.g., ‘Transmit States’710) or idle (e.g., ‘Arbitration/Idle State’705) to receiving (‘Receive States’740). As described above, upon completion of the ‘Receive States’740, the arbitration logic640returns to ‘Arbitration/Idle State’705to verify whether the transmit request (Xmit_req) is still asserted (e.g., by the translation layer410). Responsive to the transmit request (Xmit_req) being asserted, arbitration logic460enters the ‘Transmit States’710to process or service the transmit request. This conflict scenario is further explained with reference toFIGS. 6A-6B.

FIG. 8illustrates a modification of the state transition diagram ofFIG. 7, to illustrate exception handling functions performed by arbitration logic460at a local MHL 3 device, according to some embodiments.

The transition diagram ofFIG. 8is similar to the transition diagram ofFIG. 7, but with two additional Timeout states (Peer Timeout870and Local Timeout880). It should be noted that states705-770illustrated inFIG. 8may have one or more of the characteristics of the corresponding states705-770described herein with reference toFIG. 7. For brevity, these details are not repeated here.

that correspond to exception handling states indicating that the arbitration logic460has waited longer than a specified maximum duration of permissible wait time, for one or more ACK/NAK/Grant signals (collectively referred to herein as ‘handshake’ signals) from the link layer430. These handshake signals may originate from the peer device or from within the local device itself. A duration of wait time may be measured, for example, by computing or counting a time period during which the arbitration logic460has awaited the one or more signals. A counter or timer may be used to compute or count the time period of wait. When the duration of wait exceeds the specified maximum duration of permissible wait, the arbitration logic460enters a timeout state.

In some embodiments, the arbitration logic460awaits ACK/NAK (handshake) signals from the peer device. For example, when the arbitration logic460is in the stop transmission state720, it awaits an ACK or NAK signal from the peer device. As described with reference toFIG. 7, responsive to receiving an ACK signal from the peer device, the arbitration logic460progresses to a ‘Transmit Done’ state725. On the other hand, responsive to receiving a NAK signal from the peer device, the arbitration logic460progresses to a ‘Transmit Fail’ state730. However, arbitration logic460cannot and does not wait for an indefinite period of time to receive the Peer ACK or Peer NAK signal. Instead, a maximum time duration or an upper limit on the permissible wait time is specified for this wait. A time of wait is counted, or otherwise measured. The time of wait is compared to the maximum permissible wait time and if the time of wait exceeds the maximum permissible wait time, then the arbitration logic460ceases to wait for the Peer ACK or Peer NAK signals and enters a first exception handling state (in this case, a ‘Peer Timeout’ state870). Stated differently, when the handshake signals expected by the arbitration logic460are signals originating from the peer device (e.g., the Peer ACK or Peer NAK signals), upon expiry of the specified maximum duration of permissible wait, the arbitration logic460enters a ‘Peer Timeout’ state870. In other words, when arbitration logic460has waited longer than a maximum permissible wait time for peer handshake signals, the arbitration logic460enters a ‘Peer Timeout’ state870.

Alternatively, in some embodiments, the arbitration logic460awaits one or more handshake signals from within the local device400itself. For example, during the ‘Receive States’740, upon transmitting an ACK or NAK signal to the link layer430indicating whether or not a received packet successfully passed an error check, the arbitration logic460awaits a local Grant signal from the link layer430as an acknowledgement of receipt of the ACK or NAK signals. Alternatively, during the ‘Packet Transmission’ state715, the arbitration logic460awaits the local Grant signal from link layer430indicating that the link layer430is ready to handle transmission of data to the peer device. Once again, arbitration logic460cannot and does not wait for an indefinite period of time to receive the local Grant signal from the link layer430. Instead, a maximum time duration or an upper limit on the permissible wait time is defined for this wait. A time of wait is counted, or otherwise measured. If the time of wait exceeds the maximum permissible duration of wait time, then the arbitration logic460ceases to wait for the Local Grant signal and enters a second exception handling state (in this case, a ‘Local Timeout’ state880). Thus, when the handshake signals expected by the arbitration logic460are signals originating from within the local device400itself (e.g., the Local Grant signal expected during the ‘Packet Transmission’ state, the ‘Send NAK’ state, or the ‘Send ACK’ state as illustrated inFIG. 8), upon expiry of the specified maximum duration of permissible wait, the arbitration logic460enters a ‘Local Timeout’ state. In other words, when arbitration logic460has waited longer than a maximum permissible wait time for local handshake signals, the arbitration logic460enters a ‘Local Timeout’ state880.

Note that, in some embodiments, the maximum permissible wait times specified for each of these different handshake signals may differ—a maximum permissible wait time for the Peer ACK signal, for instance, may differ from the maximum permissible wait time for the Peer NAK signal. Similarly, a maximum permissible wait time for the local Grant signal may be different from a maximum wait time for either the Peer ACK or the Peer NAK signals. These maximum permissible wait times may be predefined or programmatically modifiable. From either the ‘Local Timeout’ state880or the ‘Peer Timeout’ state870, the arbitration logic460returns to the ‘Arbitration/Idle State’705.

As explained with reference toFIG. 4, during exception handling states (‘Local Timeout’ state880or the ‘Peer Timeout’ state870) when the wait time exceeds a specified threshold, the arbitration logic460sends an interrupt signal to microprocessor470(shown inFIG. 4). The microprocessor470, in turn, signals the half duplex translation layer410and/or full-duplex link layer430and/or software465(also shown inFIG. 4) to reset their respective translation layer protocol states (e.g., to an idle state, to restart the previous transmission, and so on).

Beneficially, embodiments of this disclosure permit reusability and backwards compatibility of one or more components of the legacy MHL device when interfacing with an enhanced MHL device via an enhanced MHL 3 link. In particular, the legacy half duplex translation layer410can be reused to interface with both the half duplex CBUS of a legacy MHL (MHL 1/2) link as well as with a full duplex eCBUS of the enhanced MHL (MHL 3) link. Furthermore, embodiments of the disclosure enable reusability of legacy software originally designed for compatibility with components of the legacy MHL device and legacy MHL link, with the enhanced (MHL 3) architecture. In particular, embodiments of the disclosure enable legacy MHL software to be used with both the CBUS of the legacy MHL link as well as with the eCBUS of the MHL 3 link.