HK1097372A - High data rate interface with improved link synchronization - Google Patents

Description

High data rate interface with improved link synchronization

Priority requirements according to 35 U.S.C § 119

This patent application claims priority from provisional application No. 60/527,996, entitled "switched threshold Differential Interface," filed on 8/12/2003 and assigned to the assignee of the present invention, which is expressly incorporated herein by reference.

Technical Field

In this disclosure, embodiments of the present invention relate to a digital signal protocol and process for signaling or signal transfer at high data rates between a host device and a client device. More particularly, the present disclosure relates to a technique for transferring multimedia and other types of digital signals from a host or controller device to a client device for presentation or display to an end user using a low power, high data rate transfer mechanism with internal and external device applications.

Background

In recent years, significant advances have been made in computers, video game-related products, and various video technologies (e.g., DVD and high-definition VCR) to provide end-users of such devices with increasingly higher resolution still, video-on-demand, and graphical images, including even certain types of text. These advances in turn require the use of higher resolution electronic viewing devices, such as high definition video monitors, HDTV monitors, or dedicated image projection elements. For example, when using CD-type sound reproduction, DVD, and other devices that also have an associated audio signal output, such visual images are combined with high definition or high quality audio data to create a more realistic, richer, or more realistic multimedia experience for the end user. In addition, high mobility, high quality sound systems and music delivery mechanisms, such as MP3 players, have been developed to present pure audio to end users. This has led to an increasing habit and desire of high quality or premium output by typical users of commercial electronic devices, from computers to televisions and even telephones.

In a typical video presentation scenario, video data related to electronic products is typically transmitted with current technology at a rate on the order of one to tens of kilobits per second, which is properly referred to as slow or medium. These data are then buffered or stored in temporary or long term memory devices for delayed (later) playout at the desired viewing device. For example, images may be transferred "over" or using the internet using a program resident on a computer having a modem or other type of internet connection device to receive or transmit data that can be used to digitally represent the images. Similar transmissions can be made using wireless devices such as portable computers equipped with wireless modems, wireless Personal Digital Assistants (PDAs), or wireless telephones.

Once received, the data is stored locally in a memory element, circuit or device, such as in RAM or flash memory, including internal or external storage devices, such as small-sized hard disks, for playback. Depending on the amount of data and image resolution, playback may begin sooner or be presented with a long delay. That is, in some cases, for small images or low resolution images that do not require large amounts of data or use some sort of buffering, the image presentation allows some real-time playback so that some content is presented with less delay while more content is still in the process of being delivered. This transmission is suitably (reasonably) transparent to the end user of the viewing device once the presentation has started, provided that the transmission link does not experience any interruption or interference from other systems or users with respect to the transmission channel being used. Naturally, when multiple users share a communication path (e.g., a wired internet connection), the transmission may be interrupted or slower than desired.

Data used to produce still images or motion video is often compressed using one of several well-known techniques, such as those specified by the Joint Photographic Experts Group (JPEG), Moving Picture Experts Group (MPEG), and other standard organizations or companies well known in the media, computer, and communications industries, to accelerate the transfer of data over a communication link. These techniques use a smaller number of bits to transmit a given amount of information, allowing faster transmission of images or data.

Once the data is transferred to a "local" device, such as a computer or other receiver device, where the computer has a storage mechanism, such as memory, or a magnetic or optical storage element, the resulting information is decompressed (or played using a special decoding player), decoded if necessary, and prepared for appropriate rendering based on the corresponding available rendering resolution and control elements. For example, typical computer video resolutions represented by an X by Y pixel screen resolution typically range from as low as 480 by 640 pixels to 600 by 800 to 1024 by 1024 pixels, although various other resolutions are generally possible as needed or desired.

Image presentation is also affected by the image content and the ability of a given video controller to manipulate the image in terms of certain predetermined color levels or color concentrations (bits per pixel used to generate the color) and intensities, as well as any additional overhead bits employed. For example, a typical computer presentation expects about 8 to 32 bits or more per pixel to represent various colors (shades and hues), but other values are also encountered.

From the above values, it can be seen that a given screen image will require the transfer of from 2.45 megabits (Mb) to around 33.55Mb of data, respectively, over a range of typical resolutions and densities from lowest to highest. When viewing video or motion type images at a rate of 30 frames per second, the amount of data required is about 73.7 to 1,006 megabits of data per second (Mbps), or about 9.21 to 125.75 megabytes per second (Mbps). In addition, one may wish to present audio data with images, such as a multimedia presentation, or as separate high resolution audio presentations, such as CD quality music. Additional signals handling interactive commands, controls, or signals may also be employed. Each of these options adds more data to be transmitted. In addition, newer transmission techniques involving High Definition (HD) television and movie recording may add more data and control information. In any case, when one wishes to deliver high quality or high resolution image data and high quality audio information or data signals to an end user in order to produce a content rich experience, a link with a high data transfer rate is required between the rendering element and a source or host device configured to provide such data.

Typically, data rates on the order of 115 kilobytes per second (KBps) or 920 kilobits per second (KBps) can be handled by modern serial interfaces. Other interfaces, such as USB serial interfaces, can support data transfers at rates up to 12MBps, while dedicated high speed transfers, such as those configured using the Institute of Electrical and Electronics Engineers (IEEE)1394 standard, can occur at rates on the order of 100 to 400 MBps. However, these rates fail to achieve the desired high data rates mentioned above, which are desirable for use by future wireless data devices and services to provide high resolution, content rich output signals to drive portable video displays or audio devices. This includes computers, gaming devices, etc. for business and other presentations. In addition, these interfaces require the use of a significant number of hosts or systems and guest software to operate. Their software protocol stacks also create an undesirably large amount of overhead, especially when mobile wireless device or telephone applications are considered. Such devices have severe memory and power consumption limitations, as well as being already burdened with computational power. In addition, some interfaces use bulky cables that are too bulky and unsatisfactory for highly aesthetic mobile applications or utilize complex connectors that add cost or are too power hungry.

There are also other known interfaces such as analog Video Graphics Adapter (VGA), Digital Video Interactive (DVI) or Gigabit Video Interface (GVIF). The first two of these interfaces are parallel type interfaces for processing data at higher transfer rates, but they also employ heavy cables and consume large amounts of power, on the order of a few watts. None of these features are available for use with portable consumer electronic devices. Even the third interface consumes too much power and uses expensive or bulky connectors.

There is another major drawback to some of the above interfaces, as well as other very high rate data systems/protocols or transfer mechanisms associated with data transfer of fixedly mounted computer devices. Considerable power and/or operation with large currents is also required to support the required data transfer rates. Doing so greatly reduces the availability of this technology for consumer-oriented high-mobility products.

Generally, to support such data transfer rates, the use of alternatives such as fiber-optic type connections and transmission elements also requires a number of additional switches and elements, which are more complex and costly than what is really required for consumer-oriented commercial products. To date, their power requirements and their complexity have prevented their widespread use in portable, low power, portable applications, in addition to the very expensive nature of optical systems in general.

Lacking in the portable, wireless or mobile application industries is a technology that: a high quality rendering experience is provided to a high mobility end user, whether it be audio, video or multimedia based. That is, when using portable computers, wireless telephones, PDAs, or other high mobility communication devices or appliances, the video and audio presentation systems or devices currently in use are simply not able to deliver output at the desired high quality levels. The perceived lack of quality is often a result of the inability to achieve the high data rates required to transmit high quality presentation data. This includes transfer to more efficient, advanced or feature-full external devices for presentation to end-users, or between a host and a client within a portable device such as a computer, gaming device, or the like, as well as between a host and a wireless device including one such as a mobile phone.

In the latter case, a great step has been taken in adding higher and higher resolution internal video screens and other professional input and/or output devices, and connecting to wireless devices such as so-called third generation phones and so-called laptop computers. However, the internal data bus and connections may include bridging rotating or sliding hinges or hinge-like structures that mount or connect the video screen or other components to the main housing in which the host and/or various other control elements and output components are mounted. These are typically high bandwidth or high throughput interfaces. It is very difficult to construct a high throughput data transfer interface using existing techniques, such as in wireless telephones, which require up to 90 wires or more to achieve the desired throughput. Current solutions typically employ parallel type interfaces with higher signal levels, which makes the interconnection more costly, less reliable, and may produce radiated emissions that interfere with the device's functionality. There are a number of challenges to do so with respect to manufacturing, cost constraints, and reliability.

This problem and need also exists for fixed location devices, where, for example, communication or computing type devices are added to home appliances and other consumer devices to provide advanced data capabilities, internet and data transmission connectivity, or built-in entertainment. Another example is airplanes and automobiles where separate video and audio presentation screens are mounted in the seat back. However, in these situations, it is more convenient, efficient and easy to have the main storage, processing or communication control unit remote from the visual screen or audio output to present the information using an interconnected link or channel. Such a link would need to process a significant amount of data to achieve the desired throughput as described above.

Therefore, a new transfer mechanism is needed to improve data throughput between a host device providing data and a client display device or element presenting output to an end user.

The applicants have proposed such a new transport mechanism in U.S. patent application 10/020,520 (now U.S. patent 6,760,772, issued to Zou et al at 7/6/2004) and in co-pending U.S. patent application 10/236,657 filed at 6/9/2003, both entitled "Generation and implementation A communication protocol and Interface for High Data Rate Signal Transfer" which are now assigned to the assignee of the present invention and incorporated herein by reference. Also, there is a co-pending U.S. application entitled "Generation and implementation A Signal Protocol and Interface for high Data Rates", filed on 2.6.2004, serial No. 10/860,116. The techniques discussed in these applications can greatly increase the transfer rate of large amounts of data in high speed data signals. However, there is an increasing demand for ever increasing data rates, particularly rates involving video presentation. Even with other advances being developed in the art of data signal utilization, there is a continuing need for further increases in transmission rates, increases in communication link efficiency, and makes communication links more robust. Accordingly, there remains a need to develop new or improved delivery mechanisms for improving data throughput between host and client devices.

Disclosure of Invention

The above-mentioned and other deficiencies of the art are addressed by embodiments of the present invention in which new protocols and data transfer means, methods and mechanisms for transferring data at high data rates between a host device and a recipient client device have been developed.

Embodiments of the present invention are directed to a Mobile Data Digital Interface (MDDI) that transfers digital data at high rates between a host device and a client device via a communication path, which employs a plurality or series of linked packet structures to form a communication protocol for communicating a preselected set of digital control and presentation data between the host and client devices. The signal communication protocol or link layer is used by the physical layer of the host or client link controller, receiver or driver. At least one link controller or driver residing in the host device is coupled to the client device via a communication path or link and is configured to generate, transmit, and receive packets forming the communication protocol and form the digital presentation data into one or more types of data packets. The interface provides bi-directional transfer of information between the host and client, which can reside within a common unitary housing or support structure.

The implementation is typically all digital in nature, except for differential drivers and receivers, which can be easily implemented on digital CMOS chips, require a few signals, such as 6 signals, and can operate at almost any data rate that is extremely convenient for the system designer. The simplicity of the physical and link layer protocols facilitates integration, and the simplicity coupled with the sleep state allows the portable system to have very low system power consumption.

To facilitate use and acceptance, the interface will add little cost to the device, can allow for the consumption of little power while powering the display via the interface using standard battery voltages, and can enable the device to have a pocket-able form factor. The interface is scalable to support resolutions above HDTV, supports synchronized stereoscopic video and 7.1 audio for display devices, performs conditional updates to any screen area, and supports multiple data types bi-directionally.

In accordance with further aspects of embodiments of the present invention, at least one client link controller, receiver, device or driver is disposed in the client device and coupled to the host device via a communication path or link. The client link controller is also configured to generate, transmit, and receive packets forming a communication protocol, and to form the digital presentation data into one or more types of data packets. Generally, the host or link controller employs a state machine to process data packets for use in command or some type of signal preparation and query processing, but it can also use a slower general purpose processor to manipulate data and some less complex packets for the communication protocol. The host controller comprises one or more differential line drivers; and the client receiver comprises one or more differential line receivers coupled to the communication path.

The packets are grouped together within media frames communicated between the host and client devices, the media frames having a predefined fixed length, wherein the predetermined number of packets have different variable lengths. The packets each include a packet length field, one or more packet data fields, and a cyclic redundancy check field. The sub-frame header packet is transmitted or positioned at the beginning of other packet transmissions from the host link controller. The communication protocol uses one or more video stream type packets and audio stream type packets to transfer video type data and audio type data, respectively, from the host to the client via the forward link for presentation to the client device user. The communication protocol uses one or more reverse link encapsulation type packets to communicate data from the client device to the host link controller. In some embodiments, these transfers include transferring data from an internal controller having at least one MDDI device to an internal video screen. Other embodiments include transmission to an internal sound system, and to an internal host device from a variety of input devices including joysticks and complex keyboards.

Generating, by the host link controller, a filler type packet to occupy a period of forward link transmission without data. The communication protocol uses a plurality of other packets in order to communicate video information. These packets include color mapping, bit block transfer, bitmap area fill, bitmap pattern fill, and transparent color enable type packets. The communication protocol uses user-defined stream type packets to communicate interface-user-defined data. The communication protocol uses keyboard data and pointing device data type packets to transfer data to and from user input devices associated with the client device. The communication protocol uses link shutdown type packets to terminate data transfer in either direction via the communication path.

The communication path typically includes or employs a cable having a series of four or more conductors and a shield. In addition, printed wires or leads may be used, some of which reside on the flexible substrate, as desired.

The host link controller requests display capability information from a client device to determine what types of data and data rates the client can support via the interface. The client link controller communicates display or rendering capabilities to the host link controller using at least one display capability type packet. The communication protocol uses multiple transfer modes, each allowing a different maximum number of data bits to be transferred in parallel over a given period of time, each mode being selectable by negotiation between the host and client link controllers. These transmission modes may be dynamically adjusted during data transmission and need not use the same mode on the reverse link as the transmission mode used on the forward link.

In other aspects of some embodiments of the invention, the host device comprises a wireless communication device, such as a wireless telephone, a wireless PDA, or a portable computer having a wireless modem disposed therein. Typical client devices include portable video displays, such as microdisplay devices, and/or portable audio presentation systems. In addition, the host may use a storage module or element to store rendering or multimedia data to be transferred for rendering to the user of the client device.

In other aspects of some embodiments, the host device comprises a controller or communication link control device having a drive residing within a portable electronic device, such as a wireless communication device, such as a wireless telephone, wireless PDA, or portable computer. A typical client device of this configuration includes client circuitry, an integrated circuit, or a module that is coupled to and resides in the same device as the host, and is coupled to an internal video display such as a high resolution screen in a mobile phone and/or portable audio presentation system, or some alternative type of input system or device.

Drawings

Further features and advantages of the invention, as well as the structure and operation of various embodiments of the invention, are described in detail below with reference to the accompanying drawings. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements or process steps, and the drawing in which an element first appears is indicated by the leftmost digit(s) in the reference number.

FIG. 1A illustrates a basic environment in which embodiments of the present invention can operate, including the use of a microdisplay device or projector in conjunction with a portable computer or other data processing device.

FIG. 1B illustrates a basic environment in which embodiments of the present invention can operate, including the use of a microdisplay device or projector and an audio rendering element in conjunction with a wireless transceiver.

FIG. 1C illustrates a basic environment in which an embodiment of the present invention can operate, including use with an internal display device or audio rendering device in a portable computer.

FIG. 1D illustrates a basic environment in which embodiments of the present invention can operate, including the use of an internal display or audio rendering element in a wireless transceiver.

Fig. 2 shows the general concept of a mobile digital data interface with host and client interconnections.

Fig. 3 shows a packet structure for implementing data transfer from a client device to a host device.

Fig. 4 illustrates the use of an MDDI link controller and the types of signals passed between the host and client via the physical data link wires of the type 1 interface.

Fig. 5 illustrates the use of an MDDI link controller and the types of signals passed between the host and client via the physical data link conductors of type 2, 3, 4 interfaces.

Fig. 6 shows the structure of frames and subframes for implementing the interface protocol.

Fig. 7 shows a general structure of a packet for implementing the interface protocol.

Fig. 8 shows the format of a sub-frame header packet.

Fig. 9 shows the format and content of the filler packet.

Fig. 10 shows the format of a video stream packet.

Fig. 11A to 11E show the format and contents of the video data format descriptor used in fig. 10.

FIG. 12 illustrates the use of packed and unpacked formats for data.

Fig. 13 shows the format of an audio stream packet.

FIG. 14 illustrates the use of byte-wise alignment of data and packed PCM format.

FIG. 15 shows a format of a user-defined stream packet.

Fig. 16 shows the format of a color map packet.

Fig. 17 shows the format of a reverse link encapsulation packet.

Fig. 18 shows the format of the client capability packet.

Fig. 19 shows the format of a keyboard data packet.

Fig. 20 shows the format of a pointing device data packet.

Fig. 21 shows the format of the link-down packet.

FIG. 22 shows the format of a client request and status packet.

Fig. 23 shows the format of a bit block transport packet.

Fig. 24 shows the format of the bitmap area stuffing packet.

Fig. 25 shows a format of the bitmap pattern padding packet.

Fig. 26 shows the format of a communication link data lane packet.

Fig. 27 shows the format of the interface type switch request packet.

Fig. 28 shows the format of the interface type confirm packet.

Fig. 29 shows a format of the execution type switching packet.

Fig. 30 shows the format of the forward audio channel enable packet.

Fig. 31 shows the format of an inverse audio sample rate packet.

Fig. 32 shows the format of a digital content protection overhead packet.

Fig. 33 shows the format of the transparent color enable packet.

Fig. 34 shows the format of the round trip delay measurement packet.

Fig. 35 shows the timing of events during a round trip delay measurement packet.

Fig. 36 shows an exemplary implementation of a CRC generator and checker for implementing the present invention.

Fig. 37A shows the timing of the CRC signal when the apparatus shown in fig. 36 transmits a data packet.

Fig. 37B shows the timing of the CRC signal when the apparatus shown in fig. 36 receives a data packet.

Figure 38 shows the processing steps of a typical service request without contention.

Fig. 39 shows the processing steps for a typical service request to maintain (alert) after the start of a link restart sequence in contention with the link startup.

Fig. 40 shows how DATA-STB coding is used to transmit a DATA sequence.

Fig. 41 shows circuitry that may be used to generate DATA and STB signals from input DATA in the host and then recover the DATA in the client.

FIG. 42 illustrates a driver and termination resistors that can be used to implement one embodiment.

Fig. 43 shows steps and signal levels used by a client to ensure service from a host and by the host to provide such service.

Fig. 44 shows the relative spacing between transitions on Data0, other Data lines (DataX), and strobe lines (Stb).

FIG. 45 illustrates the delay in response that may occur when the host driver is disabled after the host transfers a packet.

FIG. 46 illustrates the delay in response that may occur when the host enables the host driver to transmit packets.

FIG. 47 shows leakage current analysis.

FIG. 48 shows the switching characteristics and relative timing relationships of the host and client output disable and enable times.

FIG. 49 shows a high level diagram of signal processing steps and conditions that can be synchronized using a state machine.

Fig. 50 illustrates typical amounts of delay encountered by signal processing on the forward and reverse paths in a system employing MDDI.

Figure 51 shows a critical round trip delay measurement.

Fig. 52A shows the change in the reverse link data rate.

Fig. 52B shows an example of advanced inverse data sampling.

Fig. 53 depicts a graphical representation of the value of the reverse rate divisor as a function of the forward link data rate.

Fig. 54A and 54B show steps performed in the interface operation.

Fig. 55 shows an overview of an interface apparatus that processes a packet.

Fig. 56 shows the format of the forward link packet.

Fig. 57 shows typical values of propagation delay and skew (skew) in a type 1 link interface.

Fig. 58 shows Data, Stb (strobe), and Clock recovery timing on the type 1 link for exemplary signal processing via the interface.

Fig. 59 shows typical values of propagation delay and skew in type 2, 3 or 4 link interfaces.

Fig. 60A, 60B, and 60C illustrate different possibilities for relative timing between two data signals and MDDI _ Stb, which correspond to an ideal case, an early case, and a late case, respectively.

FIG. 61 illustrates interface pin assignments for an exemplary connector for a type 1/type 2 interface.

Fig. 62A and 62B show possible MDDI _ Data and MDDI _ Stb waveforms for type 1 and type 2 interfaces, respectively.

FIG. 63 shows a high level diagram of optional signal processing steps and conditions that can be synchronized using a state machine.

Fig. 64 shows a series of clock cycles versus timing for various reverse link packet bits and the relative timing between divisor values.

Fig. 65 shows an exemplary error code transfer process.

Fig. 66 shows an apparatus that can be used for the error code transfer process.

Fig. 67A shows an error code transfer process for code reloading.

Fig. 67B shows an error code transfer process for code reception.

FIG. 68A shows the process steps for host initiated wake up.

FIG. 68B shows the processing steps for client initiated wake up.

FIG. 68C shows the process steps for wake-up with competing host and client initiated.

Fig. 69 shows the format of the request VCP feature packet.

Fig. 70 shows the format of the VCP feature acknowledgement packet.

Fig. 71 shows the format of the VCP feature response list.

FIG. 72 shows a format for setting a VCP feature packet

Fig. 73 shows the format of the request valid parameter packet.

Fig. 74 shows the format of the validity parameter response packet.

Fig. 75 shows the format of a scalable video stream capability packet.

Fig. 76 shows the format of a scalable video stream setup packet.

Fig. 77 shows the format of a scalable video stream acknowledgment packet.

Fig. 78 shows the format of scalable video stream packets.

Fig. 79 shows the format of a request specific status packet.

Fig. 80 shows the format of the valid-state acknowledgement list packet.

Fig. 81A shows the format of a packet processing delay parameter packet.

Fig. 81B shows the format of the delay parameter list item.

Fig. 82 shows the format of the personal display capability packet.

Fig. 83 shows points of the field of view curvature point list field.

Fig. 84A shows the format of the client error report packet.

FIG. 84B illustrates the format of an error report listing.

Fig. 85 shows the format of the client identification packet.

Fig. 86 shows the format of the optional display capability packet.

Fig. 87 shows the format of the register access packet.

Fig. 88A-88C illustrate the use of two display buffers to reduce visual artifacts.

FIG. 89 shows two buffers with display refresh faster than image transfer.

FIG. 90 shows two buffers with display refresh slower than image transfer.

Fig. 91 shows two buffers that display refresh is much faster than image transfer.

FIG. 92 shows three buffers with display refresh faster than image transfer.

FIG. 93 shows three buffers with display refresh slower than image transfer.

FIG. 94 shows a buffer with display refresh faster than image transfer.

Fig. 95 shows host-client connections via daisy-chain (daisy-chain) and hub.

Fig. 96 shows client devices connected via a combination of a hub and a daisy chain.

Fig. 97 shows color mapping.

Detailed Description

I. Overview

It is a general object of the present invention to provide a Mobile Display Digital Interface (MDDI) that enables or provides a cost effective, low power consumption transport mechanism that uses a "serial" type data link or channel to enable high or very high speed data transfer over a short range communication link between a host device and such a client device as a display element. This mechanism is suitable for implementation with miniature connectors and thin flexible cables that are particularly suitable for connecting internal (within a housing or cradle) displays or output elements or devices or input devices to a central controller, communication element or device. Furthermore, such a connection mechanism is very useful when connecting an external display element or device such as a wearable micro-display (goggles or projector) or other type of visual, auditory, tactile information presentation device to a portable computer, wireless communication device or entertainment device.

Although the terms move and display are associated with the nomenclature of the protocols, it should be understood that this is merely to facilitate the easy understanding of the names of the standards by those skilled in the art studying the interfaces and protocols. It will relate to the VESA standard and various applications of the standard. However, as will be readily appreciated upon reading the examples given below, many non-mobility and non-display related applications will also benefit from applying the present protocol, resulting interface structure, or transport mechanism, and the MDDI flag is not meant to impose any limitations on the present invention or various embodiments thereof.

It is an advantage of embodiments of the present invention to provide a technique for data transfer that is low in complexity, low in cost, highly reliable, well suited to the environment of use, and very stable while maintaining very high flexibility.

Embodiments of the present invention may be used in a variety of situations to transfer or transfer large amounts of data, typically used in audio, video or multimedia applications, from a host or source device that generates, controls (e.g., transfers to a particular device) or processes or stores such data at a high rate to a client or receiving device, such as a video display or projection element, audio speakers or other presentation device. One typical application discussed below is data transfer from a portable computer, wireless telephone or modem to a visual display device, for example a small video screen or a wearable micro-display appliance (micro-displayability), such as in the form of a visor or helmet containing a small projection lens and screen, or within such a component from a host computer to a client device. That is, from the processor to an internal screen or other presentation element, and from various internal input devices or external input devices employing clients to an internally mounted (co-located within the same device housing or support structure) host or connected thereto by cables or wires.

The nature or attributes of MDDI are not dependent on the particular display or presentation technology. MDDI is a highly flexible mechanism for transferring data at high rates, regardless of the internal structure of the data, or the functional aspects of the data or commands it executes. It allows the timing of the packets being transmitted to be adjusted to suit the characteristics of the particular client device, such as the characteristics of the unique display requirements for certain devices, or the characteristics of the combined audio and video requirements for certain a-V systems, or the characteristics of certain input devices such as joysticks, touch pads, and the like. Such an interface need not know what display elements or client devices are employed as long as they comply with the selected protocol. In addition, the overall serial link data or data rate can vary by orders of magnitude, which enables designers of communication systems or host devices to optimize cost, power requirements, complexity of client devices, and update rates of client devices.

Such data interfaces are primarily used to transfer large amounts of high-rate data via "wired" signal links or small cables. However, certain applications may also utilize wireless links, including optical-based links, as long as the links are configured to use the same packet and data structures developed for this interface protocol and are able to achieve the desired level of transmission with sufficiently low power consumption or complexity to maintain practicality.

II. Environment

A typical application can be seen in fig. 1A and 1B, which show a portable or laptop computer 100 and a wireless telephone or PDA device 102 communicating data with display devices 104 and 106 and audio reproduction systems 108 and 112, respectively. In addition, FIG. 1A shows potential connections to a larger display or screen 114 or image projector 116, which are shown in only one figure for clarity, but which may also be connected to the wireless device 102. The wireless device may be currently receiving data or have pre-stored a certain amount of multimedia type data in a memory element or device for later presentation to an end user of the wireless device for viewing and/or listening. Since most of the time a typical wireless device is used for voice and simple text communications, it has a relatively small display screen and a simple audio system (speaker) to convey information to the user of the device 102.

The computer 100 has a very large screen but also lacks an external sound system and still does not reach the level of other multimedia presentation devices such as high definition television or movie screens. The computer 100 is used for illustrative purposes, and other types of processors, interactive video games, or consumer electronics devices may be used with the present invention. The computer 100 may be capable of wireless communication using a wireless modem or other embedded device, or connected to such a device using a cable or wireless link, as desired, but is not limited to such.

This is not sufficient to enable the presentation of more complex or "rich" data to provide a useful or enjoyable experience. Accordingly, the industry is developing other mechanisms and devices to present information to end users and to provide a desired minimum level of enjoyment or positive experience.

As previously mentioned, several types of display devices have been developed or are currently being developed to present information to the end user of device 100. For example, one or more companies have developed sets of wearable goggles for projecting images in front of the eyes of a user of the device to present a visual display. When correctly positioned, such devices can effectively "project" a virtual image, as perceived by the user's eyes, that is much larger than the elements that provide the visual output. That is, the very small projection elements cause the user's eyes to "see" a much larger image than is possible with a typical LCD screen or the like. The use of a larger virtual screen image also enables the use of images of much higher resolution than can be obtained with a more limited LCD screen display. Other display devices may include, but are not limited to, a small LCD screen or various flat panel display elements, a projection lens and display driver for projecting an image onto a surface, and the like.

There are additional elements connected to, or associated with, the use of the wireless device 102 or the computer 100 to present an output to other users or to other devices that also transmit signals elsewhere or store signals. For example, data may be stored in flash memory, in optical form, e.g., using a writable CD medium, stored or stored on a magnetic medium such as a tape recorder or the like for later use.

In addition, many wireless devices and computers currently have built-in MP3 music decoding capabilities, as well as other advanced sound decoders and systems. Typically, portable computers utilize CD and DVD playback capabilities, and some also have small dedicated flash memory readers to receive pre-recorded audio files. The problem with this capability is that: digital music file offers can provide a highly augmented feature rich experience, but only if the decoding and playing process can keep up. This is also true for digital video files.

To assist in sound reproduction, an external speaker 114 is shown in fig. 1A, with additional elements such as a subwoofer or "surround sound" speakers for front-to-back sound projection. Also, a speaker or earpiece 108 is shown in the form of an embedded stand or mechanism of the microdisplay device 106 of FIG. 1B. Other audio or sound reproduction elements including power amplification or sound shaping devices may also be used, as is well known.

In any case, as described above, high data rates are required when one wishes to transmit high quality or high resolution image data and high quality audio information or data signals from a data source to an end user via one or more communication links 110. That is, the transport link 110 is clearly a potential bottleneck in the data communication process, as discussed earlier, and limits system performance because current transport mechanisms are unable to achieve the high data rates that are typically desired. As described above, for higher image resolutions of 1024 × 1024 pixels, color density of 24 ~ 32 bits per pixel, and data rate at 30fps, for example, the data rate can approach a rate exceeding 755Mbps or higher. In addition, such images may be presented as part of a multimedia presentation that includes audio data and potentially additional signals to handle interactive games or communications, or various commands, controls or signals, which further increases the amount of data and data rate.

It is also apparent that the fewer cables or interconnections required to establish a data link means that the mobile device associated with the display is easier to use and more likely to be adopted by more users. This is particularly the case where multiple devices are typically used to create a full audio-video experience, and is even more pronounced as the quality levels of the display and audio output devices increase.

Other exemplary applications of the above and other improvements relating to video screens and other output or input devices can be seen in fig. 1C and 1D, which show a portable or laptop computer 130 and a wireless telephone or PDA device 140 communicating data with "internal" display devices 134 and 144 and audio reproduction systems 136 and 146, respectively.

In fig. 1C and 1D, the location of one or more internal hosts and controllers in a portion of the device is shown in a cut-away (cut-away) portion of the overall electronic device or product, with a common communications link (here 138 and 148, respectively) connecting these internal hosts and controllers to a video display element or screen with a corresponding client via some known type of rotating hinge currently used throughout the electronics industry. It can be seen that the amount of data involved in these transfers requires a large number of wires to form links 138 and 148. Since parallel interfaces or other known types of interface technologies can be used to transfer such data, it is estimated that such communication links have close to 90 or more conductors in order to meet the now growing need to utilize advanced color and graphics interfaces, display elements, on such devices.

However, such higher data rates exceed the currently available prior art for transmitting data. This is true both in terms of the amount of raw data that needs to be transferred per unit time, and in terms of a practical transfer mechanism that is reliable to manufacture at low cost.

What is needed is a technique, structure, apparatus or method for transmitting data at a high rate over a data transmission link or communication path between a presentation element and a data source that achieves a cable structure that is consistently low power, lightweight, and as simple and economical as possible. The applicant has developed a new technique, method and apparatus to achieve these and other objectives in order to enable a range of mobile, portable or even fixed location devices to transfer data to a desired display, microdisplay or audio delivery element at very high data rates, while maintaining the desired low power consumption and low complexity.

High rate digital data interface system architecture

To create and efficiently utilize new device interfaces, signal protocols and system architectures have been formulated that provide very high data transfer rates using low power signals. The protocol is based on packets and a common frame structure or structure linked together to form a protocol for communicating a preselected set of data or data type and a command or operational structure imposed on the interface.

A. Overview

Devices connected or communicating via an MDDI link are referred to as hosts and clients, which are typically some type of display device, although other output and input devices are also contemplated. When enabled by the host, data from the host to the display is transferred in the forward direction (referred to as forward traffic or link) and data from the client to the host is transferred in the reverse direction (referred to as reverse traffic or link). This is illustrated in the basic structure shown in fig. 2. In FIG. 2, host 202 is connected to client 204 using a bi-directional communication channel 206, which is shown in a form that includes a forward link 208 and a reverse link 210. However, these lanes are formed by common conductor sets whose data transfer can be effectively switched between forward and reverse link operation. This can greatly reduce the number of wires, and immediately solve one of many problems faced by the current method of high-speed data transfer in a low power consumption environment such as a mobile electronic device.

As discussed elsewhere, the host comprises one of a variety of types of devices that can benefit from the use of the present invention. For example, host 202 may be a portable computer in the form of a handheld, laptop, or similar mobile computing device, which may also be a Personal Digital Assistant (PDA), a paging device, or one of a variety of wireless telephones or modems. Alternatively, host 202 may be a portable entertainment or presentation device, such as a portable DVD or CD player, or a gaming device.

In addition, the host may exist as a host device or control element in a variety of other widely used or planned commercial products that require high-speed communication links to be established with clients. For example, the host may be used to transfer data from a video recording device to a storage-based client at a high rate to improve response, or to transfer data to a high-resolution large screen for presentation. Appliances such as refrigerators that incorporate on-board inventory (on-board inventory) or computing systems and/or bluetooth connections to other home devices have improved display capabilities when operating in the internet or bluetooth connected mode, or reduce wiring requirements for an in-room display (client) and keypad or scanner (client) when an electronic computer or control system (host) is present elsewhere in the room. In general, those skilled in the art will appreciate that a wide variety of modern electronic devices and appliances will benefit from the use of such interfaces, and that older devices can be retrofitted by utilizing a limited number of conductors available in new added or existing connectors or cables to enable higher data rate transmission of information.

Meanwhile, the client 204 may include various devices for presenting information to an end user or presenting information from a user to a host. For example, a micro-display incorporating goggles or glasses, a projection device embedded in a hat or helmet, a small screen or even a holographic element embedded in a window or windshield such as a vehicle, or various speakers, headphones, or a sound system for presenting high quality sound or music. Other presentation devices include projectors or projection devices for presenting meeting information or movies and television images. Another example is the use of touch pads or sensitive devices, voice recognition input devices, security scanners, and others that can be invoked to convey large amounts of information from a device or system user who has less realistic "inputs" from the user other than touch and sound. Additionally, the holders of computers and docking stations (docking stations) and wireless phones of vehicle accessories or desktop accessories may also serve as interface devices for end users or other devices and equipment, and may utilize clients (such as output or input devices of a mouse) or hosts to facilitate the transfer of data, particularly where high-speed networks are involved.

However, those skilled in the art will readily recognize that the present invention is not limited to these devices, and that there are many other devices available on the market that provide high quality images and sound to the end user, either in storage and transmission or in presentation when played. The present invention is useful in improving data throughput between various elements or devices, and thus can accommodate the high data rates required to achieve a desired user experience.

The MDD interface and communication signal protocol of the present invention can be used to simplify the interconnection (referred to as internal mode) between a host processor, controller or circuit component(s) within a device (internal mode), for example, and a display within the device or device housing or structure, to reduce the cost or complexity of these connections and associated power and control requirements or constraints of these connections, and to improve reliability, not just to connect to or for external elements, devices or equipment (external mode).

The total serial link data rate on each signal pair used by this interface architecture can vary by many orders of magnitude, which allows system or device designers to easily optimize cost, power, implementation complexity, and display update rate. The attributes of MDDI do not depend on the technology of the display or other rendering device (target client). The timing of data packets transmitted via the interface can be easily adjusted to the characteristics of a particular client, such as a display device, a sound system, memory and control elements, or to the characteristics of the combined timing requirements of an audio-video system. While this allows the system to consume as little power as possible, it does not require that each client have a frame buffer in order to use the MDDI protocol at least at some level.

B. Interface type

The MDD interface is contemplated as being capable of handling the physical type of at least four or more interfaces that are somewhat different as may be found in the communications and computer industries. These types of interfaces are simply labeled type 1, type 2, type 3, type 4, although other labels or names may be applied by those skilled in the art depending on the particular application targeted or the industry to which it relates. For example, a simple audio system uses fewer connections than a complex multimedia system, and may refer differently to characteristics such as "channels" and so on.

The type 1 interface is configured as a 6-wire or other type of wire or conductive element interface that makes it suitable for use with mobile or wireless telephones, PDAs, electronic games and portable media players such as CD players or MP3 players, and similar devices or devices used in similar types of electronic consumer technology. In one embodiment, an interface configured as an 8-wire (wire) interface may be more suitable for use with laptop, notebook, or desktop personal computers and similar devices or applications that do not require rapid data updates and do not have embedded MDDI link controllers. This interface type can also be distinguished by the use of an additional two-wire Universal Serial Bus (USB) interface, where USB is well suited to support existing operating system or software support common on most personal computers.

Type 2, type 3 and type 4 interfaces are suitable for high performance clients or devices and use more complex cables with additional twisted pair type conductors to provide proper shielding and low loss transmission for data signals.

Type 1 interfaces deliver signals including display, audio, control and limited signaling information and are typically used for mobile clients or client devices that do not require high resolution full rate video data. The type 1 interface can easily support SVGA resolution with 30fps plus 5.1 channel audio, and in a minimum configuration, only three line pairs are used in total, two for data transmission and one for power transfer. This type of interface is used primarily for devices such as mobile wireless devices, which typically do not have a USB host side to connect and transfer signals. In this configuration, the mobile wireless device is an MDDI host device and acts as a "master device" for controlling the communication link from the host, which typically sends data (forward traffic or link) to the client for rendering, display or playing.

In such an interface, the host can receive communication data (reverse traffic or link) from the client at the host by sending a special command or packet type to the client, allowing the client to occupy the bus (link) for a specified duration, and send the data to the host as a reverse packet. This is illustrated in fig. 3, where a packet type (discussed below), referred to as an encapsulation packet, is used to support reverse packet transmission on the transmission link to create the reverse link. The time interval allocated to the host for polling the client's data is predetermined by the host and is based on the requirements of each specified application. This type of half-duplex, bi-directional data transfer is particularly beneficial when no USB port is used to transfer information or data from the client.

High performance displays capable of supporting HDTV types or similar high resolutions require data streams at rates around 1.5Gbps to support full motion video. The type 2 interface supports high data rates by transferring 2 bits in parallel, the type 3 interface supports 4 bits by transferring 4 bits in parallel, and the type 4 interface transfers 8 bits in parallel. Types 2 and 3 use the same cables and connectors as type 1, but are capable of operating at twice and four times the data rate to support higher performance video applications on portable devices. A type 4 interface is suitable for very high performance clients or displays and requires a slightly larger cable containing an additional twisted pair of data signals.

Typically, the protocol used by MDDI allows each of the hosts of types 1, 2, 3, and 4 to communicate with any of the clients of types 1, 2, 3, and 4 by negotiating the highest data rate that can be used by the negotiation. The capabilities or available features, which may be referred to as minimum capability devices, are used to set the performance of the link. Typically, even though both the host and the client can be systems using type 2, type 3, or type 4 interfaces, both start working with type 1 interfaces. The host then determines the capabilities of the target client and negotiates an agreed switch or reconfiguration operation to one of type 2, type 3 or type 4 as appropriate for the particular application.

For the host, the correct link layer protocol (discussed further below) can typically be used and the operation is typically stepped down or reconfigured again at any time to a slower mode to save power consumption, or stepped up to a faster mode to support higher speed transfer of, for example, high resolution display content. For example, the host computer may change the interface type when the system switches from power, such as a battery, to ac power, or when the display media source switches to a lower or higher resolution format, or may consider a combination of these or other conditions or events as the basis for changing the interface type or transfer mode.

The system is also capable of transferring data using one mode in one direction and another mode in the other direction. For example, the type 4 interface mode may be used to transfer data at a high rate to a display, while the type 1 mode is used when transferring data from a peripheral device, such as a keyboard or pointing device, to a host device. One of ordinary skill in the art will appreciate that the host and client are capable of transferring output data at different rates.

Users of the MDDI protocol often can distinguish between "external" and "internal" modes. External mode describes using the protocol and interface to connect a host in a device to a client external to the device and up to about 2 meters away from the device. In this case, the host may also transmit power to the external client to facilitate both devices operating in a mobile environment. Internal schema describes a host connected to a client contained within the same device, such as within a common housing or cradle or structure. An example may be an application within a wireless telephone or other wireless device, or within a portable computer or gaming device, where the client is a display or display driver, or an input device such as a keyboard or touchpad, or a sound system, and the host is a central controller, graphics engine, or CPU element. In contrast to external mode applications, power is not typically required to connect power to the client in such a configuration, since the client is located very close to the host in internal mode applications.

C. Physical interface structure

The general configuration of a device or link controller for establishing communication between a host and a client device is shown in fig. 4 and 5. In fig. 4 and 5, MDDI link controllers 402 and 502 are shown installed in host device 202, and MDDI link controllers 404 and 504 are shown installed in client device 204. As previously described, host 202 is connected to client 204 using a bi-directional communication channel 406 that includes a series of conductors. As described below, both the host and client link controllers can be fabricated as integrated circuits using a single circuit design that can be set, adjusted, or programmed to respond as either a host controller (driver) or a client controller (receiver). This is less costly due to the need to manufacture individual circuit devices on a larger scale.

In fig. 5, MDDI link controller 502 is shown installed in host device 202 'and MDDI link controller 504 is shown installed in client device 204'. As previously described, host 202 'is connected to client 204' using a bi-directional communication channel 506 comprising a series of conductors. As described above, both the host and client link controllers can be manufactured using a single circuit design.

The signals that are communicated between the host and the client, such as a display device, via the MDDI link or physical wires used are also illustrated in fig. 4 and 5. As shown in FIGS. 4 and 5, the primary path or mechanism for transferring Data via MDDI uses Data signals labeled MDDI _ Data0 +/-and MDDI _ Stb +/-respectively. Each of these signals is a low voltage data signal that is carried via a differential pair of wires in a cable. There is only one transition on either the MDDI _ Data0 pair or the MDDI _ Stb pair for each bit sent over the interface. This is a voltage-based, not current-based, transport mechanism, and thus the quiescent current consumption is close to zero. The host drives the MDDI _ Stb signal to the client display.

The host is the master or controller of the Data link when Data can flow in both forward and reverse directions via the MDDI _ Data pair, that is, it is a bi-directional transfer path. The MDDI _ Data0 and MDDI _ Stb signal paths operate in a differential mode to maximize immunity. The data rate of the signals on these lines is determined by the clock rate transmitted by the host and can vary from 1kbps up to 400Mbps or more.

In addition to the Data pairs or paths of the type 1 interface, the type 2 interface also contains an additional Data pair or conductor or path, called MDDI _ Data1 +/-. In addition to those Data pairs or paths of the type 2 interface, the type 3 interface contains two additional Data pairs or signal paths, referred to as MDDI _ Data2 +/and MDDI _ Data3 +/-. In addition to the data pairs or paths of the type 3 interface, the type 4 interface contains four further data pairs or signal paths, respectively referred to as: MDDI _ Data4+/-, MDDI _ Data5+/-, MDDI _ Data6 +/-and MDDI _ Data7 +/-. In each of the above-described interface configurations, the HOST may provide power to the client or display using line pairs or signals designated HOST _ Pwr (HOST power supply) and HOST _ Gnd (HOST ground). As will be discussed further below, if desired, the MDDI _ Data4+/-, MDDI _ Data5+/-, MDDI _ Data6 +/-or MDDI _ Data7 +/-wires may also be used for power transfer in some configurations when the interface "type" being used utilizes fewer wires than are available or present in other modes. Although there are differences in some applications, power transfer is typically used in the external mode and power transfer is typically not required in the internal mode.

An overview of the signals passed between the host and client (display) via the MDDI link in the various modes, according to interface type, is illustrated below in table I.

TABLE I

Type 1	Type 2	Type 3	Type 4
				HOST _ Pwr/GndMDDI _ Stb +/-MDDI _ Data0 +/-optional Pwr	HOST _ Pwr/GndMDDI _ Stb +/-MDDI _ Data0+/-MDDI _ Data1 +/-optional Pwr	HOST _ Pwr/GndMDDI _ Stb +/-MDDI _ Data0+/-MDDI _ Data1+/-MDDI _ Data2+/-MDDI _ Data3 +/-optional Pwr	HOST_Pwr/GndMDDI_Stb+/-MDDI_Data0+/-MDDI_Data1+/-MDDI_Data2+/-MDDI_Data3+/-MDDI_Data4+/-MDDI_Data5+/-MDDI_Data6+/-MDDI_Data7+/-

It should also be noted that the HOST _ Pwr/Gnd connection for transfer from the HOST is typically provided for external mode. The internal application or mode of operation typically lets the client power up directly from other internal resources without using MDDI to control the power distribution, as will be apparent to those of ordinary skill in the art, and therefore such distribution is not described in further detail herein. However, as will be appreciated by those of ordinary skill in the art, power can of course be distributed via the MDDI interface to facilitate, for example, some power control, synchronization, or interconnection.

The cable typically used to achieve the above-described structure and operation is nominally on the order of about 1.5 meters in length, typically 2 meters or less, and includes three twisted pairs of conductors, again a plurality of 30AWG wires. A foil shield is wrapped or formed over the three twisted pairs as an additional ground wire. The twisted pairs and shielded ground conductors terminate in a display connector, the shield being connected to the client's shield layer, and an insulating layer covering the entire cable, as is known in the art. The wires are paired in the following manner: host _ Gnd and Host _ Pwr; MDDI _ Stb + and MDDI _ Stb-; MDDI _ Data0+ and MDDI _ Data 0-; MDDI _ Data1+ and MDDI _ Data 1-; and so on. However, as is known in the art, various wires and cables may be used to implement embodiments of the present invention depending on the particular application. For example, in some applications, a heavy outer covering or metal layer may be used to contain the cable, while a thin, flat conductive tape-type structure may be well suited for other applications.

D. Data type and rate

To achieve a useful Interface for user experience and applications, a Mobile Digital Data Interface (MDDI) supports various clients and display information, audio transducers, keyboards, pointing devices, and various other input/output devices that may be integrated into or work in conjunction with a Mobile display device, as well as control information and combinations thereof. The MDD interface is designed to accommodate a variety of potential types of data streams that are transferred between the host and client in either the forward or reverse link directions using a minimum number of cables or wires. Both synchronous and asynchronous flows (updates) are supported. Many combinations of data types are possible as long as the aggregate data rate is less than or equal to the maximum expected MDDI link rate. This MDDI link rate is limited by the maximum serial rate and the number of data pairs employed. These data rates may include, but are not limited to, those listed in tables II and III below.

TABLE II

Transfer from host to client
			Synchronizing video data	720X 480, 12 bit, 30f/s	～124.5Mbps
Synchronizing stereo audio data	44.1kHz, 16 bit, stereo	～1.4Mbps
			Asynchronous graphics data	800 x 600, 12 bit, 10f/s, stereo	～115.2Mbps
Asynchronous control	Minimum value	＜＜1.0Mbps

TABLE III

Transfer from client to host
			Synchronizing voice data	8kHz, 8 bits	＜＜1.0Mbps
Synchronizing video data	640X 480, 12 bits, 24f/s	～88.5Mbps
			Asynchronous state, user input, etc	Minimum value	＜＜1.0Mbps

To meet the flexibility requirements of future systems, the interface is not fixed, but rather is extensible, so that it can support the transfer of various "types" of information, including user-defined data. Specific examples of data supported are: full motion video, video in the form of full screen or partial screen bitmap fields or compressed video; static bitmaps at low rates to save power and reduce implementation cost; PCM or compressed audio data at multiple resolutions or rates; pointing device location and selection, and user definable data for capabilities to be defined. Such data may also be communicated with control or status information to detect device capabilities or to set operating parameters.

Embodiments of the present invention present techniques for data transfer, including but not limited to: watching movies (video display and audio); using a personal computer with limited personal viewing (graphical displays, sometimes in combination with video and audio); playing a video game (sports graphics display or composite video and audio) on a PC, console or personal device; "surfing" (two-way low-rate video and audio) the internet using a device in the form of a video phone, still digital image camera, or camcorder for taking digital video images; using a projector-extended phone or PDA to present or to dock-extend a connection to a desktop docking station connected to a video monitor, keyboard, and mouse; and using a cellular phone, smart phone or PDA, including a wireless pointing device and keyboard data, to enhance productivity or for entertainment.

The high-speed data interface described below is provided in the form of a large volume of a-V type data provided via a communication or transport link, which is typically configured as a wire line or cable type link. It will be apparent, however, that the signal structure, protocol, timing, or transport mechanism may be adjusted to provide a link in the form of an optical or wireless medium, so long as the link can maintain a desired level of data transfer.

MDDI signals use a concept called Common Frame Rate (CFR) for the basic signal protocol or architecture. The idea behind the use of a common frame rate is to provide synchronization pulses for simultaneous synchronized data streams. The client device may use this common frame rate as a time reference. The low CF rate improves channel efficiency by reducing overhead for transmitting the sub-frame header. On the other hand, a high CF rate can reduce latency and allow a less flexible data buffer to be used for audio sampling. The CF rate of the interface of the present invention is dynamically programmable and can be set to one of a plurality of values suitable for a plurality of isochronous streams used in a particular application. That is, the CF values are selected to best suit a given client and host architecture, as needed.

The number of bytes typically required per sub-frame of the isochronous stream that is likely to be used in applications such as video or microdisplays, which is adjustable or programmable, is shown in table IV.

TABLE IV

Common Frame Rate (CFR) 300Hz
									X	Y	Bit	Frame rate	Channel	Rate (Mbps)	Byte/sub-frame
Computer game	720	480	24	30	1	248.832	103680
								Computer graphics	800	600	24	10	1	115.200	48000
Video	640	480	12	29.97 or 30	1	221.184	92160
								CD audio	1	1	16	44100	2	1.4112	588
Speech sound	1	1	8	8000	1	0.064	26-2/3

Fractional bytes per sub-frame can be easily calculated using a simple programmable M/N counter structure. For example, by transmitting 2 frames of 27 bytes, each time followed by a frame of 26 bytes, a count of each CF 26-2/3 byte can be achieved. A smaller CF rate may be selected to produce an integer number of bytes per subframe. However, in general, a simple M/N counter implemented in hardware requires less area in an integrated circuit chip or electronic module implementing some or all of the embodiments of the invention than would be required for a larger audio sample FIFO buffer.

An exemplary application illustrating the impact of different data transfer rates and data types is the karaoke system. For the karaoke system, the end user or end users sing along with the music video program. The lyrics of a song are displayed somewhere on the screen, usually at the bottom of the screen, so the user knows the words to sing and knows approximately the timing of the song. Such an application requires a video display that is not updated frequently with graphics and mixes one or more user voices with the stereo audio stream.

If the common frame rate employed is 300Hz, each sub-frame will include: 92,160 bytes of video content and 588 bytes of audio content (based on 14716-bit samples in stereo) over the forward link to the client display device, and an average of 26.67(26-2/3) bytes of speech fed back from the microphone to the mobile karaoke machine. Asynchronous packets are sent between the host and the display (possibly head-mounted). This includes a maximum of 768 bytes of graphics data (quarter screen height), and less than about 200 bytes (a few bytes) for a wide variety of control and status commands.

Table V shows how data is allocated within a subframe for the karaoke example. The total rate to be used is chosen to be about 279 Mbps. Rates slightly above 280Mbps allow approximately another 400 bytes of data to be transmitted per sub-frame, thus allowing the use of sporadic control and status information.

TABLE V

Rate of element	Overhead bytes per subframe	Media bytes per subframe
			Music video of 640 x 480 pixels, 30fps	2*28＝56	92160
640 x 120 pixels, 1fps lyrics text 10 sub-frames updated, 1/30 seconds	28	768
			44,100sps, stereo, 16-bit CD audio	2*16＝32	588
8,000sps, mono, 8-bit speech	28+8+8+(4*16)+(3*27)＝125	26.67
			Sub-frame header	22
Total bytes/CF	263	115815
			Total Rate (Mbps)	(263+115815)*8*300＝278.5872

High rate digital data interface system architecture (continue)

E. Link layer

Data transmitted using the MDD interface high speed serial data signal comprises a stream of time multiplexed packets, wherein the packets are linked one after the other. MDDI link controllers typically automatically send filler packets even if the transmitting device has no data to send, thereby maintaining the packet flow. Thus, the use of a simple packet structure can ensure reliable synchronous timing of video and audio signals or data streams.

Groups of groups are included in signal elements (signal elements) or structures called subframes, whereas groups of subframes are included in signal elements or structures called media frames. Depending on the respective size of the sub-frames and the data transfer purpose, the sub-frames contain one or more packets, while the media frames contain one or more sub-frames. The protocol employed by the embodiments presented herein provides a maximum subframe of approximately 2³²On the order of 1 or 4,294,967,295 bytes, while the size of the largest media frame is about 2¹⁶On the order of 1 or 65,535 subframes.

A special sub-frame header packet contains a unique identifier that appears at the beginning of each sub-frame, as will be discussed below. This identifier is also used to obtain frame timing at the client device when initiating communication between the host and client. The acquisition of link timing is discussed in more detail below.

Typically, the display screen is updated once per media frame as full motion video is displayed. The display frame rate is the same as the media frame rate. Depending on the desired application, the link protocol supports full motion video on the entire display, or only a small area of full motion video content surrounded by still images. In some low power mobile applications, such as viewing web pages or e-mail, the display screen only needs to be updated occasionally. In these cases, it is beneficial to transmit a single subframe and then shut down the link or drop the link in order to minimize power consumption. The interface also supports effects such as stereoscopic vision and processes graphics primitives.

The sub-frames enable the system to periodically transmit high priority packets. This enables simultaneous isochronous streams to coexist with a minimal amount of data buffering. This is an advantageous embodiment provided to the display process which allows multiple data streams (high speed communication of video, voice, control, status, pointing device data, etc.) to share substantially a common channel. The interface uses a relatively small number of signals to convey information. The interface also allows for display technology specific actions such as horizontal synchronization pulses and blanking intervals (blanking intervals) for CRT monitors, or other client-technology specific actions.

F. Link controller

The MDDI link controllers shown in fig. 4 and 5 would be manufactured or assembled in a fully digital implementation without the differential line receivers used to receive MDDI data and strobe signals. However, the differential line driver and receiver may even be implemented in the same digital integrated circuit together with the link controller, for example when making a CMOS type IC. No analog function or Phase Locked Loop (PLL) is required for bit recovery or to implement the hardware of the link controller. The host and client link controllers contain very similar functionality, except for the client interface, which contains a state machine for link synchronization. Thus, embodiments of the present invention allow a single controller design or circuit to be created and configured as either a host or a client, which is advantageous for practical applications and, in general, reduces the manufacturing cost of the link controller.

Interface Link protocol

A. Frame structure

The signal protocol or frame structure for forward link communications to implement packet transfer is shown in fig. 6. As shown in fig. 6, information or digital data is combined into elements (elements) known as packets. In turn, multiple packets are combined together to form what is known as a "subframe", and multiple subframes are combined together to form a "media" frame. To control the formation of frames and the transmission of subframes, each subframe begins with a special predetermined packet called a Subframe Header Packet (SHP).

The host device selects a data rate to be used for a given transfer. The host device may dynamically change this rate based on the maximum transfer capability of the host, the data retrieved (retrieve) by the host from the information source, and the maximum capability of the client or other device to which the data is to be transferred.

A recipient client device designed to either work in conjunction with MDDI or the signaling protocol of the present invention can be queried by the host to determine the maximum or current maximum data transfer rate that can be used by the client, or a default slower minimum rate that can be used, as well as the available data types and supported features. This information may be communicated using a Display Capability Packet (DCP), as will be discussed further below. The client display device is able to use the interface to transfer data or communicate with other devices at a preselected minimum data rate or within a range of minimum data rates, and the host will perform a query using the data rates within this range to determine the full capabilities of the client device.

Other status information defining bitmap attributes and the client's video frame rate capability may be communicated to the host in status packets so that the host can configure the interface as efficiently or optimally as practical or desired within any system limitations.

When there are no (more) packets to be transmitted in this subframe, or when the host cannot transmit at a rate sufficient to keep up with the (keep pace) forward link selected data transmission rate, the host sends a filler packet. Since each sub-frame starts with a sub-frame header packet, the end of the previous sub-frame contains a packet (most likely a filler packet) that just fills the previous sub-frame. In the case where the data-carrying packet itself lacks space, the filler packet is likely to be the last packet in a subframe, or at the end of the immediately preceding (next previous) subframe and before the subframe header packet. In the host device, the task of controlling the operation is to ensure that there is enough space left in the sub-frame for each packet to be transmitted within the sub-frame. Also, once the host device begins sending data packets, the host must be able to successfully complete packets of that size within a frame without causing a data underrun (under-run) condition.

In one aspect of the embodiment, the subframe transmission has two modes. One mode is a periodic subframe mode, or periodic timing epochs, for transmitting live video and audio streams. In this mode, the subframe length is defined to be non-zero. The second mode is an asynchronous or aperiodic mode in which frames are used to provide bitmap data to a client when there is new information. This pattern is defined by setting the subframe length to zero in the subframe header packet. When a periodic pattern is used, the sub-frame packet reception can begin when the client synchronizes to the forward link frame structure. This corresponds to the state of "in sync" (in sync) as defined by the state diagram discussed below with respect to FIG. 49 or FIG. 63. In asynchronous aperiodic subframe mode, reception begins after the reception of the first subframe header packet.

B. Overall packet structure

The following describes the packet format or structure of the methods and means for specifying a communication or signaling protocol or communicating data implemented by the embodiments, bearing in mind that the interface is extensible and that additional packet structures may be added as needed. The packets are marked or classified into different "packet types" in terms of their function in the interface, i.e. the commands, information, values or data they carry or are associated with. Thus, for a given packet used to manipulate the transmitted packet and data, each packet type represents a predefined packet structure. It is obvious that the packets may have a pre-selected length or a variable or dynamically variable length according to the respective function. The packets may also have different names, although the same functionality is still implemented, as occurs when a protocol changes during the process of accepting the protocol into the standard. The bytes or byte values for the various packets are configured as multi-bit (8 or 16 bit) unsigned integers. The packet summaries employed, as well as their "type" designations, are listed in type order and are shown in tables VI-1 through VI-4.

For ease of illustration and understanding, each table gives a general "type" packet within the overall packet structure. These groupings do not imply or represent certain limitations or other impacts to the present invention and may be organized in a number of other ways as desired. The direction in which packet transfer is considered valid is also indicated.

TABLE VI-1

Link control packet

Packet name	Packet type	Positive direction effective	Effective in the reverse direction
				Sub-frame header grouping	15359	x
Filler grouping	0	x	x
				Reverse link encapsulation packet	65	x
Link shutdown packet	69	x
				Interface type switch request packet	75	x
Interface type acknowledgement packet	76		x
				Performing type switch packets	77	x
Round trip delay measurement packet	82	x
				Forward link offset calibration packets	83	x

TABLE VI-2

Elementary media stream packets

Packet name	Packet type	Positive direction effective	Effective in the reverse direction
				Video stream packets	16	x	x
Audio stream packet	32	x	x
				Reserved stream packets	1-15，18-31，33-35	x	x
User-defined stream packets	56-63	x	x
				Color mapping grouping	64	x	x
Forward audio channel enable packet	78	x
				Inverse audio sample rate grouping	79	x
Transparent color enable grouping	81	x

TABLE VI-3

Client state and control packets

Packet name	Packet type	Positive direction effective	Effective in the reverse direction
				Client capability grouping	66		x
Keyboard data grouping	67	x	x
				Pointing device data packets	68	x	x
Client request and status grouping	70		x
				Digital content protection overhead packets	80	x	x
Requesting VCP feature packets	128	x
				VCP feature acknowledgement packet	129		x
Setting VCP feature groupings	130	x
				Request valid parameter grouping	131	x
Efficient parameter response packet	132		x
				Request specific status packets	138	x
Active state acknowledgement list grouping	139		x

Packet processing delay parameter packet	140		x
				Personal display capability grouping	141		x
Client error reporting packet	142		x
				Scalable video stream capability grouping	143		x
Display identification grouping	144		x
				Selectable display capability grouping	145		x
Register access packet	146	x	x

TABLE VI-4

Advanced graphics and display grouping

Packet name	Packet type	Positive direction effective	Effective in the reverse direction
				Bit block transport packet	71	x
Bitmap area fill packet	72	x
				Bitmap mapPattern filling grouping	73	x
Read frame buffer grouping	74	x
				Scalable video stream capability grouping	143		x
Scalable video stream setup packets	136	x
				Scalable video stream acknowledgement packet	137		x
Scalable video stream packet	18	x

As will be apparent from other discussions herein, reverse encapsulation packets, client capability packets, and client request and status packets may be considered optional for internal mode operation, although they are considered important for external mode operation, even as required in many embodiments of the communication interface. Doing so creates another type of MDD interface protocol that allows data to be communicated at very high speeds with a reduced set of communication packets, and that simplifies control and timing accordingly.

The packet has a common basic structure or overall set of minimum fields including a packet length field, a packet type field, a data byte field, and a CRC field, which are shown in fig. 7. As shown in fig. 7, the packet length field contains information in the form of a multi-bit or byte value for specifying the total number of bits of the packet or specifying the length between the packet length field and the CRC field. In one embodiment, the packet length field contains an unsigned integer that is 16 bits or 2 bytes wide, which specifies the packet length. The packet type field is another multi-bit field that indicates the type of information contained within the packet. In an exemplary embodiment, the packet type field is a 16-bit or 2-byte wide value in the form of a 16-bit unsigned integer, and specifies these data types as display capabilities, switching, video or audio streams, status, and the like.

The third field is a data byte field that contains bits or data that are transferred or sent as part of the packet between the host and client devices. The data format is specifically defined for each packet type according to the specific type of data being transmitted, and the packet format may be partitioned into a series of additional fields, each with its own format requirements. That is, each packet type will have a defined format for this portion or field. The last field is the CRC field, which contains the result of the 16-bit cyclic redundancy check calculated over the data byte, packet type and packet length fields, which is used to confirm the integrity of the information in the packet. In other words, the result is calculated over the entire packet except for the CRC field itself. The client typically keeps a total count of detected CRC errors and reports this count to the host in client request and status packets (see below).

Typically, these field widths and organization structures are designed to align 2-byte fields on even byte boundaries and 4-byte fields on 4-byte boundaries. This allows the packet structure to be easily embedded in, or associated with, the host and client main memory spaces without violating data type alignment rules encountered in most or commonly used processors or control circuits.

During the transmission of the packet, the field is transmitted first starting with the Least Significant Bit (LSB) and finally ending with the transmission of the Most Significant Bit (MSB). More than one byte length parameter is transmitted the least significant byte first, so that the resulting bit transmission pattern for transmitting parameters with a length greater than 8 bits is the same bit transmission pattern used for transmitting the shorter parameter of the LSB first. The data fields of each packet are typically transmitted in the order defined in the subsequent paragraphs below, with the first field listed being transmitted first and the last described field being transmitted last. In any of the type 1, type 2, type 3, or type 4 modes, the Data on the MDDI _ Data0 signal path is aligned with the '0' bit of the byte being transferred on the interface.

When manipulating data for display, the data for the pixel array is first transferred by rows and then columns, as is conventionally performed in the electronics art. In other words, all pixels appearing in the same row in the bitmap are transferred in order, with the leftmost pixel being transferred first and the rightmost pixel being transferred last. After the rightmost pixel in a row has been transferred, then the next pixel in the order is the leftmost pixel in the next row. For most displays, rows of pixels are typically transmitted in a top-down order, but other configurations may be used as desired. Furthermore, in processing the bitmap, the conventional approach, i.e., the approach followed herein, is to define a reference point by marking the upper left corner of the bitmap as a position or offset "0, 0". The values of the X and Y coordinates used to define or determine the position in the bitmap increase as one approaches the right side and bottom of the bitmap, respectively. The first row and column (top left corner of the image) starts with the index value zero. The value of the X coordinate increases towards the right side of the image and the value of the Y coordinate increases towards the bottom of the image when viewed from the display user.

The display window is the visible part of the bitmap, i.e. the part of the pixels in the bitmap that the user can see on the physical display medium. The display window and bitmap are often the same size. The upper left corner of the display window always displays the bit pixel position 0, 0. The width of the display window corresponds to the X-axis of the bitmap and the display window width is less than or equal to the width of the corresponding bitmap. The height of the window corresponds to the Y-axis of the bitmap and the display window height is less than or equal to the height of the corresponding bitmap. The display window itself is not involved in the protocol because it is defined as the visible part of the bitmap only.

The relationship between bitmaps and display windows is well known in the computer, electronic, internet communications and other electronic related arts. And therefore no further discussion or illustration of these principles is given here.

C. Group definition

1. Sub-frame header grouping

The sub-frame header packet is the first packet of each sub-frame and has a basic structure as shown in fig. 8. The sub-frame header packet is used for host-client synchronization, each host should be able to generate this packet, while each client should be able to receive and interpret this packet. As can be seen in fig. 8, this type of packet is typically constructed with packet length, packet type, unique word, reserved 1, subframe length, protocol version, subframe count and media frame count fields in order. In one embodiment, this type of packet is typically identified as a type 15359 (0 x3bff hex) packet and uses a preselected fixed length of 20 bytes, excluding the packet length field.

The packet type field and the unique word field both use 2 byte values (16 bit unsigned integers). Combining the 4 bytes of the two fields together forms a 32-bit unique word with good autocorrelation. In one embodiment, the actual unique word is 0x005a3bff, where the lower 16 bits are transmitted first as a packet type and then the highest 16 bits.

The reserved 1 field contains 2 bytes of reserved space for future use and is generally configured here to set all bits to zero. One purpose of this field is to align the subsequent 2-byte field with a 16-bit word address and to align the 4-byte field with a 32-bit word address. The least significant byte is reserved to indicate whether the host has access to multiple client devices. This byte is reserved as a zero value to indicate that this host can only work with a single client device.

The subframe length field contains 4 bytes of information or value to indicate the number of bytes per subframe. In one embodiment, the length of this field may be set equal to zero to indicate that the host will only transmit one subframe before the link is shut down to enter the idle state. The value in this field may change dynamically "during operation (on-the-fly") when transitioning from one sub-frame to the next. This capability is useful for small timing adjustments in the synchronization pulses to support synchronous data flow. If the CRC of the sub-frame header packet is not valid, the link controller should estimate the length of the current sub-frame using the sub-frame length of the previous sub-frame header packet, which is known to be good.

The protocol version field contains 2 bytes to specify the version of the protocol used by the host. Setting the protocol version field to '0' indicates the first or current version of the protocol being used. This value will change over time when a new version is created, and the field has been updated to a value of 1 for some versions. As is well known, the version value is likely or generally compliant with the current version number of approved standard documents, including, for example, MDDI interfaces.

The subframe count field contains 2 bytes indicating a sequence number indicating the sequence number of the number of subframes that have been transmitted since the beginning of the media frame. The subframe count of the first subframe of the media frame is zero. The last subframe of the media frame has a value of n-1, where n is the number of subframes per media frame. The value of the subframe count field is equal to the subframe count transmitted in the previous subframe packet plus 1. It should be noted that if the subframe length is set equal to zero (indicating an aperiodic subframe), the subframe count must also be set equal to zero.

The media frame count field contains 4 bytes (a 32-bit unsigned integer) to specify a sequence number indicating the number of media frames that have been transmitted since the beginning of the current media item or data being transmitted. The media frame count of the first media frame of the media item is zero. The media frame count is incremented just prior to the first sub-frame of each media frame and when the maximum media frame count (e.g., media frame number 2) is used ³²-1 ═ 4,294,967,295) and then returns to zero. The media frame count value is typically readily resettable by the host to accommodate the requirements of the end application.

2. Filler grouping

A filler packet is a packet that has no other information available to be transmitted to or from a client device when sent on the forward or reverse link. It is recommended that the filler packets have a minimum length to allow maximum flexibility in sending other packets when needed. At the end of a subframe or reverse link encapsulation packet (see below), the link controller sets the size of the filler packet to fill the remaining space, thereby preserving the integrity of the packet. The filler packets are useful for maintaining timing on the link when the host or client has no information to send or exchange. Each host and client should be able to send and receive this packet in order to use the interface efficiently.

An exemplary embodiment of the format and content of the filler packets is shown in fig. 9. This type of packet is constructed to have a packet length, a packet type, padding bytes, and a CRC field, as shown in fig. 9. In one embodiment, this type of packet is typically identified as type 0, which is indicated in the 2-byte type field. The bits or bytes in the padding byte field comprise a variable number of all-zero bit values to allow the padding packet to have a desired length. The minimum padding packet contains no bytes in this field. That is, the packet includes only a packet length, packet type, and CRC, and in one embodiment, a preselected fixed length of 6 bytes or a packet length value of 4 is used. The CRC value is determined for all bytes in the packet, including the packet length, but is excluded in other packet types.

3. Video packet

Video stream packets typically carry video data to update a generally rectangular area of a display device. The size of this area may be as small as a single pixel or as large as the entire display. There can be an almost unlimited number of streams being displayed simultaneously, but it is limited by system resources because all the context required to display one stream is contained within the video stream packet. The format of one embodiment of a video stream packet (video data format descriptor) is shown in fig. 10. As shown in FIG. 10, in one embodiment, this type of packet is constructed to have packet length (2 bytes), packet type, bClient ID, video data descriptor, pixel display attributes, X left edge, Y top edge, X right edge, Y bottom edge, X and Y start, pixel count, parameter CRC, pixel data, and CRC fields. This type of packet is typically identified as type 16, which is indicated in the 2 byte type field. In one embodiment, the client uses the RGB, monochrome, and Y Cr Cb capability fields in the client capability packet to indicate the capability to receive video stream packets.

In one embodiment, the bClient ID field contains 2 bytes of information reserved for the client ID. Since this is the most recently developed communication protocol, the actual client ID is still not known or sufficiently communicated. Thus, the bit in this field is typically set equal to zero until the ID value is known, which can be inserted or used when or for this ID, as will be apparent to those skilled in the art. The same is typically performed for the client ID field discussed below.

The common frame concept described above is an effective way to minimize the audio buffer size and reduce latency. However, for video data, it may be necessary to extend the pixels of one video frame to multiple video stream packets within a media frame. It is also possible that the pixels in a single video stream packet do not correspond exactly to a complete rectangular window on the display. For an exemplary video frame rate of 30 frames per second, there are 300 subframes per second, which results in 10 subframes per media frame. If there are 480 lines of pixels in each frame, each video stream packet in each sub-frame will include 48 lines of pixels. In other cases, a video stream packet may not contain an integer number of pixel rows. This is true for other video frame sizes where the number of sub-frames per media frame cannot be equally divided by the number of lines per video frame (also called video lines). For efficient operation, each video stream packet must typically contain an integer number of pixels, even though it does not necessarily contain an integer number of pixel rows. This is important if each pixel is larger than one byte, or if they have a packet format as shown in fig. 12.

The format and content employed for implementing the exemplary video data descriptor field operations described above are illustrated in fig. 11A-11E. In fig. 11A-11E, the video data format descriptor field contains 2 bytes in the form of a 16-bit unsigned integer to illustrate the format of each pixel within the pixel data in the current stream of the current packet. Different video stream packets may use different pixel data formats, i.e. different values in the video data format descriptor, and likewise the stream (display area) may change its data format during operation (on-the-fly). The pixel data format should conform to at least one client valid format packet defined in terms of a client capability packet. The video data format descriptor defines the pixel format of the current packet only if the unchanged format is no longer used for as long as the pixel format of the current packet is implied by the lifetime of the particular video stream.

Fig. 11A to 11D illustrate how the video data format descriptor is encoded. As used in these figures, and in this embodiment, when bits [15:13] are equal to '000', as shown in fig. 11A, then the video packet includes an array of monochrome pixels, where the number of bits per pixel is defined by bits 3 through 0 of the video data format descriptor word. Bits 11 through 4 are typically reserved for future use or for other applications and are set to zero in this case. When bits [15:13] are changed to equal the value '001', as shown in FIG. 11B, then the video packet includes an array of color pixels, each of which is assigned a color by a color map (palette). In this case, bits 5 to 0 of the video data format descriptor word define the number of bits per pixel, and bits 11 to 6 are typically reserved for future use or application, and these bits are set equal to zero. When bits [15:13] are changed to equal the value '010', as shown in FIG. 11C, then the video packet includes an array of color pixels, where the number of bits per pixel red is defined by bits 11 through 8, the number of bits per pixel green is defined by bits 7 through 4, and the number of bits per pixel blue is defined by bits 3 through 0. In this case, the total number of bits in each pixel is the sum of the bits used for red, green and blue.

However, when bits [15:13] are converted to equal the value or string '011', as shown in FIG. 11D, then the video packet includes an array of video data with luminance and chrominance information in the YCbCr format of 4:2:2, where the number of bits per pixel luminance (Y) is defined by bits 11 through 8, the number of bits for the Cb component is defined by bits 7 through 4, and the number of bits for the Cr component is defined by bits 3 through 0. The total number of bits in each pixel is the sum of the number of bits used for red, green and blue. The Cb and Cr components are sent at half the rate of the Y component. In addition, the video samples in the pixel data portion of this packet are organized as: cbn, Yn, Crn, Yn +1, Cbn +2, Yn +2, Crn +2, Yn +3, wherein Cbn and Crn are associated with Yn and Yn +1, and Cbn +2 and Crn +2 are associated with Yn +2 and Yn +3, and so on.

Yn, Yn +1, Yn +2, and Yn +3 are luminance values of four consecutive pixels from left to right in a single line. If there are an odd number of pixels in a row of the window in which the video stream packet is located (X right edge-X left edge +1), then the Y value corresponding to the last pixel in each row will be followed by the Cb value of the first pixel of the next row and the Cr value of the last pixel in that row will not be sent. It is proposed that the window using the Y Cb Cr format has a width of an even number of pixels. The pixel data in the packet should contain an even number of pixels. Where the last pixel of the pixel data corresponds to the last pixel of a line in the window specified in the video stream packet header, i.e., when the X position of the last pixel in the pixel data is equal to the X right edge, the pixel data may contain an odd or even number of pixels.

When bits [15:13] are substituted to equal '100', then the video packet includes an array of spaced (Bayer) pixels, where the number of bits per pixel is defined by bits 3 through 0 of the video data format descriptor word. The pixel group pattern is defined by bits 5 and 4 as shown in FIG. 11E. The order of the pixel data may be horizontal or vertical, and pixels in a row or column may be sent in forward or backward order and defined by bits 8 through 6. Bits 11 to 9 should be set to zero. The group of four pixels within a pixel group in a spaced (Bayer) format is similar to what is often referred to as a delayed pixel in some display technologies. However, one pixel in the space (Bayer) format is only one of the four color pixels in the mosaic (mosaic) pattern.

For all five formats shown in the figure, bit 12, designated "P", indicates whether the pixel data sample is packed pixel data or byte-aligned pixel data. A value of '0' in this field indicates that each pixel in the pixel data field is byte aligned with the MDD interface byte boundary. A value of '1' indicates that each pixel and each color within each pixel in the pixel data is packed such that there are no unused bits with respect to the previous pixel or color within the pixel. Fig. 12 shows the difference between the byte-aligned pixel format and the packed pixel data format in more detail, where it can be clearly seen that the byte-aligned data leaves unused portions of the data sub-frame, as opposed to the case where unused portions are left in the packed pixel format.

The first pixel in the first video stream packet of the media frame for a particular display window would go into the upper left corner of the stream window defined by the X left edge and the Y top edge, with the next pixel received placed at the next pixel location in the same row, and so on. In this first packet of media frames, the X start value is generally equal to the X left edge, and the Y start value is generally equal to the Y top edge. In subsequent packets corresponding to the same screen window, the X and Y start values are typically set to the position of the pixel in the screen window, which pixel position typically follows the last pixel sent in the video stream packet transmitted in the previous sub-frame.

4. Audio stream packet

The audio stream packets carry audio data to be played through the client audio system or for a separate audio rendering device. Different audio data streams may be assigned to separate audio channels in the sound system, for example: left front, right front, center, left back, and right back, depending on the type of audio system being used. The full audio channel is provided for headphones that incorporate enhanced spatial acoustic signal processing. The client uses the audio channel capability and audio sample rate fields of the client capability packet to indicate the capability to receive audio stream packets. The format of the audio stream packets is illustrated in fig. 13.

As shown in fig. 13, this type of packet is constructed in one embodiment with packet length, packet type, bClient ID, audio channel ID, reserved 1, audio sample count, bits per sample and its packing, audio sample rate, parameter CRC, digital audio data, and audio data CRC fields. In one embodiment, this type of packet is generally identified as a type 32 packet.

The bClient ID field contains 2 bytes of information reserved for the client ID, as previously used. The reserved 1 field contains 2 bytes that are reserved for future use and is configured here to set all bits to zero.

The bits of each sample and its packing field contain 1 byte in the form of an 8-bit unsigned integer to illustrate the packing format of the audio data. The commonly employed format is to define the number of bits per PCM audio sample using bits 4 to 0. Bit 5 then indicates whether the digital audio data samples are packed. The difference between the packed audio samples and the byte aligned audio samples is shown in fig. 14, where 10-bit samples are used. A value of '0' indicates that each PCM audio sample in the digital audio data field is byte aligned with an MDDI interface byte boundary, and a value of '1' indicates that each successive PCM audio sample is packed relative to the previous audio sample. This bit is usually valid only if the value defined by bits 4 to 0 (the number of bits per PCM audio sample) is not a multiple of 8. Bits 7 through 6 are reserved for future use and are typically set to zero.

5. Reserved stream packets

In one embodiment, packet types 1 through 15, 18 through 31, and 33 through 55 are reserved flow packets to be defined for future versions or packet protocol changes, depending on the requirements of the various applications encountered. This is part of making MDD interfaces more flexible and still very useful in the face of ever changing technologies and system designs, compared to other technologies.

6. User-defined stream packets

The 8 data stream types, referred to as types 56 to 63, which may be defined by the device manufacturer for use with the MDDI link, are reserved for proprietary applications. These packets are referred to as user-defined stream packets. Such packets may be used for any purpose, but the host and client should only employ such packets if the results of such use are well understood or known. The specific definition of flow parameters and data for these packet types is left to the specific device manufacturer that implements such packet types or seeks its purpose. Some exemplary uses of the user-defined stream packets are to communicate test parameters and test results, factory calibration data, and proprietary special data. The format of a user-defined stream packet for one embodiment is shown in FIG. 15. As shown in fig. 15, this type of packet is constructed to have packet length (2 bytes), packet type, bClient ID number, stream parameter, parameter CRC, stream data, and stream data CRC fields.

7. Color mapping grouping

The color mapping packet illustrates the contents of a color mapping look-up table used to present colors to the client. Some applications may require a greater amount of color mapping than a single packet can transfer. In this case, multiple color map groupings, each having a different subset of color maps, may be transmitted using the offset and length fields as described below. FIG. 16 illustrates a format of a color map packet in one embodiment. As shown in fig. 16, this type of packet is constructed to have packet length, packet type, hClient ID, color map entry count, color map offset, parameter CRC, color map data, and data CRC fields. In one embodiment, this type of packet is typically identified as a type 64 packet (video data format and color map packet), as illustrated in the packet type field (2 bytes). The client uses the color map size and color map width fields in the client capability packet to indicate the capability to receive the color map packet.

8. Reverse link encapsulation packet

In one exemplary embodiment, data is transmitted in the reverse direction using reverse link encapsulation packets. A forward link packet is sent and the MDDI link operation is changed or diverted (in the transmit direction) approximately in the middle of the packet so that the packet can be sent in the reverse direction. Fig. 17 illustrates the format of a reverse link encapsulated packet in one embodiment. As shown in fig. 17, this type of packet is constructed to have a packet length, a packet type, an hCLient ID, a reverse link flag, a reverse rate divisor, a Turn-Around 1 length, a Turn-Around 2 length, a parameter CRC, all zeros 1, a Turn-Around 1, a reverse data packet, a Turn-Around 2, and all zeros 2. In one embodiment, this type of packet is generally identified as a type 65 packet. For external mode, each host must be able to generate this packet and receive data, and each client must be able to receive and send data to the host. This packet implementation is optional for internal mode, but the reverse link encapsulates the packet for the host to receive data from the client.

The MDDI link controller operates in a particular manner when transmitting reverse link encapsulated packets. The MDD interface has a strobe signal that is always driven by the host as a link controller. The host behaves as if it were transmitting zeros for each bit of the diverted and reverse data packet portions of the reverse link encapsulation packet. The host toggles (toggle) the MDDI strobe signal at the boundary of each bit during both turns and during the period assigned to the reverse data packet. That is, the host flips MDDI _ Stb starting from all zero 1 fields and ending at all zero 2 fields. (this is the same behavior as transmitting all zero data.)

The host disables its MDDI data signal line drivers and typically ensures that they are fully disabled before going to the last bit of the 1 field, then re-enables its line drivers during the 2 field and typically ensures that they are fully enabled before going to the last bit of the 2 field. The client reads the turnaround length parameter and drives a data signal to the host immediately after the last bit of the turnaround 1 field. That is, at some rising edge of the MDDI strobe, the client clocks new data into the (clock into) link, as explained below and elsewhere in the description of the packet contents. The client uses the packet length and turn length parameters to know the length of time it can use to send packets to the host. When there is no data to send to the host, the client may send a filler packet or drive the data lines to a zero state. If the data line is driven to zero, the host interprets it as a packet having a length of zero (not one active length) and during the current reverse link encapsulation packet, the host no longer receives any packets from the client.

In one embodiment, the reverse link request field of the client request and status packet may be utilized to inform the host of the number of bytes the client needs to send data back to the host in the reverse link encapsulation packet. The host attempts to grant the request by allocating at least the number of bytes in the reverse link encapsulation packet. The host may send more than one reverse link encapsulated packet in a subframe. The client can send client request and status packets almost anytime, the host will interpret the reverse link request parameter as the total number of bytes requested in one sub-frame.

9. Client capability grouping

The host must know the capabilities of the client (display) with which it communicates in order to configure the host-to-client link in a generally optimal or desirable manner. It is proposed that the display sends the client capability packet to the host after acquiring the forward link synchronization. The transmission of reverse link encapsulation packets should be considered when requested by the host using the reverse link flag in such packets. The client capability packet is used to inform the host of the capabilities of the client. For external mode, each host must be able to receive this packet, and each client must be able to send this packet in order to fully utilize this interface and protocol. The implementation of this grouping is optional for the internal mode, since in this case the capabilities of the client, such as the display, keyboard or other input/output device, should have been well defined and known to the host at the time of manufacture or when assembled into certain types of individual components or units.

The format of the client capability packet in one embodiment is shown in fig. 18. As shown in fig. 18, for the present embodiment, this type of packet is structured to have a packet length, a packet type, a reserved clclient ID, a protocol version, a minimum protocol version, a data rate capability, an interface type capability, an optional number of displays, a reserved 1, a bitmap width, a bitmap height, a display window width, a display window height, a color map size, a color map RGB width, an RGB capability, a monochrome capability, a reserved 2, Y Cr Cb capability, a granularity (Bayer) capability, an alpha cursor image plane, a client feature capability, a maximum video frame rate, a minimum sub-frame rate, an audio buffer depth, an audio channel capability, an audio adoption rate capability, an audio sampling resolution, a microphone audio sampling rate capability, a microphone sampling rate capability, a keyboard data format, a pointing device data format, a content protection type, manufacturer name, product code, reserved 3, serial number, week of manufacture, year of manufacture, and CRC field. In one exemplary embodiment, this type of packet is generally identified as a type 66 packet.

10. Keyboard data grouping

The keyboard data packet is used to transmit keyboard data from the client device to the host. A wireless (or wired) keyboard may be used in conjunction with various display or audio devices, including but not limited to a headband video display/audio presentation device. The keyboard data packet relays keyboard data received from several known keyboard-like devices to the host. This packet may also be used on the forward link to send data to the keyboard. The client uses the keyboard data field in the client capability packet to indicate the capability to send and receive keyboard data packets.

The format of the keyboard data packet is shown in fig. 19 and contains information from or for a variable number of bytes of the keyboard. This type of packet is constructed to have a packet length, a packet type, a bClient ID, a keyboard data format, keyboard data, and a CRC field, as shown in fig. 19. This type of packet is generally identified herein as a type 67 packet.

The bClient ID is a reserved field, as previously described, and performs a CRC on all bytes of the packet. The keyboard data format field contains a 2-byte value that is used to describe the keyboard data format. Bits 6 through 0 should be the same as the keyboard data format field in the client capability packet. This value is not equal to 127. Bits 15 to 7 are reserved for future use and are therefore currently set to zero.

11. Pointing device data packets

The pointing device data packet serves as a method, structure or means for transmitting location information from a wireless mouse or other pointing device from a client to a host. This packet may also be used to transmit data to the pointing device on the forward link. An exemplary format of a pointing device data packet is shown in fig. 20, and the packet format contains information from or for a variable number of bytes of the pointing device. As shown in fig. 20, this type of packet is constructed to have a packet length, a packet type, a bClient ID, a pointing device format, pointing device data, and a CRC field. In one exemplary embodiment, this type of packet is identified as a type 68 packet, typically in a 1-byte type field.

12. Link shutdown packet

A link down packet is sent from the host to the client as a method and means to indicate that MDDI data and strobes are to be turned off and enter a low power "sleep" state. This packet is useful to close the link and save power after the static bitmap is sent from the mobile communication device to the display, or when there is temporarily no further information to transfer from the host to the client. When the host sends the packet again, normal operation resumes. The first packet sent after sleep is a subframe header packet. The format of the client state packet is shown in fig. 21. This type of packet is constructed with a packet length, a packet type and CRC and all zero fields as shown in fig. 21. In one embodiment, this type of packet is identified as a type 69 packet, typically in a 1 byte type field, and a preselected fixed length of 3 bytes is used.

The packet length field specifies the number of bytes in the packet excluding the packet length field by 2 bytes. In one embodiment, the packet length of the packet is dependent on the type of interface or link mode that was active when the link shutdown packet was sent. Thus, typical packet lengths are as follows: for type 1 mode, 20 bytes (22 bytes total in a packet); 36 bytes for type 2 mode (38 bytes total in the packet); for type 3 mode, 68 bytes (70 bytes total in the packet); for type 4 mode, 132 bytes (134 bytes total in the packet).

The all-zero field uses a variable number of bytes to ensure that MDDI _ Data is at a logic zero level long enough for the client to start recovering the clock using only MDDI _ Stb before disabling the host line driver. The length of the all-zero field depends on the type of interface or link mode that is active when the link shutdown packet is sent. The length of the all-zero field is intended to produce 64 pulses on the MDDI _ Stb for any interface type setting. Thus, the all zero fields for the various interface types are as follows: for type 1, 16 bytes; for type 2, 32 bytes; 64 bytes for type 3; for type 4, 128 bytes.

The CRC field uses 2 bytes, which contains a 16-bit CRC of bytes from the packet length to the packet type.

In the low power sleep state, the MDDI _ Data0 driver is disabled to a high impedance state starting after the 16 th to 48 th MDDI _ Stb cycle or pulse after the last bit of the all-zero field. For type 2, type 3, or type 4 links, the MDDI _ Data 1-MDDI _ DataPwr7 signals are also placed in a high impedance state while the MDDI _ Data0 driver is disabled. As discussed elsewhere, it is a key advance and advantage of the present invention that either the host or the client can "wake up" the MDDI link from a dormant state.

As already described in the definition of the all-zero field, MDDI _ Stb rolls over 64 cycles after the MSB of the CRC field of the link shutdown packet in order to shut down the client controller in time. One cycle is a low to high transition followed by a high to low transition, or a high to low transition followed by a low to high transition. After sending the all-zero field, the MDDI _ Stb driver in the host is disabled.

13. Client request and status grouping

The host needs a small amount of information from the client so that it can configure the host-to-client link in an overall optimal manner. The client is proposed to send one client state packet per sub-frame to the host. The client should send this packet as the first packet in the reverse link encapsulation packet to ensure that the packet is reliably sent to the host. Forwarding of the packet may also be accomplished when the packet is requested by the host using the reverse link flag in the reverse link encapsulation packet. The client request and status packets may be used to report errors and status to the host. For external mode operation, each host should be able to receive the packet and each client should be able to send the packet in order to properly and optimally use the MDD interface protocol. It is also proposed that: for internal operations, i.e., internal host and internal client, the packet should be supported, but this is not required.

The format of the client request and status packet is shown in fig. 22. As shown in fig. 22, this type of packet is constructed with a packet length, a packet type, a clclient ID, a reverse link request, a capability change, a client busy, a CRC error count, and a CRC field. In the 1-byte type field, this type of packet is typically identified as a type 70 packet, and a preselected fixed length of 12 bytes is used.

The reverse link request field may be used to inform the host of the number of bytes the client needs in the reverse link encapsulation packet in order for it to send data back to the host. The host should attempt to grant the request by allocating at least this number of bytes in the reverse link encapsulation packet. The host may send more than one reverse link encapsulation packet in a subframe to accommodate the data. The client may send a client request and status packet at any time and the host may interpret the reverse link request parameter as the total number of bytes requested in one sub-frame. Additional details and specific examples of how the reverse link data is sent back to the host are shown below.

14. Bit block transport packet

The bit block transport packets provide a method for scrolling the display area in an arbitrary direction. A display with this capability will report the capability in bit 0 of the display feature capability indicator field of the client capability packet. The format of a bit block transport packet for one embodiment is shown in fig. 23. As shown in fig. 23, this type of packet is constructed to have packet length, packet type, hClient ID, upper left X value, upper left Y value, window width, window height, window X shift, window Y shift, and CRC fields. This type of packet is typically identified as a type 71 packet and uses a preselected fixed length of 15 bytes.

These fields are used to specify the X and Y values of the coordinates of the upper left corner of the window to be moved, the width and height of the window to be moved, and the number of pixels that the window is to be moved horizontally and vertically, respectively. Positive values of the latter two fields cause the window to move down to the right, while negative values cause the window to move up to the left.

15. Bitmap area fill packet

The bitmap area fill grouping provides a means, structure or method for easily initializing the display area to a single color. A display with this capability will report the capability in bit 1 of the client feature capability indicator field of the client capability packet. One embodiment of the format of the bitmap area fill packet is shown in fig. 24. As shown in fig. 24, this type of packet is constructed in this case to have a packet length, a packet type, hClient ID, upper left X value, upper left Y value, window width, window height, data format descriptor, pixel region fill value, and CRC field. In the 1-byte type field, this type of packet is typically identified as a type 72 packet and a preselected fixed length of 17 bytes is used.

16. Bitmap pattern fill packets

The bitmap pattern fill grouping provides a means and structure for easily initializing the display area to a preselected pattern. A display with this capability will report the capability in bit 2 of the client feature capability indicator field of the client capability packet. The upper left corner of the fill pattern is aligned with the upper left corner of the window to be filled unless the horizontal or vertical pattern offset is non-zero. If the window to be filled is wider or higher than the filling pattern, the pattern can be repeated several times horizontally or vertically in order to fill the window. The right side or bottom of the last repeated pattern is truncated as desired. If the window is smaller than the fill pattern, the right side or bottom of the fill pattern can be truncated to accommodate the window.

If the horizontal pattern offset is non-zero, then the pixels between the left side of the window and the left side plus the horizontal pattern offset are filled with the rightmost pixel of the pattern. The horizontal pattern offset will be less than the width of the pattern. Similarly, if the vertical pattern shift is non-zero, the pixels between the top edge of the window and the top edge plus the vertical pattern shift are filled with the lowest pixel of the pattern. The vertical pattern offset is less than the pattern height.

One embodiment of the format of the bitmap pattern fill packet is shown in FIG. 25. As shown in fig. 25, this type of packet is constructed to have packet length, packet type, hClient ID, upper left X value, upper left Y value, window width, window height, pattern width, pattern height, horizontal pattern offset, vertical pattern offset, data format descriptor, parameter CRC, pattern pixel data, and pixel data CRC fields. In the 1-byte type field, this type of packet is typically identified as a type 73 packet.

17. Communication link data path grouping

The communication link data lane packets provide a structure, means, or method for enabling such advanced computing capability clients as PDAs to communicate with such wireless transceivers as cellular telephones or wireless data port devices. In this case, the MDDI link acts as a convenient high-speed interface between the communication device and the computing device with the mobile display, where such packets carry data at the data link layer of the device's operating system. This grouping can be used, for example, if a web browser, email client, or entire PDA is embedded in the mobile display. A display with this capability will report the capability in bit 3 of the client feature capability indicator field of the client capability packet.

The format of one embodiment of a communication link data lane packet is shown in FIG. 26. As shown in fig. 26, this type of packet is structured to have packet length, packet type, hClient ID, parameter CRC, communication link data, and communication data CRC fields. In one embodiment, this type of packet is typically identified as a type 74 packet in the type field.

18. Interface type switch request packet

The interface type switch request packet provides a means, method or structure that enables the host to request the client or display to switch from an existing or current mode to a type 1 (serial), type 2 (2-bit parallel), type 3 (4-bit parallel) or type 4 (8-bit parallel) mode. Before the host requests a particular mode, it should confirm that the client is capable of operating in the desired mode by checking bits 6 and 7 of the display feature capability indicator field of the client capability packet. One embodiment of an interface type switch request packet format is shown in fig. 27. As shown in fig. 27, this type of packet is constructed to have a packet length, a packet type, an interface type, a reserved 1, and a CRC field. This type of packet is typically identified as a type 75 packet and uses a preselected fixed length of 4 bytes.

19. Interface type acknowledgement packet

An interface type acknowledgement packet is sent by the client and provides means, methods and structures to enable the client to acknowledge receipt of the interface type switch request packet. The requested mode, namely: type 1 (serial), type 2 (2-bit parallel), type 3 (4-bit parallel), or type 4 (8-bit parallel) mode is returned to the host as one parameter in this packet. The format of one embodiment of an interface type acknowledgement packet is shown in fig. 28. As shown in fig. 28, this type of packet is constructed to have a packet length, a packet type, a clclient ID, an interface type, a reserved 1, and a CRC field. This type of packet is typically identified as a type 76 packet and uses a preselected fixed length of 4 bytes.

20. Performing type switch packets

Executing the type switch packet is a means, structure or method for the host to command the client to switch to the mode specified in this packet. This mode is the same as the mode previously requested and acknowledged by the interface type switch request packet and the interface type acknowledge packet. After sending this packet, the host and client should switch to agreed mode. The client may lose and regain link synchronization during the mode change. The format of one embodiment of the perform type switch packet is shown in fig. 29. As shown in fig. 29, this type of packet is constructed to have a packet length, a packet type, a reserved 1, and a CRC field. In the type field of 1 byte, this type of packet is typically identified as a type 77 packet and a preselected fixed length of 4 bytes is used.

21. Forward audio channel enable packet

This grouping provides a structure, method, or means that enables the host to enable or disable audio channels in the client. This capability is useful because the client (e.g., display) can power down the audio amplifier or similar circuit element to conserve power when the host does not have audio output. It is clearly more difficult to use the mere presence or absence of an audio stream as an indicator. The default state when the client system is powered on is to enable all audio channels. The format of one embodiment of the forward audio channel enable packet is shown in FIG. 30. As shown in fig. 30, this type of packet is constructed to have a packet length, a packet type, an hClient ID, an audio channel enable mask, and a CRC field. In the 1-byte type field, this type of packet is typically identified as a type 78 packet and a preselected fixed length of 4 bytes is used.

22. Inverse audio sample rate grouping

This packet enables the host to enable or disable the reverse link audio channel and set the audio data sampling rate for this stream. The host selects a sampling rate that is defined to be valid in the client capability packet. If the host selects an invalid sampling rate, the client will not send the audio stream to the host, and an appropriate error, error value, or error signal may be sent to the host in a client error report packet. The host may disable the reverse link audio stream by setting the sampling rate to a value of 255. The default state assumed when the client system is initially powered up or connected is to disable the reverse link audio stream. The format of one embodiment of an inverse audio sample rate packet is shown in fig. 31. As shown in fig. 31, this type of packet is constructed to have a packet length, a packet type, an hClient ID, an audio sampling rate, a reserved 1, and a CRC field. This type of packet is typically identified as a type 79 packet and uses a preselected fixed length of 4 bytes.

23. Digital content protection overhead packets

This packet provides a structure, method, or means for enabling the host and client to exchange messages relating to the digital content protection method being used. Two types of content protection are currently envisaged, Digital Transmission Content Protection (DTCP) or high bandwidth digital content protection system (HDCP), and space is reserved for future alternative protection scheme names. The method used is specified by the content protection type parameter in this packet. One embodiment format of a digital content protection overhead packet is shown in fig. 32. As shown in fig. 32, this type of packet is constructed to have a packet length, a packet type, a bClient ID, a content protection type, a content protection overhead message, and a CRC field. This type of packet is typically identified as a type 80 packet.

24. Transparent color enable grouping

A transparent color enable packet is a structure, method, or means to specify which colors are transparent in a display and to enable or disable the display of images using transparent colors. A display with this capability reports the capability in bit 4 of the client feature capability indicator field of the client capability packet. When a pixel with a transparent color value is written to the bitmap, the color does not change from the previous value. The format of the transparent color enable packet is shown in fig. 33. As shown in fig. 33, this type of packet is constructed to have a packet length, a packet type, an hClient ID, a transparent color enable, a reserved 1, an alpha cursor identifier, a data format descriptor, a transparent pixel value, and a CRC field. In the 1-byte type field, this type of packet is typically identified as a type 81 packet and a preselected fixed length of 10 bytes is used.

25. Round trip delay measurement packet

The round trip delay measurement packet provides a structure, method or means to measure the propagation delay from the host to the client (display) plus the delay from the client (display) back to the host. This measurement inherently includes delays present in the line drivers and receivers and the interconnect subsystem. This measurement is used to set the steering delay and reverse link rate divisor parameters in the reverse link encapsulation packet generally described above. Such packets are most useful when the MDDI link is operating at maximum speed for a particular application. Packets may be sent at a lower data rate in type 1 mode, thereby increasing the range of round trip latency measurements. The MDDI _ Stb signal behaves as if all zero data is sent in the following fields: two guard times, all zeros and a measurement period. This causes the MDDI _ Stb to flip at half the data rate, so it can be used as a periodic clock in the client during the measurement period.

In one embodiment, the client indicates the capability to support a round trip delay measurement packet, typically by bit 18 in the client feature capability indicator field of the client capability packet. It is recommended that all clients support round trip delay measurements, but the host may also know the worst-case round trip delay based on the maximum cable delay and the maximum driver and receiver delays. The host may also pre-acquire the round trip delay of the MDDI link in internal mode, as this is an aspect of the known design factors (wire length, circuit type and characteristics, etc.) of the device using the interface.

The format of the round trip delay measurement packet is shown in fig. 34. As shown in fig. 34, in one embodiment, this type of packet is constructed with packet length, packet type, hClient ID, parameter CRC, guard time 1, measurement period, all zeros, and guard time 2 fields. This type of packet is typically identified as a type 82 packet and a preselected fixed length of 159 bits is used.

The timing of events occurring during a round trip delay measurement packet is shown in figure 35. In fig. 35, the host sends a round trip delay measurement packet, which is shown by the presence of the parameter CRC and strobe alignment fields followed by the all zeros and guard time 1 fields. A delay 3502 occurs before the packet reaches the client display device or processing circuit. When the client receives the packet, the client transmits a 0x0 pattern (pattern) of 0xff, and 30 bytes at as accurate a start of an actual measurement period as possible, where the start of the measurement period is determined by the client. The actual time that the client starts sending this sequence is delayed from the start of the measurement period from the perspective of the host. This amount of delay is essentially the time it takes for the packet to travel through the line drivers and receivers and the interconnect subsystem (cables, wires). A similar amount of delay 3504 is experienced for transferring the pattern from the client back to the host.

To accurately determine the round trip delay time of the signal to and from the client, the host counts the number of forward link bit time periods that occur after the start of the measurement period until the beginning of a 0x0 sequence of 0xff, and 30 bytes is detected to arrive. This information is used to determine the amount of time that the round trip signal is passed from the host to the client and back again. Then, about half this amount is attributed to the delay caused by the unidirectional signal path to the client.

During both guard times, both the host and the guest drive the lines to a logic zero level to keep the MDDI _ DATA lines in a defined state. During both guard times, the enable and disable times of the host and client are such that the MDDI _ Data signal is active low for any active round trip delay time.

26. Forward link offset calibration packets

The forward link offset calibration packet allows the client or display to calibrate itself for the propagation delay difference of the MDDI _ Data signal from the MDDI _ Stb signal. Without delay skew compensation, the maximum data rate is typically limited to account for potential worst-case variations in these delays. This packet is typically sent only when the forward link data rate is configured to be around 50Mbps or lower. After sending this packet to calibrate the display, the data rate may be increased in steps to over 50 Mbps. If the data rate is set too high during the offset calibration process, the display may synchronize to a glitch (alias) for that bit period, which may cause the delay offset compensation to be set off more than one bit time, resulting in a data clock error. The highest data rate type or the highest possible interface type of the interface is selected before sending the forward link deviation calibration packet, thereby calibrating all the data bits present.

One embodiment of a forward link offset calibration packet format is shown in fig. 56. As shown in fig. 56, this type of packet is constructed to have a packet length (2 bytes), a packet type, an hClient ID, a parameter CRC, all zeros, an alignment data sequence, and a CRC field. In the type field, this type of packet is typically identified as a type 82 packet and has a preselected length of 515 in one embodiment.

Virtual control panel

The use of a Virtual Control Panel (VCP) allows the host to set certain user controls in the client. By allowing these parameters to be adjusted by the host, the user interface in the client is simplified because a screen allowing the user to adjust parameters such as volume or display brightness can be generated by the host software rather than by one or more microprocessors in the client. The host has the ability to read the parameter settings in the client and determine the range of valid values for each control. The client has the ability to return reports to the host of control parameters that it can adjust.

Commonly specified control codes (VCP codes) and associated data values are used to describe the controls and settings in the client. The VCP code in the MDDI specification is extended to 16 bits to maintain proper data field alignment in the packet definition and to support in the future a supplemental value that is unique to this interface or future enhancements.

27. Requesting VCP feature packets

Requesting a VCP feature packet provides a means, mechanism or method for a host to request the current setting of a specific control parameter or all valid control parameters. Typically, the client responds to the VCP packet with the appropriate information in the VCP feature acknowledgement packet. In one embodiment, the client uses bit 20 of the client feature capability indicator field in the client capability packet to indicate the capability to support the request VCP feature packet.

The format of the request VCP feature packet in one embodiment is shown in fig. 69. As shown in fig. 69, this type of packet is constructed to have a packet length, a packet type, an hClientID, an MCCS VCP code, and a CRC field. In one embodiment, this type of packet is generally identified as type 128, which is indicated in a 2-byte type field. The packet length specifies the total number of bytes in the packet that do not include the packet length field, and for this type of packet, the packet length is typically fixed at a length of 8 bytes.

The hClient ID field is reserved for client ID use in future implementations and is typically set to zero. The MCCS VCP code field includes 2 bytes of information to specify the MCCS VCP control code parameters. A value in the range of 0 to 255 causes the VCP feature reply packet to be returned in a single entry in the VCP feature reply list corresponding to the specified MCCS code. The MCCS VCP code of 65535(0xffff) is used to request a VCP feature reply packet with a VCP feature reply list containing the feature reply list items for each control supported by the client. For this field, the values of 256 to 65534 are reserved for future use and are not currently used.

VCP feature acknowledgement packet

The VCP feature reply packet provides a means, mechanism or method for the client to respond to the host request with the current setting of a particular control parameter or all valid control parameters. In general, a client sends a VCP feature response packet in response to requesting the VCP feature packet. This grouping may be useful for determining the current settings for particular parameters, determining the effective range of particular controls, determining whether a client supports particular controls, or determining the set of controls supported by a client. If a requested VCP feature is sent that relates to a particular control that is not implemented in the client, then a VCP feature reply packet is returned with a single VCP feature reply list entry corresponding to the non-implemented control containing the appropriate error code. In one embodiment, the client uses bit 20 of the client feature capability indicator field of the client capability packet to indicate the capability to support VCP feature acknowledgement packets.

The format of the VCP feature acknowledgement packet in one embodiment is shown in fig. 70. As shown in fig. 70, this type of packet is constructed to have a packet length, a packet type, a clrientid, an MCCS version, a response sequence number, a VCP feature response list, and a CRC field. In one embodiment, this type of packet is generally identified as type 129, as indicated in a 2-byte type field.

The cClientID field contains information reserved for client IDs. This field is reserved for future use and is typically set to zero. The MCCS version field contains 2 bytes of information that specifies the version of the VESA MCCS specification implemented by the client.

The 2-byte response sequence number field contains information or data that specifies the sequence number of the VCP feature response packet returned by the client. The client, in response to requesting VCP feature packets having an MCCS control code with a value of 65535, returns one or more VCP feature response packets. The client may extend the feature reply list via a plurality of VCP feature reply packets. In this case, the client assigns a sequence number to each successive packet, and the sequence number of the VCP feature reply packet sent in response to a single request VCP feature packet is from zero and incremented by 1 each time. The last VCP feature list entry in the last VCP feature reply packet should contain an MCCS VCP control code value equal to 0xffff in order to determine that the packet is the last and contains the highest sequence number of the returned packet group. If only one VCP feature reply packet is sent in response to the request VCP feature packet, the reply sequence number in the single packet is zero and the VCP feature reply list contains records with an MCCS VCP control code equal to 0 xffff.

The number of features field in the list contains 2 bytes to specify the number of VCP feature list entries in the VCP feature reply list for the packet, and the VCP feature reply list field is a set of bytes containing one or more VCP feature reply list entries. The format of a single VCP feature reply list item in one embodiment is shown in fig. 71.

As shown in fig. 71, each VCP feature response list entry is 12 bytes in length and includes an MCCS VCP code, a result code, a maximum value, and a current value field. The 2-byte MCCS VCP code field contains data or information specifying the MCCS VCP control code parameters associated with this list entry. For the present embodiment, only the control code values defined in the VESA MCCS specification version 2 and later versions are considered to be valid. The 2-byte result code field contains information specifying an error code associated with the information request regarding the designated MCCS VCP control. A value of '0' in this field means no error, while a value of '1' means that the specified control is not implemented in the client. The other values 2 to 65535 of this field are currently reserved for future use and for implementing other applications envisaged in the field, but are not used now.

The 4-byte maximum field contains a 32-bit unsigned integer to illustrate the maximum possible value that can be set to the specified MCCS control. This value is set to zero if the requested control is not implemented in the client. If the return value is less than 32 bits (4 bytes) in length, the value is converted to a 32-bit integer and the most significant (unused) byte is set to zero. The 4-byte current value field contains information that specifies the current value of the MCCS VCP continuous (C) or discontinuous (NC) control specified. If the requested control is not implemented in the client, or if the control is implemented but the table (T) data type, this value is set to zero. If the return value is less than 32 bits (4 bytes) in length for each VESA MCCS specification, the value is converted to a 32-bit integer with the most significant (unused) byte set to zero.

29. Setting VCP feature groupings

The set VCP feature packet provides a means, mechanism, or method for the host to set VCP control values for continuous and discontinuous control in the client. In one embodiment, the client uses bit 13 of the client feature capability indicator field of the client capability packet to indicate support for setting the VCP feature packet's capability.

The format in which the VCP feature packet is set in one embodiment is shown in fig. 72. As shown in fig. 72, this type of packet is constructed to have a packet length, a packet type, an hClientID, an MCCS VCP code, the number of values in the list, a control value list, and a CRC field. This type of packet is typically identified as type 130, as shown in the 2 byte type field, and is 20 bytes long, excluding the packet length field.

The hClient ID field again uses a 2 byte value to specify or act as a client ID. This field is reserved for future use and is currently set to zero. The MCCS VCP code field uses 2 bytes of information or value to specify the MCCS VCP control code parameter to be adjusted. The quantity of values field in the 2-byte list contains information or a value that specifies the number of 16-bit values present in the list of control values. The list of control values typically contains an entry unless the MCCS control code refers to a table in the client. Without reference to the control of the table, the list of control values would contain a value that would be descriptive of the new value to be written to the control parameter specified by the MCCS VCP code field. For control involving tables, the format of the data in the list of control values is specified by the parameter description of the specified MCCSVCP code. If the list contains a value greater than one byte, the least significant byte is transmitted first, consistent with the method defined elsewhere. Finally, the 2-byte CRC field contains the 16-bit CRC of all the bytes in the packet, including the packet length.

30. Request valid parameter grouping

The request-valid-parameters packet serves as a means or mechanism for requesting the client to return a valid-parameters-reply packet containing a list of parameters supported by the specified discontinuous (NC) or table (T) control. This grouping should only specify discontinuous control or control involving tables in the client, and not the MCCS VCP code value specifying 65535(0xffff) for all controls. If an unsupported or invalid MCCS VCP code is specified, an appropriate error value is returned in the valid parameter response packet. In one embodiment, the client uses bit 20 of the client feature capability indicator field of the client capability packet to indicate the capability to support requesting valid parameter packets.

The format of the request valid parameter packet in one embodiment is shown in FIG. 73. As shown in fig. 73, this type of packet is constructed to have a packet length, a packet type, an hClientID, an MCCS VCP code, and a CRC field. In one embodiment, this type of packet is generally identified as type 131, as indicated in the 2 byte type field.

The packet length indicated in the 2-byte packet length field is typically set to have the total number of bytes in the packet, but does not include the 8 bytes of the packet length field. The hClient ID again specifies the client ID, but is now reserved for future use and is set to zero, as will be apparent to those of ordinary skill in the art. The 2-byte MCCSVCP code field contains a value that is used to specify a discontinuous MCCS VCP control code parameter to be queried. The value in this field should correspond to the discontinuous control implemented in the client. The values 256 to 65535(0xffff) are typically retained or considered invalid and are considered as control not implemented in the error response.

31. Efficient parameter response packet

The validity parameter response packet is sent in response to the request validity parameter packet. It serves as a means, method or mechanism to identify the active setting of the discontinuous MCCS VCP control or control for returning the contents of the table. If the control relates to a table in the client, then the VCP parameter answer list contains only a specific list of requested sequential table values. Multiple packets with sequential acknowledgement sequence numbers may be sent by the client if the contents of the table cannot fit into exactly a single valid parameter acknowledgement packet. In one embodiment, the client uses bit 20 of the client feature capability indicator field of the client capability packet to indicate the capability to support a valid parameter reply packet.

The host may request the contents of the table in the following manner: the host sends a set VCP feature packet containing the necessary or desired parameters, such as read/write parameters, LUT offset, and RGB selection; then sending a request effective parameter packet for explaining the required control by the host; the client then returns one or more valid parameter response packets containing the table data. This sequence of operations performs a function similar to the table reading function described in the MCCS operational model.

If the client does not support the specific client parameters, then in one embodiment the corresponding field of this packet will contain the value 255. For parameters to be used in the client, the corresponding field should contain the value of the parameter in the client.

The format of the validity parameter acknowledgement packet for one embodiment is shown in fig. 74. As shown in fig. 74, this type of packet is constructed to have a packet length, a packet type, a clrientid, an MCCS VCP code, a response sequence number, the number of values in the list, a VCP parameter response list, and a CRC field. For one embodiment, this type of packet is typically identified as type 132, as indicated in a 2-byte type field.

The clclient ID field is reserved for future client IDs as can be appreciated from the discussion above, while the 3-byte MCCS VCP code packet contains a value that accounts for the discontinuous MCCS VCP control code parameter described by this packet. If the request valid parameter packet specifies an invalid MCCS VCP control code, the same invalid parameter value in this field is specified with the appropriate value in the response code field. If the MCCS control code is invalid, then the VCP parameter answer list will have a length of zero.

The response code field contains 2 bytes of information or value that specifies the attributes of the response associated with the request for information about the designated MCCS VCP control. If the value in this field is equal to 0, then it is assumed that no errors exist for this data type and the last valid parameter acknowledgement packet in the sequence is sent, with the highest acknowledgement sequence number. If the value in this field is equal to 1, then no error is considered to be present, but other valid parameter acknowledgement packets with higher sequence numbers are to be sent. If the value in this field is equal to 2, then the specified control is deemed not to be implemented in the client. If the value in this field is equal to 3, then the control specified is not discontinuous control (it is a continuous control and always has a valid set of all values from zero to its maximum). The value of this field, which is equal to 4 to 65535, is reserved for future use and is not typically used.

The 2-byte response sequence number field specifies the sequence number of the valid parameter response packet returned by the client. The client, in response to a request-valid-parameters packet, returns one or more valid-parameters-reply packets. The client may extend the VCP parameter response column across the plurality of valid parameter response packets. In the latter case, the client will assign a sequence number to each successive packet and set the response code to 1 in all but the last packet in the sequence. The last valid parameter acknowledgement packet in the sequence will have the highest acknowledgement sequence number and the response code contains a value of 0.

The quantity of values field in the 2 byte list indicates the number of 16-bit values present in the VCP parameter response list. If the response code is not equal to zero, the parameter for the number of values in the list is zero. The VCP parameter response list field contains a list of 2-byte values 0 through 32760 indicating the set of valid values for discontinuous control specified by the MCCS control code field. The definition of discontinuous control code is given in the VESA MCCS specification. Finally, in this embodiment, the CRC field contains a 16-bit CRC of all bytes in the packet, including the packet length.

Scalable video stream images

The MDD interface or protocol mechanism, structure, means or method provides support for scalable video streaming images, which allows the host to send an image to the client that is scaled up or down compared to the original image, and the scalable image (the scaled image) is copied to the main image buffer. An overview of the functionality of a scalable video stream and associated protocol support is given elsewhere. The capability to support scalable video streams is defined within or by scalable video stream capability packets that are transmitted in response to requesting a particular status packet.

32. Scalable video stream capability grouping

The scalable video stream capability packet defines characteristics of scalable video stream source images in or used by the client. The format of the scalable video stream capability packet is shown generally in fig. 75. As shown in fig. 75, in one embodiment, the scalable video stream capability packet is constructed to have a packet length, a packet type, a clclient ID, a maximum number of streams, a source maximum X size, a source maximum Y size, RGB capability, monochrome capability, reserved 1, Y Cr Cb capability, reserved 2, and CRC fields. In one embodiment, the packet length is selected to be a fixed 20 bytes, as shown in the length field, which includes a 2 byte cClient ID field and a CRC field, where the cClient ID field is reserved for client ID and is set to zero otherwise. In one embodiment, the client indicates its capability to support the scalable video stream capability packet using the parameter value 143 in the valid parameter answer list in the valid status answer list packet.

The 2-byte maximum stream number field contains a value for identifying the maximum number of synchronous scalable video streams that can be allocated at one time. In one embodiment, if the maximum number of scalable video streams has been allocated, the client should deny the request to allocate the scalable video streams. The client may also deny the allocation request based on other resource limitations in the client if less than the maximum number of scalable video streams are allocated.

The source maximum X size and Y size fields (2 bytes) specify values representing the maximum width and height, respectively, of the source image of the scalable video stream in terms of the number of pixels.

The RGB capability field uses values to specify the number of bits of resolution that can be displayed in the RGB format. This value is set equal to zero if the scalable video stream cannot use the RGB format. The RGB capability word includes three independent unsigned values: bits 3 to 0 define the maximum number of bits for blue (blue intensity) in each pixel, bits 7 to 4 define the maximum number of bits for green (green intensity) in each pixel, bits 11 to 8 define the maximum number of bits for red (red intensity) in each pixel, and bits 15 to 12 are reserved for future capability definitions, typically set to zero.

The 1-byte monochrome capability field contains a value to specify the number of bits of resolution that can be displayed in monochrome format. This value is zero if the scalable video stream cannot use a monochrome format. Bits 7 through 4 are reserved for future use and should therefore be set to zero ('0') for the current application, although this value may change over time, as will be understood by those skilled in the art. Bits 3 to 0 define the maximum number of bits of gray levels that can be present in each pixel. These four bits can indicate that each pixel includes 1 to 15 bits. If the value is zero, the scalable video stream does not support the monochrome format.

The reserved 1 field (here 1 byte) is reserved for future use in providing values related to scalable video stream packet information or data. Thus, currently, all bits in this field are set to logic '0'. One purpose of this field is to have all subsequent 2-byte fields aligned with 16-bit word addresses and 4-byte fields aligned with 32-bit word addresses.

The 2-byte Y Cb Cr capability field contains a value for the number of bits that specifies the resolution that can be displayed in the Y Cb Cr format. This value is zero if the scalable video stream cannot use the Y Cb Cr format. The Y Cb Cr capability word includes three independent unsigned values: bits 3 to 0 define the maximum number of bits used to specify Cr sampling; bits 7 to 4 define the maximum number of bits used to account for Cb samples; bits 11 through 8 define the maximum number of bits used to account for the Y samples; bits 15 through 12 are reserved for future use and are typically set to zero.

The 1-byte capability bit field contains an 8-bit unsigned integer that contains a set of flags that specify capabilities associated with the scalable video stream. The flags are defined as follows: bit 0 covers the case where the pixel data in a scalable video stream packet can be in a packed format. An example of packed and byte-aligned pixel data is shown in previous FIG. 12. Bit 1 is reserved for future use and set to zero; bit 2 is also reserved for future use and set to zero; bit 3 covers the case where the scalable video stream can be specified in the color mapping data format. The color map for the scalable video stream is the same as the color map for the primary image buffer and the alpha cursor image plane. The color map may be configured using color map groupings described elsewhere; and bits 7 through 4 are reserved for future use and are typically set to zero.

The reserved 2 field (here 1 byte) is reserved for future use in providing values related to scalable video stream packet information or data. Thus, currently, all bits in this field are set to logic '0'. One purpose of this field is to have all subsequent 2-byte fields aligned with 16-bit word addresses and 4-byte fields aligned with 32-bit word addresses.

33. Scalable video stream setup packets

The scalable video stream setup packet is used to define parameters of the scalable video stream, and the client uses the information to allocate internal memory for buffering and scaling the images. The stream can be deallocated by sending packets with the X picture size and Y picture size fields being zero. The deallocated scalable video stream may later be reallocated using the same or different stream parameters. In one embodiment, the client indicates its capability to support scalable video stream setup packets using the parameter values 143 in the valid parameter answer list of the valid status answer list packet and by using a non-zero value in the maximum number of streams field of the scalable video stream capability packet.

Fig. 76 shows generally the format of a scalable video stream setup packet. As shown in fig. 76, in one embodiment, the scalable video stream setup packet is constructed to have a packet length, a packet type, an hClient ID, a stream ID, a visual data format descriptor, a pixel data attribute, an X left edge, a Y top edge, an X right edge, a Y bottom edge, an X image size, a Y image size, and a CRC field.

The 2-byte packet length field specifies the total number of bytes in the packet that do not include the packet length field. In one embodiment, the packet length of this packet is fixed at 24. The 2-byte packet type field identifies the packet as a scalable video stream setup packet using a value 136. The 2 byte hClient ID field is reserved for future use and all bits are set, usually temporarily with a logical zero value, or knowing that the protocol user has determined the ID value to be used, as will be appreciated.

The stream ID field uses 2 bytes to specify a unique identifier for the stream ID. This value is assigned by the host and ranges from zero to the maximum flow ID value specified in the client capability packet. The host must carefully manage the use of the flow ID values to ensure that each active flow is assigned a unique value and that no more active flows are deallocated or reallocated.

In one embodiment, the video data format descriptor specifies the format of each pixel of pixel data in the current stream of the current packet using 2 bytes. The pixel data format must conform to at least one valid format of the alpha cursor image plane defined in the alpha cursor image capability packet. The video data format descriptor defines only the pixel format of the current packet and does not imply that a constant format will continue to be used during the use of a particular video stream. Fig. 11 shows one embodiment of how the video data format descriptor is encoded, and the discussion above for other packets.

In one embodiment, the 2-byte pixel data attribute field has a value that may be interpreted as follows: bits 1 and 0 select the display to which the pixel data is to be routed. For a bit value of 11 or 00 the pixel data is displayed to both eyes, for a bit value of 10 the pixel data is routed to the left eye only and for a bit value of 01 the data is routed to the right eye only.

Bit 2 indicates that the pixel data is in interlaced format. When bit 2 is 0, the pixel data is in a standard progressive format. When proceeding from one row to the next, the row number (pixel Y coordinate) is incremented by 1. The pixel data is in interlaced format when bit 2 is 1. When proceeding from one row to the next, the row number (pixel Y coordinate) is incremented by 2.

Bit 3 indicates that the pixel data is in an alternate pixel format. This is similar to the standard interlacing mode allowed by bit 2, but here the interlacing is vertical rather than horizontal. The pixel data is in the standard progressive pixel format when bit 3 is 0-. As each successive pixel is received, the column number (pixel X coordinate) is incremented by 1. Bit 3 is a 1-time, the pixel data is in an alternating pixel format. As each pixel is received, the column number (pixel X coordinate) is incremented by 2.

Bit 4 indicates whether the pixel data relates to a display or a camera. When bit 4 is a 0-, the pixel data is sent to or from the display frame buffer. When bit 4 is a 1, pixel data is sent to or from the camera. Bit 5 is reserved for future use and is thus typically set to zero.

Bits 7 and 6 are display update bits that are used to illustrate the frame buffer to which pixel data is to be written. The effect of the frame update bit is described in more detail elsewhere. When bits [7:6] are 01, the pixel data is written to the offline image buffer. When bits [7:6] are 00, the pixel data is written to an image buffer for refreshing the display. When bits [7:6] are 11, the pixel data is written to all image buffers. If bits [7:6] are 10, it is considered as an invalid value. These bits are currently reserved for future use. In this case, the pixel data is ignored and not written to any image buffer.

Bits 8 through 15 are reserved for future use and are typically set to a logic zero level or value.

34. Scalable video stream acknowledgement packet

The scalable video stream acknowledgement packet allows the client to acknowledge receipt of the scalable video stream setup packet. The client indicates its capability to support scalable video stream acknowledgement packets via the parameter value 143 in the valid parameter answer list of the valid status answer list packet and via a non-zero value in the maximum stream number field of the scalable video stream capability packet.

Fig. 77 shows the format of a scalable video stream acknowledgment packet. As shown in fig. 77, in one embodiment, the scalable video stream acknowledgement packet is constructed to have a packet length packet, a packet type, a clclient ID, a stream ID, an ACK code, and a CRC field. A packet length of 2 bytes describes the total number of bytes in the packet that do not include the packet length field and for this packet type the packet length value is 10, while packet type 137 identifies the packet as a scalable video stream acknowledgment packet.

A 2 byte clclient ID field-is reserved for future use and is typically set to zero. The 2 byte stream ID field specifies a unique identifier for the stream ID. This is the same value as the value allocated by the host in the scalable video stream setup packet.

The 2-byte confirmation code field provides a value containing a code describing the result of attempting to update the specified scalable video stream. In one embodiment, the code is defined as follows:

0-flow allocation attempts were successful.

The 1-flow deallocation attempt was successful.

2-the assignment attempt to an already assigned stream ID is invalid.

3-deallocation attempt to a deallocated flow ID is invalid.

4-client does not support scalable video streaming

The 5-stream parameters are not consistent with client capabilities.

The 6-stream ID value is greater than the maximum allowed by the client.

7-the client has insufficient resources available to allocate the specified stream.

The 2-byte CRC field contains the CRC of all bytes in the packet, including the packet length.

35. Scalable video stream packet

Scalable video stream packets are used to transmit pixel data associated with a particular scalable video stream. The size of the area referred to by this packet is defined by the scalable video stream setup packet. The client indicates its capability to support scalable video stream packets via the parameter values 143 in the valid parameter acknowledgement list of the valid status acknowledgement list packet and via a successful scalable video stream distribution response in the acknowledgement code field of the scalable video stream acknowledgement packet.

FIG. 78 illustrates the format of one embodiment of a scalable video stream packet. As shown in fig. 78, the scalable video stream packet is structured to have packet length, packet type, hClient ID, stream ID, parameter CRC, pixel count, pixel data, and pixel data CRC fields. The 2 byte packet type field identifies the packet as a scalable video stream packet using a value 18. The hClient ID field is reserved for client IDs and is typically set to zero. As previously mentioned, the 2-byte stream ID field specifies a unique identifier for the stream ID. This value is specified by the host in the scalable video stream setup packet and acknowledged in the scalable video stream acknowledgement packet.

The 2 byte pixel count field specifies the number of pixels in the pixel data field. The 2-byte parameter CRC field has a CRC of all bytes from the packet length to the pixel count. If this CRC fails to check, the entire packet is discarded. The 2 byte pixel data field contains the original video information to be scaled and then displayed. The data is formatted in the manner described by the video data format descriptor field. The data is transmitted one row at a time in the manner defined above.

The 2-byte pixel data CRC field contains a CRC for only the pixel data. If this CRC fails to check, the pixel data may still be used, but the CRC error count is increased.

36. Request specific status packets

Requesting a particular status packet provides the host with a means, mechanism or method for requesting the client to send a capability or status packet back to the host in the manner specified in this packet. The client returns a packet of the specified type in the next reverse link encapsulation packet. If the client has the capability to respond to the request specific status packet, the client will set bit 17 in the client feature capability field in the packet client capability packet. The client may use bit 21 of the client feature capability field of the packet client capability packet to indicate its capability to support requesting a particular status packet.

FIG. 79 illustrates the format of one embodiment of a request specific status packet. Packet as shown in fig. 79, the request specific status packet is constructed with packet length, packet type, hClientID, status packet ID and CRC fields. The packet length field specifies the total number of bytes in the packet that do not include the packet length field, and for this packet type, the packet length is typically fixed to a value of 10. The packet type 138 packet identifies the packet as a request specific status packet. The hClient ID (2 bytes) field is reserved for future client ID use and is now set to zero, while the 2 byte status packet ID field specifies the capabilities or type of status packet that the client will send to the host. Typical packet types are:

66-the client sends a packet client capability packet.

133-sending an alpha cursor image capability packet by the client.

139-send valid status reply list packet for identifying the client's ability to send and the exact type of status packet.

140-sending a packet processing delay parameter packet by the client.

141-personal grouping client capability grouping is sent by the client.

142-sending a client error report packet by the client.

143-transmitting scalable video stream capability packets by the client.

144-sending the client identification packet by the client.

The packet types 56 to 63 may be used for manufacturer-specific capability and status identifiers.

The CRC field contains the CRC of all bytes in the packet including the packet length.

37. Active state acknowledgement list grouping

The active status answer list packet provides a structure, means, or method for the host to have a series of status and capability packets to which the client has the capability to respond. The client can use bit 21 of the client feature capabilities field in the packet client capabilities packet to indicate its ability to support a valid status answer list packet.

Figure 80 illustrates the format of one embodiment of a valid status acknowledgement list packet. As shown in fig. 80, the valid status reply list packet is constructed to have a packet length, a packet type, a clclient ID, the number of values in the list, a valid parameter reply list, and a CRC field. The packet length of this type of packet is typically fixed to a value of 10 and the type value 139 identifies the packet as a valid status acknowledgement packet. The cClient ID field is reserved for future use as a client ID and is typically set to zero. The quantity field of values in the 2-byte list specifies the number of entries in the subsequent valid parameter response list.

The valid parameter answer list field contains a list of 2 byte parameters that are used to specify the capabilities or type of status packets that the client may send to the host. If the client has indicated that it can respond to a request-specific status packet (using bit 21 of the client feature capability field in the packet client capability packet), it can send at least a packet client capability packet (packet type 66) and a valid status answer list packet (packet type 139). The packet types that may be sent by the client and may be included in the list and their respective allocation purposes in this embodiment are:

66-group client capability group.

133-alpha Cursor image capability grouping.

139-valid status acknowledgement list packet to identify the client's ability to send and the exact type of status packet.

140-packet processing delay parameter packet.

141-personal display capability grouping.

142-client error report packet.

143-scalable video streaming capability grouping.

144-client identification grouping.

145-other display capability grouping.

Packet types 56 to 63 may be used for manufacturer-specific capability and status identifiers.

The CRC field contains the CRC of all bytes in the packet, including the packet length.

38. Packet processing delay parameter packet

Packet processing delay parameter the packet provides a set of parameters to allow the host to calculate the time required to complete the processing associated with the reception of a particular packet type. Some commands sent by the host cannot be completed by the client in zero time. The host may poll status bits in the client request and status packets to determine whether certain functions have been completed by the client, or the host may calculate a completion time using parameters returned by the client in the packet processing delay parameter packet. The client can use the parameter values 140 in the valid parameter response list in the valid status response list packet to indicate its ability to support packet processing of the delay parameter packet.

Figure 81A generally illustrates the format of one embodiment of a packet processing delay parameter packet. As shown in fig. 81A, the packet processing delay parameter packet is constructed to have a packet length, a packet type, a clclient ID, the number of list entries, a delay parameter response list, and a CRC field. The packet length of this packet type is typically fixed to a value of 10 and the type value 140 identifies the packet as a packet processing delay parameter packet. The cllient ID field is reserved for future use as a client ID and is typically set to zero. The 2 byte list number indicates the number of items in the subsequent valid parameter answer list.

The deferred parameter answer list field is a list of one or more deferred parameter list items. Figure 81B illustrates a format of one embodiment of a single delay parameter list entry showing delay packet type, pixel delay, horizontal pixel delay, vertical pixel delay, and fixed delay fields.

Each delay parameter list entry is typically limited in length to 6 bytes and is defined as follows. The 2-byte delay packet type field specifies the packet type for the subsequent delay parameter application. The pixel delay field (1 byte) includes a delay value index (index). The value read from the table is multiplied by the total number of pixels in the destination field of the packet. The total number of pixels is the width times the height of the destination area of the bitmap located by the group. The 1-byte horizontal pixel delay field contains a value that is an index of a delay value table (the same table as the DPVL). This value read from the table is multiplied by the width (in pixels) in the destination field in the packet. The 1-byte vertical pixel delay field contains a value that is an index into a delay value table (typically the same table as the DPVL is used). This value read from the table is multiplied by the height (in pixels) in the packet destination field.

The fixed delay field uses 1 byte as an index to a delay value table (the same table as the DPVL). This value read from the table is a fixed delay parameter that represents the time required to process a packet independent of any parameter value specified in the packet. The total delay, or time delay for completion of packet processing, may be determined according to the following relationship:

delay (packet processing delay (pixel delay) · total number of pixels) +

(packet processing delay (horizontal pixel delay) +width)

(packet processing delay (vertical pixel delay) · height) +

Packet processing delay (fixed delay)

For some groupings, the total number of pixels, width or height is not used because these parameters are not referenced in the corresponding grouping. In these cases, the corresponding pixel delay parameter is typically set to zero.

39. Personal display capability grouping

The personal display capability group provides a set of parameters that describe the capabilities of a personal display device, such as a head mounted display or display glasses. This enables the host to self-define the display information according to the specific capabilities of the client. On the other hand, the client indicates its ability to send the personal display capability packet by using the corresponding parameter in the active parameter answer list of the active status answer list packet.

FIG. 82 illustrates the format of one embodiment of a personal display capability packet. As shown in fig. 82, the personal display capability group is constructed to have a group length, a group type, a clrientid, the subpixel layout, a pixel shape, a horizontal field of view, a vertical field of view, a visual axis intersection, a left/right image, a transparency (see through), a maximum brightness, an optical capability, a minimum IPD, a maximum IPD, a field of view curvature point list, and a CRC field. In one embodiment, the packet length is fixed at 68. The group type value 141 identifies the group as a personal display capability group. The cllient ID field is reserved for future use and is now typically set to zero.

The subpixel layout field illustrates the physical layout of subpixels from top to bottom and from left to right using the following values, where: using 0 indicates that the subpixel layout is not defined; use 1 indicates red, green, blue stripes; use 2 indicates blue, green, red stripes; using 3 indicates four pixels with a 2 x 2 subpixel arrangement with red on the top left, blue on the bottom right and two green subpixels, one on the bottom left and one on the top right; 4 is used to indicate four pixels with a 2 x 2 sub-pixel arrangement comprising red at the bottom left, blue at the top right and two green sub-pixels, one at the top left and one at the bottom right; 5 is used to indicate Δ (Delta) (triple); a mosaic with 6 to indicate overlap in red, green and blue (e.g., LCOS display with field sequential color); and values 7 to 255 are typically reserved for future use.

The pixel shape field describes the shape of each pixel consisting of a particular configuration of sub-pixels using the following values, where: 0 is used to indicate that the sub-pixel shape is undefined; use 1 indicates a circle; use 2 indicates a square; use 3 indicates a rectangle; use 4 to indicate an oval; the ellipse is indicated using 5; and values 6 through 255 are reserved for future use to indicate the desired shape, as will be understood by those of ordinary skill in the art.

The 1 byte horizontal field of view (HFOV) field illustrates a horizontal field of view in 0.5 degree increments (e.g., if the HFOV is 30 degrees, its value is 60). If its value is zero, then HFOV is not specified.

A vertical field of view (VFOV) field of 1 byte illustrates the vertical field of view in increments of 0.5 degrees (e.g., if VFOV is 30 degrees, its value is 60). If its value is zero, then VFOV is not assigned.

The 1-byte visual axis crossing field illustrates a visual axis crossing in 0.01 diopter (1/m) increments (e.g., if the visual axis crossing is 2.22 meters, then its value is 45). If its value is zero, the visual axis crossing is unspecified.

The left/right image overlap field of 1 byte specifies the left and right image overlap percentage. The percentage of the allowable range of image overlap is 1 to 100. The values 101 to 255 are invalid and are not normally used. If its value is zero, no image overlap is specified.

The transparency (see through) field of 1 byte specifies the transparency percentage of the image. The percentage of the allowable range of transparency is 0 to 100. The values 101 to 254 are invalid and will not be used. If its value is 255, then the transparency percentage is unspecified. The 1 byte maximum luminance field illustrates the maximum luminance in 20 nits increments (e.g., if the maximum luminance is 100 nits, its value is 5). If its value is zero, the maximum brightness is not specified.

2-byte optical power flags field-contains various fields that specify the optical power of the display. The values of these bits are typically assigned as follows:

bits 15 through 5 are reserved for future use, typically set to zero.

Bit 4 selects glasses focus adjustment and a value of 0 means that the display does not have glasses focus adjustment. A value of 1 means that the display has a glasses focus adjustment.

Bits 3 to 2 select binocular function as follows: a value of 0 means that the display is binocular and only 2-dimensional (2D) images can be displayed; a value of 1 means that the display is binocular and can display a 3-dimensional (3D) image; a value of 2-means that the display is monocular, while a value of 3 is reserved for future use.

Bits 1 to 0 select left and right field curvature symmetry, and a value of 0-value means that the field curvature is undefined. If this field is zero, then all field curvature values from A1 to E5 except for point C3 are set to zero, point C3 specifies the focal length of the display, or it is set to zero to indicate that the focal length is not specified. A value of 1-means that the left and right displays have the same symmetry. A value of 2-means that the left and right displays are mirror images of each other on the vertical axis (column C). The value 3 is reserved for future use.

A minimum interpupillary distance (IPD) field of 1 byte is used to specify the minimum interpupillary distance in millimeters (mm). If its value is zero, then the minimum interpupillary distance is not specified. A maximum interpupillary distance (IPD) of 1 byte is used to specify the maximum interpupillary distance in millimeters (mm). If its value is zero, the maximum interpupillary distance is not specified.

The field of view curvature points list field contains a list of 25 2 byte parameters for specifying focal length in units of thousandths of diopters (1/m) over a range of 1 to 65535 (e.g., 1 is 0.001 diopters and 65535 is 65.535 diopters). The 25 elements in the field of view curvature point list are labeled a1 through E5, as shown in fig. 83. The dots should be evenly distributed over the active area of the display. Column C corresponds to the vertical axis of the display and row 3 corresponds to the horizontal axis of the display. Columns a and E correspond to the left and right edges of the display, respectively. And rows 1 and 5 correspond to the top and bottom edges of the display, respectively. The order of the 25 points in the list is: a1, B1, C1, D1, E1, a2, B2, C2, D2, E2, A3, B3, C3, D3, E3, a4, B4, C4, D4, E4, a5, B5, C5, D5, E5.

The CRC field contains the CRC of all bytes in the packet, including the packet length.

40. Client error reporting packet

The client error report packet serves as a mechanism or means for allowing the client to provide a list of operational errors to the host. As a result of receiving certain commands from the host, the client may detect a variety of errors in its normal operating conditions. Examples of such errors include: the client has been commanded to operate in a mode that it does not support; the client may have received packets containing parameters that are beyond the client's capabilities or scope; the client may be instructed to enter a mode in an incorrect sequence. The client error reporting packet may be used to detect errors during normal operation, but is most useful to system designers and integrators to diagnose problems during development and integration of host and client systems. The client uses the parameter values 142 in the active parameter answer list of the active status answer list packet to indicate its ability to send a display error report packet.

FIG. 84A illustrates the format of one embodiment of client error report data. As shown in fig. 84A, the client error report data is structured to have a packet length, a packet type, a clclient ID, the number of list entries, an error code list, and a CRC field. The packet type value 142 identifies a packet as a client error reporting packet. The cllient ID field is reserved for future use and is now typically set to zero. The list entry number (2 bytes) field specifies the number of entries in the subsequent error code list. The error code list field (here 8 bytes) is a list containing one or more error report list entries. FIG. 87B illustrates the format of a single error report list entry.

In one embodiment, as shown in FIG. 87B, each error report list entry is exactly 4 bytes in length, and in one embodiment, has a structure that includes: a 2-byte display error code field to specify the type of error reported, and a 2-byte error subcode field to specify more detailed details about errors defined by the client error code packet. The specific definition of each client error code is defined by the manufacturer of the client. It is not necessary to define an error sub-code for each display error code and in case an error sub-code is not defined, the value is set to zero. The specific definition of each error subcode is defined by the manufacturer of the client.

41. Client identification grouping

The client identification packet allows the client to return identification data in response to requesting a particular status packet. In one embodiment, the client uses the parameter values 144 in the active parameter answer list of the active status answer list packet to indicate the ability to send the client identification packet. It is useful for the host to be able to determine the manufacturer name and model number of the client device by reading this data from the client. The information may be used to determine whether the client has special capabilities that cannot be described in the grouping client capabilities. There are presumably two possible methods, means or mechanisms for reading the identification information from the client. One is by using a packet client capability packet that contains fields similar to those in the basic EDID structure. Another approach is through the use of client identification packets that contain richer sets of information than similar fields in the packet client capability packet. It allows the host to identify manufacturers that are not assigned a 3-character EISA code and allows the serial number to contain alphanumeric characters.

Figure 85 illustrates the format of one embodiment of a client identification packet. As shown in fig. 85, the client identification packet is constructed to have a packet length, a packet type, a clclient ID, a manufacturing week, a manufacturing year, a manufacturer name length, a product name length, a serial number length, a manufacturer name string, a serial number string, and a CRC field.

The 2-byte packet type field contains a value for identifying the packet as a client identification packet. In one embodiment, this value is chosen to be 144. The cllient ID field (2 bytes) is also reserved for future use for client IDs and is typically set to zero. The CRC field (2 bytes) contains a 16-bit CRC of all bytes in the packet, including the packet length.

The 1-byte manufacturing week field contains a value that defines the week of display manufacturing. In at least one embodiment, if the client supports this field, then this value is in the range of 1 to 53. If the client does not support this field, it is typically set to zero. The manufacture year field of 1 byte contains a value for defining the year the client (display) is manufactured. This value is a deviation from 1990 as the starting point, although other reference years may be used. This field may represent a year in the range of 1991 to 2245. For example, 2003 corresponds to a year of manufacture value of 13. If the client does not support this field, it is typically set to zero.

The manufacturer name length, product name length, and sequence number length fields all contain 2 byte values that specify the length of the manufacturer name string field including any null terminator or null stuff character, the length of the product name string field including any null terminator or null stuff character, and the length of the sequence number string field including any null terminator or null stuff character, respectively.

The manufacturer name string, product name string, and serial number string fields all contain variable numbers of bytes specified by the length fields of the manufacturer name, product name, and serial number, respectively, and contain ASCII strings that are used to specify the manufacturer, product name, and display alphanumeric serial number, respectively. Each of these strings is terminated by at least one null character.

42. Optional (alternate) display capability grouping

The optional display capability packet indicates the capabilities of the optional display connected to the MDDI client controller. The packet is sent in response to requesting a specific status packet. When prompted, the client device sends an optional display capability packet for each optional display supported. The client can indicate its ability to send the optional display capability packet via the parameter value 145 in the active parameter answer list of the active status answer list packet.

It is common for an MDDI system to operate in an internal mode to have more than one display connected to an MDDI client controller. One exemplary application is a mobile phone having a larger display inside the flip and a smaller display outside. The client in internal mode does not have to return an optional display capability packet for two reasons. First, during maintenance, the host may have been programmed or become aware of these capabilities because they are used in a common device or enclosure. Second, because the clients cannot be easily disconnected or separated from the connection to the host as a whole, the host may contain hard-coded copies of the client's capabilities, or at least know that they do not change as the client changes, as may otherwise occur.

The number of selectable displays field of the client capability grouping is used to report more than one display connected, and the selectable display capability grouping reports the capability of each selectable display. The video stream packet contains 4 bits in the pixel data attribute field to access each selectable display in the client device.

FIG. 89 illustrates the format of one embodiment of an optional display capability packet. As shown in fig. 86, the optional display capability packet is constructed with a packet length, a packet type, a cllientid, an optional display number, a reserved 1, a bitmap width, a bitmap height, a display window width, a display window height, a color mapping RGB width, an RGB capability, a monochrome capability, a reserved 2, a Y Cb Cr capability, a display feature capability, a reserved 3, and a CRC field. The group type value 145 identifies a group as an optional display capability group. The cClient ID field is reserved for future client IDs and is typically set to zero.

The optional display number field uses 1 byte and indicates the identity of the optional display with an integer in the range of 0 to 15. The first selectable display is typically designated as number 0, while the other selectable displays are identified by a value of the unique selectable display number, and the maximum value is the total number of selectable displays minus 1. Values greater than the total number of selectable displays minus 1 should not be used. For example: a mobile phone having a main display and a caller ID display connected to an MDDI client has one selectable display, so the selectable display number of the caller ID display is zero and the value of the number of selectable displays field of the display capability grouping is 1.

The reserved 1 field (1 byte) is reserved for future use. All bits in this field are set to zero. The purpose of this field is to align all subsequent 2-byte fields with a 16-bit word address and to align a 4-byte field with a 32-bit word address.

The bitmap width field uses 2 bytes to describe the bitmap width in terms of number of pixels. The bitmap height field uses 2 bytes to describe the bitmap height in terms of number of pixels. The display window width field uses 2 bytes to describe the display window width in terms of the number of pixels. The display window height field uses 2 bytes to describe the display window height in terms of number of pixels.

The color map RGB width field uses 2 bytes to specify the number of bits of red, green, and blue color components that can be displayed in a color map (palette) display mode. Each color component (red, green and blue) can use up to 8 bits. Even if 8 bits of each color component are transmitted in the color mapping packet, only the number of bits of the least significant bit of each color component defined in this field is used. This value is zero if the display client cannot use the color mapping (palette) format. The color mapping RGB width word comprises three independent unsigned values:

bits 3 through 0 define the maximum number of bits of blue in each pixel, and values 0 through 8 are considered valid. Bits 7 through 4 define the maximum number of bits of green in each pixel, and values 0 through 8 are considered valid. Bits 11 through 8 define the maximum number of bits of red in each pixel, and values 0 through 8 are considered valid. When bits 14 through 12 are reserved for future use and are typically set to zero. Bit 15 is used to indicate the client's ability to accept color mapped pixel data in either a packed or unpacked format. When bit 15 is set to a logic 1 level, it indicates that the client is capable of accepting color mapped pixel data in either a packed or unpacked format. If bit 15 is set to a logic 0 level, it indicates that the client can only accept color mapped pixel data in an unpacked format.

The RGB capability field uses 2 bytes to specify the number of bits of resolution that can be displayed in RGB format. In one embodiment, this value is zero if the client is not able to use the RGB format. The RGB capability word includes three independent unsigned values: bits 3 to 0 define the maximum number of bits of blue (blue intensity) in each pixel. Bits 7 to 4 define the maximum number of bits of green (green intensity) in each pixel. Bits 11 through 8 define the maximum number of bits of red (red intensity) in each pixel. Bits 14 through 12 are reserved for future use and set to zero. Bit 15 is used to indicate the client's ability to accept RGB pixel data in either packed or unpacked format. When bit 15 is set to a logic 1 level, it indicates that the client is capable of accepting RGB pixel data in either packed or unpacked format. If bit 15 is set to a logic 0 level, it indicates that the client can only accept unpacked format color mapped pixel data.

The 1-byte monochrome capability field contains a value or information specifying the number of bits of resolution that can be displayed in monochrome format. If the client is unable to use a monochrome format, then this value is zero. Bits 6 through 4 are reserved for future use and are typically set to zero. Bits 3 to 0 define the maximum number of bits of gray levels that can be present in each pixel. These four bits can specify that each pixel includes 1 to 15 bits. If the value is zero, the client does not support the monochrome format. When bit 7 is set to 1, it indicates that the client is capable of accepting packed or unpacked monochrome pixel data. If bit 7 is set to 0, it indicates that the client can only accept single color pixel data in an unpacked format.

The reserved 2 field is a reserved 1 byte wide field for future use and all bits in this field should typically be set to zero. In one embodiment, the purpose of this field is to align all subsequent 2-byte fields with a 16-bit word address and to align a 4-byte field with a 32-bit word address.

The 2-byte Y Cb Cr capability field specifies the number of bits of resolution that can be displayed in the Y Cb Cr format. This value is zero if the client cannot use the Y Cb Cr format. The Y Cb Cr capability word includes three independent unsigned values: bits 3 through 0 define the maximum number of bits used to account for Cb samples. Bits 7 to 4 define the maximum number of bits used to specify the Cr samples. Bits 11 through 8 define the maximum number of bits used to account for the Y samples. Bits 14 through 12 are reserved for future use and set to zero. When bit 15 is set to 1, it indicates that the client is capable of accepting packed or unpacked Y Cb Cr pixel data. If bit 15 is set to 0, it indicates that the client can only accept Y Cb Cr pixel data in unpacked format.

The 2 byte Bayer capacity field specifies the number of bits of resolution, pixel group, and pixel order that can be communicated in Bayer format. If the client cannot use the interval format, then this value is set to zero. The Bayer capacity field consists of the following values: bits 3 to 0 define the maximum number of bits of intensity present in each pixel; bits 5 through 4 define the desired pixel group pattern; bits 8 through 6 define the pixel order required; bits 14 through 9 are reserved for future use and set to zero. When bit 15 is set to 1, it indicates that the client is capable of accepting either packed or unpacked Bayer pixel data. If bit 15 is set to 0, it indicates that the client can only accept Bayer pixel data in an unpacked format.

The 2-byte CRC field contains the 16-bit CRC of all the bytes in the packet, including the packet length.

43. Register access packet

The register access packet provides the host or client with a means, mechanism or method for accessing the configuration and status registers of the opposite end of the MDDI link. These registers are likely to be unique to each display or device controller. These registers already exist in many displays, requiring setting of configuration, operating mode and having other beneficial and necessary settings. The register access packet allows an MDDI host or client to write to a register and request a read of the register using an MDDI link. When the host or client requests to read the register, the peer should respond by sending the register data in the same packet type and by using the read/write information field to indicate that this is data read from a particular register. The register access packet may be used to read or write multiple registers by specifying a register count greater than 1. The client indicates the ability to support register access packets using bit 22 of the client feature capabilities field of the packet client capabilities packet.

FIG. 87 illustrates the format of one embodiment of a register access packet. As shown in fig. 87, the register access packet is structured to have a packet length, a packet type, a bClient ID, a read/write flag, a register address, a parameter CRC, a register data list, and a register data CRC field. The packet type value 146 identifies a packet as a register access packet. The bClientID field is reserved for future use and is typically set to zero.

A 2-byte read/write flag field specifies this particular packet as a write, read, or response to a read and provides a count of these data values.

Bits 15 to 14 serve as a read/write flag. If bits [15:14] are 00, then the packet contains data to be written to the register addressed by the register address field. The packet to be written to the specified register is contained in the register data list field. If bits [15:14] are 10, then this is a request for data from one or more registers addressed by the register address field. If bit [15:14] is an 11 packet, then this packet contains the requested data in response to the register access packet having the read/write flag of bit 15:14 set to 10. The register address field contains a register address corresponding to the first register data list item and the register data list field contains data read from the one or more addresses. If bit [15:14] bit 01, then this value is reserved for future use and not used at this time, but those skilled in the art will understand how to employ it for the purposes of the application.

Bits 13:0 use a 14-bit unsigned integer to illustrate the number of 32-bit register data items to be transferred in the register data list field. If grouping bits 15:14 are equal to "00," bits 13:0 specify the number of 32-bit register data items that are included in the register data list field and are to be written into the register beginning with the register specified by the register address field. If grouping bits 15:14 are "10," bits 13:0 specify the number of 32-bit register data items that the receiving device sends to the device requesting to read the register. The register data list field in this packet should contain no entries and be zero in length. Bits 15:14 equal "11", then the bit 13:0 packet specifies the number of register data items contained in the register data list field that have been read from the register. Presently, bits 15:14 are not set equal to "01", which is considered to be an invalid value, otherwise they are reserved for future designation or use.

The register address field uses 4 bytes to indicate the address of the register to be written to or read from. To address registers with addresses less than 32 bits, the high order bits should be set to zero.

The 2-byte parameter CRC field contains the CRC over all bytes of the packet from the packet length to the register address. If the CRC fails to check, the entire packet is discarded.

The register data list field contains a list of 4-byte register data values to be written to the guest register, or values that have been read from the guest device register.

The 2 byte register data CRC field contains a CRC for only the register data list. If the CRC fails to check, the register data is still usable, but the CRC error count will be incremented.

D. Packet CRC

The CRC field appears at the end of the packet and sometimes after certain more critical parameters in the packet, which have significantly larger data fields, increasing the likelihood of errors during transmission. In a packet with two CRC fields, the CRC generator is reinitialized after the first CRC when only one CRC is used, so the CRC calculation following the long data field is not affected by the parameters at the beginning of the packet.

In an exemplary embodiment, the polynomial used for CRC calculation is CRC-16 or X16+ X15+ X2+ X0. Fig. 36 illustrates an exemplary implementation of a CRC generator and checker 3600 that may be used to implement the present invention. In fig. 36, CRC register 3602 is initialized to a value of 0x0001 just Before transmitting the first bit of the packet input onto Tx _ MDDI _ Data _ Before _ CRC (send MDDI Data Before CRC) line, and then bytes of the packet are first shifted into the register starting with LSB. It should be noted that the number of register bits in this figure corresponds to the order of the polynomial used, rather than the position of the bits used by the MDDI. The CRC register is shifted in one direction more efficiently so that CRC bit 15 appears at bit position 0 of the MDDI CRC field, CRC register bit 14 appears at MDDICRC field bit position 1, and so on until MDDI bit position 14 is reached.

For example, if the packet contents of the client request and status packet are: 0x000c, 0x0046, 0x000, 0x0400, 0x00, 0x0000 (or as a sequence of bytes: 0x0c, 0x00, 0x46, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00) and commit (commit) using the inputs of multiplexers 3604 and 3606 and NAND (NAND) gate 3608, the final CRC output on Tx _ MDDI _ Data _ With _ CRC lane is 0xd9aa (or as a sequence 0xaa, 0xd9 sequence).

When CRC generator AND checker 3600 is configured as a CRC checker, the CRC received on Rx _ MDDI _ Data (receive MDDI Data) lines is input to multiplexer 3604 AND NAND gate 3608, AND is bitwise compared to the value found in the CRC register using NOR (NOR) gate 3610, exclusive or (XOR) gate 3612, AND (AND) gate 3614. If there are any errors, as output by AND gate 3614, then the CRC is incremented once for each packet containing a CRC error by connecting the output of gate 3614 to the input of register 3602. It should be noted that the exemplary circuit shown in fig. 36 may output more than one CRC error signal within a given CHECK _ CRC _ NOW window (see fig. 37B). Thus, the CRC error counter typically only counts the first CRC error instance within each interval that CHECK _ CRC _ NOW is active. If configured as a CRC generator, the CRC is clocked out of the CRC register at a time aligned with the end of the packet.

The timing of the input and output signals and the enable signal are illustrated graphically in fig. 37A and 37B. Fig. 37A shows generation of CRC and transmission of a packet of Data With the state (0 or 1) of Gen _ Reset, Check _ CRC _ Now, generation _ CRC _ Now, and transmission _ MDDI _ Data (transmitting MDDI Data) signals and the state (0 or 1) of Tx _ MDDI _ Data _ Before _ CRC (transmitting MDDI Data Before CRC) and Tx _ MDDI _ Data _ With _ CRC (transmitting MDDI Data With CRC) signals. Reception of a packet of Data and checking of a CRC value are shown in fig. 37B in states of Gen _ Reset, Check _ CRC _ Now, generation _ CRC _ Now, and Sending _ MDDI _ Data signals, and Rx _ MDDI _ Data (received MDDI Data) and CRC _ Error (CRC Error) signals.

E. Error code overloading of packet CRC

Whenever only packets of data and CRC are transferred between the host and client, no error codes are accommodated therein. The only error is loss of synchronization. Otherwise, it must wait for the link to time out due to lack of a good data transfer path or pipeline, then reset the link and proceed. However, this is time consuming and inefficient.

For use in one embodiment, a new technique has been developed in which the CRC portion of the packet is used to convey error code information. This is generally shown in fig. 65. That is, one or more error codes are generated by a processor or device processing the data transfer that indicate particular predetermined errors or defects that may occur within the communication process or link. When an error is encountered, the CRC bits of the packet are used to generate and transmit the appropriate error code. That is, the CRC value is reloaded or overwritten with a required error code that can be detected at the receiving end by an error monitor or checker that monitors the CRC field value. For the case where the error code and the CRC value match for some reason, the complement of the error code is transmitted to prevent confusion.

In one embodiment, to provide a robust (robust) error warning and detection system, an error code is transmitted several times using a series of packets, typically all packets, that are transmitted or sent after an error has been detected. This condition will occur until the error generating condition is cleared from the system, at which time the normal CRC bits are transferred without reloading with another value.

This technique of reloading the CRC value provides a very fast response to system errors while using a minimum amount of extra bits or fields.

As shown in fig. 66, a CRC overwrite mechanism or means 6600 is illustrated with an error detector or detection module 6602, which can form part of other circuitry previously described or appreciated, for detecting the presence or occurrence of errors within a communication link or process. An error code generator or module 6604, which may form part of other circuitry or use techniques such as look-up tables to store preselected error messages, generates one or more error codes to indicate that a particular predetermined error or defect has been detected to occur. It will be readily appreciated that devices 6602 and 6604 may be formed as a single circuit or device, or as part of a programmed sequence of steps for other known processors and elements, as desired.

A CRC value comparator or comparison module 6606 is shown for checking if the selected error code or codes are the same as the transmitted CRC value. If so, a code complement generator or generation module or device is utilized to provide the complement of the error code so as to prevent the error code from being mistaken for the original CRC pattern (pattern) or value, thereby confusing or complicating the detection scheme. An error code selector or selection module element or device 6610 then selects the error code desired to be inserted or rewritten, or their respective complements, as the case may be. Error code CRC rewriter or rewrite mechanism or module 6612 is a device that receives the data stream, packets, and desired code to be inserted and rewrites the corresponding or appropriate CRC value to transmit the desired error code to the receiving device.

As described above, error codes may be transmitted multiple times using a series of packets, so the rewriter 6612 may utilize memory storage elements to save a copy of the code during processing or invocation of such code from a previous element or other known storage location for storing or retaining their values as needed or desired.

An implementation of the overall processing of the rewrite mechanism implementation of FIG. 66 is shown in greater detail in FIGS. 67A and 67B. At 67A, one or more errors are detected in the communicated data or process at step 6702, and an error code is selected to indicate this condition at step 6704. At the same time, or at an appropriate point, the CRC value to be replaced is checked in step 6706 and compared to the required error code in step 6708. As discussed earlier, the result of this comparison is to determine whether the required code or other representative value is the same as the current CRC value. If so, then processing proceeds to step 6712 to select the complement or, in some cases, other representative value as needed, for insertion as a code. Once it is determined in steps 6710 and 6714 what error code or value will be inserted, the appropriate code is selected for insertion. For clarity, these steps are shown as separate steps, but it is usually presented as a single choice based on the output of the decision of step 6708. Finally, at step 6716, these appropriate values are rewritten in the CRC locations for transmission with the packet targeted by the process.

On the packet receiving side, as shown in fig. 67B, the packet CRC value is monitored in step 6722. Typically, the CRC value is monitored by one or more processes within the system to determine whether an error in the data transfer has occurred, and to determine whether a retransmission of one or more packets is requested, or to inhibit further operations, etc., some of which have been discussed above. As part of such monitoring, it is also possible to use the information to compare with known or preselected error codes or representative values and to detect the occurrence of errors. Alternatively, a separate error detection process and monitor may be implemented. If such a code appears to be present, it is extracted or otherwise marked for further processing at step 6724. In step 6726 it can be determined whether this is the actual code or the complement, in which case an additional step 6728 is used to convert the value to the required code value. In either case, the code, complement or other recovery value ultimately extracted at step 6730 may be used to detect which errors have occurred from the transmitted code.

Link hibernation

The MDDI link can quickly enter a sleep state and quickly wake up from sleep. This response allows the communication system and device to force the MDDI link to go to sleep often to reduce power consumption, since the MDDI link can wake up again very quickly for use. In one embodiment, when an external mode client wakes up from sleep for the first time, it does so at the data rate and with a strobe timing that is consistent with a rate of 1Mbps, that is, the MDDI _ Stb corresponds to flipping at a rate of 500 kHz. Once the characteristics of the client have been discovered by the host or their characteristics have been communicated to the host, the host can typically wake up the link at any rate from 1Mbps to the maximum rate at which the client can operate. A client in internal mode can wake up at any rate at which both the host and the client can run. This also applies generally to the internal mode client waking up for the first time.

In one embodiment, the host and client exchange pulse sequences when the link wakes from hibernation. These pulses can be detected using a low speed line receiver that consumes only a portion of the current required by the differential receiver to receive signals at the maximum link operating speed. Either the host or the client can wake up the link, so the wake-up protocol is designed to handle the possible contention that occurs when both the host and client attempt to wake up at the same time.

During the sleep state, the MDDI _ Data and MDDI _ Stb differential drivers are disabled and the differential voltage across all differential pairs is a zero voltage. The differential line receiver used to detect the pulse train during wake-up from sleep has an intentional voltage offset. In one embodiment, the threshold between logic 1 and logic 0 levels in these receivers is approximately 125 mV. This causes the undriven differential line pair to be treated as a logic zero level during the link wakeup sequence.

To enter the sleep state, the host sends 64 MDDI _ Stb cycles after the CRC of the link down packet. The host disables the MDDI _ Data0 output of the host over a range of 15 to 56 MDDI _ Stb cycles (including output disable propagation delay) after the CRC. The host sends 64 MDDI _ Stb cycles after the CRC of the link shutdown packet and before it initiates the wake-up sequence. In one embodiment, a host initiated wake-up is defined as the host having to wait 100 nanoseconds after MDDI _ Data0 reaches an active logic 1 level and before driving a pulse on MDDI _ Stb. In one embodiment, the client needs to wait at least 60 MDDI _ Stb cycles after the CRC of the link shutdown packet and before it will drive waiting MDDI _ Data0 to a logic 1 level to attempt to wake up the host.

In order to "wake up" from a sleep state, several actions and procedures need to be performed. When a client, here a display, requires Data or communications, services from a host, the client drives MDDI _ Data0 line to a logic 1 state for approximately 70 to 1000 microseconds while the MDDI _ Stb is in an inactive state and still keeps MDDI _ Data0 driven to a logic 1 level for approximately 70 MDDI _ Stb cycles (over the range of 60 to 80) after the MDDI _ Stb becomes active, although other periods may be used as desired. The client then disables the MDDI _ Data0 driver by placing the MDDI _ Data0 driver in a high impedance state.

If the MDDI _ Stb is in the active state during sleep, although this is unlikely, the client can only drive MDDI _ Data0 to the logic 1 state for approximately 70 MDDI _ Stb cycles (over the range of 60 to 80). This action causes the host to initiate and restart data traffic on the forward link (208) and query the client for status.

The host must detect the occurrence of the request pulse and begin the startup sequence, i.e., first drive MDDI _ Stb to a logic 0 level and MDDI _ Data0 to a logic high level for at least 100 nsec. Then, while MDDI _ Stb is flipped, MDDI _ Data0 continues to be driven to a logic 1 level for 150 MDDI _ Stb cycles (over a range of 140 to 160), and MDDI _ Data0 is driven to a logic 0 level for 50 MDDI _ Stb cycles (over a range of 40 to 60). If the client detects that MDDI _ Data0 is in the logic 1 state for more than 80 MDDI _ Stb cycles, the client should not send a service request. When the guest detects that MDDI _ Data0 is at a logic 1 level for 60-80 MDDI _ Stb cycles, then the guest searching host drives MDDI _ Data0 to a logic 0 level for an interval of 50 MDDI _ Stb cycles. After the host drives MDDI _ Data0 to a logic 0 level for a time of 50 MDDI _ Stb cycles, the host then begins sending packets on the link. The first packet transmitted is a sub-frame header packet. After MDDI _ Data0 is at logic 0 level for 40 MDDI _ Stb cycles of 50 cycle intervals, the client starts looking for a subframe header packet. The world-selective properties and time interval tolerances associated with the hibernation process and startup sequence are discussed further below. (see FIGS. 68A-C below)

The host may initiate the wake up by first enabling MDDI _ Stb and simultaneously driving it to a logic 0 level. MDDI _ Stb is not driven to a logic 1 level until the pulse is output as described below. After MDDI _ Stb reaches an active logic 0 level, the host enables MDDI _ Data0 and simultaneously drives it to a logic 1 level. MDDI _ Data0 should not be driven to a logic 0 level until MDDI _ Data0 is driven to a logic 0 level for an interval of 50 MDDI _ Stb pulses as described below. The host should wait at least 100 nanoseconds after MDDI _ Data0 reaches a logic 1 level and before driving a pulse on MDDI _ Stb. This timing relationship occurs when the worst-case output enable delay is taken into account. This essentially ensures that the client has sufficient time to fully enable its MDDI _ Stb receiver after it is woken up by the logic 1 level on the MDDI _ Data0 driven by the host.

Fig. 38 shows an example of processing steps for a typical service request event 3800 without competition, where the event is marked with letters A, B, C, D, E, F and G for ease of illustration. The process begins at point a when the host sends a link shutdown packet to the client device to inform it that the link is going to transition to a low power sleep state. In the next step, the host enters a low power sleep state, as shown at point B, by disabling the MDDI _ Data0 driver and setting the MDDI _ Stb driver to logic 0. MDDI _ Data0 is driven to a logic 0 level through a high impedance bias network. After some period of time, the client sends a service request to the host by driving MDDI _ Data0 to a logic 1 level, as shown at point C. The host still uses a high impedance bias network to maintain (assert) a logic 0 level, but the driver in the client forces the line into a logic 1 level. Within 50 microseconds, the host recognizes this service request pulse and maintains a logic 1 on MDDI _ Data0 by enabling its driver, as shown at point D. The client then stops attempting to maintain the service request burst and places its driver in a high impedance state, as shown at point E. The host drives MDDI _ Data0 to a logic 0 level for 50 microseconds, as shown at point F, and generates MDDI _ Stb in a manner consistent with the logic 0 level on MDDI _ Data 0. After MDDI _ Data0 is at logic 0 level for 40 MDDI _ Stb cycles, the client starts looking for a subframe header packet. After placing MDDI _ Data0 at logic 0 level and driving MDDI _ Stb for 50 microseconds, the host begins transmitting Data on the forward link by sending a sub-frame header packet, as shown by point G.

A similar example is illustrated in fig. 39, where a service request is maintained (alert) after a link restart sequence has been started, and the events are also marked with letters A, B, C, D, E, F and G. This represents the worst case scenario where the request burst or signal from the client is very close to corrupting the sub-frame header packet. The process begins at point a when the host sends a link shutdown packet to the client device again, informing it that the link will transition to a low power sleep state. In the next step, the host enters the low power sleep state by disabling the MDDI _ Data0 driver and setting the MDDI _ Stb driver to a logic 0 level, as shown at point B. As previously described, MDDI _ Data0 is driven to a logic 0 level by a high impedance bias network. After a period of time, the host begins the link restart sequence by driving MDDI _ Data0 to a logic 1 level for 150 microseconds, as shown at point C. After the start of the link restart sequence and before 50 microseconds has elapsed, the display also maintains MDDI _ Data0 at 1 for a duration of 70 microseconds, as shown at point D. This occurs because the display needs to request service from the host and has not yet identified that the host has begun a link restart sequence. The client then no longer attempts to maintain the service request burst and the client places its driver in a high impedance state, as shown at point E. The host continues to drive MDDI _ Data0 to a logic 1 level. The host drives MDDI _ Data0 to a logic 0 level for 50 microseconds, as shown by point F, and generates MDDI _ Stb in a manner consistent with the logic 0 level on MDDI _ Data 0. After maintaining MDDI _ Data0 to a logic 0 level and driving MDDI _ Stb for 50 microseconds, the host begins transmitting Data on the forward link by sending a sub-frame header packet, as shown by point G.

From the above discussion, one can see that: as part of the wake-up sequence, previous solutions involve having the host go through two states. For the first state, the host drives the MDDI _ Data0 signal high for 150 microseconds, then drives the MDDI _ Data0 signal low for 50 microseconds, while activating the MDDI _ Stb line, then begins transmitting MDDI packets. This procedure can be used well to advance the state of the art in terms of the data rates achievable using MDDI apparatus and methods. However, as previously mentioned, faster speeds are always required in terms of reducing response time to conditions or enabling faster selection of the next step or process (i.e., the ability to simplify processing or components).

Applicants have discovered a new and innovative approach to wake-up processing and timing, where the host uses clock cycle based timing for signal toggling (toggle). According to this configuration, after the host drives the MDDI _ Data0 signal high at the beginning of the wake-up sequence, the host flips MDDI _ Stb from 0 to 10 microseconds, and does not wait until the signal is driven low. During the wake-up sequence, the host flips MDDI _ Stb as if the MDDI _ Data0 signal were always at a logic 0 level. This effectively removes the notion of time from the client side, and for these cycles the host changes from the 150 microsecond and 50 microsecond time periods of the first two states to 150 clock cycles and 50 clock cycles for these time periods.

The host is now responsible for driving the data line high and starts transmitting the strobe signal within 10 clock cycles as if the data line were zero. After the host has driven the data lines high for 150 clock cycles, the host drives the data lines low for 50 clock cycles while continuing to transmit the strobe signal. After the host has completed both processes, the host may begin transmitting the first subframe header packet.

On the client side, the client implementation can now use the generated clock to calculate the number of clock cycles that the data line is first high and then low. The number of clock cycles that need to be present on a data line driven high is 150 and the number of clock cycles on a data line driven low is 50. This means that for a correct wake-up sequence, the client should be able to count at least 150 consecutive clock cycles with the data line in the high state, followed by at least 50 consecutive clock cycles with the data line in the low state. Once these two conditions are met, the client can begin searching for the unique word of the first subframe. The interrupt in this mode is used as the basis for returning the counter to the initial state, where the client again looks for the first 150 consecutive clock cycles that the data line is in the high state.

As previously discussed, the client implementation of the present invention, which is based on host wake-up from hibernation, is very similar to the initial startup case, except that there is no mandatory clock rate to start at 1 Mbps. Instead, the clock rate may be set to resume from any previous rate at which the communication link was active when it entered sleep. If the host begins transmitting strobe signals as described above, the client should again be able to count at least 150 consecutive clock cycles with the data line in the high state, followed by at least 50 consecutive clock cycles with the data line in the low state. Once these two conditions have been met, the client can begin searching for unique words.

The client implementation of the present invention, which is client based wake-up from hibernation, is similar to host-based wake-up, except that it is initiated by having the client drive the data lines. The client may asynchronously drive the data lines without a clock to wake up the host device. Once the host recognizes that the data line is driven high by the client, it may begin its wake-up sequence. The client may count the number of host-generated clock cycles at the beginning or during its wake-up process. Once the client counts out 70 consecutive clock cycles that the data line is in the high state, it may stop driving the data line high. At this point, the host should also have driven the data line to a high state. The client can then count another 80 consecutive clock cycles that the data line is in the high state to bring the clock cycle that the data line is in the high state to 150 and can therefore look for 50 clock cycles that the data line is in the low state. Once these three conditions are met, the client can begin looking for unique words.

An advantage of this new implementation of the wake-up process is that it does not require a time measurement device. Whether it be an oscillator, a capacitor discharge circuit, or other such known device, the client no longer needs such an external device to determine the start-up condition. This saves money and circuit area when implementing controllers, counters, etc. on the client device board. While not necessarily as beneficial to the host as to the guest, this technique should also simplify the host in terms of Very High Density Logic (VHDL) for the core circuitry. The power consumption of using the data and strobe lines as wake-up notification and measurement sources is also very low, since there is no need to run any external circuitry for the core element to wait for a host-based wake-up. The number of cycles or clock cycles used is exemplary and other cycles may be used as will be apparent to those of ordinary skill in the art.

An advantage of this new implementation of the wake-up process is that it does not require a time measurement device. Whether it be an oscillator, a capacitor discharge circuit, or other such known device, the client no longer needs such an external device to determine the start-up condition. This saves money and circuit area when implementing controllers, counters, etc., and thus saves area on the client device board. While not necessarily as beneficial to the host as to the guest, this technique should also simplify the host in terms of Very High Density Logic (VHDL) for the core circuitry. The power consumption when using data and strobe lines as wake-up notification and measurement sources is also very low, since no external circuitry is required for the core element to wait for a host-based wake-up.

To clarify and illustrate the operation of this new technology, the timing of the various operations with respect to the clock cycles, MDDI _ Data0, MDDI _ Stb, and MDDI _ Stb are shown in fig. 68A, 68B, and 68C.

An example of the processing steps of a typical host initiated wake up without contention is shown in fig. 68A, where the events are also marked with letters A, B, C, D, E, F and G for ease of illustration. The process begins at point a when the host sends a link shutdown packet to the client device to inform it that the link is to transition to a low power sleep state. In the next step, at point B, the host rolls over (toggle) the MDDI _ Stb and continues to roll over for about 64 cycles (as required by the system design) to allow the client's processing to complete before stopping the MDDI _ Stb roll, which stops the recovered clock in the client device. The host initially also sets MDDI _ Data0 to a logic 0 level, and then after CRC disables the MDDI _ Data0 output for a range of 16-48 cycles (typically including output disable propagation delays). This may require that the high-speed receivers of MDDI _ Data0 and MDDI _ Stb in the client be placed in a low power state after 48 cycles after the CRC, and sometime before the next phase (C). At any time after the rising edge of the 48 th MDDI _ Stb cycle following the CRC of the link shutdown packet, the client puts its high speed receivers of MDDI _ Data0 and MDDI _ Stb to sleep. It is suggested that the client put its high speed receivers of MDDI _ Data0 and MDDI _ Stb to sleep before the rising edge of the 64 th MDDI _ Stb cycle following the CRC of the link shutdown packet.

The host enters the low power sleep state at point C or step C by disabling MDDI _ Data0 and MDDI _ Stb drivers and placing the host controller in the low power sleep state. The MDDI _ Stb driver may also be set to a logic 0 level (using a high impedance bias network) or to continuously toggle during sleep, as desired. The client is also in a low power level sleep state.

After some time, the host begins the link restart sequence at point D by enabling the MDDI _ Data0 and MDDI _ Stb driver outputs. The host drives MDDI _ Data0 to a logic 1 level and MDDI _ Stb to a logic 0 level for as long as it should take the drivers to fully enable their respective outputs. After these outputs reach the required logic levels, and before driving the pulse on the MMDI _ Stb, the host typically waits around 200 nanoseconds. In this way, the client has time to prepare for reception.

When the host driver is enabled and MDDI _ Data0 is driven to a logic 1 level, the host begins to flip MDDI _ Stb and makes it continue to flip 150 MDDI _ Stb cycles, as shown at point E. The host drives MDDI _ Data0 to a logic 0 level for 50 cycles, as shown by point F, and the client begins looking for a subframe header packet after MDDI _ Data0 is at a logic 0 level for 40 MDDI _ Stb cycles. The host begins transmitting data on the forward link by sending a sub-frame header packet, as shown at point G.

An example of the processing steps for a typical client initiated wake up without contention is illustrated in fig. 68B, where the events are also labeled with letters A, B, C, D, E, F, G, H and I for ease of illustration. As previously described, the process begins at point A, when the host sends a link close packet to the client informing it that the link will transition to a low power state.

At point B, the host rolls over MDDI _ Stb for 64 cycles (as required by the system design) to allow the client processing to complete before stopping MDDI _ Stb rolling, this signal is used to stop the recovered clock in the client device. The host initially also sets MDDI _ Data0 to a logic 0 level and then disables MDDI _ Data0 output after CRC in the range of 16 to 48 cycles (typically including output disable propagation delay). After 48 cycles after the CRC, and sometime before the next phase (C), the high speed receivers of MDDI _ Data0 and MDDI _ Stb in the client need to be placed in a low power state.

The host enters the low power sleep state at point C or step C by disabling MDDI _ Data0 and MDDI _ Stb drivers and placing the host controller in the low power sleep state. The MDDI _ Stb driver may also be set to a logic 0 level (using a high impedance bias network) or to continue to toggle during sleep, as desired. The client is also in a low power level sleep state.

After a certain period of time, the client starts the link restart sequence at point D by enabling the MDDI _ Stb receiver and enabling an offset in the MDDI _ Stb receiver to ensure that the state of the version of MDDI _ Stb received in the client is a logic 0 level before the host enables its MDDI _ Stb drive. The offset (offset) may need to be enabled by the client slightly ahead of when the receiver is enabled, as needed, to ensure that a valid differential signal is received and to prevent erroneous signals. The client enables the MDDI _ Data0 driver while driving MDDI _ Data0 lines to a logic 1 level. If the time to activate the offset and standard MDDI _ Data0 differential receiver is 200 nanoseconds, then both MDDI _ Data0 and MDDI _ Stb may be enabled.

Within about 1 millisecond, at point E, the host recognizes the service request pulse from the client, and the host begins the link restart sequence by enabling MDDI _ Data0 and MDDI _ Stb driver outputs. The host drives MDDI _ Data0 to a logic 1 level and MDDI _ Stb to a logic 0 level for as long as the drivers should take to enable their respective outputs. After these outputs reach the required logic levels, and before driving the pulse on the MMDI _ Stb, the host typically waits around 200 nanoseconds. Thus, the client has time to receive.

When the host driver is enabled and MDDI _ Data0 is driven to a logic 1 level, the host outputs a pulse on MDDI _ Stb for the duration of 150 MDDI _ Stb cycles, as shown at point F. When the client recognizes the first pulse on the MDDI _ Stb, it disables the offset (offset) in its MDDI _ Stb receiver. The client continues to drive MDDI _ Data0 to a logic 1 level for 70 MDDI _ Stb cycles, and disables its MDDI _ Data0 driver at point G. The client continues to drive MDDI _ Data0 to a logic 1 level for 80 additional MDDI _ Stb pulses and MDDI _ Data0 to a logic zero level at point H.

As shown at points G and H, the host drives MDDI _ Data0 to logic 0 level for 50 cycles, and the guest starts looking for a subframe header packet after MDDI _ Data0 is at logic 0 level for 40 MDDI _ Stb cycles. After driving MDDI _ Stb for 50 cycles, the host starts transmitting data on the forward link by sending a sub-frame header packet, as shown at point I.

An example of processing steps for a typical host initiated wake up with contention from the client, i.e., the client also wants to wake up the link, is illustrated in fig. 68C. For ease of illustration, the letters A, B, C, D, E, F, G, H and I are also used to mark the event. As previously described, the process begins at point a, when the host sends a link close packet to the client device to inform the client that the link is to transition to a low power state, then proceeds to point B, where the MDDI _ Stb is flipped and flipped for approximately 64 cycles (or as required by system design) to allow the processing performed by the client to complete, then proceeds to point C, when the host enters a low power sleep state by disabling the MDDI _ Data0 and MDDI _ Stb drivers and placing the host controller in a low power sleep state. After some period of time, the host begins the link restart sequence at point D by enabling MDDI _ Data0 and MDDI _ Stb driver outputs, and begins flipping MDDI _ Stb for the duration of 150 MDDI _ Stb cycles, as shown at point E.

At up to 70 MDDI _ Stb cycles after point E, here point F, the guest has not yet recognized that the host is driving MDDI _ Data0 to a logic 1 level, so the guest also drives MDDI _ Data0 to a logic 1 level. This occurs because the client needs to request service but does not recognize that the host with which it is attempting to communicate has begun a link restart sequence. At point G, the client stops driving MDDI _ Data0 and places its driver in a high impedance state by disabling its output. The host continues to drive MDDI _ Data0 to a logic 1 level and for 80 additional cycles.

The host drives MDDI _ Data0 to a logic 0 level for 50 cycles, as shown by point H, and the guest begins looking for a subframe header packet after MDDI _ Data0 is at a logic 0 level for 40 MDDI _ Stb cycles. The host begins transmitting data on the forward link by sending a sub-frame header packet, as shown at point I.

VI electrical specification of interface

In an exemplary embodiment, DATA in a non-return to zero (NRZ) format is encoded using a DATA strobe signal or DATA-STB format, thus embedding clock information in the DATA and strobe signals. The clock can be recovered without a complex phase locked loop. Data is carried by a bi-directional differential link, which is typically implemented using wire line cables, although other wires, printed wiring, or transmission elements may be used as previously described. The strobe Signal (STB) is carried over a unidirectional link that is driven only by the host. The strobe signal toggles the value (0 or 1) whenever there is a back-to-back state, 0 or 1, i.e., remains unchanged on the data line or signal.

An example of how a DATA sequence such as bit "1110001011" may be transmitted using DATA-STB (DATA-strobe) encoding is shown in graphical form in fig. 40. In fig. 40, the DATA signal 4002 is shown on the top row of the signal timing diagram, and the STB (strobe) signal 4004 is shown on the second row, both aligned each time according to the appropriate need (common starting point). Over time, when the state appearing on the DATA line 4002 (signal) changes, then the STB line 4004 (signal) remains in the previous state, so that the first '1' state of the DATA signal correlates to the first '0' state of the STB signal, i.e., its starting value. However, if the state, level of the DATA signal does not change, then the STB signal flips to the opposite state, i.e., the '1' state in this example, as would be the case if DATA provided yet another '1' value in FIG. 40. That is, there is one and only one transition between DATA and STB per bit period. Thus, when the DATA signal remains at '1', the STB signal transitions again, this time to '0', and when the level of the DATA signal changes to '0', the STB maintains this level. When the DATA signal remains at '1', the STB signal flips to the opposite state, i.e., '1' in the present example, and as the DATA signal changes or remains at a level or value, the STB signal remains or transitions, and so on.

Upon receipt of these signals, an exclusive OR (XOR) operation is performed on the DATA and STB signals to generate clock signal 4006, which is shown at the bottom of the timing diagram for comparison with the desired DATA and strobe signals. An example of a circuit that may be used to generate DATA and STB outputs or signals from input DATA at the host and then recover or retrieve DATA from the DATA and STB signals at the client is shown in fig. 41.

In fig. 41, a transmitting part 4100 is used to generate and transmit the original DATA and STB signals via an intermediate signal path 4102, while a receiving part 4120 is used to receive the signals and recover the DATA. As shown in fig. 41, to transfer DATA from the host to the client, the DATA signal is input to two D-type flip-flop circuit elements 4104 and 4106, and a clock signal is input to flip the circuits. The outputs (Q) of the two trigger circuits are then divided into differential pairs of signals MDDI _ Data0+, MDDI _ Data0-, and MDDI _ Stb +, MDDI _ Stb-, respectively, using two differential line drivers 4108 and 4110 (voltage mode). A three input exclusive nor (XNOR) gate, circuit or logic element 4112 is connected to receive DATA and the outputs of the two flip-flops and generates an output for providing a DATA input to a second flip-flop which in turn generates the MDDI _ Stb +, MDDI _ Stb-signal. For convenience, an inverting bubble is drawn on the XNOR gate to indicate that it effectively inverts the Q output of the flip-flop that generates the strobe signal.

In the receiving section 4120 of fig. 41, MDDI _ Data0+, MDDI _ Data0-, and MDDI _ Stb +, MDDI _ Stb-signals are received by each of two differential line receivers 4122 and 4124, which generate single-ended outputs from the differential signals. The output of the amplifier is then input to each input of a two-input exclusive or (XOR) gate, circuit or logic element 4126, which logic element 4126 is used to generate a clock signal. The clock signal is used to trigger each of two D-type flip-flop circuits 4128 and 4130 for receiving a delayed version of the DATA signal through a delay element 4132, one (4128) of the D-type flip-flops generating a DATA '0' value and the other (4130) generating a DATA '1' value. The clock also has a separate output from the XOR logic. Since clock information is distributed to the DATA and STB lines, the signal transitions between states are each slower than half the clock rate. Since the clock is reproduced using exclusive-or processing of the DATA and STB signals, the system is practically tolerant of twice the amount of skew between the input DATA and the clock, as compared to the case where the clock signal is sent directly via a single dedicated DATA line.

The MDDI data pairs, MDDI _ Stb + and MDDI _ Stb-signals, operate in a differential mode to maximize immunity from the negative effects of noise. Each of the differential pairs is terminated in parallel using the characteristic impedance of the cable or wire carrying the signal. Typically, all of the parallel termination resistors reside in the client device. This is similar to a differential receiver for forward traffic (data sent from the host to the client), but it is for reverse traffic (data sent from the client to the host) at the driven end of the cable or other conductor or transport element. For reverse traffic, the signal is driven by the client, reflected by a high impedance receiver at the host, and terminated at the client. This avoids the need for a double-ended resistor which would increase current consumption. It also operates at data rates greater than the inverse of the cable round trip delay. The MDDI _ Stb + and MDDI _ Stb-wires or signals are driven only by the host.

An exemplary configuration of components that may be used to implement the drivers, receivers, and termination resistors that convey signals as part of the MDDI interface of the present invention is shown in fig. 42. This exemplary interface uses low voltage detection, here 200mV, with a voltage swing less than 1 volt and low power consumption. The driver for each signal pair has a differential current output. When an MDDI packet is received, the MDDI _ Data and MDDI _ Stb pair uses a conventional differential receiver and the voltage threshold is zero volts. In the sleep state, the driver outputs are disabled and the parallel termination resistors pull the voltage on each signal pair up to zero volts. During sleep, the dedicated receiver on the MDDI _ Data0 pair has a positive 125mV offset input threshold that causes the sleep line receiver to interpret the non-logic zero level with the undriven signal pair.

Sometimes, the host or the guest simultaneously drives a differential pair to a logic 1 level or a logic 0 level in order to ensure that the logic level on the differential pair is valid when the data flow direction changes (from host to guest or from guest to host). The output voltage range and output specification should still be sufficient for driving the output simultaneously to the same logic level. In some systems, a small current must also be driven into the terminated differential pair to create a small offset voltage at a particular time during sleep and when the link is awakened from sleep. In theseIn the case, the current level of the enabled offset current bias drive is represented as: i is_ESD-and-Rx-an internal ESD diode and a differential receiver input, wherein I_ESD-and-Rx≤1μA；I_Tx-Hi-Z-a differential driver output in a high impedance state, wherein I_Tx-Hi-Z≤1μA；I_external-ESDLeakage through external ESD protection diodes, where in general I_external-ESD≤3μA。

Fig. 47 shows each of these leakage currents. When all leakage occurs simultaneously, the pull-up and pull-down circuits must reach the minimum differential voltage for the worst-case leakage condition described above. The total leakage is ≦ 4 μ A for the internal mode without external ESD protection diode, and ≦ 10 μ A for the external mode with external ESD protection.

Tables VIIa-VIId depict the electrical parameters and characteristics of the differential line driver and line receiver for one exemplary embodiment. Functionally, the driver passes the logic level on the input directly to the positive output and the inverse of the input to the negative output. The delay from input to output is well matched to a differential line driven in a differential manner. In most implementations, the voltage swing on the output is smaller than the swing on the input, thereby minimizing power consumption and electromagnetic radiation. In one embodiment, the minimum voltage swing is about 0.5V. However, other values are also available, as is known to those skilled in the art, and the inventors contemplate that in some embodiments, smaller values may also be possible depending on design constraints.

The differential line receiver has the same characteristics as the high-speed voltage comparator. In FIG. 41, the input without bubbles is the positive input, and the input with bubbles is the negative input. If (V)_{Input device}+)-(V_{Input device}-) is greater than 0, then the output is a logic 1. Another way to describe this is to have a very large (virtually infinite) gain, differential amplifier with the output clamped at logic 0 and 1 voltage levels.

The delay skew between different pairs should be minimized in order to operate the differential transmission system at the highest speed.

TABLE VIIa

Electrical specification of host transmitter

Parameter(s)	Description of the invention	Minimum value	Maximum value	Unit of
					Voutput-range	Host driver output voltage range allowed relative to host ground	0.35	1.60	V
IOD+	Driver differential output high current (when driving terminal transmission line)	2.5	4.5	mA
					IOD-	Driver differential output low voltage (when driving terminal transmission line)	-4.5	-2.5	mA
TRise-Fall	Measured rise and fall time of driver output in differential mode (between 20% and 80% amplitude)	425	Note that item 1	psec
					Tskew-pair	Deviation between positive and negative outputs of the same differential pair (deviation within pair)		125	psec
TDifferential-skew	Peak delay deviation between one differential pair and another differential pair		See above	psec
					TA	Jitter, bit boundary to intermediate cross point	0	TB-283	psec
TB-TP0-DRVR	Jitter, bit boundary to minimum output level	0	See above	psec

Note 1: the maximum rise and fall time is either 30% of the interval in which a bit is sent on a differential pair, or 100nsec, whichever is smaller.

TABLE VIIb

Client transmitter electrical specification

Parameter(s)	Description of the invention	Minimum value	Maximum value		Unit of
						Voutput-Range-Ext	Allowed client driver output voltage range with respect to client ground (external mode)	0	1.25		V
Voutput-Range-Int	Allowed client driver output voltage range with respect to client ground (internal mode)	0.35	1.60		V
						IOD+	Driver differential output high voltage (when driving pull-up and pull-down circuit equivalent circuits present in host and client)	2.5	4.5		mA
IOD-	Driver differential output low voltage (when driving pull-up and pull-down circuit equivalent circuits present in host and client)	-4.5	-2.5		mA
						TRise-Fall	Measured rise and fall time of driver output in differential mode (between 20% and 80% amplitude)	425	Note that item 1		psec
Tskew-pair	Deviation between positive and negative outputs of the same differential pair (deviation within pair)		125		psec
						TDifferential-skew	Peak delay deviation between one differential pair and another differential pair		See above		psec
TA	Jitter, bit boundary to intermediate cross point	0	TB-283		psec
						TB-TP4-DRVR	Jitter, bit boundary to minimum output level	0	See above		psec

Note 1: the maximum rise and fall time is either 30% of the interval in which a bit is sent on a differential pair, or 100nsec, whichever is smaller.

TABLE VIIc

Client receiver electrical specification

Parameter(s)	Description of the invention	Minimum value	Typical value	Maximum value	Unit of
						VIT+	Receiver differential input high threshold voltage		0	50	mV
VIT-	Receiver differential input low threshold voltage	-50	0		mV
						VIT+	Receiver differential input high threshold voltage (offset for sleep wakeup)		125	175	mV
VIT-	Receiver differential input low threshold voltage (offset for sleep wakeup)	75	125		mV
						VInput-Range	Receiver input voltage range allowed relative to client ground	0		1.65	V
Rterm	Parallel terminal resistance value	98	100	102	Ω
						Iin	Input drain current	-10		10	μA
Cpad	To the client sideCapacitor (Note 1)			5	pF
						Cdiff	Capacitance between two signals of a differential pair (Note 1)			1	pF
Tskew-pair-INT	Differential receiver induced skew (intra-pair skew) between the positive and negative inputs of the differential receivers of the same differential pair. Internal mode			250	psec
						Tskew-pair-EXT	Internal bias, external mode			50	psec

TDifferential-Skew	Peak delay skew between one differential pair and another differential pairSeparation device			See above
						TA	Jitter, bit boundary to intermediate cross point			TB-38.5	psec
TB-TP4-DRVR-INT	Jitter to minimum output level, bit boundary (internal mode)	0		See above	psec
						TB-TP4-DRVR-EXT	Jitter to minimum output level, bit boundary (external mode)	0		See above	psec

TABLE VIId

Host receiver electrical specification

Parameter(s)	Description of the invention	Minimum value	Typical value	Maximum value	Unit of
						VIT+	Receiver differential input high threshold voltage (no offset)		0	50	mV
VIT-	Receiver differential input low threshold voltage (no offset)	-50	0		mV
						VIT+	Receiver differential input high threshold voltage (sleep wake-up offset)		125	175	mV
VIT-	Receiver differential input low threshold voltage (sleep wake-up offset)	75	125		mV
						VInput-Range	Receiver input voltage range allowed relative to host ground	0		1.65	V
Iin	Input drain current (eliminating sleep bias)	-10		10	μA
						Cpad	Capacitor to host ground			5	pF
Cdiff	Capacitance between two signals of a differential pair			1	pF
						Tskew-pair	Differential reception of the same differential pair			250	psec

	Skew caused by differential receiver between positive and negative inputs of the device (skew within pair)
						Tskew-pair-EXT	Internal bias, external mode			50	psec
TA	Jitter, bit boundary to intermediate cross point			TB-38.5	psec
						TB-TP0-DRVR-INT	Jitter to minimum output level, bit boundary (external mode)			See above	psec
TB-TP0-DRVR-EXT	Jitter to minimum output level, bit boundary (external mode)			See above	psec

In fig. 42, host controller 4202 and client or display controller 4204 communicate packets via communication link 4206. The host controller employs a series of three drivers 4210, 4212 and 4214 to receive host DATA and STB signals to be transmitted and to receive client DATA signals to be transmitted, while the client employs three drivers 4230, 4232 and 4234. The driver (4212) responsible for host DATA transfer employs an enable signal input to allow activation of the communication link, typically only when transfer from the host to the client is required. Since the STB signal is formed as part of the data transfer, no additional enable signal is employed for this driver (4212). The input of each of the client DATA and STB receiver (4132, 4230) drivers has a termination impedance or resistor 4218 and 4220, respectively, connected across (facecross) thereto. The driver 4234 in the client controller is used to prepare data signals to be transmitted from the client to the host, wherein the input side driver 4214 processes the data.

Dedicated receivers (drivers) 4216 and 4236 are coupled or connected with the DATA lines and generate or use the 125mV voltage offset previously discussed as part of the sleep control discussed elsewhere. This offset causes the dormant line receiver to interpret the undriven signal pair as a logic 0 level.

The above-described drivers and impedances may be formed as discrete components or as part of a circuit module, or as an Application Specific Integrated Circuit (ASIC) that acts as a more cost effective encoder or decoder solution.

It can be easily seen that: power is transferred from the HOST device to the client device or display via a pair of conductors using signals labeled HOST _ Pwr and HOST _ Gnd. The HOST _ Gnd portion of the signal serves as a reference ground and power return path or signal for the client device. The HOST _ Pwr signal serves as the power source for the client device, which is driven by the HOST device. In an exemplary configuration, the client device is allowed to use up to 500mA for low power applications. The HOST _ Pwr signal may be provided from a portable power source, such as, but not limited to, a lithium ion type battery or battery pack resident in the HOST device, and may range from 3.2 to 4.3 volts with respect to HOST _ Gnd.

Timing characteristics

A. Overview

The steps and signal levels shown in fig. 43a, 43b and 43c, respectively, are used by the host or client to enter a sleep state (no service is requested, expected or needed) and to obtain service from the host for the client. In fig. 43a, 43b and 43c, the first part of the signals shown show a link down packet transmitted from the host and then driving the data line to a logic 0 state using a high impedance bias circuit. A client or host that has disabled its drive does not transfer data. Since MDDI _ Stb is active during the link down packet, a series of strobes of the MDDI _ Stb signal line can be seen at the bottom. When the host drives the bias circuit and logic to zero, the logic level becomes 0 once the packet is over. This situation represents the last signal transmitted from the host or the end of service from the host, and this may occur at any time in the past, and this is included to show the state of the signal before the service was previously suspended and before the service started. Such a signal may be sent, if required, simply to reset the communication link to the appropriate state without requiring a 'known' prior communication already by the host device.

As shown in fig. 43a, and as discussed above for the link close packet, in the low power sleep state, the MDDI _ Data0 driver is disabled to enter a high impedance state starting after the 16 th to 48 th MDDI _ Stb cycles or pulses following the last bit of the all-zero field in the link close packet. For type 2, type 3, or type 4 links, the MDDI _ Data 1-MDDI _ DataPwr7 signals are also placed in a high impedance state while the MDDI _ Data0 driver is disabled. As already described in the definition of the all-zero field, the MDDI _ Stb flips 64 cycles after the MSB of the CRC field of the link shutdown packet (or as desired by the system design) to enable the processing of the client and the orderly shutdown in the client controller. One cycle is a low-to-high transition followed by a high-to-low transition, or a high-to-low transition followed by a low-to-high transition. After sending the all zero field, the MDDI _ Data0 and MDDI _ Stb driver in the host are disabled and the host enters a low power sleep state. After a period of time, with MDDI _ Data0 and MDDI _ Stb line or driver output enabled, the host begins the link restart sequence as shown in fig. 43b and 43c and begins to flip MDDI _ Stb as part of a host or client initiated wake-up request.

As shown in FIG. 43b, after a period of time has elapsed with the output signals of the drivers for MDDI _ Data0 and MDDI _ Stb disabled, the host enables the period of time t by its MDDI _ Stb driver_{stb-data-enb1}Starting service or waking from sleep, during which time the line is driven to a logic zero level until it is fully enabled and then its MDDI _ Data0 driver is enabled. After MDDI _ Data0 reaches the high or logic 1 level (after a time period t_{client-startup}Occurs), the host maintains MDDI _ Stb at a logic zero level. At a time period t_{client-startup}At the end, the host flips the MDDI _ Stb signal or line. At a time period t_restart-highIn turn, the host drives MDDI _ Data0 line high, i.e., logic 1 level, while the guest does not drive MDDI _ Data0, then for a time period t_restart-lowThe MDDI _ Data0 line is driven low, i.e., a logic zero level. Thereafter, the first forward traffic starts with a sub-frame header packet, and then, the forward traffic packet is transmitted. At a time period t_restart-lowAnd subsequent subframe header packet periods, the MDDI _ Stb signal is active.

As shown in FIG. 43c, after a period of time has elapsed with the output signals of the drivers for MDDI _ Data0 and MDDI _ Stb disabled, the driver is disabled by the host for a period of time t before its MDDI _ Stb is enabled _{stb-data-enb1}The offset or output signal in the MDDI _ Stb receiver is enabled internally and the client makes a service request or wakes up from sleep. The client then enables its MDDI _ Data0 driver for a time period t_host-detectDuring this time, the lines are driven to a logic zero level before the host starts the MDDI _ Stb flip.

Before the host detects the request, a certain amount of time may elapse or be required, which is denoted as "t_host-detect", thereafter, the host holds the MDDI _ Stb at a logic zero level for a period of time t_stb-startupResponds and then the host responds for a time period t_restart-highMDDI _ Data0 is driven to a logic 1 or high level, starting to flip MDDI _ Stb with the link startup sequence. When the client finds the first pulse on the MDDI _ Stb, it disables the offset in its MDDI _ Stb receiver. The client continues to drive MDDI _ Data0 to a logic 1 level or time period t_{client-detect}Until it detects that the host drives the line. At this point, the guest no longer maintains (de-assert) the request and its MDDI _ Data0 driver is disabled, so the output from the guest also goes to the 0 logic level and the host drives MDDI _ Data 0. As previously described, during the time period "t_restart-highInternally, the host continues to drive MDDI _ Data0 to a logic '1' level, after which the host drives the MDDI _ Data0 line low and for "t _restart-low"time period, after which the first forward traffic starts with a sub-frame header packet. At t_restart-lowThe MDDI _ Stb signal is active during a time period and during a subsequent subframe header packet.

Table VIII shows representative times or treatment periods for the lengths of the various periods described above, as well as exemplary minimum sumsA relationship between maximum data rates, wherein:where Link _ Data _ Rate is the bit Rate of a single Data pair.

TABLE VIII

Parameter(s)	Description of the invention	Minimum value	Typical value	Maximum value	Unit of
						1/tBIT-min-perf	Link data rate for lowest performing device	0.001		1.1	Mbps
1/tBIT-max-perf	Maximum link data rate range of external device	0.001		400	Mbps
						1/tBIT-max-perf	Maximum link data rate range of internal device	0.001		550	Mbps
	Reverse link data rate	0.0005		50	Mbps
						tBIT	Period of forward link data bits in external mode	2.5		106	nsec
tBIT	Period of forward link data bits in intra mode	1.8		106	nsec
						trestart-high	High burst period of host link restart	140	150	160	Stb clock
trestart-low	Low burst period of host link restart	50	50	50	Stb clock
						tstb-data-enabl	MDDI _ Stb fully enabled to the link with MDDI _ Data0 enabled	0			Microsecond range

	Restart sequence
						tclient-startup	The time that the host holds MDDI _ Stb at logic 0 level after MDDI _ Data0 reaches logic high level	200			Nanosecond
thost-detect	Time to rollover from MDDI _ Data0 high to MDDI _ Stb	0		1000	Microsecond range
						tclient-detect	The time when the client detects MDDI _ Data0 as a logic high performance device	60		80	stb clock
tstb-startup	Time to hold MDDI _ Stb at logic 0 level before host starts MDDI _ Stb flip	100			Nanosecond

Those skilled in the art will readily appreciate that the functions of the various elements illustrated in fig. 41 and 42 are well known, and the functions of the elements in fig. 42 are confirmed by the timing diagrams in fig. 43a, 43b and 43 c. The details of the series connection of the termination resistance and the sleep resistance shown in fig. 42 are omitted from fig. 41, because the information is not necessary to describe how to perform data-strobe encoding and recover the clock from it.

B. Data-strobe sequential forward link

The switching characteristics for transferring data from the host driver output on the forward link are shown in table IX-1. Table IX gives the minimum and maximum values required against the typical times at which certain signal transitions occur in tabular form. For example, a transition occurs from the beginning to the end of a data value ('0' or '1' output) (referred to as t)_{tdd-(host-output)}Data0 to Data0 transition) is t_tbitAnd the minimum time is about t_tbit-0.5 ns and a maximum time of about t_tbit+0.5 ns. The relative spacing between transitions on Data0, other Data lines (DataX), and strobe lines (Stb) is illustrated in fig. 44, which shows the transition intervals of Data0 to strobe, strobe to Data0, Data0 to non-Data 0, non-Data 0 to non-Data 0, non-Data 0 to strobe, and strobe to non-Data 0, referred to as t-Data, respectively _{tds-(host-output)}、t_{tss-(host-output)}、t_{tsd-(host-output)}、t_{tddx-(host-output)}、t_{tdxdx-(host-output)}、t_{tdxs-(host-output)}And t_{tsdx-(host-output)}。

TABLE IX-1

Parameter(s)

Description of the invention

Minimum value

Typical value

Maximum value

Unit of

ttdd-(host-output)	Data0 to Data0 transition	ttbit-0.5	ttbit	ttbit+0.5	Nanosecond
						ttds-(host-output)	Data0 to strobe transition	ttbit-0.8	ttbit	ttbit+0.8	Nanosecond
ttss-(host-output)	Strobe-to-strobe transition	ttbit-0.5	ttbit	ttbit+0.5	Nanosecond
						ttsd-(host-output)	Strobe to Data0 transition	ttbit-0.8	ttbit	ttbit+0.8	Nanosecond
ttddx-(host-output)	Data0 to non-Data 0 transition		ttbit		Nanosecond
						ttdxdx-(host-output)	non-Data 0 to non-Data 0 transition	ttbit-0.5	ttbit	ttbit+0.5	Nanosecond
ttdxs-(host-output)	non-Data 0 to strobe transition		ttbit		Nanosecond
						ttsdx-(host-output)	Gated to non-Data 0 transition		ttbit		Nanosecond

Typical MDDI timing requirements for client receiver inputs carrying the same signal on the forward link are shown in table IX-2. Since the same signals are discussed except for the time delays, no new figures are needed to illustrate the signal characteristics or meanings of the various labels, as will be understood by those skilled in the art.

TABLE IX-2

Parameter(s)	Description of the invention	Minimum value	Typical value	Maximum value	Unit of
						ttdd-(display-input)	Data0 to Data0 transition	ttbit-1.0	ttbit	ttbit+1.0	Nanosecond
ttds-(display-input)	Data0 to strobe transition	ttbit-1.5	ttbit	ttbit+1.5	Nanosecond
						ttss-(display-input)	Strobe-to-strobe transition	ttbit-1.0	ttbit	ttbit+1.0	Nanosecond
ttsd-(display-input)	Strobe to Data0 transition	ttbit-1.5	ttbit	ttbit+1.5	Nanosecond
						ttddx-(host-output)	Data0 to non-Data 0 transition		ttbit		Nanosecond
ttdxdx-(host-output)	non-Data 0 to non-Data 0 transition		ttbit		Nanosecond
						ttdxs-(host-output)	non-Data 0 to strobe transition		ttbit		Nanosecond
ttsdx-(host-output)	Gated to non-Data 0 transition		ttbit		Nanosecond

Fig. 45 and 46 illustrate the delay that exists in response when the host disables or enables the master drive, respectively. In the case where the host transmits certain packets, such as reverse link encapsulation packets or round trip delay measurement packets, the host disables the line driver after the required packets, such as the already transmitted parameters CRC, strobe alignment, and all zero packets illustrated in fig. 45, are transmitted. However, as shown in fig. 45, the state of the line does not have to be switched instantaneously from '0' to the required high value, although this can be achieved with some existing control or circuit elements, but over a period of time called the host driver disable delay period to respond. Although this switching can in fact be done immediately, so that this time period is 0 nanoseconds (nsec) in length, it can also easily extend for a longer period, i.e. 10 nanoseconds as the maximum period length required, which is done during guard time 1 or a turnaround 1 packet period.

Referring to fig. 46, one sees a change in signal level when the host driver is enabled to transmit packets such as reverse link encapsulation packets or round trip delay measurement packets. Here, after guard time 2 or turnaround 2 packet periods, the host driver is enabled and begins driving level (here '0') approaching or reaching this value after a period of time called the host driver enable delay period, which occurs during the driver re-enable period before the first packet is sent.

A similar process occurs for driver and signaling for client devices, here displays. The general criteria for the lengths of these periods and their respective relationships are shown in table X below.

Table X

Description of the invention	Minimum value	Maximum value	Unit of
				Host driver disable delay	0	10	Nanosecond
Host driver enable delay	0	2.0	Nanosecond
				Display deviceDevice driver disable delay	0	10	Nanosecond
Display driver enable delay	0	2.0	Nanosecond

C. Host and client output enable and disable times

The switching characteristics and relative timing relationships of the host and client output enable and disable times or operations with respect to the reverse link encapsulation packet structure and period are shown in fig. 48. The driver output function or operation is labeled as: t is t_host-enableRepresenting a host output enable time; t is t_host-disableRepresenting a host output disable time; t is t_{client-enable}Output an enable time on behalf of the client; t is t_{client-disable}The disable time is output on behalf of the client. Typical times for a particular signal transition are discussed below. The minimum period of these operations will be 0 nanoseconds, with typical or maximum values being determined by the system design in which the interface is employed, and may be on the order of 8 nanoseconds or more.

Table XI below shows the general guidelines for the lengths of these periods (host and client enable/disable times) and their respective relationships.

Parameter(s)	Description of the invention	Minimum value	Typical value	Maximum value	Unit of
						thost-enable	Host output enable time	0		24·tBIT	Nanosecond
thost-disable	The host outputs the disable time, turning to the full length of 1 field	0		24·tBIT	Nanosecond
						tclient-enable	Client output enable time, full length to 1 field	0		24·tBIT	Nanosecond
tclient-disable	Client output disable time measured from last bit of steering 2 field	0		24·tBIT	Nanosecond

Implementation of link control (link controller operation)

A. State machine packet processor

Packets transmitted over an MDDI link are typically delivered very quickly at a rate of about 300Mbps or more, such as 400Mbps, although lower rates can certainly be supported when needed. For currently available (economical) general-purpose microprocessors and the like, the speed of this type of bus or transfer link is too high to control. A practical implementation for implementing this type of signalling therefore consists in parsing the incoming packet stream with a programmable state machine in order to produce packets that are transmitted or redirected to the appropriate audio-video subsystem to which they should go. Such devices are well known and use circuitry that is typically dedicated to a limited number of operations, functions or states in order to achieve the desired high speed or ultra high speed operation.

A general purpose controller, processor, or processing element may be used to more appropriately act on or manipulate certain information having lower speed requirements, such as control or status packets. Upon receipt of those packets (control, status or other predefined packets), the state machine should have them passed to the general purpose processor via a data buffer or similar processing element so that the packets can be manipulated to provide the desired results (effects) while the audio and visual packets are being transmitted to their appropriate destinations for action. The states or state machines discussed below may also be implemented using software control of such devices, typically as programs stored on memory elements or media, if microprocessors or other general purpose controllers, processors or processing elements capable of higher data rate processing capabilities are manufactured in the future.

In some embodiments, the general processor functions may be implemented using processing power or excess cycles available from a microprocessor (CPU) or controller in a computer application, a processor, a Digital Signal Processor (DSP), an application specific circuit, or an ASIC found in a wireless device in a manner very similar to some modems or image processors using the processing power of a CPU found in a computer to perform some functions and to reduce the complexity and cost of hardware. However, such sharing or use of cycles can negatively impact processing speed, timing, or overall operation of such elements, and thus in many applications dedicated circuits or elements are more suitable for such general purpose processing.

In order to be able to view image data on a display (microdisplay) or reliably receive all packets sent by the host device, the client signal processing is synchronized with the forward link channel timing. That is, the signals arriving at the client and client circuitry are substantially synchronized in time for proper signal processing. A high-level diagram of the signal processing steps or states of a method implementation in which such synchronization may be implemented is illustrated in fig. 49. In fig. 49, it is shown that the possible forward link synchronization "states" for the state machine 4900 are classified into one "asynchronous frame state" 4904, two "get synchronization states" 4902 and 4906, and three "in-synchronization states" 4908, 4910 and 4912.

As shown in a start step or state 4902, a display or client, such as a rendering device, starts in a preselected "no sync" state and searches for a unique word in the detected first sub-frame header packet. It should be noted that this unsynchronized state represents a minimum communication setting or a "fall-back" setting when selecting a type 1 interface. When the unique word is found during the search, the client saves the subframe length field. The CRC bits are not checked while processing this first frame or until synchronization is achieved. If this sub-frame length is zero, then the synchronization state processing therefore continues to state 4904, here labeled "asynchronous frame" (async frame) state, which indicates that synchronization has not been achieved. In fig. 49, this step is labeled as having cond 3, or condition 3, in the process. Additionally, if the frame length is greater than zero, then the synchronization state processing proceeds to state 4906 where the interface state is set to "one synchronization frame found". In fig. 49, this step in the process is labeled as having cond 5, or condition 5. Additionally, if the state machine sees a frame header packet and determines that it has a good CRC for frames with a frame length greater than zero, then the process proceeds to the "find a sync frame" state. In fig. 49, it is marked as conformant cond6, or condition 6.

In each case where the system is in a state other than "out of sync", when it is determined that the subframe header packet has a good CRC result, the interface state changes to "in sync" state 4908. In fig. 49, this step in the process is marked as cond 1, or condition 1, being satisfied. On the other hand, if the CRC in any packet is incorrect, then the synchronous state processing continues or returns to the interface state 4902 of the "asynchronous frame" state. In the state diagram of fig. 49, this part of the process is marked as conformant 2, or condition 2.

B. Synchronizing acquisition time

The interface may be configured to allow a certain number of "synchronization errors" before deciding to lose synchronization and return to the "unsynchronized frame" state. In FIG. 49, once the state machine has reached the "in sync state" and no errors are found, it will continuously encounter the result of cond 1 and remain in the "in sync" state. However, once a cond 2 result is detected, the process changes the state to a "one-sync-error" state 4910. At this point, if the process detects the result of yet another cond 1, then the state machine returns to the "in sync" state, otherwise it encounters the result of yet another cond 2 and moves to the "two sync error" state 4912. Further, if cond 1 occurs, processing returns the state machine to the "in-sync" state. Otherwise, a further cond 2 is encountered and the state machine returns to the "unsynchronized" state. It will also be appreciated that if the interface encounters a "link down packet", this will cause the link to terminate the data transfer and return to the "unsynchronized frame" state, as if nothing can be synchronized with it, which in the state diagram shown in fig. 49 is referred to as cond 4 compliant.

It should be understood that there may be a duplicate "false copy" (false) of the unique word, which may occur at some fixed location within the subframe. In those cases, it is extremely unlikely that the state machine will synchronize to this subframe, since the CRC on the subframe header packet must also be valid in order for the MDD processing to go to the "in-sync" state when processing is done.

The subframe length in the subframe header packet may be set to zero to indicate that the host transmits only one subframe before the link is shut down and the MDD interface is set or configured to the idle sleep state. In this case, the client must receive packets via the forward link immediately after detecting the sub-frame header packet because only one sub-frame is sent before the link transitions to the idle state. In normal or typical operation, the sub-frame length is non-zero and the client processes only forward link packets, while the interface is in those states which are collectively shown as "in sync" states in fig. 49.

A client device in external mode may be connected to a host and the host is already sending a forward link sequence. In this case, the client must synchronize to the host. The time required for a client to synchronize to a forward link signal varies with the subframe size and the forward link data rate. When the sub-frame size is larger, there is a greater likelihood that a "false copy" of the unique word that is part of the random data or more is detected in the forward link. Also, when the forward link data rate is slow, the ability to recover from error detection is lower, and the time it takes to perform this operation is longer.

For one or more embodiments, it is recommended or understood that the MDDI host should perform some additional steps to ensure that the MDDI reverse link is stable before it stops forward link transmission to enter a low power mode or completely shut down the link.

One such problem may arise: if the round trip delay measurement used by the host is incorrect, this may result in a failure to receive all reverse data transport streams from the client at a later time, even if the forward link appears to be good. This occurs when the client is not synchronized with the forward link or if the host sends a round trip delay measurement packet, the round trip delay is affected by a correspondingly large change in the propagation delay of the differential driver and receiver due to extreme ambient temperature changes. Intermittent cable or splice contact failures may also cause the client to temporarily lose synchronization and then regain synchronization, during which time it may not receive round trip delay measurement packets. Subsequent reverse link packets cannot be decoded correctly by the host.

Another class of problems that can occur is: if the client temporarily loses synchronization, the host sends a link shutdown packet before the client can regain synchronization. When the client cannot enter the sleep state, the host will be in the sleep state because it has not received the link shutdown packet and has no clock because the link is in the sleep state.

One technique or embodiment that may be used to overcome these problems is: the host is enabled to ensure that the client is synchronized with the forward link before placing the link into a dormant state. If the MDDI host is unable to do so or has no opportunity, for example, when it is dead or has a link down or fails due to the separation, disconnection, or disconnection of cables, conductors, or splices occurring during operation, the host should try to ensure that the client is synchronized before starting the round trip delay measurement process or sending reverse link encapsulation packets.

The host may observe the CRC error count field in the client request and status packets sent by the client to determine the integrity of the forward link. The host requests the packet from the client. However, if there is a major link failure or disruption, the request will likely not be responded to because the client cannot decode the packet correctly, or may not receive it at all. The request for CRC error counting using the client request and status packet sent in the reverse link encapsulation packet serves as a first integrity check, equivalent to a first thread. In addition, the host may send a round trip delay measurement packet to confirm whether the assumption about the client losing synchronization is valid. If the client does not respond to the round trip delay measurement packet, the host may conclude that the client has lost synchronization and may then initiate a process to bring it back into synchronization.

Once the host concludes that it is likely that the host will lose synchronization with the forward link, it waits until the next subframe header before attempting to send any packets other than the filler packets. This is done to allow the client sufficient time to detect or look for the unique word contained in the sub-frame header packet. Thereafter, the host may assume that the client has reset itself because it did not find the unique word at the correct location. At this point, the host may follow the sub-frame header packet with a round trip delay measurement packet. If the client still does not respond correctly to the round trip delay measurement packet, the host may repeat the resynchronization process. The correct response is that the client sends the specified sequence back to the host in a round trip delay measurement packet. If the sequence is not received, reception of the reverse data in the reverse link encapsulation packet will fail. A continuing failure of this nature may indicate some other system error that must be resolved in other ways and is not part of the link synchronization at this point.

However, if the host still sees corrupted data in a successful round trip delay measurement packet, or there is no response in the reverse link encapsulation packet, it should confirm that the reverse data sample is correct by resending a round trip delay measurement packet. If this is not successful after several attempts, it is proposed for one embodiment that the host decrease the reverse data rate by increasing the reverse rate divisor value.

The host should perform the link failure detection and link resynchronization steps described above before placing the MDDI link into a dormant state. This can generally ensure that the round trip delay measurement packet performed when the link is later restarted is successful. If the host has no reason to suspect a link failure and the client reports a correct response to the reverse link encapsulated packet and zero forward link CRC errors, then the host can assume that everything is working or functioning properly (e.g., no link failure) and continue the power down/sleep process.

Another way in which the host can test synchronization is: having the host send a round trip delay measurement packet and acknowledge the correct response from the client. If the host receives a correct response, it can be reasonably assumed that the client is successfully interpreting the forward link packet.

C. Initialization

As previously described, at "start-up," the host configures the forward link to operate at or just below the minimum required or required data rate of 1Mbps, and configures the subframe length and media frame rate as appropriate for a given application. That is, both the forward and reverse links begin to operate using the type 1 interface. These parameters are typically only temporarily used when the host determines the capabilities or desired configuration of the client display (or other type of client device). The host sends or transmits a sub-frame header packet via the forward link followed by a reverse link encapsulation packet that sets bit '0' of the request flag to a value of one (1) to request the display or client to respond with a client capability packet. Once the display is synchronized on (or with) the forward link, it sends client capability packets and client request and status packets via the reverse link or channel.

The host examines the contents of the client capability packet to determine how to reconfigure the link for optimal consideration or required level of performance. The host checks the protocol version and minimum protocol version fields to confirm that the host and client use protocol versions that are compatible with each other. The protocol version is typically the first two parameters that are saved as a client capability packet, so compatibility can be determined even if other elements of the protocol are not compatible or cannot be fully understood to be compatible.

In the internal mode, the host can know the client parameters in advance without receiving a client capability packet. The link can be restarted at any data rate that enables both the host and the client. In many embodiments, the system designer will likely choose to start the link at the highest data rate achievable to speed up data transfer, but this is not necessary and in many cases does not need to be used. For internal mode operation, the frequency of strobes used during link restart from the sleep state typically coincides with the expected rate.

CRC processing

The packet processor state machine ensures that the CRC checker is properly or correctly controlled for all packet types. When a CRC comparison is detected that produces one or more errors, a CRC error counter is also incremented and reset at the beginning of each subframe being processed.

E. Optional out-of-sync verification

While the above series of steps or states can produce higher data rates or throughput speeds, applicants have discovered that: even higher data rates or throughput may also be effectively achieved using other alternative settings or changes in conditions that the client uses to declare loss of synchronization with the host. The new embodiment of the invention has the same basic structure but the conditions for changing states are changed. In addition, a new counter is implemented to facilitate subframe synchronization checks. These steps and conditions are presented with respect to fig. 63, which shows a series of states and conditions for establishing the operation of a method or state machine. For clarity, only the "get synchronization status" and "in synchronization status" portions are shown. In addition, since the resulting states are substantially identical to the state machine itself, they are given the same reference numerals. However, the conditions that change state (and state machine operation) change somewhat, so for clarity of both figures, all are renumbered (1, 2, 3, 4, 5 and 6 versus 61, 62, 63, 64, and 65) to facilitate identification of the differences. Since the asynchronous frame state is not considered in this discussion, there is a state (4904) and condition (6) that is not used in this figure.

In fig. 63, the system or client (for display or presentation) starts with state machine 5000 in a preselected "unsynchronized" state 4902, which is the same as fig. 49. The first state change to change state from the unsynchronized condition 4902 is made under condition 64 where the synchronized mode is found. Assuming that the CRC of the sub-frame header is also passed on this packet (conditional 61 is met), the state of the packet processor state machine may change to in-sync state 4908. A synchronization error, condition 62, will cause the state machine to switch to state 4910 and to state 4912 when this condition occurs a second time. However, it has been found that any CRC failure of an MDDI packet will cause the state machine to move out of the in-sync state 4908 and into a sync error state 4910. Yet another CRC failure of any MDDI packet may result in a move to two synchronization failure states 4912. A packet decoded with the correct CRC value will cause the state machine to return to in-sync state 4908.

Where a change has occurred is the use of a CRC value or CRC determination for 'per' packets. That is, instead of just observing the sub-frame header packet, the state machine is made to look at (look at) the CRC value of each packet to determine loss of synchronization. In this structure or process, loss of synchronization is determined not using a unique word and only using a subframe header CRC value.

This new interface implementation allows the MDD interface link to more quickly identify synchronization failures and thus recover from them more quickly as well.

To make such a system more robust, the client should also add or utilize a subframe counter. The client then checks for the presence of the unique word when the unique word is expected to arrive or appear in the signal. If the unique word does not occur at the correct time, the client can more quickly identify that a synchronization failure has occurred, much faster than it must wait for a few (here three) packets, much longer than the sub-frame length, or period. If the test on the unique word indicates that it is not present, in other words, the timing is incorrect, the client immediately declares that the link is out of sync and moves to an out of sync state. The process of checking for the presence of the correct unique word adds a condition 65(cond65) to the state machine that the unique word is incorrect. If a sub-frame packet is expected to be received on the client but not matched, the client may immediately enter the unsynchronized state 4902, thereby saving additional time waiting for multiple synchronization errors (condition 62), which are typically encountered through states 4910 and 4912.

This change uses an additional counter or a counting function in the client core to count the subframe length. In one embodiment, a countdown function is used, and if the counter expires, the transmission of any packet currently being processed is interrupted in order to check the subframe unique word. Alternatively, the counter may increment a count, compare the count to a maximum or particular required value required, and check the current packet at the time corresponding to this value. This procedure protects the client from decoding packets of particularly long length that are received incorrectly on the client. If the sub-frame length counter needs to interrupt some other packet being decoded, it can be determined that synchronization has been lost since the packet should not cross a sub-frame boundary.

IX. packet processing

For each type of packet described above that the state machine receives, it performs a specific processing step or series of steps to implement the operation of the interface. The forward link packet is generally processed in accordance with the exemplary process set forth in table XII below.

TABLE XII

Packet type	Packet processor state machine response
		Sub-frame header (SH)	Good packets are acknowledged, the subframe length field is captured and packet parameters are sent to the general purpose processor.
Filler character (F)	The data is ignored.
		Video Streaming (VS)	Interpreting the video data format descriptors and other parameters, transforming the pixels, if necessary, by color mapping, as to the packed pixel data, and writing the pixel data in the appropriate location in the bitmap.
Audio Stream (AS)	Sending audio sample rate settings to an audio sample clock generator, separating audio samples of a specified size, unpacking audio sample data if necessary, and routing the audio samples to an appropriate audio sample FIFO
		Color Mapping (CM)	The color map size and offset parameters are read and the color map data is written to a color map memory or storage unit.
Reverse link encapsulation (REL)	Facilitating the transmission of packets in reverse at the appropriate time. Checking the reverse link flag to send client capability scores when neededAnd (4) grouping. Client request and status packets are also sent, as appropriate.
		Client Capability (CC)	This type of packet is sent when requested by the host using the reverse link flag field of the reverse link encapsulation packet.

Packet type	Packet processor state machine response
		Keyboard (K)	If a keyboard type device is present and needs to be used, the packets are passed to and received from a general purpose processor in communication with the keyboard type device.
Indicating equipment (PD)	If a pointing type device is present and needs to be used, the packets are passed to and received from a general purpose processor in communication with the pointing type device.
		Link closing (LS)	The fact that the link is closed is recorded and the general purpose processor is notified.
Client Service Request and Status (CSRS)	This packet is sent as the first packet in the reverse link encapsulation packet.
		Bit block transfer (BPT)	Interpreting grouping parameters such as video data format descriptors, determining which pixels move first, and moving pixels in the bitmap as needed.
Bitmap Area Filling (BAF)	Interpreting the grouping parameters, transforming the pixels by color mapping, if necessary, and writing the pixel data to the appropriate location in the bitmap,
		bitmap Pattern Fill (BPF)	Interpreting the grouping parameters, unpacking the packed pixel data if necessary, transforming the pixels by color mapping if necessary, and writing the pixel data into the appropriate location in the bitmap.
Communication Link Channel (CLC)	This data is sent directly to the general purpose processor.
		Client Service Request (CSR) during dormancy	The general purpose processor controls the low level functions that send the request and detects contention for a link restart on its own.
Interface type switch request (ITHR) and Interface Type Acknowledgement (ITA)	These packets may be passed to and from a general purpose processor. The logic for receiving this type of packet and composing a response with an acknowledgement is substantially minimal. Thus, this operation may also be implemented within the packet processor state machine. The resulting switch exists as a low level physical layer action and is unlikely to affect the functionality of the general purpose processor.
		Execution type switching (PTH)	This can be done directly on the packet or by passing the packet to a general purpose processor and commanding hardware to perform a mode change.

X. reducing reverse link data rate

The inventors have observed that: it is highly desirable that certain parameters for the host link controller be adjustable or configurable in a particular manner to achieve a maximum or more optimal (scaled) reverse link data rate. For example, during the reverse data packet field used to transmit reverse link encapsulation packets, the MDDI _ Stb signal pair is flipped (toggle) to generate a periodic data clock at half the forward link data rate. This occurs because the host link controller generates an MDDI _ Stb signal corresponding to MDDI _ Data0 signal, as if MDDI _ Data0 were sending all zeros. The MDDI _ Stb signal is transmitted from the host to the client where it is used to generate a clock signal to transmit reverse link data from the client, whereby the reverse data is sent back to the host. The typical amount of delay encountered in signaling and processing on the forward and reverse paths in a system employing MDDI is shown in fig. 50. In FIG. 50, a series of delay values are shown in the vicinity of the processing portion of the Stb +/-generation, cable delivery to client, client receiver, clock generation, signal clock, Data0 +/-generation, cable delivery to host, and host receiver stages, respectively, namely: 1.5 nanoseconds, 8.0 nanoseconds, 2.5 nanoseconds, 2.0 nanoseconds, 1.0 nanoseconds, 1.5 nanoseconds, 8.0 nanoseconds, and 2.5 nanoseconds.

Depending on the forward link data rate and the signal processing delays encountered, more than one cycle on the MDDI _ Stb signal may be required for a "round trip" effect or to complete a set of events, resulting in an undesirable consumption of time or amount of cycles. To prevent this problem, the reverse rate divisor allows a bit time on the reverse link to span multiple cycles of the MDDI _ Stb signal. This means that the reverse link data rate is less than the forward link rate.

It should be noted that the actual length of signal delay through the interface will vary with each particular host-client system or hardware used. Although not required, each system generally performs better by using round trip delay measurement packets to measure the actual delay in the system, thereby setting the reverse rate divisor to an optimal value. The host may support basic data sampling that is simpler but runs at a lower speed, or may also support advanced data sampling that is more complex but supports a higher reverse data rate. Also, client capabilities are considered to support both methods.

The round trip delay is measured by having the host send a round trip delay measurement packet to the client. The client responds to the packet by sending a 1 sequence back to the host within or during a preselected measurement window, referred to as the measurement period field, in the packet. The detailed timing of this measurement was described previously. The round trip delay is used to determine the rate at which reverse link data can be safely sampled.

The round trip delay measurement involves determining, detecting, or counting the number of forward link data clock intervals that occur between the beginning of the measurement period field and the beginning of the time period when the host receives a 0xff, 0x00 response sequence from the client. It should be noted that it is possible that a response is received from the client a fraction of the forward link clock cycle before the measurement count is about to increase. If this unmodified value is used to calculate the reverse rate divisor, it can result in bit errors on the reverse link due to unreliable data samples. One example of this is illustrated in fig. 51, where signals representing MDDI _ Data at the host, MDDI _ Stb at the host, the forward link Data clock internal to the host, and the delay count are shown graphically. In fig. 51, a response sequence is received from the client for a portion of the forward link clock cycle immediately before the delay count is increased from 6 to 7. If the delay is assumed to be 6, the host will sample the inverted data just after the transition or possibly in the middle of the bit transition. Doing so can result in sampling errors at the host. For this reason, the measured delay should typically be increased by 1 before it is used to calculate the reverse rate divisor.

The reverse rate divisor is the number of MDDI _ Stb cycles that the host should wait before sampling the reverse link data. Since MDDI _ Stb is cycled periodically at half the forward link rate, the correct round trip delay measurement needs to be divided by 2 and then rounded up to the next integer. This relationship is expressed as the formula:

for the given example, it becomes:

if the round trip delay measurement for this example is 7 instead of 6, then the reverse rate divisor is also equal to 4.

The reverse link data is sampled by the host at the rising edge of the reverse link clock. Counters or similar known circuits or devices are present in both the host and client (displays) for generating the reverse link clock. The counter is initialized so that the first rising edge of the reverse link clock occurs at the beginning of the first bit of the reverse link packet field of the reverse link encapsulation packet. The case for the example given below is illustrated in fig. 52A. The counter is incremented by 1 on each rising edge of the MDDI _ Stb signal and the count number is incremented until the reverse rate divisor parameter in the reverse link encapsulation packet sets the count back to (wrap around) zero. Since the MDDI _ Stb signal is flipped at half the forward link rate, the reverse link rate is half the forward link rate divided by the reverse rate divisor. For example, if the forward link rate is 200Mbps and the reverse rate divisor is 4, the reverse link data rate may be expressed as:

An example of the timing of the MDDI _ Data0 and MDDI _ Stb signal lines in a reverse link encapsulation packet is shown in fig. 52, where the packet parameters used for illustration have the following values:

packet length 1024(0x0400) turn 1 length 1

Packet type 65(0x41) turn 2 length 1

Reverse link flag 0 reverse rate divisor 2

The parameter CRC 0xdb43 all zeros 0x00

The packet data between the packet length and parameter CRC fields is:

0x00，0x04，0x41，0x00，0x02，0x01，0x01，0x43，0xdb，0x00，……

the first reverse link packet returned from the client is a client request and status packet having a packet length of 7 and a packet type of 70. This packet starts with byte values 0x07, 0x00, 0x46, … …, and so on. However, only the first byte (0x07) can be seen in FIG. 52. This first reverse link packet is shifted in time by one reverse link clock cycle in the figure to illustrate the actual reverse link delay. An ideal waveform with a host-to-client round trip delay of zero is shown as a dashed trace.

The MS byte of the parameter CRC field is transmitted, the CRC being preceded by the packet type and then the all zero field. When the data from the host changes levels, the strobe from the host switches from a switch to zero and back to one, forming a wider pulse. When the data goes to zero, the strobe signal switches at a higher rate, only data changes on the data lines resulting in changes near the end of the alignment field. For the rest of the figure, since the data signal has a fixed 0 or 1 level and extends for some period of time, the strobe signal switches at the higher rate and this transition falls on the pulse pattern (edge).

The host's reverse link clock is at zero until the end of the turnaround 1 period, at which time the clock begins to support reverse link packets. The arrows in the lower part of the figure indicate the moment of data sampling, as is evident from the rest of the disclosure. The first byte of the packet field (here 11000000) shown being transmitted begins to appear after a turn 1 and the line level is stable because the host driver is disabled. The delay in the delivery of the first bit (passage) can be seen in the dashed line of the data signal and as seen for bit three.

A typical value for the reverse rate divisor based on the forward link data rate can be seen in fig. 53. The actual reverse rate divisor is determined as a result of the round trip link measurement to ensure proper reverse link operation. The first area 5302 corresponds to a safe operation area, the second area 5304 corresponds to a marginal performance area, and the third area 5306 indicates settings that are highly unlikely to work properly.

When working with any of the interface type settings on the forward or reverse link, the round trip delay measurement and reverse rate divisor settings are the same because they are expressed and operated on the actual clock period rather than the number of bits transmitted or received.

Typically, the maximum possible reverse rate divisor is half the number of bits that can be sent in the measurement window of the round trip measurement packet using the type I interface, or, for this example:

an advanced inverse data sampling method may also be employed as an option to make the inverse bit time smaller than the round trip delay. For this technique, the host measures only the round trip delay, but can also determine the phase of the response from the client relative to the client and link "ideal" bit boundaries with zero delay. Knowing the phase of the client device response, the host can determine a safer time to sample the reverse data from the client. The round trip delay measurement indicates to the client the position of the first bit of the reverse data relative to the start of the reverse data packet field.

One embodiment of advanced inverse data sampling is shown in the schematic diagram of fig. 52B. The ideal reverse data signal with zero round trip delay is shown as a dotted line waveform. The actual round trip delay between 3.5 and 4 MDDI Stb cycles can be observed as the delay difference between the solid line waveform and the ideal waveform. This is the same delay as measured with the round trip delay measurement packet, which is a measured round trip delay value equal to 7 forward link bit times. In this embodiment, the reverse data bits are 2 MDDI _ Stb pulses long, i.e., 4 forward link bit times, corresponding to a reverse rate divisor equal to 2. For advanced inverse data sampling, it is convenient to use a preselected inverse rate divisor of 2, rather than compute it as elsewhere. This seems to be a substantially optimal choice for advanced inverse data sampling, since the ideal sampling point can easily be determined using the conventional measurements described above.

The ideal sample point for the inverted data can be easily calculated as follows: the hint signal of the total round trip delay is divided by the number of forward link clocks per backward bit or the round trip delay per backward bit is modulo the forward link clock. Then, subtracting 1 or 2 yields a safe point away from the data transformation. In this example, 7mod 4 is 3, so 3-1 is 2 or 3-2 is 1. The safe sampling point is 1 or 2 forward link bit times, starting from the "ideal" bit boundary edge with zero round trip delay. The sampling point shown in the figure is at 2 forward link bit times from the ideal bit boundary, as shown by the series of vertical arrows at the bottom of the timing diagram. The first sample point is the first ideal bit boundary after the round trip delay is measured plus the offset of the safety sample. In this example, the round trip delay measurement is 7, so the next ideal bit boundary is at the 8 th bit time, then 1 or 2 is added to the security sample point, so the first bit should be sampled 9 or 10 forward link bit times after the start of the reverse data packet field.

XI steering and guard time

The turn 1 field in the reverse link encapsulation packet allows time for host driver disable and client driver enable to occur simultaneously. The guard time 1 field in the round trip delay measurement packet enables the host and client to overlap so the client driver can be enabled before the host interface driver is disabled. The turn 2 field in the reverse link encapsulation packet enables the data in the previous field to be completely sent out from the client before the host driver is enabled. The guard time 2 field provides a time value or period to enable the client and host drivers to drive simultaneously at a logic zero level. The guard time 1 and guard time 2 fields are typically filled with preset or preselected length values that cannot be adjusted. Depending on the interface hardware being used, empirical data may be used to obtain these values and in some cases adjust them to improve operation.

Steering 1

There are several factors that help determine the length of turnaround 1, these factors being the forward link Data rate, the maximum disable time of the MDDI _ Data driver in the host, and the enable time of the client driver (which is typically the same as the host disable time). Select length of turn 1 field to be 24 t_BIT. (table XI) the length of the forward link byte count to the 1 field is determined by the interface type factor (InterfaceTypeFactor) and calculated using the relationship:

where the interface type factor is 1 for type 1, 2 for type 2, 4 for type 3, and 8 for type 4.

Steering 2

Factors that determine the length of time typically used for turnaround 2 are the round trip delay of the communication link, the maximum disable time of the MDDI _ Data driver in the client, and the enable time of the host driver (specified to be the same as the client driver disable time). The maximum host driver enable time and the client driver disable time are given in. The unit of measurement of the round trip delay is t_BIT. The minimum length specified in number of forward link bytes diverted to the 2 field is calculated according to the following relationship:

for example, a type 3 forward link with a round trip delay of 10 forward link clocks typically uses a turn 2 delay on the order of:

Xii. optional reverse link timing

Although a high data transfer rate interface can be realized using the above-described timing and guard band (guard band), the inventors of the present invention have found a technique of providing a reverse bit length shorter than a round trip time by changing a reverse timing discovery (reverse timing discovery).

As described above, the previous approach to reverse link timing is configured such that the number of clock cycles is counted from the last bit of guard time 1 of the reverse timing packet until the first bit is sampled on the rising edge of the IO clock. This is the clock signal used to time the inputs and outputs of the MDD interface. The calculation of the reverse rate divisor is then given by the following equation:

this provides a bit width equal to the round trip delay, thereby enabling a very reliable reverse link. However, it has been demonstrated that the reverse link can operate faster, or at higher data transfer rates, which the inventors wish to utilize. The new technology of the present invention allows the additional capabilities of the interface to be exploited to achieve higher speeds.

This is accomplished by having the host count the number of clock cycles until sampling is completed for one 1, but during the reverse timing packet the host samples the data line on both the rising and falling edges. Doing so allows the host to select the most useful or even the best sample point within the inverted bit to ensure that the bit is stable. That is, the most useful or optimal rising edge is found to sample the data on the reverse encapsulation packet of the reverse traffic. The optimal sampling point depends on the reverse link divisor and whether the first 1 is detected on the rising or falling edge. The new timing method allows the host to look for only the first edge of the 0xFF0x 00 pattern sent by the client in the reverse link timing to determine where to sample in the reverse encapsulated packet.

An example of the inverse bits that arrive and how the bits will look for the various inverse rate divisors, and the number of clock cycles that have occurred since the last bit of guard time 1, is illustrated in fig. 64. It can be seen in fig. 64 that if the first edge occurs between rising and falling edges (labeled rising/falling), then the optimum sampling point for the reverse rate divisor of 1, i.e., the optimum sampling point, is the edge of the clock cycle labeled 'b' because it is the only rising edge that occurs within the reverse bit period. For the case of a reverse rate divisor of 2, the best sampling point may still be the clock cycle leading edge 'b' since the periodic edge 'c' is closer to the bit edge than 'b'. For the case of a reverse rate divisor of 4, the optimal sampling point may be the edge of the clock period'd' because it is closer to the trailing edge of the reverse bit whose value may have settled.

Returning to fig. 64, however, if the first edge occurs between the falling and rising edges (labeled falling/rising), then the best sample point for the reverse rate divisor of 1 is the sample point clock period edge 'a' because this is the only rising edge that occurs within the reverse bit time period. The optimal sampling point is edge 'b' for the case of a reverse rate divisor of 2, and edge 'c' for the case of a reverse rate divisor of 4.

It can be seen that as the inverse rate divisor gets larger and larger, the optimal sampling point becomes more convenient to determine or select, since it should be the rising edge closest to the middle.

Using this technique, the host can find the number of rising clock edges before the rising data edge of the timing packet observed on the data line. Thus, based on whether the edge occurs between rising and falling edges or between falling and rising edges, and what the reverse rate divisor is, a determination can be made as to how many additional clock cycles to add to the counter to reasonably ensure that the sampling of the bit is always as close to the middle as possible.

Once the host has selected or determined the number of clock cycles, it can "investigate" the various reverse rate divisors with the client to determine if a particular reverse rate divisor is available. The host (and client) may start with a divisor of 1 and check the CRC of the reverse status packet received from the client to determine if this reverse rate can properly transfer data. If the CRC is corrupted, there is a possibility of a sampling error, and the host may increase the reverse rate divisor and attempt to request a status packet again. If the second requested packet is corrupted, the divisor may be increased again and the request made again. This reverse rate divisor can be used for all future reverse packets if this packet is decoded correctly.

This method is efficient and useful because the reverse timing should not change since the initial round trip timing estimate. If the forward link is stable, the client should continue decoding the forward link packets even if there is a reverse link failure. Of course, since this approach does not ensure that the reverse link is ideal, it is still the responsibility of the master to set the reverse link divisor for that link. In addition, the divisor will depend primarily on the clock quality used to generate the IO clock. If the clock has a large amount of jitter, there is a greater likelihood of sampling errors. This error probability increases with the amount of clock cycles in the round trip delay.

This implementation appears to be best suited for type 1 reverse data, but problems may arise for type 2 to type 4 reverse data, since the deviation between the data lines may be too large to operate the link at the rate best suited for only one data pair. However, even with type 2 through type 4 operation, the data rate may not need to be reduced to the previous method. This method may also work best if it is repeated on each data line to select the ideal or optimal clock sampling location. This method can continue to work if they are at the same sample time for each data pair. If they are at different sampling periods, two different approaches may be used. The first is to select a desired or more optimal sampling position for each data point, even though the sampling position is not the same for each data pair. The host is then able to reconstruct the data stream after sampling all bits from the set of data pairs: type 2 is two bits, type 3 is four bits and type 4 is eight bits. Another option for the host is to increase the reverse rate divisor so that the data bits of each data pair can be sampled on the same clock edge.

Effect of Link delay and skew XIII

The delay skew between the MDDI _ Data pair and MDDI _ Stb on the forward link will limit the maximum Data rate possible unless delay skew compensation is employed. The delay differences that create timing skew arise from the controller logic, line drivers and receivers, and cables and connectors outlined below.

A. Link timing analysis by deviation constraint (MDDI type 1)

1. Delay and skew examples for type 1 links

An exemplary interface circuit for supporting a type 1 interface link, similar to that shown in fig. 41, is shown in fig. 57. In fig. 57, exemplary or typical values of propagation delay and deviation are shown for each of a plurality of processing or interface stages of the MDDI type 1 forward link. The deviation in the delay between MDDI _ Stb and MDDI _ Data0 causes the duty cycle of the output clock to be distorted. The data at the D input of the receiver flip-flop (RXFF) stage using flip-flops 5728, 5732 changes slightly after a clock edge so that the data can be reliably sampled. The figure shows two cascaded delay lines 5732a and 5732b that address two different problems by creating this timing relationship. In a practical implementation, they may be combined into a single delay element.

Fig. 58 shows data, Stb and clock recovery timing on a type 1 link for exemplary signal processing via the interface.

The total delay bias, which is usually significant, occurs or comes from the sum of the biases in the following stages: a transmitter flip-flop (TXFF) with flip-flops 5704, 5706; a transmitter driver (TXDRVR) with drivers 5708, 5710; CABLE (CABLE) 5702; a receiver line receiver (RXRCVR) with receivers 5722, 5724, and receiver XOR logic (RXXOR). The delay 15732 a should match or exceed the delay of the XOR gate 5736 of the RXXOR stage, which can be determined by the following relationship:

t_{PD-min (delay 1)}≥t_PD-max(XOR)

This requirement is preferably met so that the D input of the receiver flip-flop 5728, 5732 does not change before its clock input. This is valid if the hold time of RXFF is zero.

The purpose or function of Delay 2(Delay2) is to compensate for the hold time of the RXFF flip-flop as follows:

t_{PD-min (delay2)}＝t_H(RXFF)

In many systems this value will be zero, since the hold time is zero, in which case the maximum delay of delay2 is of course also zero.

The worst case of skew in the receiver XOR stage is a data-late/strobe-early case where delay 1 is at a maximum and the clock output from the XOR gate arrives as early as possible according to the following relationship:

t_{Offset-max (RXXOR)}＝t_{PD-max(Delay1)}-t_PD-min(XOR)

In this case, the data may change between two bit periods n and n +1, with the change time very close to the time at which bit n +1 is clocked into the receiver flip-flop.

The maximum data rate (minimum bit period) of an MDDI type 1 link is a function of the maximum skew encountered through all drivers, cables, and receivers in the MDDI link plus the aggregate data set into the RXFF stage. The total delay deviation in the link up to the output of the RXRCVR stage can be expressed as:

t_{offset-max (LINK)}＝t_{Offset-max (TXFF)}+t_{Offset-max (TXDRVR)}+t_{Deviation-max (Cable)}+t_{Offset-max (RXRCVR)}

Where "cable" represents various conductors or interconnects or lines and corresponding delays, and the minimum bit period is given by:

t_bit-min＝t_{Offset-max (Link)}+2·t_B-TP4+t_Asymmetry+t_{Offset-max (RXXOR)}+t_jitter-host+t_{PD-max(Delay2)}+t_SU(RXFF)

In the example shown in FIG. 57, for the external mode, t_{Offset-max (Link)}1000psec and the minimum bit period can be expressed as:

t_bit-min1000+2 · 125+625+125+200+0+100 is 2300psec or approximately 434 Mbps. In the example shown in FIG. 57, for the internal mode, t_{Offset-max (Link)}500psec and the minimum bit period can be expressed as:

t_bit-min500+2 · 125+625+125+200+0+100 is 1800psec or approximately 555 Mbps.

MDDI type 2, type 3, and type 4 link timing analysis

Typical interface circuitry similar to that shown in fig. 41 and 57 is shown in fig. 59 for supporting type 2, 3, and 4 interface links. Additional components are used in the TXFF (5904), TXDRVR (5908), RXRCVCR (5922), and RXFF (5932, 5928, 5930) stages to support additional signal processing. In fig. 59, exemplary or typical values of propagation delay and deviation are shown for each of a plurality of processing or interface stages of an MDDI type 2 forward link. In addition to the deviation in delay between MDDI _ Stb and MDDI _ Data0, which affects the duty cycle (duty-cycle) of the output clock, there is also a deviation between these two signals and the other MDDI Data signals. The data at the D input of the receiver flip-flop b (rxffb) stage, which is comprised of flip-flops 5928 and 5930, changes slightly after the clock edge so that the data can be reliably sampled. If MDDI _ Data1 arrives earlier than MDDI _ Stb or MDDI _ Data0, then MDDI _ Data1 should be delayed in order to sample MDDI _ Data1 by at least the delay offset. To accomplish this, a Delay 3(Delay3) Delay line is used to Delay the data. If MDDI _ Data1 arrives later than MDDI _ Stb and MDDI _ Data0, and it is also delayed by delay3, then the point at which MDDI _ Data1 changes is moved closer to the next clock edge. This process determines the upper limit on the data rate of MDDI type 2, type 3 or type 4 links. Some exemplary different possibilities of timing or offset relationships of the two data signals and MDDI _ Stb relative to each other are shown in fig. 60A, 60B, and 60C.

When MDDI _ DataX arrives early, to reliably sample data in RXFFB, the delay is set according to the following relationship:

t_{PD-min(Delay3)}≥t_{offset-max (LINK)}+t_H(RXFFB)+t_PD-max(XOR)

The maximum link speed is determined by the minimum bit period allowed. This speed is most affected when MDDI _ DataX arrives as late as possible. In this case, the minimum allowable cycle time is given by the following equation:

t_bit-min＝t_{Offset-max (LINK)}+t_{PD-max(Delay3)}+t_SU(RXFFB)-t_PD-min(XOR)

The upper limit of the link speed is then:

t_{PD-max(Delay3)}＝t_{PD-min(Delay3)}

and under this assumption:

t_{bit-min(lower-bound)}＝2·t_{Offset-max (LINK)}+t_PD-max(XOR)+t_SU(RXFFB)+t_H(RXFFB)

In the example given above, the lower limit of the minimum bit period is given by the following relationship:

t_{digit-min (lower-bound)}2- (1000+2 · 125+625+200) +1500+100+0 5750psec, which is about 174 Mbps.

This is much slower than the maximum data rate that can be used for a type 1 link. The automatic delay skew compensation capability of MDDI significantly reduces the impact of delay skew on the maximum link rate factor, only the margin for valid data establishment. The calibration offset between MDDI _ Data0 and MDDI _ Stb is:

t_{SKEW-max(calibrated)}＝2·t_{TAP-SPACING-max}

and the minimum bit period is:

t_{BIT-min-calibrated}＝t_{SKEW-max(calibrated)}+2·t_B-TP4+t_Asymmetry+t_jitter-host+t_{SKEW-max(RXAND+RXXOR)}+t_SU(RXFF)

wherein "TB" or t_BRepresenting the jitter of the signal from a bit boundary to the minimum output level. Asymmetry merely represents the asymmetric nature of the delay within a differential receiver. "TP 4" is associated with or effectively defines a connection or interface (a pin of an MDDI controller device in a client) for electrical characterization and testing purposes as a client differential line driver and receiver. For the links of the rest of the system, it represents a convenient or predetermined point from which the signal delay is measured and characterized. In one embodiment, for internal mode, parameter T is at TP4 _BIs given by the relation t_{Differential-Skew-TP4-DRVR-EXT}＝0.3·t_BITIs defined as t for the internal mode of the client transmitter_{Differential-Skew-TP4-DRVR-INT}＝0.6·t_BIT(ii) a For the external mode of the client receiver, t is_{B-TP4-RCVR-EXT}＝0.051·t_BIT+175ps。

The label TP4 is used only to number different Test Points (TP) in the interface and the link. In one embodiment, the test points are defined to be the same for both the internal and external patterns. There is a corresponding "TP 0" test point for or associated with a connection or interface pin of an MDDI controller device in a host that contains differential line drivers and receivers. In this embodiment, for the host receiver, for the internal mode, the parameter T at TP0_BIs given by the relation t_{B-TP0-RCVR-INT}＝0.051·t_BIT+50ps, for external mode, the relationship is t_{B-TP0-RCVR-EXT}＝0.051·t_BIT+175 ps; for the host transmitter, the relationship is t_B-TP0＝0.102·t_BIT。

In the example given in FIG. 59, t_{SKEW-max(Data0-Stb-Caliberated)}300psec and the minimum bit period is:

t_{BIT-min-calibrated}300+2 · 125+625+200+175+100 is 1650psec, which is about 606 Mbps.

When MDDI _ Data1 arrives early, the associated programmable delay is adjusted to an optimum setting, one tap accurate, for reliable sampling of the Data in RXFFB, adding additional tap delays for safety. The maximum link speed depends on the minimum allowed bit period. The effect is greatest when MDDI _ Data1 arrives as late as possible. In this case, the minimum allowable cycle time is:

t_{BIT-min-Data1-calibrated}＝2·t_{TAP-Spacing-max}+2·t_TA-TP4

Wherein "TA" or t_ARepresenting the jitter of the signal from the bit boundary to the middle crossing.

In the example given in fig. 59, the lower bound of the minimum bit period based on sampled MDDI _ Data1 is:

t_{BIT-min-Data1-calibrated}＝2·150+2·125＝550psec

in one embodiment, for the internal mode, the typical total delay time of delay skew, delay asymmetry and clock jitter in the host is defined as:

t_{Asymmerty-TXFF}+t_{Asymmetry-TXDVR}+t_Skew-TXFF+t_Skew-TXDRVR+t_jitter-host＝

0.467·(t_BIT-150ps)

for the external mode:

t_{Asymmerty-TXFF}+t_{Asymmetry-TXDVR}+t_Skew-TXFF+t_Skew-TXDRVR+t_jitter-host＝

0.TBD·(t_BIT-150TBDps)

for internal modes, delay skew, delay asymmetry and typical total delay time (t) of the setup time in the client_B-TP4) Is defined as:

t_{Asymmerty-RXRCVR}+t_{Asymmetry-RXXOR}+t_Skew-RXRCVR+t_Skew-RXXOR+t_setup-RXFF＝

0.307·(t_BIT-150ps)

for the external mode, it is:

t_{Asymmerty-RXRCVR}+t_{Asymmetry-RXXOR}+t_Skew-RXRCVR+t_Skew-RXXOR+t_setup-RXFF＝

0.TBD·(t_BIT-TBDps)

the term TBD is a flexible position maintenance flag for future pending values depending on a variety of well-known characteristics and operational requirements of the external mode connection.

XIV physical layer interconnect description

The physical connections of the interfaces that can be used to implement the present invention can be implemented using commercially available parts, such as part number 3260-8S2(01) manufactured by Hirose Electric Company Ltd on the host side and part number 3240-8P-C manufactured by Hirose Electric Company Ltd on the client device side. Exemplary interface pin assignments or "pin outs" for such connectors for use with the type 1/type 2 interface are listed in table XIII and illustrated in fig. 61.

TABLE XIII

Signal name	Pin number	Signal name	Pin number
				MDDI_Pwr	1	MDDI_Gnd	11
MDDI_Stb+	2	MDDI_Stb-	12
				MDDI_Data0+	4	MDDI_Data0-	14
MDDI_Data1+	6	MDDI_Data1-	16
				MDDI_Data2+	8	MDDI_Data2-	18
MDDI_Data3+	10	MDDI_Data3-	20
				MDDI_Data4+	9	MDDI_Data4-	19
MDDI_Data5+	7	MDDI_Data5-	17
				MDDI_Data6+	5	MDDI_Data6-	15
MDDI_Data7+	3	MDDI_Data7-	13

						Shielding

The shield is connected to HOST _ Gnd in the HOST interface and the shield ground in the cable is connected to the shield of the client connector. However, this shield and ground are not connected to circuit ground inside the client.

The interconnecting elements or devices are selected or designed to be small enough for use in mobile communication and computing devices, such as PDAs and wireless telephones, or portable gaming devices, without exceeding or appearing unsightly in comparison to the size of the associated device. Any connectors and cables should be sufficiently durable and small in size, especially for cables, and relatively low in cost in a typical consumer environment. The transfer element should support data and strobe signals as differential NRZ data having a transfer rate of up to around 450Mbps for type 1 and type 2 and up to 3.6Gbps for the 8-bit parallel type 4 version.

For internal mode applications, there is also no connector for the wires used, or such connecting elements tend to be miniaturized. One example is a zero insertion force "socket" for accepting an integrated circuit or component for insertion into a host or client device. Another example is where the host and client reside on printed circuit boards having various interconnection wires, and have "pins" or contacts extending from the housing that are soldered to the wires used for interconnection of the integrated circuits.

XV. operation

An overview of the general steps performed in processing data and packets during operation of an interface using an embodiment of the present invention is shown in fig. 54A and 54B, and an overview of an interface apparatus processing the packets is shown in fig. 55. In these figures, the process begins at step 5402 by determining whether the client and host are connected using a communication path (here, a cable). This may be done by the host periodically polling using software or hardware that detects the presence of a connector, cable or signal (e.g., USB interface) at the input of the host, or by other known techniques. If no client is connected to the host, it may only enter a wait state of some predetermined length, enter a sleep mode, or be inactive for future use, depending on the application, which may require the user to take action to reactivate the host. For example, when a host resides on a computer type device, the user may have to click on a screen icon or request a program to activate the host process to find the client. Furthermore, host processing may be activated simply by plugging in a USB type connection, depending on the capabilities and configuration of the host or resident host software.

Once the client is connected to the host, or vice versa, or the client is detected as present, the client or host sends an appropriate request service packet at steps 5404 and 5406. At step 5404, the client may send a client service request or status packet. It should be noted that, as described above, the link may have been previously shut down or in a sleep mode, and thus the subsequent may not be a complete initialization of the communication link. Once the communication link is synchronized and the host attempts to communicate with the client, the client also provides the client capability packet to the host, as in step 5408. The host may now begin to determine the type of support, including transfer rates, that the client is capable of supporting.

Typically, at step 5410, the host and client also negotiate the type (rate/speed) of service mode to be used, e.g., type 1, type 2, etc. Once the service type is established, the host can begin to transmit information. In addition, the host may use the round trip delay measurement packets to optimize the timing of the communication link in parallel with other signal processing, as shown in step 5411.

As previously described, all transfers begin with the sub-frame header packet being transferred as shown at step 5412, followed by the data type being transferred and the filler packet as shown at step 5414, where the data types are video and audio stream packets. The audio and video data have been pre-prepared or mapped into packets and filler packets inserted as needed or desired to fill the number of bits required for a media frame. The host can send a packet, such as a forward audio channel enable packet, to activate the audio device. In addition, in step 5416, the host can use the other packet types described above to transfer commands and information, shown here as color mapping, bit block transfer, or transfer of other packets. Further, the host and client can exchange data relating to the keyboard or pointing device using appropriate packets.

During operation, one of a number of different events may occur, which may result in the host or client requiring a different data rate or a different interface mode type. For example, a computer or other device used to communicate data may encounter loading conditions (conditions) in the processing of the data that result in a slow preparation or rendering of packets. A client receiving data may switch from a dedicated ac power source to a more limited battery power source and may not be able to quickly transfer data, easily process commands, or use the same resolution or color depth at a limited power setting. Alternatively, the constraints may be reduced or eliminated, allowing the device to transmit data at a higher rate. This makes a request to change to a higher transfer rate mode more necessary.

If these or other types of known conditions occur or change, the host or client may detect them and attempt to renegotiate the agreed-upon interface mode. This is shown in step 5420 where the host sends an interface type switch request packet to the client to request a switch to another mode, the client sends an interface type acknowledge packet to acknowledge that a change is sought, and the host sends an execute type switch packet to change to the specified mode.

Although no particular order of processing is required, the client and host may exchange packets relating to data that is to be sent to or received from a pointing device, keyboard or other user-type input device that is primarily connected to the client, although these elements may also be present on the host side. These packets are typically processed using general purpose processor type elements rather than state machines (5502). In addition, some of the commands described above are also processed by the general purpose processor (5504, 5508).

After data and commands have been exchanged between the host and the client, at some point a decision is made as to whether additional data is to be transferred or whether the host or the client is to stop the service provided for the transfer. This is shown in step 5422. If the link is going to sleep or completely shut down, the host sends a link shutdown packet to the client and both sides terminate transmitting data.

The packets transmitted in the above operational process are transmitted using the drivers and receivers previously discussed with respect to the host and client controllers. These line drivers and other logic elements are connected to the state machine and general purpose processor as shown in the overview of FIG. 55. In fig. 55, state machine 5502 and general processors 5504 and 5508 may be further connected to other elements not shown, such as a dedicated USB interface, a memory element or other components residing outside of the link controller with which they interact, including but not limited to a data source and a video control chip for viewing the display device.

The processor and state machine provide enable and disable control of the driver, as discussed above with respect to guard time and the like, to ensure that the communication link is effectively established or terminated and packets are transmitted.

XVI display frame buffer

The buffering requirements for video data are different for moving video images compared to computer graphics. The pixel data is often stored in the client's local frame buffer so the image on the client can be refreshed locally.

When displaying full motion video (almost every pixel in the display changes in every media frame), it is generally preferable to store the pixel data being input in one frame buffer while refreshing the image on the display from the second frame buffer. More than two display buffers may be used to remove visual artifacts (visual artifacts), as described below. When the entire image has been received in one frame buffer, the roles of the buffers can be switched, the newly received image being used to refresh the display, and the next frame of the image being filled into the other buffer. This concept is illustrated in FIG. 88A, where pixel data is written to the offline image buffer by setting the display update bit to "01".

In other applications, the host need only update a small portion of the image, rather than having to redraw the entire image. In this case, new pixels need to be written directly to the buffer for refreshing the display, as shown in fig. 88B.

In applications with fixed images of smaller video windows, it is easiest to write the fixed images to two buffers (display update bit equals "11"), as shown in FIG. 88C, and then write the motion image pixels to the offline buffer by setting the display update bit to "01".

The following rules describe the beneficial manipulation of the buffer pointer while writing new information to the client and refreshing the display. There are three buffer pointers: current _ file (currently filled) points to the buffer currently being filled by data on the MDDI link; just filled points to the most recently filled buffer; the bed _ displayed points to the buffer currently being used to refresh the display. All three buffer pointers may contain values from 0 to N-1, where N is the number of display buffers and N ≧ 2. The operation on the buffer pointer is modulo N (mod N), for example, when N is 3 and current _ file is 2, adding current _ file lets current _ file be set to 0. In the simple case of N-2, just _ file is always the complement of current _ file. The following operations are performed in the specified order at each MDDI medium frame boundary (subframe header packet of subframe count field equals zero): just _ file is set equal to current _ file, and current _ file is set equal to current _ file + 1.

The MDDI video stream packet updates the buffer as follows: when the display update bit equals '01', writing the pixel data into the buffer specified by current _ file; when the display update bit is equal to '00', writing the pixel data to the buffer specified by just _ filed; when the display update bit equals "11", the pixel data is written to all buffers. The buffer specified by the bed _ displayed pointer refreshes the display. After the display refreshes the last pixel in one frame refresh epoch (epoch) and before it starts refreshing the first pixel in the next frame refresh epoch, the display update process performs an operation of setting the waiting refresh equal to just filed.

The video stream packet includes a pair of display update bits, illustrating the frame buffer to which pixel data is to be written. The client capability packet has three additional bits indicating combinations of display update bits supported in the client. In many cases, computer-generated images need to be incrementally refreshed based on user input, or derived from information received from a computer network. Display update bit patterns "00" and "11" support this mode of operation by having pixel data written to either the frame buffer being displayed or to both frame buffers.

When supporting a video image, fig. 89 illustrates how a pair of frame buffers is used to display a video image when the display update bit is equal to "01" and video data is transmitted over the MDDI link. After a media frame boundary is detected on the MDDI link, the display refresh process will begin refreshing from the next frame buffer when the refresh process for the frame currently being refreshed is complete.

An important assumption related to fig. 89 is that: the image is received from the host as a continuous stream of pixels that is transmitted in the order in which the client reads the pixels from the frame buffer to refresh the display (usually starting from the top left and reading line by line, up to the bottom right corner of the screen). This is an important detail in the case where the display refresh and image transfer operations involve the same frame buffer.

The display refresh frame rate needs to be greater than the image transfer frame rate in order to avoid displaying partial images. Fig. 90 shows how image fragmentation occurs in the case where the display refresh rate is slow, that is, the display refresh is slower than the image transfer.

In images containing a combination of computer graphics images and motion video images, video pixel data may occupy a small portion of the media frame. This is important in the case where the display refresh operation and the image transfer involve the same frame buffer. These cases are illustrated by the cross-hatched shading in fig. 91, where the pixels read from the buffer to refresh the display may be the pixels written to the buffer two frames ago, or they may correspond to the frames that are being written to the same frame buffer.

Three frame buffers are used in the client to solve the problem of contention for small windows accessing the frame buffers, as shown in fig. 92.

However, if the display refresh rate is less than the media frame rate on the MDDI link, then a problem still exists, as shown in fig. 93.

There is a problem in how much a single buffer is used for moving video images, as shown in fig. 94. When the display refreshes faster than the image is transferred into the buffer, the image being refreshed will sometimes display the upper portion of the frame being written, while the lower portion of the image is the previously transferred frame. The case of frames showing similar split images will occur more frequently when the display refreshes faster than the image transfer (preferred mode of operation).

Table of delay values xvii

Packet processing delay parameter the packet uses a table lookup function to calculate the predicted delay to process certain commands in the client. The values in the table are increased logarithmically to provide very wide dynamic range delay values. An exemplary table of delay values for implementing embodiments of the present invention can be found in table XX below, with corresponding indices being contrasted with the delay values.

Table XX

0-no delay	37-1.5ns	74-51ns	111-1.8us	148-62us	185-2.2ms	222-75ms
							1-46ps	38-1.6ns	75-56ns	112-2.0us	149-68us	186-2.4ms	223-83ms
2-51ps	39-1.8ns	76-62ns	113-2.2us	l50-75us	187-2.6ms	224-91ms
							3-56ps	40-2.0ns	77-68ns	114-2.4us	151-83us	188-2.9ms	225-100ms
4-62ps	41-2.2ns	78-75ns	115-2.6us	152-91us	189-3.2ms	226-110ms
							5-68ps	42-2.4ns	79-83ns	116-2.9us	153-100us	190-3.5ms	227-120ms
6-75ps	43-2.6ns	80-91ns	117-3.2us	154-110us	191-3.8ms	228-130ms
							7-83ps	44-2.9ns	81-100ns	118-3.5us	155-120us	192-4.2ms	229-150ms
8-91ps	45-3.2ns	82-110ns	119-3.8us	156-130us	193-4.6ms	230-160ms
							9-100ps	46-3.5ns	83-120ns	120-4.2us	157-150us	194-5.1ms	231-180ms
10-110ps	47-3.8ns	84-130ns	121-4.6us	158-160us	195-5.6ms	232-200ms
							11-120ps	48-4.2ns	85-150ns	122-5.1us	159-180us	196-6.2ms	233-220ms
12-130ps	49-4.6ns	86-160ns	123-5.6us	160-200us	197-6.8ms	234-240ms
							13-150ps	50-5.1ns	87-180ns	124-6.2us	161-220us	198-7.5ms	235-260ms
14-160ps	51-5.6ns	88-200ns	125-6.8us	162-240us	199-8.3ms	236-290ms
							15-180ps	52-6.2ns	89-220ns	126-7.5us	163-260us	200-9.1ms	237-320ms
16-200ps	53-6.8ns	90-240ns	127-8.3us	164-290us	201-10ms	238-350ms
							17-220ps	54-7.5ns	91-260ns	128-9.1us	165-320us	202-11ms	239-380ms
18-240ps	55-8.3ns	92-290ns	129-10us	166-350us	203-12ms	240-420ms
							19-260ps	56-9.1ns	93-320ns	130-11us	167-380us	204-13ms	241-460ms
20-290ps	57-10ns	94-350ns	131-12us	168-420us	205-15ms	242-510ms
							21-320ps	58-11ns	95-380ns	132-13us	169-460us	206-16ms	243-560ms
22-350ps	59-12ns	96-420ns	133-15us	170-510us	207-18ms	244-620ms
							23-380ps	60-13ns	97-460ns	134-16us	171-560us	208-20ms	245-680ms
24-420ps	61-15ns	98-510ns	135-18us	172-620us	209-22ms	246-750ms
							25-460ps	62-16ns	99-560ns	136-20us	173-680us	210-24ms	247-830ms
26-510ps	63-18ns	100-620ns	137-22us	174-750us	211-26ms	248-910ms
							27-560ps	64-20ns	l01-680ns	138-24us	l75-830us	212-29ms	249-1.0sec
28-620ps	65-22ns	102-750ns	139-26us	176-910us	213-32ms	250-1.1sec
							29-680ps	66-24ns	l03-830ns	140-29us	177-1.0ms	214-35ms	251-1.2sec
30-750ps	67-26ns	104-910ns	141-32us	178-1.1ms	215-38ms	252-1.3sec
							31-830ps	68-29ns	105-1.0us	142-35us	179-1.2ms	216-42ms	253-1.5sec
32-910ps	69-32ns	106-1.1us	143-38us	180-1.3ms	217-46ms	254-1.6s
							33-1.0ns	70-35ns	107-1.2us	144-42us	181-1.5ms	218-51ms	255-indeterminate
34-1.1ns	71-38ns	108-1.3us	145-46us	182-1.6ms	219-56ms
							35-1.2ns	72-42ns	109-1.5us	146-51us	183-1.8ms	220-62ms
36-1.3ns	73-46ns	110-1.6us	147-56us	184-2.0ms	221-68ms

The delay is calculated by performing a table lookup with the specified parameter as an index to the table. This means that the delay is equal to the packet processing table (index). For example: if one of the parameters from the delay parameter list entries is an 8-bit value equal to 134, then the delay is equal to the packet processing table (134), i.e., 16 microseconds. A value of 255 indicates that the command completion time cannot be determined by calculation and the host must check the graphics busy flag or the MCCS VCP control parameter B7h in the client request and status packet.

In some cases, this delay is multiplied by the height, width, or number of pixels of the target image and added to the other delays to calculate the overall packet processing delay.

XVIII Multi-client support

Current protocol versions appear to be unable to directly support multiple client devices. However, most packets contain a reserved client ID field that can be used to address a particular client device in a system with multiple clients. Currently, for many applications, this client ID or these client IDs are set to zero. The sub-frame header packet also contains a field to indicate whether the host supports multiple client systems. Thus, there is a way in which it is possible to connect and address multiple client devices in future applications of the MDD interface or protocol to help system designers plan for future compatibility with multiple client hosts and clients.

In a system with multiple clients, it may be beneficial to connect the clients to the host via a Daisy-chained (Daisy-chained) of clients, either using a hub, as shown in fig. 95, or using a combination of these techniques, as shown in fig. 96.

XVIII. appendix

In addition to the format, structure, and content of the architecture and protocols discussed above for implementing embodiments of the present invention, more detailed field content or operations are provided herein for certain packet types. These matters are presented to further clarify their respective use or operation in order to make it easier for a person skilled in the art to understand and use the present invention for various applications. Only a few fields that have not been discussed are discussed herein. In addition, these fields are given with exemplary definitions and values with respect to the embodiments given above. These values, however, should not be construed as limiting the invention, but rather they represent one or more embodiments useful for implementing these interfaces and protocols, and not all embodiments need be implemented together or simultaneously. Other embodiments may also employ other values in order to achieve presentation of the desired data or data rate transmission results, as will be understood by those skilled in the art.

A. With respect to video stream packets

In one embodiment, the pixel data attribute field (2 bytes) has a series of bit values as explained below. Bits 1 and 0 select how to route the display pixel data. For bit value '11' data is displayed to either or both eyes, for bit value '10' data is routed only to the left eye and for bit value '01' data is routed only to the right eye, and for bit value '00' data is routed to an alternative display, as specified by bits 8 through 11 discussed below.

Bit 2 indicates whether the pixel data is provided in interlaced format, and a value of '0' means that the pixel data is in standard progressive format, with the line number (pixel Y coordinate) incremented by 1 as one progresses from one line to the next. When this bit has the value '1', the pixel data is in interlaced format and the line number is incremented by 2 as one progresses from one line to the next. Bit 3 indicates that the pixel data is in an alternate pixel format. This is similar to the standard interlacing mode with bit 2 enabled, but here the interlacing is vertical rather than horizontal. When bit 3 is '0', the pixel data is in a standard pixel-by-pixel format, and the column number (pixel X coordinate) is incremented by 1 as each successive pixel is received. When bit 3 is '1', the pixel data is in an alternating pixel format, with the column number incremented by 2 as each pixel is received.

Bit 4 indicates whether the pixel data relates to a display or a camera, i.e. where the data is transferred to or from an internal display of a wireless telephone or similar device, or even a portable computer or other device as described above, or where the data is transferred to or from a camera embedded in or directly coupled to the device. When bit 4 is '0', the pixel data is being transferred to or from the display frame buffer. When bit 4 is a '1', the pixel data is transferred to and from some type of camera or video device, such devices being well known in the art.

Bit 5 is used to indicate when a pixel group contains the next consecutive row of pixels in the display. This is considered the case when bit 5 is set equal to '1'. When bit 5 is set to '1', then the X left edge, Y top edge, X right edge, Y bottom edge, X start, and Y start parameters are not defined and are ignored by the client. When bit 15 is set to a logic 1 level, it indicates that the pixel data in the packet is the pixel data for the last row of pixels in the image. Bit 8 of the client feature capability identifier field of the client capability packet indicates that the feature is supported.

Bits 7 and 6 are display update bits to illustrate the frame buffer to which pixel data will be written. More specific effects are discussed elsewhere. For bit value '01', the pixel data is written into the offline image buffer. For bit value '00', the pixel data is written into an image buffer for refreshing the display. For bit value '11', pixel data is written into all image buffers. The bit value or combination '10' is treated as an invalid value or designation and the pixel data is ignored and not written to any image buffer. This value may have use for future applications of the interface.

Bits 8 through 11 form a 4-bit unsigned integer that illustrates the optional display or display location to which the pixel data is to be routed. Bits 0 and 1 are set equal to 00 to cause the display client to interpret bits 8 through 11 as the selectable display number. If bits 0 and 1 are not equal to 00, then bits 8 through 11 are set to zero.

Bits 12 through 14 are reserved for future use and should typically be set to logic zero. Bit 15 in question is used in conjunction with bit 5 and setting bit 15 to a bit logic 1 indicates that the row of pixels in the pixel data segment is the last row of pixels in the data frame. The next video stream packet with bit 5 set to logic 1 corresponds to the first row of pixels of the next video frame.

The 2 byte X start and Y start fields specify the absolute X and Y coordinates of the point (X start, Y start) of the first pixel in the pixel data field. The 2-byte X left edge and Y top edge fields specify the X coordinate of the left edge and the Y coordinate of the top edge of the screen window filled by the pixel data field, while the X right edge and Y bottom edge fields specify the X coordinate of the right edge and the Y coordinate of the bottom edge of the window being updated.

The pixel count field (2 bytes) specifies the number of pixels in the following pixel data field.

The parameter CRC field (2 bytes) contains the CRC of all bytes from the packet length to the pixel count. If this CRC fails to check, the entire packet is discarded.

The pixel data field contains the original video information to be displayed and is formatted in the manner described by the video data format descriptor field. As discussed elsewhere, data is transmitted one "row" at a time. When bit 5 of the pixel data attribute field is set to a logic 1 level, the pixel data field contains exactly one row of pixels, and the first pixel being transferred corresponds to the leftmost pixel and the last pixel transferred corresponds to the rightmost pixel.

The pixel data CRC field (2 bytes) contains only a 16-bit CRC of the pixel data. If the CRC check for this value fails, the pixel data is still usable, but the CRC error count is incremented.

B. Relating to audio stream packets

In one embodiment, the audio channel ID field (1 byte) identifies the particular audio channel to which the client device is to send audio data using an 8-bit unsigned integer value. The physical audio channels are designated or mapped by this field according to the values 0, 1, 2, 3, 4, 5, 6 or 7, which indicate the left front, right front, left rear, right rear, front center, subwoofer, surround left and surround right channels, respectively. The audio channel ID value 254 indicates that a single stream of digital audio samples is sent to the front left and front right channels. This simplifies communication for some applications, such as applications that use stereo headphones for voice communication, applications that improve productivity for PDA use, or other applications where a simple user interface generates an alert sound. The ID field values in the range from 8 to 253 and 255 are currently reserved for use in cases where new designs require additional tagging, as would be foreseeable by one skilled in the art.

The reserved 1 field (1 byte) is typically reserved for future use and all bits in this field are set to zero. One function of this field is to have all subsequent 2-byte fields aligned with a 16-bit word address and 4-byte fields aligned with a 32-bit word address.

The audio sample count field (2 bytes) specifies the number of audio samples in this packet.

Each of the number of sample bits and the packing field contains 1 byte for explaining the packing format of the audio data. In one embodiment, the commonly employed format is to define the number of bits per PCM audio sample using bits 4 through 0. Bit 5 then indicates whether the digital audio data samples are packed. As described above, fig. 12 illustrates the difference between packed audio samples and byte-aligned audio samples. A value of '0' for bit 5 indicates that each PCM audio sample in the digital audio data field is byte aligned with a byte boundary of the interface, and a value of '1' indicates that each successive PCM audio sample is packed relative to the previous audio sample. This bit is usually valid only if the value defined in bits 4 to 0 (the number of bits per PCM audio sample) is not a multiple of 8. Bits 7 through 6 are reserved for use when additional identification is required by the system design and are typically set to a value of zero.

The audio sample rate field (1 byte) specifies the audio PCM sample rate. The adopted formats are respectively as follows: the rate at value 0 is 8,000 samples per second (sps), value 1 indicates 16,000sps, value 2 indicates 24,000sps, value 3 indicates 32,000sps, value 4 indicates 40,000sps, value 5 indicates 48,000sps, value 6 indicates 11,025sps, value 7 indicates 22,050sps and value 8 indicates 44,100sps, and values 9 through 255 are reserved for future use, so they are currently set to zero.

The parameter CRC field (2 bytes) contains a 16-bit CRC of all bytes from the packet length to the audio sample rate. If this CRC fails to properly check, the entire packet is discarded. The digital audio data field contains the original audio samples to be played and is typically in the form of a linear format of unsigned integers. The audio data CRC field (2 bytes) contains a 16-bit CRC for audio data only. If this CRC fails to check, the audio data may still be used, but the CRC error count is increased.

C. Stream packet definition for user

In one embodiment, a 2 byte stream ID number field is used to identify a particular user-defined stream. The contents of the stream parameters and stream data fields are typically defined by the MDDI device manufacturer. The 2 byte stream parameter CRC field contains a 16 bit CRC of all bytes of the stream parameters starting from the packet length to the audio encoded bytes. If this CRC fails to check, the entire packet is discarded. Both the flow parameters and the flow parameter CRC fields may be discarded if they are not needed by the end application of the MDD interface, i.e. they are considered optional. The 2 byte stream data CRC field contains a CRC for only the stream data. The use of stream data is optional if this CRC fails to check properly, depending on the requirements of the application. The use of stream data is contingent on the goodness of the CRC, which typically requires buffering of the stream data until the CRC is confirmed as good. If the CRC does not pass the check, the CRC error count is incremented.

D. Grouping for color mapping

The 2-byte hClient ID field contains information or values reserved for client IDs, as previously used. Since this field is normally reserved for future use, it is currently set to zero by setting these bits to '0'.

The 2-byte color mapping entry count field uses a value to specify the total number of 3-byte color mapping entries contained in the color mapping data field or the total number of entries of the color mapping table present in this grouped color mapping data. In this embodiment, the number of bytes in the color mapping data is 3 times the color mapping item count. The color map item count is set equal to zero so that no color map data is sent. If the color map size is zero, the color map offset value is still typically sent but ignored by the display. The color mapping offset field (4 bytes) specifies the offset of the color mapping data in this packet from the beginning of the color mapping table in the client device.

The 2-byte parameter CRC field contains the CRC of all bytes from the packet length to the audio coding byte. If this CRC fails to check, the entire packet is discarded.

For the color map data field, the width of each color map location is specified by a color map entry size field, where in one embodiment, a first portion specifies a blue value, a second portion specifies a green value and a third portion specifies a red value. The color map size field specifies the number of 3-byte color map entries present in the color map data field. If a single color map cannot conform to the (fit into) video data format and color map groupings, the entire color map can be specified by sending multiple groupings, each with different color map data and color map offsets. The number of bits of blue, green and red in each color map data entry should be the same as specified by the color map RGB width field of the display capability grouping.

The 2-byte color mapping data CRC field contains only the CRC of the color mapping data. If such a CRC fails to check, the color mapping data is still usable, but the CRC error count is increased.

Each color mapping data item is transmitted in the following order: blue, green, red, the least significant bit of each component is transmitted first. The individual red, green and blue components of each color map entry are packed, but each color map entry (the least significant bit of the blue component) should be byte aligned. Fig. 100 shows an example of a color map data item having 6-bit blue, 8-bit green, and 7-bit red. For this example, the color map entry size in the color map packet is equal to 21, and the color map RGB width field of the client capability packet is equal to 0x 0786.

E. Encapsulating packets with respect to reverse link

The parameter CRC field (2 bytes) contains a 16-bit CRC of all bytes from the packet length to the turn length. If this CRC fails to check, the entire packet is discarded.

In one embodiment, the reverse link flag field (1 byte) contains a set of flags for requesting information from the client. If the bit (e.g., bit 0) is set to a logic 1 level, the host uses the client capability packet to request the specified information from the display. If the bit is set to a logic zero level, the host does not need information from the guest. The remaining bits (here bits 1 to 7) are reserved for future use and set to zero. However, more bits may also be used to set the flag for the reverse link as needed.

The reverse rate divisor field (1 byte) specifies the number of MDDI _ Stb cycles that occur in relation to the reverse link data clock. The reverse link data clock is equal to the forward link data clock divided by a double reverse rate divisor. The reverse link data rate relates to the reverse link data clock and the type of interface on the reverse link. In one embodiment, the reverse data rate is equal to the reverse link data clock for type 1 interfaces and equal to 2, 4, and 8 times the reverse link data clock for type 2, type 3, and type 4 interfaces, respectively.

The all-zero 1 field contains a set of bytes, here 8, which can be set equal to zero by setting the respective bit to a logic 0 level, and this field can be used to ensure that all MDDI _ Data signals can be at the logic zero level for a sufficient time before disabling the host line driver during the turnaround 1 field to allow the client to start recovering the clock using only MDDI _ Stb. In one embodiment, the length of the all-zeros 1 field is greater than or equal to the number of forward link byte transmissions in the round trip delay of the cable.

The Turn 1 Length field (1 byte) specifies the total number of bytes allocated to Turn 1 to establish the first Turn period. The Flex 1 field takes the number of bytes specified by the Flex 1 Length parameter before the line drivers in the host are disabled, to allow the MDDI _ Data line drivers in the client to be enabled. During bit 0 of turnaround 1, the guest enables its MDDI _ Data line driver, and the host disables its output to completely disable its output before the last bit of turnaround 1. The MDDI _ Stb signal behaves as if MDDI _ Data0 were at a logic 0 level during the entire turnaround 1 period. A more complete description of the steering 1 arrangement is given above.

The reverse data packet field contains a series of packets of data that are transmitted from the client to the host. When the guest has no Data to send to the host, the guest may send a stuff packet or drive the MDDI _ Data line to a logic 0 state or level. In this embodiment, if the MDDI _ Data line is driven to 0, the host interprets it as a packet having a length of 0 (not an active length), and the host will not receive further packets from the client during the current reverse link encapsulation packet.

The Turn 2 Length field (1 byte) specifies the total number of bytes allocated to Turn 2 for establishing the second Turn period. The recommended length of Flex 2 is the round trip delay plus the number of bytes required by the host to enable its MDDI Data drive. The turn 2 length value may also be greater than the minimum required or calculated value to allow sufficient time to process reverse link packets in the host.

The turn 2 field includes the number of bytes specified by the turn length parameter. The host waits at least the round trip delay time during turnaround 2 before enabling its MDDI _ Data line driver. The host enables its MDDI _ Data line drivers so that they are normally fully enabled before the last bit of turnaround 2, and the guest disables its outputs so that they are normally fully disabled before the last bit of turnaround 2. The purpose of the divert 2 field is to be able to transfer the amount of data remaining from the reverse data packet field from which the client sent or transmitted. Given the differences in the amount of security tolerance that different systems implement the interface and allocate, it is possible that neither the host nor the client drive the MDDI Data signal to a logic zero level during some portion of the turnaround 2 field period, as shown by the line receivers in the host. The MDDI _ Stb signal behaves as if MDDI _ Data0 were at a logic 0 level substantially during the entire turnaround 2 period. A description of the steering 2 arrangement is given above.

The reverse data packet field contains a series of data packets transmitted from the client to the host. As previously described, the filler packets are sent to fill the remaining space not used by other packet types.

The all-zeros-2 field contains a set of bytes (8 in this embodiment) set equal to zero values by setting these bits to a logic 0 level and is used to ensure that all MDDI _ Data signals can be in the zero state for sufficient time after the host line driver is enabled following the go-around-2 field so that the client can start recovering the clock using both MDDI _ Data0 and MDDI _ Stb.

F. Grouping client capabilities

As one embodiment illustrates, the protocol version field uses 2 bytes to specify the protocol version used by the client. The initial version is now set equal to 1 and changes over time as new versions are generated, as will be appreciated, while the minimum protocol version field uses 2 bytes to specify the minimum protocol version that the client can employ or interpret. In this case, the 0 value is also a valid value. The data rate capability field (2 bytes) specifies the maximum data rate that the client can receive on each data pair on the forward link of the interface and is specified in the form of millions of bits per second (Mbps). The interface type capability field (1 byte) specifies the type of interface supported on the positive and negative links. A bit set to "1" indicates that the specified interface is supported, while a bit set to "0" indicates that the specified type is not supported. The host and client should support at least type 1 on the forward and reverse links. There is no need to support contiguous ranges of interface types. For example, it would be very efficient to support only type 1 and type 3 in the interface, and not type 3 and type 4. Nor does it require that the forward and reverse links operate using the same interface type. However, when the link wakes up from hibernation, the forward and reverse links should start running in type 1 mode until either the negotiation has agreed or the other mode is selected, or both the host and the client agree to use the other mode.

In one embodiment, the type of interface supported is indicated by selecting bit 0, bit 1, or bit 2 to select a type 2(2 bit), type 3(4 bit), or type 4(8 bit) mode on the forward link, respectively, while bit 3, bit 4, or bit 5 selects a type 2, type 3, or type 4 mode on the reverse link, respectively; bits 6 and 7 are reserved and are typically set to zero. The bitmap width and height fields (2 bytes) specify the width and height of the bitmap in pixels, respectively.

The monochrome capability field (1 byte) is used to specify the number of bits of resolution that can be displayed in monochrome format. This value is set to zero if the display cannot use a monochrome format. Bits 7 through 4 are reserved for future use and are set to zero. Bits 3 to 0 define the maximum number of bits of gray levels that can be present in each pixel. These four bits can specify values 1 to 15 for each pixel. If the value is zero, then the display does not support the monochrome format.

The Bayer capacity field uses the number of bits of resolution, pixel groups, and pixel order that 1 byte can transmit in the Bayer format. This value is zero if the client cannot use the Bayer format. The Bayer capacity field consists of the following values: bits 3 to 0 define the maximum number of bits of intensity present in each pixel, while bits 5 to 4 define the necessary paxel pattern, while bits 8 to 6 define the necessary pixel order; bits 14 through 9 are reserved for future use and are also typically set to zero. A bit 15 set to 1 indicates that the client is capable of accepting Bayer pixel data in either packed or unpacked format. If bit 15 is set to 0, this indicates that the client is only able to accept Bayer pixel data in an unpacked format.

The color mapping capability field (3 bytes) specifies the maximum number of entries present in the display color mapping table. This value is zero if the display cannot use the color mapping format.

The RGB capability field (2 bytes) specifies the number of bits of resolution that can be displayed in RGB format. This value equals zero if the display cannot use the RGB format. The RGB capability word includes three independent unsigned values, where: in each pixel, bits 3 to 0 define the maximum number of bits for blue, bits 7 to 4 define the maximum number of bits for green, and bits 11 to 8 define the maximum number of bits for red. Currently, bits 14 through 12 are reserved for future use and are typically set to zero. A bit 15 set to 1 indicates that the client is capable of accepting RGB pixel data in either packed or unpacked format. If bit 15 is set to a logic 0 level, this indicates that the client is only capable of accepting RGB pixel data in an unpacked format.

The Y Cr Cb capability field (2 bytes) specifies the number of bits of resolution that can be displayed in the Y Cr Cb format. This value is set equal to zero if the display cannot use the Y Cr Cb format. The Y Cr Cb capability word includes three independent unsigned values, where: bits 3 to 0 define the maximum number of bits in the Cb sample, bits 7 to 4 define the maximum number of bits in the Cr sample, bits 11 to 8 define the maximum number of bits in the Y sample, and bits 15 to 12 are currently reserved for future use and set to zero.

The client feature capability indicator field uses 4 bytes and contains a set of flags to indicate the particular features supported in the client. A bit set to a logic 1 level indicates that the capability is supported, and a bit set to a logic zero level indicates that the capability is not supported. In one embodiment, the value of bit 0 indicates whether a bitmap block transfer packet (packet type 71) is supported. The values of bits 1, 2, and 3 indicate whether a bitmap area padding packet (packet type 72), a bitmap pattern padding packet (packet type 73), or a communication link data channel packet (packet type 74), respectively, is supported. The value of bit 4 indicates whether the client has the ability to make one color transparent, while the values of bits 5 and 6 indicate whether the client can accept the video data or audio data in a packetized format, respectively, and the value of bit 7 indicates whether the client can transmit a reverse link video stream from the camera. The value of bit 8 indicates whether the client is capable of receiving full line pixel data and ignoring display addressing as specified by bit 5 of the pixel data attribute field of the video stream packet, and the client may also use bit 15 of the pixel data attribute field to detect the end of frame sync or video frame data.

The values of bits 11 and 12 indicate whether the client is communicating with the pointing device and is capable of sending and receiving packets of pointing device data or the keyboard data, respectively. The value of bit 13 indicates whether the client has the ability to set one or more audio or video parameters by supporting VCP feature packets such as: a request VCP feature packet, a VCP feature reply packet, a set VCP feature packet, a request valid parameter packet, and a valid parameter reply packet. The value of bit 14 indicates whether the client has the ability to write pixel data to the offline display frame buffer. If the value of this bit is set to a bit logic 1 level, then the display update bits (bits 7 and 6 of the pixel data attribute field of the video stream packet) may be set to a value of "01".

The value of bit 15 indicates whether the client has the ability to write pixel data only to the display frame buffer that is currently being used to refresh the display image. If the bit is set to 1, then the display update bit (bits 7 and 6 of the pixel data attribute field of the video stream packet) may be set to the value "00". The value of bit 16 indicates that the client has the ability to write pixel data from a single video stream packet to the display frame buffer. If the bit is set to 1, then the display update bit (bits 7 and 6 of the pixel data attribute field of the video stream packet) may be set to the value "11".

The value of bit 17 indicates when the client has the ability to respond to a request for a particular status packet, the value of bit 18 indicates when the client has the ability to respond to a ping pong delay measurement packet, and the value of bit 19 indicates when the client has the ability to respond to a forward link deviation calibration packet.

The value of bit 21 indicates when the client has the ability to interpret a request for a particular status packet and respond with a valid status answer list packet. As described elsewhere, the client indicates the ability to return additional status in the valid parameter answer list field of the valid status answer list packet.

Bit 22 indicates whether the client has the ability to respond to the register access packet. Bits 9 through 10 and bits 23 through 31 indicate that they are currently reserved for future use or are used as optional flags to the benefit of the system designer and are typically set equal to zero.

The display video frame rate capability field (1 byte) specifies the maximum video frame update capability of the display in frames per second. The host may choose to update the image at a slower rate than the value specified in this field.

The audio buffer depth field (2 bytes) specifies the depth of the elastic buffer in the display dedicated to each audio stream.

The audio channel capability field (2 bytes) contains a set of flags to indicate which audio channels are supported by the client or client connection device. A bit set to 1 indicates that the channel is supportable and a bit set to zero indicates that the channel is unsupported. The bit positions are assigned to different channels, e.g., in one embodiment, bit positions 0, 1, 2, 3, 4, 5, 6, or 7 indicate the left front, right front, left back, right back, front center, subwoofer, surround left, and surround right channels, respectively. Bits 8 through 14 are currently reserved for future use and are typically set to zero. In one embodiment, bit 15 is used to indicate whether the client provides support for forward audio channel enable packets. If this is the case, bit 15 is set to a logic 1 level. However, if the client cannot disable the audio channels as a result of the forward audio channel enable packet, or if the client does not support any audio capability, then this bit is set to a logic 0 level or value.

The 2-byte audio sample rate capability field for the forward link contains a set of flags to indicate the audio sample rate capability of the client device. Thus, bit positions are assigned to different rates, such as bits 0, 1, 2, 3, 4, 5, 6, 7, and 8 being assigned to 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, and 44,100 Samples Per Second (SPS), respectively, bits 9 through 15 being reserved for future use or for alternative rates as needed, so they are currently set to '0'. Setting the bit value of one of the bits to '1' indicates that the particular sampling rate can be supported, and setting the bit to '0' indicates that the sampling rate is not supported.

The minimum subframe rate field (2 bytes) specifies the minimum subframe rate in frames per second. The minimum sub-frame rate remains sufficient to read the display state refresh rate of certain sensors or pointing devices in the display.

The 2-byte microphone sample rate capability field for the reverse link contains a set of flags to indicate the audio sample rate capability of the microphone of the client device. For purposes of utilizing MDDI, the client device microphone is configured to minimally support a rate of 8,000 samples per second. The bit positions for this field are assigned to different rates, e.g., with bit positions 0, 1, 2, 3, 4, 5, 6, 7, and 8 being used to represent 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, and 44,100 Samples Per Second (SPS), respectively, with bits 9 through 15 being reserved for future use or for alternative rates as needed, so they are currently set to '0'. Setting the bit value of one of the bits to '1' indicates that the particular sampling rate is supported, and setting the bit to '0' indicates that the sampling rate is not supported. If no microphone is connected, each bit of the microphone sample rate capability bits is set equal to zero.

The keyboard data format field (here 1 byte) specifies whether a keyboard is connected to the client system and the type of keyboard connected. In one embodiment, the value established by bits 6 through 0 is used to define the type of keyboard connected. If the value is zero, the keyboard type is considered unknown. When a value of 1, the keyboard data format is considered to be a standard PS-2 approach. Values in the range of 2 to 125 are not currently used and are reserved for system designers or interface companies (incorporators) or product developers to define specific keyboards or input devices for use with the MDD interface or corresponding client or host. Value 126 is used to indicate a user-defined keyboard data format and value 127 is used to indicate a keyboard that cannot be connected to the client. In addition, bit 7 can be used to indicate whether the keyboard is capable of communicating with the client. The intended use of this bit is to indicate the case where the keyboard communicates with the client using a wireless link. If bits 6 through 0 indicate a client to which the keyboard cannot connect, then bit 7 will be set to the 0 level. Thus, for one embodiment, when the value of bit 7 is 0, the keyboard and client cannot communicate, whereas if the value of bit 7 is 1, the keyboard and client have confirmed that they can communicate with each other.

The pointing device data format field (here 1 byte) specifies whether a pointing device is connected to the client system and the type of pointing device connected. In one embodiment, the value established by bits 6 to 0 is used to define the type of pointing device connected. If the value is zero (0), then the indication device type is considered unknown. When a value of 1, the pointing device data format is considered a standard PS-2 approach. Values in the range of 2 to 125 are not currently used and are reserved for use by system designers or interface companies (incorporators) or product developers to define specific pointing devices or input devices for use with the MDD interface or corresponding client or host. A value 126 is used to indicate a user-defined pointing device data format and a value 127 is used to indicate a pointing device that cannot be connected to the client. In addition, bit 7 can be used to indicate whether the pointing device is capable of communicating with the client. The intended use of this bit is to indicate the case where the pointing device is communicating with the client using a wireless link. If bits 6 through 0 indicate a client that indicates that the device cannot connect, then bit 7 will be set to the 0 level. Thus, for one embodiment, when the value of bit 7 is 0, it indicates that the device and client are unable to communicate, whereas if the value of bit 7 is 1, it indicates that the device and client have confirmed that they are able to communicate with each other.

The content protection type field (2 bytes) contains a set of flags to indicate the type of digital content protection supported by the display. Currently, bit position 0 is used to indicate the support of DTCP and bit position 1 is used to indicate the support of HDCP, and bit positions 2 through 15 are reserved for other protection schemes that are needed or available, so they are currently set to zero.

The manufacturer name field (here 2 bytes) includes the manufacturer's EISA 3-character ID and is packed into 3 5-bit characters in the same manner as in the VESA EDID specification. The character "a" is represented as binary 00001, the character "Z" is represented as binary 11010, and all letters between "a" and "Z" are represented as binary values corresponding to the alphabetical order between "a" and "Z". The most significant bit of the manufacturer name is unused and is typically set to logic 0 until used for future implementations. For example, a manufacturer represented by the string "XYZ" would have a manufacturer name with a value of 0x633 a. If the client does not support this field, it will be set to 0. The product code uses 2 bytes to contain the product code assigned by the display manufacturer. If the client does not support this field, then this field will be set to 0.

The reserved 1, reserved 2 and reserved 3 fields (here 2 bytes) are reserved for future use to reveal information. All bits in these fields are typically set to 0. The purpose of these fields is now to align all consecutive 2-byte fields with a 16-bit word address and to align 4-byte fields with a 32-bit word address.

In this embodiment, the sequence number field indicates the numerical sequence number of the display in 4 bytes. If the client does not support this field, then this field will be set to 0. The manufacture week field defines the manufacture week of the display with 1 byte. If the client supports this field, then the value is in the range of 1-53. If the client does not support this field, then this field will be set to 0. The year of manufacture field is 1 byte which defines the year of manufacture of the display. This value is the offset from 1990. The range of the year represented by this field is 1991-2245. For example, 2003 corresponds to a manufacturing year with a value of 13. If the client does not support this field, then this field will be set to 0.

The CRC field (here 2 bytes) contains a 16-bit CRC value for all bytes in the packet, including the length of the packet.

G. Grouping about client requests and status

The reverse link request field (3 bytes) specifies the number of bytes required by the client to send information to the host on the reverse link in the next subframe.

The CRC error count field (1 byte) indicates how many CRC errors have occurred since the beginning of the media frame. The CRC count is reset when a subframe header packet with a subframe count of zero is transmitted. This value typically saturates at 255 if the actual number of CRC errors exceeds 255.

The capability change field uses 1 byte to indicate a change in client capability. This may occur if the user connects a peripheral device such as a microphone, keyboard or display, or for other reasons. When bits [7:0] are equal to 0, then the capabilities have not changed since the last client capability packet was sent. However, when bits [7:0] are equal to 1 through 255, the capabilities have changed. The client capability packet is examined to determine new display characteristics.

The client busy field uses 2 bytes to indicate that the client is performing a particular function and is not ready to accept other packets associated with that function. The bit set to a logic 1 level or value indicates that the client is currently performing the particular function and that the relevant functional unit in the client is busy. This bit is set to logic 0 if the relevant feature in the client is ready. The client should return a busy status (bit set to 1) for all functions not supported in the client.

In one embodiment, these bytes are interpreted according to the following relationship: if bit 0 is "1", the bitmap block transfer function is busy, if bit 1 is "1", the bitmap area filling function is busy, and if bit 2 is "1", the bitmap pattern filling function is busy. Currently, bits 3 through 15 are reserved for future use and are typically set to a logic 1 level or state to indicate a busy state if these bits are allocated in the future.

H. Transmitting packets with respect to bit blocks

The window top left coordinate X-value and Y-value fields both use 2 bytes to specify the X and Y values of the coordinates of the top left corner of the window to be moved. The window width and height fields both use 2 bytes to specify the width and height of the window to be moved. The window X and Y move fields each use 2 bytes for specifying the number of pixels for the window to move horizontally and vertically, respectively. Typically, these coordinates are configured such that a positive value of X causes the window to move to the right, a negative value causes it to move to the left, and a positive value of Y causes the window to move downward and a negative value causes it to move upward.

I. Filling packets with respect to bitmap regions

The window top left coordinate X and Y values fields both use 2 bytes for X and Y values that illustrate the coordinates of the top left corner of the window to be filled. The window width and height fields (each 2 bytes) are used to illustrate the width and height of the window to be filled. The video data format descriptor field (2 bytes) specifies the format of the pixel region fill value. The format is the same as the same field in the video stream packet. The pixel region fill value field (4 bytes) contains the pixel values to be filled into the window specified by the field. The format of this pixel is specified in the video data format descriptor field.

J. Filling packets with respect to bitmap patterns

The window top left coordinate X and Y values fields both use 2 bytes to specify the X and Y values of the top left coordinate of the window to be filled. The window width and height fields (each 2 bytes) are used to illustrate the width and height of the window to be filled. The pattern width and pattern height fields (each 2 bytes) are used to illustrate the width and height of the fill pattern, respectively. The horizontal pattern offset field (2 bytes) specifies the horizontal offset of the pixel data pattern from the left edge of the specified window to be filled. This value is designated to be less than the value in the pattern width field. The vertical pattern offset field (2 bytes) specifies the vertical offset of the pixel data pattern from the top edge of the specified window to be filled. This value is designated to be less than the value in the pattern height field.

The 2-byte video data format descriptor field specifies the format of the pixel region fill value. Fig. 11 illustrates how a video data format descriptor is encoded. The format is the same as the same field in the video stream packet.

The parameter CRC field (2 bytes) contains the CRC of all bytes from the packet length to the video format descriptor. If this CRC fails to check, the entire packet is discarded. The pattern pixel data field contains the original video information that specifies the fill pattern in the format specified by the video data format descriptor. The data is packed into bytes and the first pixel of each row will be byte aligned. The fill pattern data is transmitted one line at a time. The pattern pixel data CRC field (2 bytes) contains a CRC for only the pattern pixel data. If this CRC fails to check, the pattern pixel data may still be used, but the CRC error count is increased.

K. Communication link data path grouping

The parameter CRC field (2 bytes) contains one 16-bit CRC of all bytes from the packet length to the packet type. If this CRC fails to check, the entire packet is discarded.

The communication link data field contains the raw data from the communication channel. This data is merely passed on to the computing device in the display.

The communication link data CRC field (2 bytes) contains a 16-bit CRC over only the communication link data. If this CRC fails to check, the communication link data may still be used or still be useful, but the CRC error count is increased.

Handover request packet for interface type

The interface type field (1 byte) specifies the new interface type to be used. The value in this field specifies the interface type in the following manner. If the value of bit 7 is equal to '0', then the type switch request is for the forward link, and if equal to '1', then the type switch request is for the reverse link. Bits 6 through 3 are reserved for future use and are typically set to zero. Bits 2 to 0 are used to define the interface type to be used, a value of 1 means switching to type 1 mode, a value of 2 means switching to type 2 mode, a value of 3 means switching to type 3 mode, and a value of 4 means switching to type 4 mode. The values '0' and 5 to 7 are reserved for use by the flags of the future alternative modes or mode combinations.

Acknowledge packet on interface type

The interface type field (1 byte) has a value for confirming a new interface type to be used. The value in this field specifies the interface type in the following manner. If the value of bit 7 is equal to '0', then the type switch request is for the forward link, or if equal to '1', then the type switch request is for the reverse link. Bit positions 6 through 3 are now reserved for designating other handover types as needed and are typically set to zero. However, bit positions 2 to 0 are used to define the type of interface to be used, where a value of '0' indicates a negative acknowledgement, or the requested switch cannot be performed, and values of '1', '2', '3', and '4' indicate a switch to type 1, type 2, type 3, and type 4 modes, respectively. The values 5 to 7 are reserved to be used as optional flags for the mode as required.

With respect to performing type switching packets

The 1 byte interface type field indicates the new interface type to be used. The value present in this field specifies the interface type by first using the value of bit 7 to determine whether to type switch the forward or reverse link. A value of '0' indicates that the type handover request is for the forward link, and a value of '1' indicates that the type handover request is for the reverse link. Bits 6 through 3 are reserved for future use and are typically set to a value of zero. However, bits 2 to 0 are used to define the interface type to be used, and values 1, 2, 3 and 4 specify switching to type 1, type 2, type 3 and type 4 modes, respectively. The values 0 and 5 to 7 of these bits are reserved for future use.

Enabling packets for forward audio channels

The audio channel enable mask field (1 byte) contains a set of flags to indicate which audio channels are to be enabled in the client. A bit set to 1 enables the corresponding lane and a bit set to zero disables the corresponding lane. Bits 0 through 5 indicate channels 0 through 5, respectively, which are centered at the front left, front right, back left, back right, front, and subwoofer channels. Bits 7 through 6 are reserved for future use while normally being set to zero.

Packet for inverse audio sampling rate

The audio sample rate field (1 byte) specifies the digital audio sample rate. The values of this field are assigned to different rates, with values 0, 1, 2, 3, 4, 5, 6, 7 and 8 being used to indicate 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050 and 44,100 Samples Per Second (SPS), respectively, and the values 9 through 254 are reserved for use at alternative rates as needed, so they are currently set to '0'. The value 255 is used to disable the reverse link audio stream.

The sample format field (1 byte) specifies the format of the digital audio samples. When bits [1:0] are equal to '0', the digital audio samples are in a linear format, when they are equal to 1, the digital audio samples are in a μ -law format, and when they are equal to 2, the digital audio samples are in an A-law format. Bits [7:2] are reserved for alternative use to indicate audio format as needed and are typically set equal to zero.

Protection of overhead packets with respect to digital content

The content protection type field (1 byte) specifies the digital content protection method used. A value of '0' indicates Digital Transmission Content Protection (DTCP), and a value of 1 indicates a high-bandwidth digital content protection system (HDCP). The value range of 2 to 255 is currently specified, but is reserved for optional protection schemes as needed. The content protection overhead message field is a variable length field that contains the content protection message sent between the host and the client.

Enable grouping for transparent color

The transparent color enable field (1 byte) specifies the case where the transparent color mode is enabled or disabled. If bit 0 is equal to 0, then the transparent color mode is disabled, if equal to 1, then the transparent color mode is enabled, and the transparent color is specified by the following two parameters. Bits 1 through 7 of this byte are reserved for future use and are typically set equal to zero.

The video data format descriptor field (2 bytes) specifies the format of the pixel region fill value. Fig. 11 illustrates how a video data format descriptor is encoded. The format is typically the same as the same field in a video stream packet.

The pixel region fill value field uses 4 bytes to assign to the pixel values to be filled into the window specified above. The format of this pixel is specified in the video data format descriptor field.

Measurement packet for round trip delay

The 2-byte packet length field specifies the total number of bytes in the packet that do not include the packet length field, and in one embodiment a fixed length of 159 is selected. The 2 byte packet type field identifies the packet type with a value 82 that identifies a packet as a round trip delay measurement packet. As before, the hClientID field is reserved for future use as a Client ID and is typically set to 0.

In one embodiment, the parameter CRC field (2 bytes) contains a 16-bit CRC of all bytes from the packet length to the packet type. If this CRC fails to check, the entire packet is discarded.

The guard time 1 field (here 64 bytes) is used to allow the MDDI _ Data line driver in the client to be enabled before the line driver in the host is disabled. During bit 0 of guard time 1, the client enables the MDDI _ Data line driver, and the host disables its line driver so that it is completely disabled before the last bit of guard time 1. During guard time 1, both the host and the guest drive a logic zero level when they are not disabled. Another purpose of this field is to ensure that: prior to disabling the host line drivers, all of the MDDI _ Data signals are at a logic zero level for a sufficient time to allow the client to begin recovering the clock or clock signal using only the MDDI _ Stb

The measurement period field is a 64 byte window that allows the client to respond with 0xff, and 30 bytes of 0x0 at half the data rate used on the forward link. This data rate corresponds to the case where the reverse link rate divisor is 1. The client returns this response as soon as it is perceived to be at the beginning of the measurement period. The host receives this response from the client at the time the exact link round trip delay plus the logical delay of the client has elapsed after the first bit of the measurement period started at the host.

The all zeros 1 field (2 bytes) contains multiple zeros to allow the MDDI _ Data line drivers in the host and client to overlap so that MDDI _ Data is always driven. The host enables MDDI _ Data during bit 0 of guard time 2 and the client also drives the signal to a logic 0 level as it did at the end of the measurement period.

The value in the guard time 2 field (64 bytes) allows the measurement periods driven by the client to overlap when the round trip delay is at the maximum value that the measurement period can measure. The guest disables its line driver during bit 0 of guard time 2, while the host enables its line driver immediately after the last bit of guard time 2. During guard time 2, both the host and the guest drive a logic 0 level when they are not disabled. Another purpose of this field is to ensure that all MDDI _ Data signals are at a logic 0 level for a sufficient time to allow the guest to begin recovering clock signals using MDDI _ Data0 and MDDI _ Stb after the line drivers of the host are enabled.

Calibrating packets for forward link deviation

In one embodiment, the parameter CRC field (2 bytes) contains a 16-bit CRC of all bytes from the packet length to the packet type. If this CRC fails to check, the entire packet is discarded.

The all-zeros 1 field uses 1 byte, ensuring a transition on MDDI _ Stb at the end of the parameter CRC field.

The calibration Data sequence field contains the Data sequence for the MDDI _ Data signal to toggle every Data cycle. The length of the calibration data sequence field depends on the interface used on the uplink. During processing of the calibration Data sequence, the MDDI host controller sets all MDDI _ Data signals equal to the strobe signal. When the calibration Data sequence field is received by the client display, the client clock recovery circuit should recover the Data clock using only the MDDI _ Stb instead of the exclusive or of the MDDI _ Stb and MDDI _ Data 0. Depending on the exact phase of the MDDI _ Stb signal at the beginning of the calibration data sequence field, the calibration data sequence will typically be one of the following based on the type of interface being used when sending this packet:

type 1- (64 byte data sequence) 0xaa, 0xaa … … or 0x55, 0x55 … …

Type 2- (128 byte data sequence) 0xcc, 0xcc … … or 0x33, 0x33 … …

Type 3- (256 byte data sequence) 0xf0, 0xf0 … … or 0x0f, 0x0f … …

Type 4- (512 byte data sequence) 0xff, 0x00, 0xff, 0x00 … … or 0x00, 0xff, 0x00, 0xff … …

Examples of possible MDDI _ Data and MDDI _ Stb waveforms for type 1 and type 2 interfaces are shown in fig. 62A and 62B, respectively.

XVII. end word

While various embodiments of the present invention have been described, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims (40)

1. A digital data interface for transferring digital presentation data at a high rate between a host device and a client device via a communication path, comprising:

a plurality of packet structures linked together to form a communication protocol for communicating a preselected set of digital control and presentation data between the host and client machines via said communication path; and

at least one link controller residing in the host device coupled to the client through the communication path, the link controller configured to generate, transmit, and receive packets forming the communication protocol, and form digital presentation data into one or more types of data packets.

2. The interface of claim 1, further comprising:

the packets grouped together within media frames, wherein the media frames are communicated between the host and client and have a predefined fixed length, and a predetermined number of the packets have different and variable lengths.

3. The interface of claim 1, further comprising:

a sub-frame header packet located at the beginning of a packet transmission from the host.

4. The interface of claim 1, wherein the link controller is a host link controller, and further comprising:

At least one client link controller residing in the client device coupled to the host through the communication path and configured to generate, transmit, and receive packets forming the communication protocol and to form digital presentation data into one or more types of data packets.

5. The interface of claim 2, further comprising:

a plurality of transfer modes, each transfer mode allowing a different maximum number of bits of data to be transferred in parallel within a given time period, wherein each mode is selectable by negotiation between the host and client link drivers; and

wherein the transfer mode is dynamically adjustable between the plurality of modes during transfer of data.

6. The interface of claim 1, further comprising:

a link shutdown type packet transmitted by said host to said client for terminating data transfer in either direction over said communication path.

7. The interface of claim 1, further comprising:

means for causing the client to wake the host from a sleep state.

8. A method for transferring digital data at a high rate between a host device and a client device via a communication path for presentation to a user, comprising:

Generating one or more of a plurality of predefined packet structures and linking the packet structures together to form a predefined communication protocol;

communicating a preselected set of digital control and presentation data between said host and said client device via said communication path using said communication protocol;

coupling at least one host link controller residing in the host device to the client device over the communication path, the host link controller configured to generate, transmit, and receive packets forming the communication protocol, and form digital presentation data into one or more types of data packets; and

transmitting data in packets via the communication path using the link controller.

9. The method of claim 8, further comprising:

grouping the packets together in media frames for transfer between the host and client, the media frames having a predefined fixed length, and a predetermined number of the packets having different and variable lengths.

10. The method of claim 8, further comprising:

starting transmission of packets from the host using a sub-frame header type packet.

11. The method of claim 8, further comprising:

packets forming the communication protocol are generated, transmitted, and received by at least one client link controller residing in the client device coupled to the host device over the communication path.

12. The method of claim 11, further comprising:

negotiating one of a plurality of transfer modes used in each direction between link drivers of the host and client, each transfer mode allowing a different maximum number of bits of data to be transferred in parallel within a given time period; and

dynamically adjusting between the plurality of transfer modes during transfer of data.

13. The method of claim 8, further comprising:

data transfer in either direction over the communication path is terminated using a link shutdown type packet transmitted by the host to the client.

14. The method of claim 8, further comprising:

waking up the host from a sleep state through communication with the client.

15. Apparatus for transferring digital data at a high rate between a host device and a client device via a communication path for presentation to a user, comprising:

At least one host link controller disposed in said host device for generating one or more of a plurality of predefined packet structures and linking these together to form a predefined communication protocol, and for communicating a preselected set of digital control and presentation data between said host and said client devices via said communication path using said communication protocol;

at least one client controller disposed in the client device and coupled to the host link controller through the communication path; and

each link controller is configured to generate, transmit, and receive packets forming the communication protocol, and to form digital presentation data into one or more types of data packets.

16. The apparatus of claim 15, wherein the host controller comprises a state machine.

17. The apparatus of claim 15, wherein the host controller comprises a general purpose signal processor.

18. The apparatus of claim 15, further comprising a sub-frame header type packet located at the beginning of a packet transmission from the host.

19. The apparatus of claim 15, wherein the host controller comprises one or more differential line drivers; and, the client receiver includes one or more differential line receivers coupled to the communication path.

20. The apparatus of claim 15, wherein the host and client link controllers are configured to use one of a plurality of transfer modes in each direction, each transfer mode allowing a different maximum number of data bits to be transferred in parallel within a given time period; and is capable of dynamically adjusting between the plurality of transfer modes during transfer of data.

21. The apparatus of claim 15, wherein the host controller is configured to transmit a link shutdown type packet to the client module to terminate data transfer in either direction over the communication path.

21. A computer program product for use in an electronic system for transferring digital data at a high rate between a host device and a client device via a communication path for presentation to a user, the computer program product comprising:

a computer usable medium having computer readable program code means embodied in said medium for causing an application program to execute on said computer system, wherein said computer readable program code means comprises:

computer readable first program code means for causing said computer system to generate one or more of a plurality of predefined packet structures and link the packet structures together to form a predefined communication protocol;

Computer readable second program code modules for causing said computer system to communicate a preselected set of digital control and presentation data between said host and said client devices via said communication path using said communication protocol;

computer readable third program code modules for causing the computer system to couple at least one host link controller disposed in the host device to at least one client controller disposed in the client device over the communication path, the link controllers configured to generate, transmit and receive packets forming the communication protocol and to form digital presentation data into one or more types of data packets; and

computer readable fourth program code module for causing the computer system to transmit data in packets via the communication path using the link controller.

22. An apparatus for transferring digital data at a high rate between a host device and a client device via a communication path for presentation to a user, comprising:

means for generating one or more of a plurality of predefined packet structures and linking the packet structures together to form a predefined communication protocol;

Means for communicating a preselected set of digital control and presentation data between said host and said client device via said communication path using said communication protocol;

means for coupling at least two link controllers together over the communications path, one such means in each of the host and client and configured to generate, transmit and receive packets forming the communications protocol and to form digital presentation data into one or more types of data packets; and

means for transmitting data in packets via the communication path using the link controller.

23. The apparatus of claim 22, further comprising means for beginning transmission of packets from the host with a subframe header type packet.

24. The apparatus of claim 22, further comprising means for requesting display capability information from a client by a host link controller to determine what data types and data rates the client is capable of supporting through the interface.

25. A processor for use in an electronic system for communicating digital data at a high rate between a host device and a client device via a communication path, the processor configured to generate one or more of a plurality of predefined packet structures and link the packet structures together to form a predefined communication protocol; forming the digital presentation data into one or more types of data packets; communicating a preselected set of digital control and presentation data between said host and said client device via said communication path using said communication protocol; and transmitting data in the form of packets via the communication path.

26. A state machine for use in obtaining synchronization in an electronic system for transferring digital data at a high rate between a host device and a client device via a communication path, the state machine configured to have a synchronization state of at least one asynchronous frame state, at least two synchronization states of obtaining synchronization states, and a synchronization state of at least three in-synchronization states.

27. A state machine for use in obtaining synchronization in an electronic system for transferring digital data at a high rate between a host device and a client device via a communication path, the state machine configured to have at least one synchronization state to obtain a synchronization state and a synchronization state of at least two in-synchronization states.

28. The state machine of claim 27, wherein one condition for transitioning between the acquiring synchronization state and the first in-synchronization state is a detected presence of a synchronization pattern in the communication link.

29. The state machine of claim 27, wherein a second condition for transitioning between the acquiring synchronization state and the first in-synchronization state is detecting the presence of a subframe header packet and a correct CRC value at a frame boundary.

30. The state machine of claim 27, wherein one condition for transitioning between the first in-sync state and the obtaining synchronization state is detecting an absence of a synchronization pattern or a presence of an erroneous CRC value at a subframe boundary.

31. The state machine of claim 27, wherein one condition for transitioning between the first in-sync state and the second in-sync state is detecting an absence of a synchronization pattern or a presence of an erroneous CRC value at a subframe boundary.

32. The method of claim 12, further comprising:

waking up a communication link by the host by driving a data line to a high state for at least 10 clock cycles and starting transmission of a strobe signal with the data line being zero.

33. The method of claim 32, further comprising:

after the data lines have been driven high by the host for about 150 clock cycles, the data lines are driven low by the host for a predetermined number of clock cycles while continuing to transmit a strobe signal.

34. The method of claim 32, further comprising:

beginning transmission of a first subframe header packet by the host.

35. The method of claim 33, further comprising:

counting, by the client, at least 150 consecutive clock cycles of the data line in a high state and then at least 50 consecutive clock cycles of the data line in a low state.

36. The method of claim 33, further comprising:

stopping driving the data line high after the client counts 70 consecutive clock cycles of the data in a high state.

37. The method of claim 36, further comprising:

counting another 80 consecutive clock cycles of the data line in a high state by the client to reach 150 clock cycles of the data line in a high state and looking for 50 clock cycles of the data line in a low state and looking for the unique word.

38. The method of claim 12, further comprising:

the number of clock cycles that occur is counted until the host samples a 1 by sampling the data line on both rising and falling edges during the reverse timing packet.

39. The method of claim 12, further comprising:

The number of clock cycles that occur is counted until the host samples a 1 by sampling the data line on both rising and falling edges during the reverse timing packet.