Generating and implementing a communication protocol and interface for high data rate signal transfer

Generation and realization of communication protocols and interfaces for high data rate signal transmission

[0001] This application is a divisional application of a Chinese patent application whose application date is September 6, 2002, and the application number is No. 02821314.9. The invention title is "Generation and Implementation of Communication Protocols and Interfaces for High Data Rate Signal Transmission". .

[0002] Cross-references to related applications

[0003] This application claims priority for the following applications: U.S. Provisional Patent Application No. 60/255, 833,-filed on December 15, 2000, converted to U.S. Serial No. 10/020, 520, on December 14, 2001 Submitted, pending approval; and U.S. Provisional Patent Application No. 60/317,858, filed on September 6, 2001, pending approval; and U.S. Patent Application No. 60/356,892, submitted on February 13, 2002, pending approval, these applications It is fully incorporated herein by reference.

Technical field

[0004] The present invention relates to a digital signal protocol and process for transferring signals between a host communication device and a client audio/video display device at a high data rate. The present invention particularly relates to a technology for transmitting multimedia or other types of data from a wireless device to a micro display unit or other display device using a transmission mechanism of low power and high data rate.

Background technique

[0005] Computers, electronic game-related products, and various video technologies (for example, DVDs and high-definition VCRs) have greatly advanced in the past few years, and even when certain types of text are included, they will have higher resolutions. The static, video, video-on-demand, and graphic images of this device appear to the end user of this device. These advancements require the use of higher-resolution electronic viewing devices, such as high-definition video monitors, HDTV monitors, or dedicated image projection components. In order to create a more realistic, content-rich, or authentic multimedia experience for end users, a combination of this visual image and high-definition or high-quality audio data is used, such as when using CD-type sound reproduction, DVD, And other devices that also have related audio signal output. In addition, in order to only show audio to end users, a highly mobile, high-quality sound system and music transmission mechanism, such as MP3 players, have been developed.

[0006] In a typical video presentation situation, video data is generally transmitted using current technology, and the transmission rate is preferably slow and medium, on the order of one to ten kilobits per second. This data is then either buffered or stored in a transient or longer-term storage device for delayed (later) display on the desired viewing device. For example, in order to receive or send data useful when digitally reproducing an image, the image can be transmitted "via" or using the Internet, using a program that resides on a computer with a modem or Internet connection. Similar transmissions also occur when using wireless devices such as portable computers equipped with wireless modems, or wireless personal data assistants (PDAs), or wireless phones.

[0007] Once the data is received, it is stored locally in a storage element, circuit or device including an external storage device, such as RAM or flash memory, for playback. Depending on the amount of data and image resolution, playback can start relatively quickly, or be displayed after a long delay. That is to say, in some cases, the image display allows a certain degree of real-time playback for small and low-resolution images that do not require a lot of data, or allows the use of a certain type of buffering to display some material after a small delay , And more material is transmitted. Assuming that there are no obstacles in the transmission link, once the appearance starts, the transmission is reasonably transparent to the end user of the viewing device.

[0008] Data used to create or static images or moving videos is usually compressed using one of a variety of known techniques, such as the Joint Photographic Experts Group (JPEG), Moving Picture Experts Group (MPEG), and media, computer and communications In order to increase

CN 101197652 Β

The technology specified by other well-known standards organizations or companies for data transmission on high-speed communication links. This enables faster transfer of images or data by using a smaller number of bits to transfer a given amount of information.

[0009] Once the data is transferred to a "local" device such as a computer or other device, the resulting information is uncompressed (or played with a dedicated decoding player) and is ready to be based on the corresponding available display resolution and control elements Appropriate display. For example, the typical computer video resolution represented by the screen resolution of X by Υ pixels generally ranges from as low as 480 X 640, through 600 X 800, to 1024 X 1024, but it can also be used according to expectations or needs. Resolution.

[0010] Image rendering is also affected by the content of the image and the performance of a given video controller to manipulate the image, which is expressed in terms of predefined color levels or color depths (bits per pixel used to produce colors) and density, and Any additional overhead bits can be used. For example, a typical computer display would expect anywhere from about 8 to 32 bits per pixel or more to display various colors (shadows and chromaticity), but other values are also encountered.

[0011] It can be seen from the above values that a given screen image requires data to be transmitted anywhere from 2.45 megabits (Mb) to about 33.55Mb, with typical resolution and depth ranging from the lowest to the highest. . When watching video or sports-type images at a rate of 30 frames per second, the amount of data required is about 73.7 to 1006 megabits per second (Mbps), or about 9.21 to 125.75 megabits per second Bits (MBps). In addition, people may wish to display audio data in combination with images, such as for multimedia presentations, or as separate high-resolution audio presentations, such as CD quality music. Additional signal processing of interactive commands, controls, or signals can also be used. Each of these options adds more data to be transferred. In any case, when people expect to transmit high-quality or high-resolution image data and high-quality audio information or data signals to the end user in order to create a rich experience, the display element and used to provide such data Types of sources or host devices require high data transfer rate links.

[0012] A data rate of approximately 115 kilobytes per second (KBps) or 920 kilobytes (Kbps) can be conventionally handled by modern serial interfaces. Other interfaces such as the USB serial interface can provide data transmission at a rate of up to 12MBps, while dedicated high-speed transmissions such as the Institute of Electrical and Electronics Engineers (IEEE) 1394 standard configuration will occur on the order of 50 to 100MBps. Unfortunately, these rates are not up to the expected high data rates discussed above. The above-mentioned high data rates are conceived for future wireless data devices and services to provide high-resolution, content for stimulating portable video displays or audio devices. Rich output signal. In addition, these interfaces require the use of a large number of hosts or systems for operation and client software. Their software protocol stack also creates a lot of undesirable overhead, especially when considering mobile wireless devices or telephone applications. Moreover, some of these interfaces use bulky cables, which are too bulky and unsatisfactory for highly aesthetic mobile applications, complicated connectors that add cost, or simply consume too much power.

[0013] There are other well-known interfaces, such as an analog video graphics array (VGA) interface, a digital video interactive (DVI) interface, or a gigabit video interface (GVIF). The first two are parallel-type interfaces. They process data at a higher transmission rate, but also use bulky cables and consume a lot of power on the order of several watts. Neither of these features can be used in portable consumer electronic devices. Even the third interface consumes too much power and uses expensive or bulky connectors.

[0014] For some of the aforementioned interfaces, as well as very high-speed data systems/protocols or transfer mechanisms related to data transfer for fixed installation of computer equipment, there is another major disadvantage. In order to provide the desired data transfer rate, large amounts of power and/or operation at high current levels are also required. This greatly reduces the usefulness of this technology for highly mobile consumer-oriented products.

[0015] Generally speaking, in order to provide such data transmission with selected objects such as optical fiber type connection and transmission elements, etc.

CN 101197652 Β

Delivery rate, compared to what is expected for actual commercial consumer-oriented products, also requires some additional converters and components that introduce complexity and cost. In addition to the generally expensive characteristics of optical systems to date, their power requirements and complexity hindered the general use of lightweight, low-power, portable applications.

[0016] What is lacking in the portable or mobile application industry is a technology that provides high-quality presentation experience for highly mobile terminal users, whether based on audio, video, or multimedia. In other words, when using portable computers, such as wireless phones, PDAs, or other highly mobile communication devices or equipment, the currently used video or audio display systems or devices cannot deliver output at the desired high-quality level at all. Often, the perceived lack of quality is the result of not being able to obtain the high data rates required to transmit high-quality display data. Therefore, a new transmission mechanism is needed to increase the data flux between the host device that provides data and the client display device or element that displays the output to the end user.

Summary of the invention

[0017] In view of the above-mentioned defects and other existing defects in the field, the embodiment of the present invention develops a new protocol and data transfer mechanism for transferring between the host device and the receiving client device at a high data rate. Transfer data.

[0018] The advantage of the embodiments of the present invention is that a technology for data transmission is provided, which has low complexity, low cost, high reliability, is suitable for use environment, and is very robust, yet still very flexible.

[0019] The embodiment of the present invention is directed to a mobile digital data interface (Mobile Digital Data Interface), which is used to transmit digital data between a host device and a client device at a high rate on a communication path, and the communication path uses multiple and A series of packet structures that are connected together to form a communication protocol for transmitting a set of pre-selected digital control and visualization 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. At least one link controller residing in the host device is coupled with the client device through a communication path or link, and is used to generate, send, and receive packets forming a communication protocol, and compose digital display data into one or more Types of data packets. The interface provides two-way information transfer between the host and the client.

[0020] In still other aspects of the present invention, at least one client link controller, or client receiver, is deployed in the client device and coupled with the host device through a communication path or link. The client link controller is also configured to generate, send, and receive packets forming a communication protocol, and compose digital display data into one or more types of data packets. Generally speaking, the host or link controller uses a state machine in order to process data packets used in instructions or some type of signal preparation and query processing, but a slower general-purpose processor can be used to manipulate data and communication protocols used Some of the less complex groupings. The host controller includes one or more differential line drivers; and the client receiver includes one or more differential line receivers coupled to the communication path.

[0021] The packets are grouped together in a media frame transmitted between the host and the client device, the media frame has a predefined fixed length, and a predetermined number of packets with different variable lengths. Each packet includes a packet length field, one or more packet data fields, and a cyclic redundancy check field. The subframe header packet is transmitted or located at the beginning of the transmission of other packets from the host link controller. In order to transmit video type data and audio type data respectively from the host to the client on the forward link to be presented to the user, the communication protocol uses one or more video stream type packets and audio stream type packets. The communication protocol uses one or more reverse link encapsulation type packets to transfer data from the client device to the host link controller.

[0022] In order to occupy the forward link transmission period when there is no data, the host link controller generates a filler type packet. The communication protocol uses a number of other packet types to convey video information. This grouping includes color map, bit block transmission, bitmap area filling, bitmap mode filling, and transparent color enable type grouping. The communication protocol is divided into user-defined stream types

Group to transmit interface user-defined data. The communication protocol uses keyboard data and pointing device data type grouping to transfer data to and from the user input device associated with the client device. The communication protocol uses link close type packets to terminate data transmission in either direction of the communication path.

[0023] The communication path generally includes or uses a cable with a series of four or more wires and a shield. In some embodiments, the link controller includes a USB data interface, and the cable uses a USB type interface and other wires. In addition, printed circuits or flexible wires can be used as needed.

[0024] In order to determine what type of data and data rate the client can provide through the interface, the host link controller requests the client device to display performance information. The client link controller uses at least one display performance type group to transmit the display or display performance to the host link controller. The communication protocol uses multiple transmission modes, each of which allows data with a different maximum number of bits to be transmitted in parallel over a given period of time. These transfer modes are dynamically adjustable during data transfer, and do not need to use the same modes used on the forward link on the reverse link.

[0025] In other aspects of some embodiments of the present invention, the host device includes a wireless communication device, such as a wireless phone, a wireless PDA, or a portable computer in which a wireless modem is deployed. Typical client devices include portable video displays, such as microdisplay devices, and/or portable audio presentation systems. Also, the host can use a storage device or element to store presentation or multimedia data to be presented to the user of the client device to be transmitted.

Description of the drawings

[0026] The following describes further features and advantages of the present invention, as well as the structure and operation of various embodiments of the present invention, with reference to the accompanying drawings. In the drawings, the same reference numerals generally indicate the same, functionally similar, and/or structurally similar elements or processing steps, and the leftmost digit in the reference numeral represents the drawing where the element first appears.

[0027] FIG. 1a illustrates the basic environment in which the present invention can work, including a microdisplay device used in conjunction with a portable computer.

[0028] FIG. 1b illustrates the basic environment in which the present invention can work, including a micro display device and an audio display element used in conjunction with a wireless transceiver.

[0029] FIG. 2 illustrates the general concept of a mobile digital data interface (Mobile Digital DataInterface) with a host and a client interconnection.

[0030] FIG. 3 illustrates a packet structure for realizing data transfer from a client device to a host device.

[0031] FIG. 4 illustrates the MDDI link controller and signal types transmitted between the host and the client on the physical data link wires of the Type-I and Type U interfaces.

[0032] FIG. 5 illustrates the MDDI link controller and the signal type transmitted between the host and the client on the physical data link wires of the Type-IKII and IV interfaces.

[0033] FIG. 6 illustrates the structure of frames and subframes used to implement the interface protocol.

[0034] FIG. 7 illustrates a general packet structure used to implement the interface protocol.

[0035] FIG. 8 illustrates the format of a subframe header packet.

[0036] FIG. 9 illustrates the format and content of the filler packet.

[0037] FIG. 10 illustrates the format of a video stream packet.

[0038] FIG. 11 illustrates the format and content of the video data format descriptor of FIG. 10.

[0039] Figure 12 Data usage in grouped and unpacked formats.

[0040] FIG. 13 illustrates the format of an audio stream packet.

CN 101197652 Β

[0041] FIG. 14 illustrates the use of the byte-aligned and packetized PCM format of data.

[0042] FIG. 15 illustrates the format of a user-defined stream packet.

[0043] FIG. 16 illustrates the format of the color map grouping.

[0044] FIG. 17 illustrates the format of a reverse link encapsulation packet.

[0045] FIG. 18 illustrates the format of the display performance grouping.

[0046] FIG. 19 illustrates the format of a keyboard data packet.

[0047] FIG. 20 illustrates the format of a pointing device data packet.

[0048] FIG. 21 illustrates the format of a link close packet.

[0049] FIG. 22 illustrates the format of the display request and status packet.

[0050] FIG. 23 illustrates the format of a bit block transmission packet.

[0051] FIG. 24 illustrates the format of a bitmap area padding packet.

[0052] FIG. 25 illustrates the format of a bitmap mode padding packet.

[0053] FIG. 26 illustrates the format of a communication link data channel packet.

[0054] FIG. 27 illustrates the format of an interface type switching request packet.

[0055] FIG. 28 illustrates the format of an interface type confirmation packet.

[0056] FIG. 29 illustrates the format of an execution type switching packet.

[0057] FIG. 30 illustrates the format of a forward audio channel enable packet.

[0058] FIG. 31 illustrates the format of a reverse audio sample rate packet.

[0059] FIG. 32 illustrates the format of a digital content protection overhead packet.

[0060] FIG. 33 illustrates the format of a transparent color enable packet.

[0061] FIG. 34 illustrates the format of a round trip delay measurement packet.

[0062] FIG. 35 illustrates the timing of events during the round trip delay measurement packet.

[0063] FIG. 36 illustrates an example implementation of the CRC generator and checker used in the present invention.

[0064] FIG. 37a illustrates the CRC signal timing of the device of FIG. 36 when sending a data packet.

[0065] FIG. 37b illustrates the CRC signal timing of the device of FIG. 36 when a data packet is received.

[0066] FIG. 38 illustrates the processing steps of a typical service request without content.

[0067] FIG. 39 illustrates the processing steps of a typical service request with link start content after the start of the link restart sequence.

[0068] FIG. 40 illustrates how to use DATA-STB encoding to transmit a data sequence.

[0069] FIG. 41 illustrates the circuitry used to generate DATA and STB signals from input data at the host, and then restore the data at the client.

[0070] FIG. 42 illustrates drivers and terminating resistors used to implement embodiments of the present invention.

[0071] FIG. 43 is used by the client to ensure the security of services from the host and the steps and signal levels used by the host to provide such services.

[0072] FIG. 44 illustrates Data. , The relative interval of transition between other data lines (DataX) and strobe lines (Stb).

[0073] FIG. 45 illustrates the response delay that may occur when the host disables the host driver after transmitting the packet.

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

[0075] FIG. 47 illustrates the timing of the data being transmitted at the input of the host receiver and the relationship between the leading edge and the trailing edge of the strobe pulse.

[0076] FIG. 48 illustrates the switching characteristics formed by reverse data timing and the corresponding client output delay.

[0077] FIG. 49 illustrates a high-level diagram of the signal processing steps, which can be used to synchronize the present invention with a state machine. [0078] FIG. 50 illustrates the general amount of delay encountered by signal processing on the forward and reverse paths in a system using MDDI. [0079] FIG. 51 illustrates the marginal round trip delay measurement.

[0080] FIG. 52 illustrates reverse link data rate changes.

[0081] FIG. 53 illustrates a graphical representation of the value of the reverse rate divisor with respect to the forward link data rate.

[0082] Figures 54a and 54b illustrate the steps to proceed in the interface operation.

[0083] FIG. 55 illustrates an overview of drivers, receivers, processors, and state machines used to implement embodiments of the present invention.

[0084] FIG. 56 illustrates the format of a forward link packet.

[0085] FIG. 57 illustrates the general values of propagation delay and skew in Type-I link interfaces.

[0086] FIG. 58 illustrates data, Stb, and clock recovery timing on a Type-I link of exemplary signal processing through an interface.

[0087] FIG. 59 illustrates the general values of propagation delay and skew in Type-II, Type-III, or Type-IV link interfaces.

[0088] FIGS. 60a, 60b, and 60c illustrate the different possibilities of the timing of the two data signals and MDDI_Stb relative to each other, which are ideal, early and late respectively.

[0089] FIG. 61 illustrates an exemplary connection of the interface pin assignment used by the Type-1/Similar-II interface.

[0090] FIGS. 62a and 62b illustrate possible MDDI_Data and MDDI_Stb waveforms for Type-1 and Type-11 interfaces, respectively.

Detailed ways

[0091] I. Overview

[0092] The general purpose of the present invention is to provide a mobile display digital interface (MDDI) as described below, which leads to or provides a cost-effective, low-power transmission mechanism that allows a short distance between the host device and the display device High-speed or very high-speed data transmission on a communication link. The communication link uses a "serial" type data link or channel. This mechanism can be implemented with micro-connectors and thin flexible cables. They are especially useful when connecting display elements or devices such as wearable micro-displays (eyepieces or projectors) to portable computers, wireless communication devices, or entertainment devices. effective.

[0093] The present invention can be used in a variety of occasions to transfer or transmit large amounts of data, generally audio, video or multimedia applications, from a host or source device that generates or stores such data to a client display or display device at a high rate. . The following typical application is to transfer data either from a portable computer or from a wireless phone or modem to a visual display, such as a small video screen or a wearable microdisplay device, for example in the form of an eyepiece or a helmet containing a small projection lens and a screen.

[0094] The characteristics or attributes of MDDI are that they are independent of specialized display technologies. This is a highly flexible mechanism for transferring data at a high rate, regardless of the internal structure of the data and the functional aspects of the data or instructions it implements. This allows the timing of the data packets to be adjusted to suit the characteristics required by a specific display device or the unique display of a certain device, or to meet the combined audio and video requirements of certain A-V systems. The interface is a fully displayed component or unknowable client device, as long as it follows the selected protocol. In addition, the total serial link data or data rate can be varied by several orders of magnitude, allowing the communication system or host device designer to optimize cost, power requirements, client device complexity, and display device update rate.

[0095] The given data interface is mainly used to transmit large amounts of high-speed data on "wired" signal links or small cables. Of course

However, some applications can also utilize wireless links, including optical-based links, as long as it is configured to use the same packet and data interfaces as the packet and data interfaces developed for the interface protocol, and is maintained at a sufficiently low level for practical use. The expected level of power consumption transfer.

[0096] II. Environment

[0097] A typical application can be seen in FIGS. 1a and 1b, where the portable or laptop computer 100 and the wireless phone or PDA device 102 shown are transmitted together with the display devices 104 and 106 and the audio reproduction system 108 and 110, respectively. data. The wireless device may be currently receiving data or have previously stored a certain amount of multimedia type data in a storage element or device for later presentation for viewing and/or listening by the end user of the wireless device. Since a typical wireless device is used for voice and simple text communication most of the time, it has a small display screen and a simple audio system (speaker) for transmitting information to the user of the device 102.

[0098] The computer 100 has a large screen and an external sound system that is still insufficient, and is still inferior to other multimedia display devices such as high-definition televisions or movie screens. The computer 100 is used for illustration purposes, but the present invention may also use other types of processors, interactive video games, or consumer electronic devices. The computer 100 may use, but is not limited to, a wireless modem or other built-in device for wireless communication, or may be connected to such a device by a cable or a wireless link as required.

[0099] This makes the visualization of more complex or "rich" data not a valid or pleasant experience. Therefore, other mechanisms and devices have been developed in the industry to present information to end users and provide the lowest level of desired enjoyment or affirmative experience.

[0100] As described above, several types of display devices have been developed or are currently being developed to present information to end users of the device 100. For example, one or more companies have developed wearable eyepiece sets that project images in front of the device user's eyes for visual display. When properly placed, this device effectively "projects" a virtual image, as seen by the user's eyes, which is much larger than the element that provides visual output. In other words, the very small projection element allows the user's eyes to "see" a larger proportion of the image, possibly with a typical LCD screen and so on. Other display devices may include, but are not limited to, small LCD screens or various flat-panel display elements, projection mirrors, and display drivers for projecting images on surfaces, and so on.

[0101] There may also be additional elements connected to or related to the use of the wireless device 102 or computer 100 for presenting output to another user, or connected to another device that, in turn, transmits signals elsewhere or stores them. For example, data can be stored in flash memory in optical form for later use, for example using writable CD media or on magnetic media as in tape recorders or similar devices.

[0102] In addition, many wireless devices and computers now have built-in MP3 music decoding capabilities and other advanced sound decoders and systems. Portable computers use CD and DVD playback performance as a general rule, and some have small dedicated flash readers for receiving pre-recorded audio files. The problem with this performance is that digital music files promise a highly increased feature rich experience, but only when the decoding and playback processes can go hand in hand. The same is true for digital audio files.

[0103] In order to assist sound reproduction, an external speaker 108 is shown in FIG. 1a, which may also be accompanied by additional elements, such as a subwoofer or a surround sound speaker for forward and backward sound projection. At the same time, the speaker or earphone 110 is represented as a built-in type to support the frame or mechanism of the micro display device of FIG. 1b. It can be seen that other audio or sound reproduction components can be used, including power amplification or sound shaping devices.

[0104] As mentioned above, in any case, when people expect to transmit high-quality or high-resolution image data and high-quality audio information or data signals from the data source to the end user on one or more communication links 112 When it needs to be high

CN 101197652 Β

Data rate. That is to say, since the current transmission mechanism does not reach the generally expected high data rate, the transmission link 112 is undoubtedly a potential bottleneck for the aforementioned data communication and limits system performance. For example, as described above, for a higher image resolution such as 1024 by 1024 pixels, and a color depth of 24-32 bits per pixel and a data rate of 30 fps, the data rate may approach a rate exceeding 336 Mbps or more. In addition, such images can be displayed as part of a multimedia presentation, which includes audio data and potentially additional signals for processing interactive games or communications, or various commands, controls, or signals, further increasing the quality or data and data rate .

[0105] It can also be seen that fewer cables or interconnections required to establish a data link mean that mobile devices related to the display are easier to use and are more likely to be adopted by a larger user base. This is especially true when multiple devices are commonly used to build a full audio-visual experience, and it is more true when the quality level of displays and audio output devices increases.

[0106] Unfortunately, higher data rates exceed the technologies currently available for transferring data. There is a need for a technology for transmitting data at a higher rate on the data transmission link or communication path between the display element and the data source, which allows continuous low (lower) power, light weight, and minimal Possible simple and economical cable structure. The applicant has developed a new technology, or method, and device to achieve these and other goals to allow arrays of mobile stations, portable or even fixed location devices to transmit data to the desired display, at very high data rates. Microdisplay or audio transmission element, while maintaining the desired low power consumption and complexity.

[0107] III. High-speed digital data interface system structure

[0108] In order to create and effectively utilize a new device interface, a signal protocol and system structure is designed to provide a very high data transfer rate with a low-power signal. The protocol is based on packet and common frame structure, or connected together to form the structure of the protocol, used to transmit a set of pre-selected data or data types and instructions or operation structures imposed on the interface.

[0109] A. Overview

[0110] Devices connected by or communicating on the MDDI link are called a host and a client, and the client is generally some type of display device. As allowed by the host, the data from the host to the display propagates in the forward direction (called forward traffic or link), and the data from the display to the host travels in the reverse direction (called reverse traffic or link) spread. This is illustrated in the basic configuration shown in Figure 2. In FIG. 2, the host 202 is connected to the client 204 by a two-way communication channel 206, and the two-way communication channel includes a forward link 208 and a reverse link 210. However, these channels are formed by a set of common wires, and the data transmission of the wires is effectively switched between forward and reverse link operations.

[0111] As discussed elsewhere, the host includes one of several types of devices that can benefit from the use of the present invention. For example, the host 202 may be a portable computer in the form of a handheld, laptop, or similar mobile computing device, and it may be a PDA, a paging device, or one of many wireless telephones or modems. At the same time, the client 204 may include a variety of useful devices for presenting information to end users. For example, micro-displays integrated in eyepieces or glasses, projection devices built in hats or helmets, small screens or uniform holographic elements embedded in vehicles, such as windows or windshields, or various speakers, headphones or used to display high Sound system for quality sound or music. However, those skilled in the art can easily know that the present invention is not limited to these devices. There may be other devices on the market that have been proposed for use. They either use storage and transmission or display during playback to try to provide end users with High-quality images and sounds. The present invention is useful in increasing the data throughput between various devices to provide the high data rate required to achieve the desired user experience.

[0112] B. Interface type

[0113] The MDD interface is considered to target five or more slightly different physical interface types found in the communications and computer industries. These are simply labeled here as Type T, Type TI, Type TII, Type-IV and Type-Uo

[0114] The Type-1 interface is configured as a 6-wire (wire) interface, suitable for mobile or wireless phones, PDAs, e-books, electronic games, and portable media players, such as CD players or MP3 players, and similar types Electronic consumer technology. The Type-U interface is configured as an 8-wire (wire) interface, suitable for laptops, notebooks, or desktop personal computers and similar devices or applications. They do not require rapid display refresh and no built-in MDDI link control Device. This type of interface is also distinguishable by using an additional two-wire universal serial bus (USB) interface. The USB interface is particularly useful in providing support for existing operating systems or software in most personal computers. For example, the Type-U interface can also be used in a USB-only mode, where the display only has a USB connector, which is connected to a standard USB port on a computer or similar device.

[0115] Type-II, Type-III, and Type-IV interfaces are suitable for high-performance displays or devices, and use larger and more complex cables with additional twisted-pair type conductors to provide proper shielding and low-voltage protection for data signals. Loss of transmission.

[0116] The signals transmitted by the Type-I interface may include display, video, control, and wired signaling information, and are generally used for devices that do not require high-resolution full-rate video data. This type of interface is mainly used for devices such as mobile wireless devices, where the USB host is generally invalid in the device for signal connection and transmission. In this configuration, the mobile device is the MDDI host device and acts as the "master" controlling the communication link from the host. It generally sends display data to the client (forward traffic or link).

[0117] In this interface, the host allows receiving communication data from the client (reverse traffic or link) at the host by sending a special command or packet type to the client, and the client allows it to continue in a specific Time takes over the bus and sends the data as reverse packets to the host. This is illustrated in Figure 3, where a packet type called encapsulated packet (discussed below) is used to provide the transmission of reverse packets on the transmission link, thereby creating a reverse link. The time interval allocated to the host for the display of polling data is predetermined by the host and based on the requirements of each specialized application. This type of half-duplex two-way data transmission is particularly advantageous when the USB port is not available for information or data transmission from the client.

[0118] The Type U interface transmits signals suitable for laptop and desktop applications. The USB interface is widely supported by a large number of motherboards or other hardware, and is supported by operating system software. The use of the added USB interface can use the "plug and play" feature and easy application configuration. The inclusion of USB also allows the universal two-way flow of commands, status, audio data, etc., while audio and video data directed to the client device can be transmitted at low power and high speed using a twisted pair cable. As described below, power can be transmitted with other wires. The embodiment of the present invention using the USB interface allows high-speed transmission on a set of wires while mainly realizing signaling and control on the USB connection, which can be turned off when not in use and consumes very little power.

[0119] The USB interface is a very widely used standard for modern personal computer equipment, and the details of the USB interface and its operation are well known in the art, so it will not be described here. For the USB interface, the communication between the host and the display complies with the Universal Serial Bus specification, revision 2.0. In applications using the Type U interface, where USB is the main signaling channel and possibly the voice return channel, optionally the host can poll the client via the MDDI serial data signal.

[0120] In order to support full motion video, a high-performance display of HDTV type or similar high-resolution performance requires a data stream at a rate of about 1.5 Gbs. The Type TI interface supports high data rates by sending 2 bits in parallel, the Type-111 interface supports 4 bits in parallel, and the Type-IV interface transmits 8 bits in parallel. The protocol used by MDDI allows each type-1, II, III, or IV host to communicate with any type-1, II, III, or IV client by negotiating the highest data rate that can be used. The performance or available characteristics that can be referred to as the least possible device are used to set the performance of the link. As a rule, even for systems where both the host and the client can use Type-II, Type-III, or Type-IV interfaces, both begin to work as Type T interfaces. Then, the host determines the performance of the target client or display, and negotiates the switching or reconfiguration operation to either type TI, type TII, or type TV mode, which is for specific applications

appropriate.

[0121] The host may generally use the appropriate link layer protocol (discussed further below) and at any time reduce or reconfigure the operation to a slower mode to save power, or increase to a faster mode to support higher Speed of transmission, such as for higher resolution display content. For example, when the display system is switched from a power source such as a battery to an AC power source, or when the source of the display media is switched to a lower or higher resolution format, or a combination of these or other conditions or events can be regarded as a change When the display or data transmission mode is based, the host can change the display mode.

[0122] The system can also transmit data in one mode in one direction and another mode in the other direction. For example, the Type-IV interface mode can be used to transfer data to the display at a high rate, and when transferring data from a peripheral device such as a keyboard or pointing device to the host device, the Type-I or Type U mode is used.

[0123] C. Physical interface structure

[0124] FIGS. 4 and 5 show the general configuration of a device or link controller for establishing communication between a host and a client device. In FIGS. 4 and 5, the MDDI link controller 402 is installed in the host device 202, and the MDDI link controller 404 is installed in the client device 204. As before, the host 202 is connected to the client 204 using a two-way communication channel 406 including a series of wires. As described below, both the host and client link controllers can be manufactured as integrated circuits using a single circuit design that can be set, adjusted, or programmed to respond to either the host controller (driver) or the client controller ( Receiver). This provides lower costs caused by the larger-scale manufacturing of a single circuit device.

[0125] In FIG. 4, a USB host device 401 and a USB client device 410 are also shown, which are used to implement the Type U interface version of MDDI. Circuits and devices for realizing device functions are well known in the art and will not be described here.

[0126] In FIG. 5, the MDDI link controller 502 is installed in the host device 202, and the MDDI link controller 504 is installed in the client device 204. As before, the host 202, is connected to the client 204, using a two-way communication channel 406 including a series of wires. As mentioned earlier, both the host and client link controllers can be manufactured with a single circuit design.

[012] Figures 4 and 5 also illustrate the signal transmitted on the MDDI link between the host and the client such as a display device, or the physical wires used. It can be seen from Figures 4 and 5 that the main channel or base station used to transmit data through MDDI uses data signals marked MDDI_DateO+/- and MDDI_Stb+/-. Each of these signals is a low-voltage data signal, which is transmitted on a pair of differential wires in the cable. For each bit sent on the interface, either on the MDDI_Data0 pair or on the MDDI_Stb pair, there is only one transition. This enables a voltage-based rather than current-based transmission mechanism, so quiescent current consumption is close to zero. The host drives the MDDI_Stb signal to the client display.

[0128] Although data can flow in the forward and reverse directions on the MDDI_Data pair, that is, it is a two-way transmission channel, the host is the master or controller of the data link. In order to maximize noise immunity, MDDI_DataO and MDDI_Stb signal channels work in differential mode. The data rate of the signals on these lines is determined by the clock rate sent by the host, and is variable in the range of about lkbps to 400Mbps or more.

[0129] The Type-II interface contains one additional data pair or wire or channel on the data pair of Type-I, and it is called MDDI_Data1+/-o. The type TII interface contains two additional data on the data pair of the Type TI interface. The data pairs or signal channels are called MDDI_Data2+/- and MDDI_Data3+/-. The Type-IV interface contains four or more additional data pairs or signal channels above the data pair of the Type TII interface, which are called MDDI_Data4+/-, MDDI_Data5+/-, MDDI_Data6+/- and MDDI_Data7+/-, respectively. In each of the above-mentioned interface configurations, the host uses wire pairs or signals named MDDI_Pwr and MDDI_Gnd to send power to the client or display.

[0130] One type of transmission generally only available for Type U configuration is the MDDI USB connection or signal channel. MDDI USB connection

CN 101197652 Β

The UI/57 interface includes secondary channels for communication between the host and client displays. In some applications, it may be more advantageous to send specific information between the host and the client at a relatively low data rate. Using a USB transmission link enables devices without an MDDI link controller with a USB host or limited host performance to communicate with an MDDI-compatible client or display equipped with a Type-U interface. Examples of information that can be effectively transmitted to the display on the USB interface are: static bitmaps, digital audio streams, pointing device data, keyboard data, and control and status information. All functions supported through the USB interface can also be implemented with the main MDDI high-speed serial data channel. Although the data defined above (see the packet below) can be sent on a USB type interface, the requirement to link data in a back-to-back format does not apply to this USB interface, and the use of packets that support MDDI type switching does not apply to this type of interface. USB interface.

[0131] Below, Table 1 describes an overview of the signals transmitted between the host and the client (display) on the MDDI link according to the interface type.

[0132] Table 1

[0133]

<td>Type-1</td><td>Type TI</td><td>Type-I</td><td>Type-I</td>

<td>MDDI_Pwr/Gnd</td><td>MDDI_Pwr/Gnd</td><td>MDDI_Pwr/Gnd</td><td>MDDI_Pwr/Gnd</td>

<td>MDDI_Stb+/-</td><td>MDDI_Stb+/-</td><td>MDDI_Stb+/-</td><td>MDDI_Stb+/-</td>

<td>MDDI_DataO+/-</td><td>MDDI_DataO+/-</td><td>MDDI_DataO+/-</td><td>MDDI_DataO+/-</td>

<td></td><td>MDDI_Datal+/-</td><td>MDDI_Datal+/-</td><td>MDDI_Datal+/-</td>

<td></td><td></td><td>MDDI Data2+/^_</td><td>MDDI Data2+/^_</td>

<td>Type-I</td><td></td><td>MDDI_Data3+/-</td><td>MDDI_Data3+/-</td>

<td>MDDI_Pwr/Gnd</td><td></td><td></td><td>MDDI_Data4+/-</td>

<td>MDDI_Stb+/-</td><td></td><td></td><td>MDDI_Data5+/-</td>

<td>MDDI_DataO+/-</td><td></td><td></td><td>MDDI_Data6+/-</td>

<td>MDDI_USB+/-</td><td></td><td></td><td>MDDI_Data7+/-</td>

[0134] The cables used to achieve the above structure and operation are generally rated on the order of 1.5 meters in length and contain three twisted pairs, each of which is a multi-strand 30AWG wire. The foil shield is covered or formed into the above three twisted pairs as an additional drain wire. The twisted pair and the shielded drain wire terminate in the display connector, where the shield is connected to the shield of the display (client), and there is an insulating layer covering all the cables, which is well known in the art. The wires are paired as follows: MDDI_Gnd and MDDI_Pwr; MDDI_Stb+ and MDDI_Stb-; MDDI_DataO+ and MDDI_DataO-; MDDI_Datal+ and MDDI_Datal-; and so on. The rated cable diameter is on the order of 3.0 mm, and the rated impedance is 85 ohms ± 10%, and the DC resistance is rated at 110 ohms per 1000 feet. The signal propagation speed should be rated at 0.66c, and the maximum delay through the cable is less than about &amp; 0 nanoseconds.

[0135] D. Data Type and Rate

[0136] In order to achieve a full range of user experience and useful interfaces for applications, the Mobile Digital Data Interface (MDDI) supports various displays and display information, audio sensors, keyboards, pointing devices, and many other input devices, which can be integrated in In the mobile display device or in cooperation with the mobile device, control information, and their combination. The MDD interface is designed to be able to provide multiple potential types of data flow back and forth between the host and the client with a minimum number of cables or wires or in the forward or reverse link direction. Both synchronous streaming and asynchronous streaming (refresh) can be supported. As long as the total data rate is less than or equal to the maximum expected MDDI link rate, many combinations of data types are possible. These may include, but are not limited to the items listed in Table II and Table III below.

[0137] Table II

[0138]

<td colspan="3">Transfer from host to client</td>

<td>Synchronize video data</td><td>720x480, 12 bit, 30f/s</td><td>~124.5 Mbps</td>

<td>Synchronize stereo audio data</td><td>44. 1 kHz, 16 bit, stereo</td><td>~1. 4 Mbps</td>

<td>Asynchronous graphics data</td><td>800x600, 12 bit, 10f/s, stereo</td><td>~115. 2 Mbps</td>

<td>Asynchronous control</td><td>Minimum</td><td>&lt;&lt; 1. 0 Mbps</td>

[0139] Table III

[0140]

<td colspan="3">Transfer from client to host</td>

<td>Synchronized voice data</td><td>8 kHz, 8 bits</td><td>&lt;&lt; 1. 0 Mbps</td>

<td>Sync video</td><td>640x480, 12 bit, 20f/s</td><td>~88. 5 Mbps</td>

<td>Asynchronous state, user input, etc.</td><td>Minimum</td><td>&lt;&lt; 1. 0 Mbps</td>

[0141] The interface is not fixed but extensible, so that it can support the transmission of multiple information "types" including user-defined data for future system flexibility. Specific examples of the data to be supported are: full motion video, or in the form of full or partial screen bitmap fields, or in the form of compressed video; static bitmaps at low rates to save power and reduce implementation costs; each PCM or compressed video data at various resolutions or rates; indicating device location and selection; and user-defined data for the performance to be defined. This data can also be transmitted along with control or status information for testing device performance or setting operating parameters.

[0142] The present invention leads in the field of data transmission, including but not limited to: watching movies (video display and audio); using a personal computer with limited personal observation (graphic display, sometimes combined with video and audio); or "Surfing" on the Internet; using video phones (two-way low-rate video and audio), cameras for still digital photos, or cameras for capturing digital video images; and for productivity improvement or using cellular phones, smart phones, or PDA entertainment.

[0143] The following mobile data interface is provided by providing a large amount of AV type data on a communication or transmission link that is generally configured as a wired or cable type link. However, it is obvious that if the desired level of transmission can be maintained, the signal structure, protocol, timing, or transmission mechanism can be adjusted to provide a link in the form of optical or wireless media.

[0144] The MDD interface signal is a basic signal protocol or structure using a concept called Common Frame (CF). The idea behind using the common frame is to provide synchronization pulses for simultaneous synchronization data streams. The display device can use the common frame as a time interface.

The low CF rate increases the channel efficiency by reducing the overhead of transmitting the subframe header. Conversely, a high CF rate reduces latency and allows less flexible data buffering of audio samples. The CF rate of the inventive interface is dynamically programmable and can be set to one of many values suitable for the synchronous stream used in a specific application. That is, the CF value is selected as desired to best fit a given display device and host configuration.

[0145] The number of bytes generally required for each common frame of the synchronous data stream is adjustable and programmable, and they are likely to be used in applications, such as the head-mounted microdisplay shown in Table IV.

[0146] Table IV

[0147]

<td colspan="8">Common frame rate (CFR) = 1200 Hz</td>

<td></td><td>X</td><td>Y</td><td>Bit</td><td>Frame rate</td><td>channel</td><td>Rate (Mbps)</td><td>Byte/CFR</td>

<td>DVD movie</td><td>720</td><td>480</td><td>12</td><td>30</td><td>1</td><td>124.4</td><td>12960</td>

<td>Three-dimensional graphics</td><td>800</td><td>600</td><td>12</td><td>10</td><td>2</td><td>115.2</td><td>12000</td>

<td>Video camera</td><td>640</td><td>480</td><td>12</td><td>24</td><td>1</td><td>8&amp; 5</td><td>9216</td>

<td>CD audio</td><td>1</td><td>1</td><td>16</td><td>44100</td><td>2</td><td>1.4</td><td>147</td>

<td>Voice</td><td>1</td><td>1</td><td>8</td><td>8000</td><td>1</td><td>0. 1</td><td>6. 7</td>

[0148] With a simple programmable M/N counter structure, a partial count of bytes per common frame can be easily obtained. For example, by transmitting 2 frames of 27 bytes, each followed by a frame of 26 bytes, a count of 26-2/3 per CF is realized. You can choose a smaller CF rate to produce an integer number of bytes per CF. However, generally speaking, a simple M/N counter implemented by hardware requires a smaller area in the integrated circuit chip used to implement part or all of the present invention than a larger audio sampling FIFO buffer.

[0149] An exemplary application illustrating the influence of different data transmission rates and data types is the Karaoke system. For the Kara OK system, system users sing along with music and video programs. The lyrics are displayed at the bottom of the screen, so the user knows the lyrics to sing and the approximate time of the song. This kind of application requires a video display with infrequent graphics refresh, and mixes the user's voice with a stereo audio stream.

[0150] If it is assumed that the rate of the common frame is 300 Hz, then each CF will include: 92160 bytes of video content and 588 bytes of audio content on the forward link to the display device (in stereo, based on 147 16-bit Sampling), an average of 29.67 (26-2/3) bytes of voice are sent back from the microphone to the mobile karaoke machine. Asynchronous packets are sent between the host and the display. This includes graphics data of up to 768 bytes (a quarter of the screen height), and is less than about 200 bytes (several) of other various control and status commands.

[0151] Table V shows how data is distributed in the common frame of the KaraOK instance. The total rate used was chosen to be approximately 225 Mbps. The slightly higher rate of 226 Mbps allows for transmission of approximately another 400 bytes per subframe, which allows the use of occasional control and status messages.

[0152]

<td>Element rate</td><td>Byte/CF</td>

<td>640X480 pixels and 30fps music video</td><td>92160</td>

CN 101197652 Β

<td>Lyric text in 640X120 pixels and lfps</td><td>768</td>

<td>44100sps, stereo, 16-bit CD audio</td><td>588</td>

<td>8000sps, mono, 8-bit voice</td><td>26. 67</td>

<td>Subframe header</td><td>19</td>

<td>Reverse link overhead</td><td>26. 67+2*9+20</td>

<td>Total bytes/CF</td><td>93626. 33</td>

<td>Total rate (Mbps)</td><td>224.7032</td>

[0153] Ε. Link layer

[0154] The data transmitted by the MDD interface high-speed serial data signal includes one-to-one connected time-division multiplexed packet streams. Even when the transmitting device has no data to be sent, the MDDI link controller automatically sends filler packets, thereby maintaining the packet flow. The use of a simple packet structure ensures reliable synchronization timing of video and audio signals or data streams.

[0155] A group grouping is contained in a signal element or structure called a subframe, and a group of subframes is contained in a signal element or structure called a media frame. A subframe contains one or more packets, depending on their corresponding size and data transmission purpose. The media frame must contain one more subframe. The maximum subframe provided by the protocol used in the present invention is on the order of 232-1, that is, 4,294,967, 295 bytes, so the maximum media frame size becomes on the order of 216-1, that is, 65,535 bytes.

[0156] As described below, a special header packet containing a unique identifier appears at the beginning of each subframe. This identifier is also used to capture frame timing at the client device when the communication between the host and the display is initiated. Link timing capture is detailed below.

[0157] Generally speaking, when a full-motion video is displayed, the display screen is updated once every media frame. The display frame rate is the same as the media frame rate. The link protocol supports full-motion video on the entire display, or only a small area of full-motion video content surrounded by static images, depending on the desired application. In some low-power mobile applications, such as viewing Web pages or emails, the display screen only needs to be updated occasionally. In those cases, it is advantageous to transmit a single subframe and then close the link to minimize power consumption. The interface also supports effects such as stereoscopic display, and handles graphics primitives.

[0158] The existence of subframes enables high-priority packets to be periodically transmitted. This allows simultaneous simultaneous streams to coexist with a minimum number of data buffers. This is an advantage that the present invention provides to the display process, allowing multiple data streams (high-speed communication of video, voice, control, status, indicating devices, etc.) to essentially share a common channel. It uses relatively few signals to transmit information. It also enables the existence of display technology proprietary actions, such as the vertical sync pulse and blanking period of CRT monitors.

[0159] F. Link Controller

[0160] The MDDI link controller shown in FIGS. 4 and 5 is manufactured or simulated as a fully digital implementation, except for a differential line receiver for receiving MDDI data and strobe signals. The hardware that implements the link controller does not require any analog operations or phase-locked loops (PLL). The host and display link controller contain very similar functions, except that the display interface contains a state machine for link synchronization. Therefore, the present invention allows practical advantages to be able to create a single controller design or circuit configured as a host or a client, which in general can reduce the manufacturing cost of the link controller.

[0161] IV. Interface Link Protocol

[0162] A. Frame Structure

[0163] FIG. 6 illustrates a signal protocol or frame structure that implements forward link communication for packet transmission. As shown in Figure 6, information or digital data is combined into elements called groups. Multiple groups are sequentially combined to form a "subframe", and multiple subframes are sequentially combined to form a "media" frame. In order to control the frame format and the transmission of subframes, each subframe starts with a special predefined packet, which is called the subframe header packet (SHP).

[0164] The host device selects the data rate to be used for a given transmission. The rate can be dynamically changed by the host device according to the maximum transmission performance of the host or the data picked up by the host from the source, and the maximum capacity of the display or other device to which the data is sent.

[0165] The trusted client device is designed to work with WDDI, or the invented signal protocol can be queried by the host to determine the maximum or current maximum data transmission rate it can use, or the default Lower minimum rate, and supported available data types and characteristics. As described further below, this information can be transmitted using Display Performance Packets (DCP). The client display device can use the interface to transmit data or communicate with other devices at a pre-selected minimum data rate or within the minimum data rate range, and the host will use the data rate within this range to make an inquiry to determine the full performance of the client device.

[0166] Other status information that defines the bitmap properties of the display and the video frame rate performance can be transmitted to the host in the status packet, so that the host can configure the interface to be efficient or best in practice, or in any case. Expected within system limits.

[0167] When there is no data packet to be transmitted in the current subframe, or when the host cannot transmit at a sufficient rate that is synchronized with the data transmission rate selected for the forward link, the host sends a filler packet. Since each subframe starts with a subframe header packet, the end of the previous subframe contains a packet that just fills the previous subframe (most likely a filler packet). In the absence of data space for each set of packets, padding The symbol packet is most likely the last packet in the subframe, or at the end of the next previous subframe and before the subframe header packet. The task of controlling the operation in the host device is to ensure that there is enough remaining space in the subframe for sending each packet in the subframe. At the same time, once the host device starts sending the data packet, the host must be able to successfully complete the packet of this size in the frame without incurring a data under-run state.

[0168] In one aspect of the embodiment of the present invention, subframe transmission has two modes. One mode is a periodic sub-frame mode for transmitting live video and audio streams. In this mode, the subframe length is defined as non-zero. The second mode is an asynchronous or non-periodic mode, where frames are used to provide bitmap data to the display device only when new information is available. This mode is defined by setting the subframe length to zero in the subframe header packet. When using the periodic mode, subframe packet reception can start when the display has been synchronized with the forward link frame structure. This corresponds to the "synchronizing" state defined in the state diagram discussed below with reference to FIG. 49. In the asynchronous aperiodic subframe mode, reception starts after receiving the first subframe header packet.

[0169] Β. Total packet structure

[0170] The packet format or structure used to formulate the signaling protocol implemented by the present invention is given below, keeping in mind that the interface is extensible and additional packet structures can be added as needed. Packets are marked or divided into different "packet types" according to their functions in the interface, that is, according to the instructions or data they transmit. Therefore, each packet type represents a predefined packet structure used to manipulate a given packet of transmitted packets and data. It can be clearly seen that the packets may have a pre-selected length or may have a variable or dynamically variable length according to their corresponding function. The bytes or byte values used in various groups are configured as multi-bit (8 or 16-bit) unsigned integers. Table VI lists the used grouping summary and its "type" representation in order of type. The direction in which the packet transmission is considered valid is also noted, and

Are they used for Type-U interfaces.

[0171] Table VI

[0172]

<td>Group Name</td><td>Group type</td><td>Effective in direction</td>

[0173]

<td></td><td></td><td>forward</td><td>Reverse</td><td>Type u</td>

<td>Subframe header packet</td><td>255</td><td>X</td><td></td><td>X</td>

<td>Filler grouping</td><td>0</td><td>X</td><td>X</td><td></td>

<td>Video stream grouping</td><td>1</td><td>X</td><td>X</td><td>X</td>

<td>Audio stream grouping</td><td>2</td><td>X</td><td>X</td><td>X</td>

<td>Reserved rice group</td><td>3-55</td><td></td><td></td><td></td>

<td>User-defined flow grouping</td><td>56-63</td><td>X</td><td>X</td><td>X</td>

<td>Color map</td><td>64</td><td>X</td><td>X</td><td>X</td>

<td>Reverse link encapsulation packet</td><td>65</td><td>X</td><td></td><td></td>

<td>Show performance grouping</td><td>66</td><td></td><td>X</td><td>X</td>

<td>Keyboard data grouping</td><td>67</td><td>X</td><td>X</td><td>X</td>

<td>Indicating load data grouping</td><td>68</td><td>X</td><td>X</td><td>X</td>

<td>Link down packet</td><td>69</td><td>X</td><td></td><td></td>

<td>Show request and status grouping</td><td>70</td><td></td><td>X</td><td>X</td>

<td>Bit block transmission packet</td><td>71</td><td>X</td><td></td><td>X</td>

<td>Bitmap area filling group</td><td>72</td><td>X</td><td></td><td>X</td>

<td>Bitmap mode i fill grouping</td><td>73</td><td>X</td><td></td><td>X</td>

<td>Communication Lianlu Data Channel Grouping</td><td>74</td><td>X</td><td>X</td><td>X</td>

<td>Interface type switching request packet</td><td>75</td><td>X</td><td></td><td></td>

<td>Interface type confirmation packet</td><td>76</td><td></td><td>X</td><td></td>

<td>Execution type switch grouping</td><td>77</td><td>X</td><td></td><td></td>

<td>Forward audio channel enable group</td><td>78</td><td>X</td><td></td><td>X</td>

<td>Reverse audio sampling rate grouping</td><td>79</td><td>X</td><td></td><td>X</td>

<td>Digital content protection overhead grouping</td><td>80</td><td>X</td><td>X</td><td>X</td>

<td>Transparent payment enable group</td><td>81</td><td>X</td><td></td><td>X</td>

<td>Round trip elbow measurement group</td><td>82</td><td>X</td><td></td><td></td>

[0174] A packet has a common basic structure or a total set of minimum fields, including a packet length field, a packet type field, a data byte field, and a CRC field, which are illustrated in FIG. 7. As shown in Figure 7, the packet length field contains information in the form of a multi-bit or multi-byte value, specifying the total number of bits in the packet, or its length between the packet length field and the CRC field. In a preferred embodiment of the example of the present invention, the packet length field contains a 16-bit or 2-byte wide, unsigned integer, which specifies the packet length. The packet type field is another multi-bit field that indicates the type of information contained in the packet.

In the exemplary embodiment of the example of the present invention, this is an 8-bit or 1-byte wide value in the form of an 8-bit unsigned integer, and specifies data such as display performance, switching, video or audio streaming, status, etc. Types of.

[0175] The third field is a data byte, which contains bits or data that are transmitted or sent between the host and the client device as part of the packet. The data format is specifically defined for each packet type according to the specific type of data to be transmitted, and can be divided into a series of additional fields, each with its own format requirements. In other words, each grouping type has a defined format for the part or field. The last field is the CRC field, which contains the 16-bit cyclic redundancy code result calculated on the data byte, packet type, and packet length fields to confirm the integrity of the information in the packet. In other words, it is calculated on all packets except the CRC field itself. The client generally keeps the total number of CRC errors detected and reports this number back to the host in the display request and status packet (see below).

[0176] During packet transmission, the transmitted field starts with the least significant bit (LSB) and ends with the most significant bit (MSB) transmitted last. Parameters longer than one byte are sent with the least significant byte first, resulting in the use of the same bit transmission mode for parameters longer than 8 bits, as used in shorter parameters where the LSB is sent first. The data on the MDDI_DataO signal channel is aligned with the 0th bit of the byte sent on the interface in any mode, the modes are Type-I, Type TI, Type-III or Type-IVo

[0177] When manipulating data for display, the data of the pixel array is first sent in rows and then in columns, which is generally done in the electronic field. In other words, the sending order of all pixels appearing in the same row of the bitmap is: the leftmost pixel is sent first, and the rightmost pixel is sent last. After sending the rightmost pixel of a row, the next pixel in the sequence is the leftmost pixel of the next row. For most displays, the rows of pixels are generally sent in order from top to bottom, but other configurations can also be used as needed. Moreover, when dealing with bitmaps, the conventional method followed here is to define a reference point by marking the upper left corner of the bitmap as a position or offset "0,0". When a person approaches the right and bottom of the bitmap, respectively, the X and Y coordinate values used to define or determine the position in the bitmap increase. The first row and the first column start with a subscript value of zero.

[0178] C. Group Definition

[0179] 1. Subframe header grouping

[0180] The subframe header packet is the first packet of each subframe, and has a basic structure as described in FIG. 8. As shown in Figure 8, this type of packet is structured to have packet length, packet type, unique word, subframe length, protocol version, subframe count, and media frame count fields, generally in this order. This type of packet is generally identified as a type 255 (0xff hexadecimal) packet and uses a preselected fixed length of 17 bytes.

[0181] Although the packet type field uses a 1-byte value, the unique word field uses a 3-byte value. The 4-byte combination of these two fields together form a 32-bit unique word with good autocorrelation. The actual unique word is 0x005a3bff, in which the lower 8 bits are sent first as the packet type, and the highest 24 bits are sent later.

[0182] The subframe length field contains 4 bytes of information specifying the number of bytes per subframe. The length of this field can be set to zero, which means that the host will only send one subframe before the link is closed to the idle state. When transitioning from one subframe to the next subframe, the value in this field can be dynamically changed "on the fly". This feature is useful in order to make small timing adjustments in the synchronization pulses used to provide the synchronization data stream. If the CRC of the subframe header packet is invalid, the link controller should estimate the length of the current subframe using the subframe length of the previously known good subframe header packet.

[0183] The protocol version field contains 2 bytes and specifies the protocol version used by the host. The protocol version field is set to "0", specifying the first or current version of the protocol as in use. This value will change over time as new versions are created. The subframe count field contains 2 bytes and specifies the sequence number that indicates the number of subframes that have been sent since the start of the media frame. Media frame

The first subframe has a subframe count of zero. The value of the last subframe of the media frame is nl, where n is the number of subframes per media frame. Note that if the subframe length is set to zero (indicating aperiodic subframes), the subframe count must also be set to zero.

[0184] The Media Frame Count field contains 3 bytes and designates a sequence number, which represents the number of media frames that have been sent since the start of the currently transmitted media item or data. The media frame count of the first media frame of the media item is zero. The media frame count is incremented by one just before the first subframe of each media frame, and returns to zero after using the maximum media frame count (number of media frames 224-1 = 16, 777, 215). The media frame count value can generally be reset by the host at any time to meet the needs of the terminal program.

[0185] 2. Filler grouping

[0186] A filler packet is a packet that is sent to or from the client device when there is no other information that can be sent on the current or reverse link. It is recommended that filler packets have a minimum length in order to allow maximum flexibility when other packets need to be sent. At the end of the subframe or reverse link encapsulation packet (see below), the link controller sets the size of the filler packet in order to fill the remaining space to maintain the integrity of the packet.

[0187] FIG. 9 shows the format and content of a filler packet. As shown in FIG. 9, the structure of this type of packet has a packet length, packet type, filler bytes, and CRC fields. This type of packet is generally identified as type 0, which is represented in a 1-byte type field. The bits or bytes in the filler byte field include a variable number of all-zero bits, allowing filler packets to be of a desired length. The smallest filler packet does not contain any bytes in this field. That is, the packet is only composed of packet length, packet type, and CRC, and uses a pre-selected fixed length of 3 bytes.

[0188] 3. Video Stream Grouping

[0189] The video stream packet carries video data to irregularly update the rectangular area of the display device. The size of this area can be as small as a single pixel or as large as the entire display. There may be an almost unlimited number of streams that can be displayed at the same time, which is limited by system resources. This is because the entire range required to display a stream is contained in the video stream grouping. Fig. 10 shows the format of a video stream packet (video data format descriptor). As shown in Figure 10, the structure of this type of packet has packet length, packet type, video data descriptor, display attributes, X left edge, Y upper edge, X right edge, Y lower edge, X and Y starting points, pixels Count, parameter CRC, pixel data, and CRC fields. This type of packet is generally identified as type 1, which is represented in a 1-byte type field.

[0190] The above-mentioned common frame concept is an effective way to minimize the audio buffer size and reduce the waiting time. However, for video data, it may be necessary to extend the pixels of one video frame among multiple video stream packets in the media frame. It is also very likely that the pixels in a single video stream packet will not exactly correspond 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 rows of pixels in each frame, each video stream grouping in each sub-frame will contain 48 rows of pixels. In other cases, the video stream packet may not contain an integer number of rows of pixels. This is also true for other video frame sizes, where the number of sub-frames per media frame is unevenly divided into the number of lines per video frame (also called video lines). Even though each video stream packet may not contain an integer number of pixels, it must contain an integer number of pixels. This will be important if the pixels are larger than one byte per pixel, or if they are in the packet format shown in Figure 12.

[0191] FIGS. 11a-lld show the format and content used to implement the operation of the above-mentioned video data descriptor field. In Figures 11a-lld, the video data format descriptor field contains 2 bytes in the form of a 16-bit unsigned integer, which specifies the format of each pixel in the pixel data in the current stream in the current packet. Different streams (indicated by the stream ID field) may use different pixel data formats, that is, use different values in the video data format descriptor. Similarly, any stream may change its data format during operation. The video data format descriptor defines the pixel format of the current packet, but this does not mean a specific

CN 101197652 Β

The constant format will continue to be used for the duration of the video stream.

[0192] Figures 11a-lld illustrate how to encode a video data format descriptor. As used in these figures, as shown in Figure 11a, when the bits [15:13] are equal to "000", the video data includes an array of monochrome pixels, where the number of bits per pixel is determined by the bit number of the video data format descriptor word. 3 to 0 defined. As shown in Figure lib, when the bits [15:13] are equal to "001", the video data includes an array of color pixels, where each pixel specifies a color in the color map. 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 set equal to zero. As shown in Figure 11c, when the bits [15:13] are equal to "010", the video data includes an array of color pixels, where the number of bits per pixel for red is defined by bits 11 to 8, and the number of bits per pixel for green is defined by Bits 7 to 4 are defined, and the number of bits per pixel for blue is defined by bits 3 to 0. In this case, the total number of bits per pixel is the sum of the number of bits used for red, green, and blue.

[0193] However, as shown in Figure lid, when the bit [15:13] is equal to "011", the video data includes an array of video data in a format of 4:2:2 with luminance and chrominance information, where The number of bits per pixel of the brightness (Y) is defined by bits 11 to 8, the number of bits of the Cr component is defined by bits 7 to 4, and the number of bits of the Cb component is defined by bits 3 to 0. The total number of bits per pixel is the sum of the number of bits used for red, green, and blue. Cr and Cb are sent at half the rate at which Y is sent. In addition, the video samples in the pixel data part of the group are organized as follows: Y", Cr_n, Cb_n, Y_n+1, Υη+2, Cr_n+2, Cb_n+2, Υ_η+3,...Where Cr_nAnd Cb_nWith Y_nAnd Υ_η+1Related, Cr_n+2And Cb_n+2With Y_n+2And Υ_η+3Related, and so on. If there are an odd number of pixels in a row of the current stream (X right edge-X left edge + D, the Cb value corresponding to the last pixel in each row will be followed by the Y value of the first pixel in the next row.

[0194] For all four formats shown in the figure, bit 12 designated as "P" specifies whether the pixel data sample is grouped or byte-aligned pixel data. The value "0" in this field indicates that each pixel and each color in each pixel in the pixel data field are aligned with the byte boundary bytes of the MDDI interface. The "1" value means that each pixel and each color in each pixel in the pixel data are packed with respect to the previous pixel or color in the pixel without leaving unused bits.

[0195] The first pixel in the first video stream packet of a specific display window will enter the upper left corner of the stream window defined by the X offset and Y offset, and the next received pixel is placed on the next in the same row. Pixel position, and so on. To facilitate this operation, the display keeps the "next pixel row and column" counter associated with each active video stream ID.

[0196] 4. Audio Stream Grouping

[0197] The audio stream packet carries audio data to be played through the audio system of the display or used in an independent audio presentation device. In the audio system, separate audio channels can be assigned different audio data streams, such as: left front, right front, middle, left rear, and right rear, depending on the type of audio system used. It provides a complete complement of audio channels for headsets that include enhanced air-return sound signal processing. Figure 13 illustrates the format of the audio stream packet. As shown in FIG. 13, this type of packet structure has packet length, packet type, audio channel ID, audio sample count, bits per sample and packet, audio sample rate, parameter CRC, digital audio data, and audio data CRC fields. This type of packet is generally marked as a type 2 packet.

[0198] The bit field of each sample and packet contains 1 byte in the form of an 8-bit unsigned integer, which specifies the packet format of audio data. The format generally used is bits 4 to 0 to define the number of bits per PCM audio sample. Bit 5 specifies whether the digital audio data sample is grouped. Figure 14 illustrates the difference between grouped and byte-aligned audio samples. The "0" value indicates that each PCM audio sample in the digital audio digital field is byte-aligned with the MDDI interface byte boundary, and the "1" value indicates that each consecutive PCM audio sample is grouped relative to the previous audio sample. This bit is valid only when the value defined in bits 4 to 0 (the number of bits per PCM audio sample) is not a multiple of eight. Bits 7 to 6 are reserved for future use and one

It is generally set to zero.

[0199] 5. Reserved flow packet

[0200] As expected by various applications encountered, packet types 3 to 55 are reserved for streaming packets to be defined for future forms or variants of the packet protocol. Also, this part makes the MDD interface more flexible and useful in the face of constantly changing technology and system design compared to other technologies.

[0201] 6. User-defined flow grouping

[0202] Eight data stream types called types 56 to 63 are reserved for use in proprietary applications that can be defined by device manufacturers for use with MDDI links. These are called user-defined flow packets. The video stream packet carries video data to update (or not) the rectangular area of the display. The definition of the flow parameters and data of these packet types is left to specific equipment manufacturers to find their uses. Figure 15 illustrates the format of a user-defined stream packet. As shown in FIG. 15, this type of packet structure has fields of packet length, packet type, stream ID number, stream parameter, parameter CRC, stream data, and stream data CRC.

[0203] 7. Color Map Grouping

[0204] The color map grouping specifies the content of the color map lookup table used to visualize colors for the display. Some applications may require the color map to be larger than the amount of data that can be sent in a single packet. In these cases, multiple colormap packets can be transmitted, each with a different subset of the colormap by using the offset and length fields described below. Figure 16 illustrates the format of the color map grouping. As shown in Figure 16, the structure of this type of packet has packet length, packet type, color map data size, color map offset, parameter CRC, color map data, and data CRC fields. This type of packet is generally identified as a type 64 packet.

[0205] 8. Reverse Link Encapsulation Packet

[0206] Data is transmitted in the reverse direction with reverse link encapsulation packets. The forward link packet is sent, and the MDDI link operation (transmission direction) is changed or diverted in the middle of the packet so that the packet can be sent in the reverse direction. Figure 17 illustrates the format of the reverse link encapsulation packet. As shown in Figure 17, this type of packet structure has packet length, packet type, reverse link flag, turnaround length, parameter CRC, turnaround 1, reverse data packet, and turnaround 2. This type of packet is generally identified as a type 65 packet.

[0207] The MDDI link controller works in a special way when sending reverse link encapsulation packets. The MDD interface has a strobe signal that is always stimulated by the host. The host behaves as if it is sending a zero for each bit of the reverse link encapsulation packet's turn and reverse data packet portion. During the two turnaround time periods and the time period allocated for the reverse data packet, the host switches the MDDI_Strobe signal at each bit boundary. (This is equivalent to the behavior of sending all zero data.) The host disables its MDDI data signal line driver during the time period specified by the diversion 1, and the client restarts the driver field after the time period specified by the diversion 2 field Restart the line driver during this period. The display reads the turning length parameter and immediately drives the data signal to the host after turning to the last bit of the 1 field. The display uses the packet length and turn-around length parameters to know the length of time available to send the packet to the host. When there is no data sent to the host, the client can send filler packets or energize the data line to a zero state. If the data line is energized to zero, the host understands it as a packet with a length of zero (not a valid length), and the host no longer receives any packets from the client during the duration of the current reverse link encapsulation packet.

[0208] The display energizes the MDDI data line to zero level at least one reverse link clock cycle before the start of the steering 2 field. This keeps the data line in a certain state during the turn 2 time period. If the client has no more packets to send, it can even disable the data line after energizing them to zero level. This is because the sleep bias resistor (discussed elsewhere) keeps the data line in the reverse data packet field for the rest of the time Keep it at zero level.

CN 101197652 Β

[0209] In order to inform the host of the number of bytes required by the display in the reverse link encapsulation packet when sending data back to the host, the reverse link request field of the Display Request and Status Packet can be used. The host attempts to allow 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. The display can send display requests and status packets at almost any time, and the host interprets the reverse link request parameters as the total number of bytes requested in a subframe.

[0210] 9. Display performance grouping

[0211] In order to configure the host-to-display link in a generally optimal or desired manner, the host needs to know the performance of the display (client) it is communicating with. It is recommended that the display send display performance packets to the host after obtaining the forward link synchronization. When the host uses the reverse link to encapsulate the reverse link flag request in the packet, it is deemed necessary for the transmission of this packet. Figure 18 illustrates the format of the display performance grouping. As shown in Figure 18, this type of packet structure has packet length, packet type, protocol version, minimum protocol version, bitmap width, bitmap height, monochrome performance, colormap performance, RGB performance, Y Cr Cb performance, Display feature performance, data rate performance, frame rate performance, audio buffer depth, audio stream performance, audio rate performance, minimum subframe rate, and CRC fields. This type of packet is generally identified as a type 66 packet.

[0212] 10. Keyboard Data Grouping

[0213] The keyboard data packet is used to send keyboard data from the client device to the host. The wireless (or wired) keyboard can be used with various displays or audio devices, the latter including, but not limited to, head-mounted audio displays/audio display devices. The keyboard data packet relays the keyboard data received from one of the multiple known keyboard-like devices to the host. This packet can also be used on the forward link to send data to the keyboard. Figure 19 shows the format of a keyboard data packet containing variable number of bytes of information from or for the keyboard. As shown in Figure 19, this type of packet structure has packet length, packet type, keyboard data, and CRC fields. This type of packet is generally identified as a type 67 packet.

[0214] 11. Indicating device data packet

[0215] The pointing device data packet is used to send position information from a wireless mouse or other pointing device from the display to the host. Data can also be sent to the pointing device on the forward link in this packet. FIG. 20 shows the format of a data packet of a pointing device, which contains information of a variable number of bytes from the pointing device or for the pointing device. As shown in FIG. 20, this type of packet structure has packet length, packet type, indicating device data, and CRC fields. This type of packet is generally identified as a type 68 packet.

[0216] 12. Link Close Packet

[0217] The link close packet is sent from the host to the client display, indicating that the MDDI data and strobe will be closed and enter a low power consumption "sleep" state. After the static bitmap is transmitted from the mobile communication device to the display, or when no information is currently transmitted from the host to the client, the packet is useful for closing the link and conserving power. Normal operation continues when the host sends the packet again. The first packet sent after sleep is the subframe header packet. Fig. 21 shows the format of the display status packet. As shown in Figure 21, this type of packet structure has packet length, packet type, and CRC fields. This type of packet is generally identified as a type 69 packet in the 1-byte type field, and uses a pre-selected fixed length of 3 bytes.

[0218] In the low-power sleep state, the MDDI_Data driver is disabled to a high-impedance state, and the MDDI_Data signal is pulled to a logic zero state with a high-impedance bias network that can be overdriven by the display. In order to minimize power consumption, the strobe signal used by the interface is set to a logic zero level in the sleep state. As described elsewhere, or the host or display can "wake up" the MDDI link from the dormant state, which is the key advancement and advantage of the present invention.

[0219] 13. Display request and status grouping

[0220] The host needs a small amount of information from the display, so it can configure the host-to-display link in an optimal way. It is recommended that the display send a display status packet to the host every subframe. The display should send this packet as the first packet in the reverse link encapsulation packet to ensure that it is reliably delivered to the host. Fig. 22 shows the format of the display status packet. As shown in Figure 22, this type of packet structure has packet length, packet type, reverse link request, CRC error count, and CRC fields. This type of packet is generally identified as a type 70 packet in the 1-byte type field, and uses a pre-selected fixed length of 7 bytes.

[0221] The reverse link request field can be used to inform the host of the number of bytes required by the display in the reverse link encapsulation packet when sending data back to the host. The host should allow the request by allocating at least this number of bytes in the reverse link encapsulation packet. In order to provide data, the host may send more than one reverse link encapsulation packet in a subframe. The display may send out display request and status grouping at any time, and the host will interpret the reverse link request parameter as the total number of bytes requested in a subframe. The following shows additional details and specific examples of how reverse link data is sent back to the host.

[0222] 14. Bit block transmission packet

[0223] The bit block transmission packet provides a means for scrolling the display area in any direction. Displays with this capability will report this capability in bit 0 of the display feature performance indicator field of the display capability grouping. Fig. 23 shows the format of a bit block transmission packet. As shown in FIG. 23, this type of packet structure has packet length, packet type, upper left X value, upper left Y value, window width, window height, window X displacement, window Y displacement, and CRC fields. This type of packet is generally identified as a type 71 packet, and uses a pre-selected fixed length of 15 bytes.

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

[0225] 15. Bitmap area filling grouping

[0226] The bitmap area filling grouping provides a means to easily initialize the display area to a single color. Displays with this capability will report this capability in bit 1 of the display feature performance indicator field of the display capability grouping. Figure 24 shows the format of the bitmap area padding packet. As shown in FIG. 24, this type of packet structure has packet length, packet type, upper left X value, upper left Y value, window width, window height, data format descriptor, pixel area filling value, and CRC fields. This type of packet is generally identified as a type 72 packet in the 1-byte type field, and uses a pre-selected fixed length of 17 bytes.

[0227] 16. Bitmap Pattern Fill Grouping

[0228] The bitmap pattern fill grouping provides a means to easily initialize the display area to a pre-selected pattern. Displays with this capability will report this capability in bit 2 of the display feature performance indicator field of the display capability grouping. The upper left corner of the filling pattern is aligned with the upper left corner of the window to be filled. If the window to be filled is wider or taller than the filling pattern, the pattern may be repeated multiple times horizontally or vertically to fill the window. The right or bottom of the pattern that was repeated last time is truncated as needed. If the window is smaller than the fill pattern, in order to fit the window, the right or bottom edge of the fill pattern is cut off.

[0229] FIG. 25 shows the format of a bitmap fill packet. As shown in Figure 25, this type of packet structure has packet length, packet type, upper left X value, upper left Y value, window width, window height, pattern width, pattern height, data format descriptor, parameter CRC, pattern pixel data , And the pixel data CRC field. This type of packet is generally identified as a type 73 packet in the 1-byte type field.

[0230] 17. Communication link data channel grouping

[0231] The communication link data channel grouping provides a display device with a high level of computing performance, such as a PDA, for communicating with a wireless transceiver such as a cellular phone or a wireless data port device. In this case, the MDDI link functions as a convenient high-speed interface between a communication device and a computing device with a mobile display, where the packet transmits data at the data link layer of the device's operating system. For example, if a Web browser, e-mail client, or the entire PDA is built into the mobile display, this grouping can be used. Displays with this capability will report this capability in bit 3 of the display feature performance indicator field of the display capability grouping.

[0232] FIG. 26 shows the format of a communication link data channel packet. As shown in FIG. 26, this type of packet structure has packet length, packet type, parameter CRC, communication link data, and communication data CRC fields. This type of packet is generally identified as a type 74 packet in the type field.

[0233] 1&amp;Interface Type Switching Request Packet

[0234] The interface type switching request packet enables the host to request that the client, that is, the display, switch from the existing or current mode to Type I (serial), Type II (2-bit parallel), Type 111 (4-bit parallel), or Type IV (8-bit parallel) mode. Before the host requests a specific mode, it should confirm that the display can work in the desired mode by checking bits 6 and 7 of the display feature performance indicator field of the display performance group. Fig. 27 shows the format of an interface type switching request packet. As shown in Figure 27, this type of packet structure has packet length, packet type, interface type, and CRC fields. This type of packet is generally identified as a type 75 packet, and uses a pre-selected fixed length of 4 bytes.

[0235] 19. Interface Type Confirmation Packet

[0236] The interface type confirmation packet is sent by the display to confirm the reception of the interface type switching packet. The requested mode, Type I (serial), Type II (2-bit parallel), Type 111 (4-bit parallel), or Type IV (8-bit parallel) mode, is reflected back to the host as a parameter in the packet. Fig. 28 shows the format of the interface type confirmation packet. As shown in Figure 28, this type of packet structure has packet length, packet type, interface type, and CRC fields. This type of packet is generally identified as a type 76 packet, and uses a pre-selected fixed length of 4 bytes.

[023 knife 20. Execution type switching grouping

[0238] The execution type switching group is a device that the host instructs the display to switch to a specified mode in the group. This is the same as the previous mode in which the interface type switching request packet and the interface type confirm the packet request and confirm. The host and display should switch to the agreed mode after sending the group. The display may lose and regain link synchronization during the mode change. Fig. 29 shows the format of the execution type switching packet. As shown in FIG. 29, this type of packet structure has packet length, packet type, packet type, and CRC fields. This type of packet is generally identified as a type 76 packet in the 1-byte type field, and uses a pre-selected fixed length of 4 bytes.

[0239] 21. Forward Audio Channel Enable Group

[0240] This grouping allows the host to enable or disable the audio channel in the display. This performance is useful, so the display (client) can turn off audio amplifiers or similar circuit elements to save power when there is no audio to be output by the host. This is particularly difficult to implicitly realize the presence or absence of an audio stream used as an indicator. The default state when the display system is powered on is that all audio channels are enabled. Fig. 30 shows the format of a forward audio channel enable packet. As shown in Figure 30, this type of packet structure has packet length, packet type, audio channel enable mask, and CRC fields. This type of packet is generally identified as a type 78 packet in the 1-byte type field, and uses a pre-selected fixed length of 4 bytes.

[0241] 22. Reverse audio sampling rate grouping

[0242] This group allows the host to enable or disable the reverse link audio channel, and set the audio data sample of this stream

CN 101197652 Β

rate. The host selection is defined as the effective sampling rate in the display performance group. If the host selects an invalid sampling rate, the display will not send the audio stream to the host. The host can disable reverse link audio streaming by setting the sampling rate to 255. The default state assumes that the display system is initially powered on or connected with reverse link audio streaming disabled. Figure 31 shows the format of the reverse audio sample rate packet. As shown in Figure 31, this type of packet structure has packet length, packet type, audio sampling rate, and CRC fields. This type of packet is generally identified as a type 79 packet, and uses a pre-selected fixed length of 4 bytes.

[0243] 23. Digital content protection overhead grouping

[0244] This packet allows the host and the display to exchange messages related to the digital content protection method used. Two types of content protection are currently designed, digital transmission content protection (DTCP), or high-bandwidth digital content protection system (HDCP), leaving room for the designation of additional protection schemes in the future. The method used is specified by the content protection type parameter in the group. Fig. 32 shows the format of the digital content protection overhead packet. As shown in FIG. 32, this type of packet structure has packet length, packet type, content protection type, content protection overhead message, and CRC fields. This type of packet is generally identified as a type 80 packet.

[0245] 24. Transparent color enable grouping

[0246] The transparent color enable group is used to specify the transparent color in the display and enable or disable the use of the transparent color for displaying images. Displays with this capability will report this capability in bit 4 of the Display Feature Performance Indicator field of the Display Performance grouping. When a pixel with a transparent color value is written into the bitmap, the color does not change from the previous value. Fig. 33 shows the format of the transparent color enable packet. As shown in Figure 33, this type of packet structure has packet length, packet type, transparent color enable, data format descriptor, transparent pixel value, and CRC fields. This type of packet is generally identified as a type 81 packet in the 1-byte type field, and uses a pre-selected fixed length of 10 bytes.

[0247] 25. Round Trip Delay Measurement Packet

[0248] The round trip delay measurement packet is used to measure the delay from the host to the client (display) plus the delay from the client (display) back to the host. This measurement inherently includes the delays that exist in the line drivers and receivers and interconnect subsystems. As described generally above, this measurement is used to set the steering delay and reverse link rate divisor parameters in the reverse link encapsulation packet. This grouping is most useful when the MDDI link is operating at the maximum speed of the specific application. MDDI_Stb works as if all zero data is sent in the following fields: all zeros, two guard times, and measurement period. This causes MDDI_Stb to switch at half the data rate, so it can be used as a periodic clock in the display when measuring cycles.

[0249] FIG. 34 shows the format of a round trip delay measurement packet. As shown in Figure 34, this type of packet structure has packet length, packet type, parameter CRC, strobe alignment, all zeros, guard time 1, measurement period, guard time 2, and driver re-enable fields. This type of packet is generally identified as a type 82 packet, and uses a pre-selected fixed length of 535 bits.

[0250] FIG. 35 illustrates the timing of events that occur during the round-trip delay measurement packet. In Figure 35, the host sends a round-trip delay measurement packet, which is shown by the existence of the parameter CRC and the strobe alignment field after the all zeros and guard time 1 field. Delay 3502 occurs before the packet reaches the client display or processing circuitry. When the display receives the packet, it sends out a pattern of 0xff.0xff.0x0 that is as accurate as possible at the beginning of the measurement period determined by the display. The actual time at which the display starts to send the sequence is delayed from the start of the measurement cycle from the perspective of the host. This amount of delay is exactly the time it takes for the packet to propagate through the line driver and receiver and the interconnection subsystem. In order for the pattern to propagate from the display back to the host, a similar amount of delay 3504 is caused.

[0251] In order to accurately determine the round-trip delay of the signal traversing the client, the host compares the ratio of the

CN 101197652 Β

The number of special time periods is counted until the beginning of the 0xff.0xff.0x0 sequence is detected after arrival. This information is used to determine the amount of time it takes for the round trip signal to pass from the host to the client and back again. Then, approximately half of this number is due to the delay created for the one-way path of the signal to the client.

[0252] The display disables its line driver almost immediately after sending out the last bit of the 0xff.0xff.0x0 pattern. Guard time 2 enables the line driver of the display to enter the high-impedance state completely before the host sends the packet length of the next packet. The sleep pull-up and pull-down resistors (see Figure 42) ensure that the MDDI_Data signal is held at a valid low level during the interval when the line driver is disabled in both the host and the display.

[0253] 26. Forward Link Offset Calibration Packet

[0254] The Forward Link Skew Calibration Packet (Forward Link Skew Cal ibration Packet) allows the client or display to calibrate itself for the difference in the propagation delay of the MDDI_Data signal relative to the MDDI_Stb. If there is no delay offset compensation, the maximum data rate is generally limited to compensate for potential worst-case changes in these delays. Generally speaking, this packet is only sent when the forward link data rate is configured to be about 50 Mbps or lower. After sending this packet to calibrate the display, the data rate can be increased to more than 50Mbps. If the data rate is set too high during the offset calibration process, the display may be synchronized to another bit period, which will cause the delay offset compensation to be cut off by more than one bit time, resulting in incorrect data timing. Before sending the forward link offset calibration packet, select the interface type with the highest data rate or the most likely interface type in order to calibrate all existing data bits.

[0255] FIG. 56 shows the format of a forward link offset calibration packet. As shown in Figure 56, this type of packet is constructed with packet length (2 bytes), packet type, parameter CRC, calibration data sequence, and CRC fields. This type of packet is generally identified as a type 83 packet in the type field, and the pre-selected length is 515.

[0256] D. Packet CRC

[0257] The CRC field appears at the end of the packet, and sometimes after some multiple key parameters in the packet. The latter packet has a large data field and therefore has an increased possibility of error during transmission. In a packet with two CRC fields, when only one is used, the CRC generator is reinitialized after the first CRC, so the CRC calculation following the long data field is not affected by the parameters at the beginning of the packet.

[0258] In an exemplary embodiment of the present invention, the polynomial used for CRC calculation is called CRC-16, that is, x¹⁶+χ¹⁵+χ²+χ°_οFigure 36 shows a simple implementation of a CRC generator and checker 3600 useful in implementing the present invention. In Figure 36, the CRC register 3602 is initialized to the value 0x0001 just before the first bit of the packet is transmitted. The first bit is input on the Tx_MDDI_Data_Before_CRC line, and then the bytes of the packet are shifted to the register starting with LSB first. in. Note that the number of register bits in the figure corresponds to the polynomial order used, not the bit positions used by MDDI. It is more effective to shift the CRC register in a single direction, which causes CRC bit 15 to appear in bit position 0 of the MDDI CRC field, CRC register bit 14 to appear in bit position 1 of the MDDICRC field, and so on, until it reaches MDDI bit position 14. .

[0259] As an example, if the group content of the display request and status group is = 0x07, 0x46, 0x000400, 0x00 (or expressed as a byte sequence: 0x07, 0x00, 0x46, 0x00, 0x04, 0x00, 0x00), and use more The input of the multiplexers 3604 and 3606 and the NAND gate 3608 are submitted, and the CRC output generated on the Tx_MDDI_Data_With_CRC line is OxOeal (or expressed as the sequence 0xal, 0x0e).

[0260] When the CRC generator and checker 3600 is configured as a CRC checker, the CRC received on the Rx_MDDI_Data line is the input of the multiplexer 3604 and the NAND gate 3608, and the AND NOR gate 3610 , XOR gate 3612 and AND gate 3614 compare the values found in the CRC register bit by bit. Note that the example circuit shown in Figure 36 can be used in

More than one CRC error signal is output in a given CHECK_CRC_N0W window (see Figure 37b). Therefore, the CRC error counter only counts the first CRC error instance in each interval of CHECK_CRC_N0W activity. If configured as a CRC generator, the CRC will be output from the CRC register as a clock tick at the time that coincides with the end of the packet.

[0261] Figures 37a and 37b graphically illustrate the timing of input and output signals and enable signals. In FIG. 37a, the Gen_Reset, Check_CRC_Now, Generate_CRC_Now, and Sending_MDDI_Data signals, and the state (0 or 1) of the Tx_MDDI_Data_Before_CRC and Tx_MDDI_Data_With_CRC signals show the generation of CRC and the transmission of data packets. In Fig. 37b, the status of the Gen_Reset, Check_CRC_Now, Generate_CRC_Now and Sending_MDDI_Data signals, as well as the Rx_MDDI_Data and CRC error signals shows the reception of the data packet and the check of the CRC value.

[0262] V. Link restart from hibernation

[0263] When the host restarts the forward link from the dormant state, it will excite MDDI_Data to a logic 1 state for about 150 microseconds, then activate MDDI_Stb and simultaneously excite MDDI_Data to a logic zero state for 50 microseconds, and then send subframes Header packet to start forward link traffic. This generally allows bus contention to be resolved before sending out sub-frame header packets by providing sufficient settling time between signals.

[0264] When the client, here is the display, needs data or communication from the host, it energizes the MDDI_Data0 line to the logic 1 state for about 70 microseconds, but other time periods can be used as desired, and then by placing it in high The driver is disabled in the resistive state. This action causes the host to start or restart data traffic on the forward link (208) and poll the client about its status. The host must detect the presence of the request pulse within 50 microseconds, and then start the start sequence, energizing MDDI_Data0 to logic 1 for 150 microseconds and to logic zero for 50 microseconds. If the display detects MDDI_Data0 for more than 50 microseconds in the logic 1 state, it must not send a service request pulse. The selective nature of the time and the tolerance of the time interval related to the sleep processing and the startup sequence are discussed further below.

[0265] FIG. 38 illustrates an example of the processing steps of a typical service request event 3800 without contention, where the letters A, B, C, D, E, F, and G are used to indicate events for the convenience of description. When the host sends a Linkshutdown Packet to the client device to inform it that the link will transition to a low-power sleep state, the process starts at point A. In the next step, the host enters the low-power sleep state by disabling the MDDI_DataO driver and setting the MDDI_Stb driver to logic zero, as shown in point B. MDDI_DataO is driven to zero level by a high impedance bias network. After a certain period of time, the client sends a service request pulse to the host by driving MDDI_Data0 to a logic 1 level as shown in point C. The host still uses the high-impedance bias network to send out a zero level, and the driver in the client forces the line to a logic 1 level. Within 50 microseconds, the host recognizes the service request pulse and sends a logic 1 level on MDDI_Data0 by enabling its driver, as shown in point D. Then, the client stops trying to send a service request pulse, and the client puts its driver in a high-impedance state, as shown in point E. The host drives MDDI_DataO to a logic zero level for 50 microseconds, as shown in point F, and also Start generating MDDI_Stb in a manner consistent with the logic zero level on MDDI_Data0. After setting MDDI_Data0 to zero level and driving MDDI_Stb for 50 microseconds, the host starts to send data on the forward link by sending subframe header packets, as shown by point G.

[0266] A similar example is illustrated in FIG. 39, where a service request is issued after the start of the link restart sequence, and the events are again marked with the letters A, B, C, D, E, F, and G. This reproduces the worst case, where the request pulse from the client arrives closest to destroying the subframe header packet. When the host sends a link-down packet to the client again to inform it that the link will become a low-power sleep state, the process starts at point A. In the next step, the host enters the low-power sleep state by disabling the MDDI_DataO driver and setting the MDDI_Stb driver to zero level, as shown in point B. As before, MDDI_

CN 101197652 Β

DataO is driven to zero level by a high impedance bias network. After a period of time, the client starts the link restart sequence by driving MDDI_Data0 to a logic 1 level for 150 microseconds as shown in point C. Before 50 microseconds have elapsed after the start of the link restart sequence, the display also validates MDDI_Data0 for a duration of 70 microseconds, as shown in point D. This happens because the display needs to request service from the host and does not recognize that the host has started the link restart sequence. Then, the client stops trying to apply the service request pulse, and the client puts its driver to a high impedance state, as shown by point E. The host continues to drive MDDI_DataO to a logic 1 level. The host drives MDDI_DataO to a logic zero level for 50 microseconds, as shown at point F, and also starts to generate MDDI_Stb in a manner consistent with the logic zero level on MDDI_DataO_oAfter setting MDDI_Data0 to zero level and energizing MDDI_Stb for 50 microseconds, the host starts to send data on the forward link by sending subframe header packets, as shown by point G.

[0267] VI. Interface Electrical Specifications

[0268] In an exemplary embodiment of the present invention, data in reverse non-return-to-zero (NRZ) format is encoded with a data strobe signal or DATA-STB format, which allows clock information to be embedded in the data and strobe signal . The clock can be recovered without a complicated phase-locked loop circuit. Data is transmitted on a two-way differential link, which is generally realized with a wired cable. However, as mentioned earlier, other wires, printed wires or transmission elements can also be used. The strobe signal (STB) is transmitted on a unidirectional link driven only by the host. The strobe signal reverses its value (0 or 1) in the next state 0 or 1, which is the same on the data line or signal.

[0269] FIG. 40 graphically shows an example of how to transmit a data sequence such as the bit "1110001011" with DATA-STB encoding. In FIG. 40, the DATA signal 4002 is shown on the top line of the signal timing diagram, and the STB signal 4004 is shown on the second line, each appropriately time aligned (common starting point). As time goes by, when a state change occurs on the DATA line 4002 (signal), the STB line 4004 (signal) maintains the previous state. Therefore, the first "1" state of the DATA signal and the initial value of the STB signal are the first The "0" state is relevant. However, if or when the state and level of the DATA signal have not changed, the STB signal is switched to the relative state, that is, "1" in the previous example, as shown in Figure 40 when DATA is providing another "1" value. In other words, there is always one and only one transition between DATA and STB per bit period. Therefore, when the DATA signal remains at "1", the STB signal transitions to "0" again this time and maintains the level or value when the DATA signal level changes to "0". When the DATA signal remains at "1", the STB signal switches to the opposite state, that is, "1" in the previous example, and so on when the DATA signal changes or maintains the level or value.

[0270] After receiving these signals, an exclusive OR (XOR) operation is performed on the DATA and STB signals to generate a clock signal 4006, which is shown at the bottom of the timing diagram of the relative comparison of the desired data and the strobe signal. Figure 41 shows an example of a circuit system for generating DATA and STB output OR signals from input data at the host, and then recovering or recapturing the data from the DATA and STB signals at the client.

[0271] In FIG. 41, the transmitting part 400 is used to generate and transmit the original DATA and STB signals on the intermediate signal channel 4102, and the receiving part 4120 is used to receive signals and restore data. As shown in FIG. 41, in order to transfer data from the host to the client, the DATA signal is input to the two D-type flip-flop circuit elements 4104 and 4106 together with the clock signal for the trigger circuit. Then, the two flip-flop circuit outputs (Q) are split into differential pair signals MDDI_DataO+, MDDI_DataO- and MDDI_Stb+, MDDI_Stb- using two differential line drivers 4108 and 4110 (voltage mode), respectively. A three-input XNOR gate, circuit or logic element 4112 is connected to receive the output of DATA and two flip-flops, and generate an output that provides the data input of the second flip-flop, which in turn generates MDDI_Stb+, MDDI_Stb-signal. For simplicity, the XNOR gate has an inverting bubble to indicate that it effectively inverts the Q output of the flip-flop that generates the strobe.

[0272] In the receiving section 4120 of FIG. 41, MDDI_Data0+, MDDI_Data0- and MDDI_Stb+, MDDI_

CN 101197652 Β

The Stb-signal is received by each of the two differential line receivers 4122 and 4124, respectively, and the receiver produces a single output from the differential signal. Then, the output of the amplifier is input to each input terminal of two input exclusive OR (X0R) gates, circuits or logic elements, the latter generates a clock signal. The clock signal is used to trigger each of the two D-type flip-flop circuits 4128 and 4130. The latter receives the delayed form of the DATA signal through the delay element 4132. One (4128) generates the data "0" value and the other ( 4130) Generate data "1" value. The clock also has an independent output from the X0R logic. Since the clock information is distributed between the DATA and STB lines, the signal transitions between states are slower than half of the clock rate. Since the clock is reproduced by the exclusive OR process of the DATA and STB signals, the system effectively tolerates twice the deviation between the input data and the clock compared to the case where the clock signal is sent directly on a single dedicated data line.

[0273] In order to maximize the resistance to the negative effects of noise, the MDDI data pair, MDDI_Stb+ and MDDI_Stb- signals are operated in a differential mode. The various parts of the differential signal channel are terminated with a source that is half the characteristic impedance of the cable or wire that transmits the signal. MDDI data pairs are source terminated on both the host and the client. Since only one of these two drives is active at a given time, there is always a termination at the source of the transmission link. The MDDI_Stb+ and MDDI_Stb- signals are only driven by the host.

[0274] FIG. 42 shows a configuration of exemplary elements for implementing the driver, receiver, and termination of the transmission signal as part of the inventive MDD interface. And Table VII shows the corresponding DC electrical specifications of MDDI_Data and MDDI_Stb. This exemplary interface uses low voltage sensing, here 200 millivolts, with a power drift of less than 1 volt and low power consumption.

[0275] Table VII

[0276]

<td>&lt;π1</td><td></td><td>Han Μ</td><td>&gt;</td><td>&gt;</td><td>&gt;</td><td>&gt;</td><td>&gt;</td><td>&gt;</td><td>&gt;</td><td>η</td>

<td>y</td><td>οCO inch</td><td>τ-Η</td><td>CQCQ</td><td>CC&amp;</td><td></td><td>CCο1</td><td>οτ-Η</td><td></td><td>CC&amp;</td><td>LO Ζ</td>

<td>I</td><td>Inch</td><td>Ο τ-Η</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td>

<td></td><td>COτ-Η inch</td><td>CC</td><td>LO τ-Η</td><td>ο</td><td>CCο</td><td></td><td></td><td>οτ-Η1</td><td>ο</td><td>LO ζ1</td>

<td>Lift</td><td>&gt;</td><td></td><td></td><td>Friends B</td><td></td><td></td><td></td><td></td><td>Friends Β r scale</td><td></td>

<td>a</td><td></td><td>J</td><td></td><td></td><td>g</td><td>g</td><td>£&gt;</td><td>1</td><td>ω Μ Chengg Μ</td><td>S 1~~1</td>

CN 101197652 Β

[0277] Table VIII shows the electrical parameters and characteristics of the differential line driver and the line receiver. Functionally, the driver directly transmits the logic level on the input terminal to the positive output terminal, and transmits the inverse of the input terminal to the negative output terminal. The delay from the input to the output is well matched with the differential line being driven differentially. In most implementations, in order to minimize power consumption and electromagnetic radiation, the voltage drift at the output is smaller than the drift at the input. Table VII gives a minimum voltage drift of approximately 0.8 volts. However, other values can be used, which are known to those skilled in the art, and the inventors have conceived smaller values on the order of 0.5 or 0.6 in certain embodiments based on design constraints.

[0278] The differential line receiver has the same characteristics as the high-speed voltage comparator. In Figure 41, the input without inverting is the positive input, and the input with inverting is the negative input. If: (v_input+)-(v_input_) is greater than zero, the output is logic 1. Another way to illustrate this is a differential line amplifier with a very large (essentially infinite) gain, the output of which is clipped at logic 0 and 1 voltage levels.

[0279] The deviation of the delay between different pairs should be minimized to operate the differential transmission system at the highest potential speed.

[0280] In FIG. 42, it is shown that the host controller 4202 and the client, that is, the display controller 4204, transmit packets on the communication link 4206. The host controller uses a series of three drivers 4210.4212 and 4214 to receive host DATA and STB signals to be transmitted, and to receive client data (Data) signals to be transmitted. The driver responsible for the passage of the host DATA uses the enable signal input to allow the communication link to be activated only when a transfer from the host to the client is required. Since the STB signal is formed as part of the data transmission, no additional enable signal is used for the driver (4212). The output of each DATA and STB driver is connected to terminal impedance, namely resistors 4216a, 4216b, 4216c, and 4216d, respectively.

[0281] The terminal resistors 4216a and 4216b also serve as the input terminal impedance of the client receiver 4220 for STB signal processing, and the additional terminal resistors 4216e and 4216f are connected to the input terminal of the client data processing receiver 4222, respectively. The resistors 4216c and 4216d are connected in series. The sixth driver 4226 in the client controller is used to prepare the data signal to be transmitted from the client to the host, and the driver 4214 at the input end processes the data to be transmitted to the host for processing through the terminal resistors 4216c and 4216d.

[0282] Two additional resistors 4218a and 4218b are placed between the terminating resistor and ground and voltage source 4220, respectively, as part of the sleep control described elsewhere. The voltage source is used to drive the transmission line to the aforementioned high or low level to manage the flow of data.

[0283] The above-mentioned driver and impedance can be formed as discrete components or as an application specific integrated circuit (ASIC), the latter serving as a more efficient and cost-effective encoder or decoder solution.

[0284] It can be easily seen that the signals labeled MDDI_Pwr and MDDI_Gnd are used to transmit power from the host device to the client device, or display, on a pair of wires. The MDDI_Gnd part of the signal serves as the reference ground and the power return channel or signal of the display device. The MDDI_Pwr signal serves as a power source for the display device driven by the host device. In an exemplary configuration, for low-power applications, the display device is allowed to extract 500 mA. The MDDI_Pwr signal can be provided from a portable power source such as, but not limited to, a lithium-ion battery or battery pack residing in the host device , And can vary with respect to MDDI_Gnd in the range of 3.2 to 4.3 volts.

[0285] VII. Timing characteristics

[0286] A. Overview

[0287] FIG. 43 illustrates the steps and signal levels used by the client to protect the service from the host and the host to provide this service. In FIG. 43, the first part of the signal shows that the link is closed packet from the host, and then the data line is driven to a logic zero state by a high impedance bias circuit. The clients display, or the host does not transmit any data

According to reports, its drive is disabled. Since MDDI_Stb is active during the link-down packet, a series of strobe pulses of the MDDI_Stb signal line can be seen at the bottom. Once the grouping is over and the logic level becomes zero when the host drives the bias circuit and logic to zero, the MDDI_Stb signal line also becomes zero level. This represents the last signal transmission from the host or the termination of the service, and may have occurred at any time in the past, including it to show the previous stop of the service, and the signal state before the service started. If necessary, this signal can be sent only to reset the communication link to an appropriate state, without "knowing" the previous communication that has been taken by the host.

[0288] As shown in FIG. 43, the signal output from the client is initially set to a zero logic level. In other words, the client output is at high impedance and the driver is disabled. When requesting service, the client starts its driver and sends the service request to the host. This is a period of time, indicated as t_serviceDuring this period, the line is driven to a logic 1 level. Then, a period of time passes, or it may be needed before the host detects the request, called t_host__detectAfter this, the host responds with the link start sequence by driving the signal to a logic 1 level. Here, the host cancels the request and disables the service request driver, so that the output line from the client becomes zero logic level again. During this time, the MDDI_Stb signal is at a logic zero level.

[0289] The host is in the time period t_restart__highThe host data output is driven to the "1" level within, and then the host drives the logic level to zero and in the time period t_restart__lowMDDI_Stb is activated internally, and then the first forward traffic starts with the frame header packet, and then the forward traffic packet is transmitted. MDDI_Stb signal in time period t_restart__lowAnd the subsequent frame header is active during the packet.

[0290] Table VIII shows the representative time of the aforementioned various time period lengths, and the relationship with exemplary minimum and maximum data rates, where: 'Link _ Data _ Rate

[0292] Table VIII

[0293]

<td colspan="2">Μ Bu</td><td colspan="2">1 1</td><td colspan="2">1 1</td><td>S ¥</td><td>sd how</td><td>s¥</td><td>Litigation Μ</td>

<td></td><td>§</td><td>ο9τ-Η</td><td>Ο9</td><td>S</td><td>S</td><td>τ-Η</td><td>s inch</td><td>s</td><td>g τ-Η</td>

<td></td><td>ο</td><td>S τ-Η</td><td>S</td><td></td><td></td><td></td><td></td><td></td><td></td>

<td>£</td><td>ο9</td><td>Almost τ-Η</td><td></td><td>τ-Η</td><td>τ-Η</td><td>τ-Η Οο</td><td>τ-Η Οο</td><td></td><td>Ζ&amp;</td>

<td>Lift</td><td></td><td></td><td></td><td></td><td></td><td>Every Μ battlement S3&lt;ΕΠ</td><td>ΒΜ battlement</td><td></td><td></td>

<td>Wear a</td><td>ω ο I4</td><td>4</td><td>§ ϊtwoω4</td><td>bα</td><td>484£</td><td>qτ-Η</td><td>JωHeadIqτ-Η</td><td></td><td>7-1</td>

[0294] Those skilled in the art can easily understand that the functions of the individual elements described in FIGS. 41 and 42 are well known, and the functions of the elements in FIG. 42 are determined by the timing chart in FIG. 43. The details of the series termination and sleep resistors shown in FIG. 42 are omitted from FIG. 41 because it describes how to perform Data-Strobe encoding and recover from it

CN 101197652 Β

The clock does not need this information.

[0295] B. Data-Srobe timing forward link

[0296] Table IX shows the switching characteristics of data transmission on the forward link output from the host driver. Table IX gives a tabular form of the expected minimum and maximum time for a signal transition relative to the general time. For example, the transition from the beginning to the end of the data value is ttdd-(host-output)» that is, the general length of time used for the transformation from DataO to DataO is as Tsuji, and the minimum time is about ttbit-0.5 nanoseconds, and the maximum is about ttbit +O. 5 nanoseconds. Figure 44 illustrates the relative interval between the transitions on DataO, other data lines (DataX), and strobe lines (Stb), which shows DataO to Strobe, Strobe to Strobe,

Strobe to DataO&gt;DataO to non-DataO, non-DataO to non-DataO, non-DataO to Strobe, and Strobe to non-DataO transitions are called ^tds- (host-output), ^tss-(host-output), ts d- (ho st -out put), ^tddx- (host-output), ^tdxdx-(host-output), t dx s- (ho st -output) and ^tsdx-(host-output) °

[0297] Table IX

[0298]

CN 101197652 Β

<td>&lt;π1</td><td></td><td>Litigation</td><td>Z</td>

<td>y</td><td>ttbit+0· 5</td><td></td><td></td>

<td>I</td><td>4-Q</td><td>4-Q</td><td>4-Q</td>

<td></td><td>LOΟ14-Q</td><td>COο14-Q</td><td>LOO14-Q</td>

<td>Lift</td><td>DataO to DataO transformation</td><td>DataO to Strobe transformation</td><td>Strobe to Strobe transformation</td>

<td>a</td><td>4</td><td>ttds- (host-output)</td><td>4</td>

[0299]

CN 101197652 Β

<td>ttsd- (host-output)</td><td>Strobe to DataO transformation</td><td>Such as factory 0.8</td><td>±tbit</td><td>ttbit+O· 8</td><td>Nanosecond</td>

<td>ttddx- (host-output)</td><td>DataO to non-DataO transformation</td><td></td><td>±tbit</td><td></td><td>Nanosecond</td>

<td>ttdxdx- (host-output)</td><td>Non-DataO to non-DataO transformation</td><td>Seven litigation factory°· 5</td><td>±tbit</td><td>ttbit+O· 5</td><td>Nanosecond</td>

<td>ttdxs (host-output)</td><td>Non-DataO to Strobe transformation</td><td></td><td>±tbit</td><td></td><td>Nanosecond</td>

<td>ttsdx (host-output)</td><td>Strobe to non-DataO transformation</td><td></td><td>±tbit</td><td></td><td>Nanosecond</td>

[0300] Table X shows the general MDDI timing requirements input by the client receiver of the same signal transmitting data on the forward link. Since the same signal is discussed but time-delayed, there is no need for a new diagram to illustrate the signal characteristics or the meaning of the corresponding labels, which can be understood by those skilled in the art.

[0301]Table X

[0302]

<td>&lt;π1</td><td></td><td>Litigation</td><td></td><td>Litigation</td><td>Litigation</td><td>Z</td><td>Z</td><td>Z</td>

<td>y</td><td>hbit+i· ο</td><td></td><td>hbit+i· ο</td><td></td><td></td><td></td><td></td><td></td>

<td>I</td><td>4-Q</td><td>4-Q</td><td>4-Q</td><td>4-Q</td><td>4-Q</td><td>4-Q</td><td>4-Q</td><td>4-Q</td>

<td></td><td>Οτ-Η14-Q</td><td>LOτ-Η14-Q</td><td>oτ-H14-Q</td><td>LOτ-Η14-Q</td><td></td><td></td><td></td><td></td>

<td>Lift</td><td>DataO to DataO transformation</td><td>DataO to Srobe transformation</td><td>Srobe to Srobe transformation</td><td>Srobe to DataO transformation</td><td>DataO to non-DataO transformation</td><td>Non-DataO to non-DataO transformation</td><td>Non-DataO to Srobe transformation</td><td>Srobe to non-DataO transformation</td>

<td>a</td><td>ttdd- (display-input)</td><td>ttds- (display-input)</td><td>4</td><td>4</td><td>t tddx-(host-output)</td><td>ttdxdx- (host-output)</td><td>ttdxs- (host-output)</td><td>4</td>

CN 101197652 Β

[0303] FIGS. 45 and 46 respectively illustrate the existence of a delay, which occurs when the host disables or enables the host driver. In the case that 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 expected packet is delivered, and the expected packet has the parameters CRC, which have been transmitted as described in Figure 45, Strobe alignment and all zero grouping. However, as shown in Figure 45, the line state does not need to be switched from "0" to the desired higher value instantaneously. However, this can potentially be achieved with some existing control or circuit elements, but it takes a while, called the host The drive disables the delay time period to respond. Although it occurs almost immediately so that the length of the time period is 0 nanoseconds (nsec), it can easily be extended to some longer time periods of 10 nanoseconds. It is the maximum time period length expected and occurs at guard time 1. Or turn to the period of 1 grouping time period.

[0304] Referring to FIG. 46, when the host driver is enabled to transmit packets such as reverse link encapsulation packets or round-trip delay measurement packets, it can be seen that the signal level changes. Here, after the protection time 2 or the shift to 2 grouping time periods, the host driver is enabled and starts to drive a level, here is "0", approaching and reaching this value during the host driver enable delay time period, It occurs in the driver re-enable time period before the first packet is sent.

[0305] A similar process occurs for the driver and signal transmission of the client (here, the display). Table XI below shows the general guidelines for the length of these time periods and their corresponding relationships.

[0306] Table XI

[0307]

<td>description</td><td>The smallest</td><td>maximum</td><td>unit</td>

<td>Host driver disable delay</td><td>0</td><td>10</td><td>Nanosecond</td>

<td>Host driver enable delay</td><td>0</td><td>2. 0</td><td>Nanosecond</td>

<td>Display driver disable delay</td><td>0</td><td>10</td><td>Nanosecond</td>

<td>Display driver enable delay</td><td>0</td><td>2. 0</td><td>Nanosecond</td>

[0308] C. Data-Gating Timing Reverse Link

[0309] FIGS. 47 and 48 illustrate switching characteristics and timing relationships of data and strobe signals for outputting data transmitted on the reverse link from the client driver. The typical time for a certain signal transition is discussed below. Figure 47 illustrates the timing of the data being transmitted at the input of the host receiver and the relationship between the rising and falling edges of the strobe pulse. That is, it is called t_sd__srAnd the settling time ts"f of the falling edge of the strobe signal, that is, the trailing edge. The typical length of these settling periods is on the order of 8 nanoseconds.

[0310] FIG. 48 illustrates the switching characteristics formed by reverse data timing and the corresponding client output delay. In Figure 48, you can see the relationship between the timing of the data being transmitted and the rising and falling edges of the strobe pulse that causes the delay. That is, the rise of the so-called strobe signal is the propagation delay t between the leading edge and the data._pd__sr, And the propagation delay t between the falling edge of the data and the strobe signal, that is, the back edge_pd__sfOThe typical length of these propagation delay periods is on the order of 8 nanoseconds.

[0311] VIII. Implementation of Link Control (Link Controller Operation)

[0312] A. State Machine Packet Processor

[0313] The packets transmitted on the MDDI link are scheduled very quickly, usually at a rate of 300 Mbps or higher, but of course, a lower rate can also be used as needed. This type of bus or transmission link speed is too large for the currently commercially available (economical) general purpose microprocessors or the like for control. Therefore, to achieve this

The actual realization of this kind of signal transmission is to use a programmable state machine to decompose the input packet stream, thereby generating packets that are transmitted or redirected to their desired appropriate audio-visual subsystem.

[0314] General-purpose controllers, processors, or processing elements can be appropriately used to act on or manipulate information such as control or status grouping, and they have lower requirements for speed. When those packets (control, status, or other predefined packets) are received, the state machine should pass them to the general-purpose processor through a data buffer or similar processing element, so that they can act on the packets to provide the desired results (effects) ), and audio and visual packets work for the work to be transmitted to their appropriate destinations.

[0315] It can be implemented in some embodiments by using the processing power or transition period available in the microprocessor (CPU), or processor, digital signal processor (DSP), or ASIC in the wireless device in a computer application General-purpose processor operation, which is very similar to the way that certain modems or graphics processors use the processing power of the CPU in the computer to perform certain operations and reduce hardware complexity and cost. However, this will negatively affect the processing speed, timing or The total operation of this element. Therefore, in many applications, it is best to select dedicated circuits or components for this general-purpose processing.

[0316] In order to view image data on the display (microdisplay), or to reliably receive all packets sent by the host, the display signal processing must be synchronized with the forward link channel timing. That is, the signals arriving at the display and display circuits must be synchronized in time so that proper signal processing can occur. The description of FIG. 49 gives a high-level state diagram realized by the signal processing steps or methods that can realize this synchronization. In Figure 49, the possible forward link synchronization states of the state machine 4900 shown are classified into an asynchronous frame (Async Frames) state 4904, two acquisition synchronization (Acquiring Sync) states 4902 and 4906, and three synchronization states ( In-Sync) status 4908, 4910 and 4912. [0317] As shown in the start step or state 4902, the display starts in a preselected "no synchronization" state, and searches for a unique word in the first subframe header packet to be detected. It is worth noting that this non-synchronized state indicates that the minimum communication setting or "backward" setting of the Type I interface is selected. When a unique word is found in the search, the display reserves the sub-frame length field. The CRC bits used for processing are not checked on this first frame, or until synchronization is obtained. If the length of the subframe is zero, then the synchronization state processing proceeds according to this method to the state 4904 marked as the "asynchronous frame" state here, indicating that it is still Synchronization is not reached. In Figure 49, this step in the process is marked as encountering cond 3, that is, condition 3. Otherwise, if the frame length is greater than zero, the synchronization state processing proceeds to state 4906, where the interface state is set to "a synchronization frame has been found". In Figure 49, this step in the process is marked as encountering cond 5, that is, condition 5. In addition, if the state machine sees a frame header packet and a good CRC determination for a frame length greater than 0, the processing proceeds to the "a synchronization frame has been found" state. In Figure 49, this step in the process is marked as encountering cond 6, that is, condition 6.

[0318] In each case where the system is in the "no synchronization" state, when a unique word is detected and a good CRC result is determined for the subframe header packet, and the subframe length is greater than zero, then the interface state becomes "Syncing" status 4908. In Figure 49, this step in the process is marked as cond 1, that is, condition 1. On the other hand, if any one of the unique word or the CRC of the subframe header packet is not corrected, the synchronization state processing proceeds or returns to the interface state 4902 of the "no synchronization frame" state. In the state diagram of FIG. 49, this part The treatment is marked as encountering cond 2, which is condition 2.

[0319] B. Synchronize to obtain time

[0320] The interface may be configured to accommodate a certain number of "synchronization errors" before determining that synchronization has been lost and returning to the "no synchronization frame" state. In FIG. 49, once the state machine has reached the "synchronizing state" and no errors are found, it is continuously encountering the condition 1 result and maintains the "synchronizing" state. However, once a condition 2 result is detected, the process changes the state to the "a synchronization error" state 4910. In this way, if the processing results in the detection of another condition 1 result, the state machine returns to the "synchronizing" state, otherwise it encounters another condition 2 result and moves to the "two synchronization errors" state

CN 101197652 Β

4912. Similarly, if condition 1 occurs, the processing returns the state machine to the "synchronizing" state. Obviously, meeting the "link closed packet" will cause the link to terminate the data transmission and return to the "no synchronization frame" state. This is because there is no content that can be synchronized with it. This is called the cond 4 in the state diagram shown in Figure 49. , Or condition 4.

[0321] It can be understood that the "fake copy" of the unique word may be repeated, which appears at certain fixed positions within the subframe. In this case, the state machine is very unlikely to be synchronized with the subframe, because in order for the MDD interface processing to proceed to the "synchronizing" state, the CRC on the subframe header packet must be valid.

[0322] The subframe length in the subframe header packet may be set to zero to indicate that the host will only send one subframe before the link is closed, and the MDD interface is placed or configured in an idle sleep state. In this case, the display must receive the packet on the forward link immediately after detecting the subframe header packet, because only a single subframe is sent out before the link transitions to the idle state. In normal or typical operation, the subframe length is non-zero, and only forward link packets are processed when the interface is in those states collectively referred to as "IN_SYNC" in Figure 49.

[0323] The time required for the display to synchronize with the forward link signal is a variable that depends on the subframe size and the forward link data rate. When the size of the subframe is large, the likelihood of detecting the "fake copy" of the unique word as part of random or more random data in the forward link is also greater. At the same time, when the forward link data rate is slow, the ability to recover from false detection is low, and it takes longer to complete it.

[0324] C. Initialization

[0325] As mentioned earlier, at the time of "startup", the host configures the forward link to work under the minimum required or expected data rate of 1 Mbps, and configures the subframe length and media frame suitable for a given application rate. That is, both the forward and reverse links start with a Type I interface. When the host determines the performance or desired configuration for the client display (or other device), these parameters are generally only used temporarily. In order to request the display to respond with a display performance packet, the host sends or transmits a subframe header packet on the forward link, followed by a reverse link encapsulation packet, and the bit "0" of the packet request flag is set to a value of one (1 ). Once the display is synchronized on the forward link, it sends out display performance packets and display request and status packets on the reverse link or channel.

[0326] In order to determine how to reconfigure the link with the best or desired performance level, the host checks the contents of the displayed performance group. The host checks the protocol version and minimum protocol version fields to confirm that the host and the display use mutually compatible protocol versions. The protocol version maintains the first two parameters of the display performance group, so that compatibility can be determined even when other elements of the protocol may be incompatible or cannot be considered compatible at all.

[0327] D. CRC processing

[0328] For all packet types, the packet processor state machine ensures that the CRC checker is properly controlled. It also increments the CRC error counter when the CRC comparison results in one or more errors detected. And it resets the CRC counter at the beginning of each processed subframe.

[0329] IX. Grouping Processing

[0330] For each type of packet received by the above state machine, it takes a specific processing step or a series of steps to implement the operation of the interface. Forward link packets are generally processed according to the exemplary processing listed in Table XII below.

[0331] Table XII

[0332]

<td>Group type</td><td>Packet processor state machine response</td>

<td>Subframe Header Packet (SH)</td><td>Confirm the packet, capture the subframe length field, and send the packet parameters to the general-purpose processor.</td>

<td>Filler (F)</td><td>Ignore the data.</td>

<td>Video streaming (VS)</td><td>Interpret the video data format descriptor and other parameters, disassemble the packed pixel data when needed, explain the pixel through the color map if necessary, and write the pixel data into the appropriate position in the bitmap</td>

<td>Audio Stream (AS)</td><td>Send the audio sample rate setting to the audio sample clock generator, separate audio samples of a specific size, unpack the audio sample data when needed, and route the audio samples to the appropriate audio sample FIFO.</td>

<td>Color map (CM)</td><td>Read the color map size and offset parameters, and write the color map data into the color map memory or storage unit.</td>

<td>Reverse Link Encapsulation Packet (REL)</td><td>It is convenient to send packets in the reverse direction at an appropriate time. Check the reverse link flag and send display performance packets as needed. The display request and status packet are also sent appropriately.</td>

<td>Display performance (DC)</td><td>The host sends this type of packet when requested by the reverse link flag field of the reverse link encapsulation packet.</td>

<td>Keyboard (K)</td><td>These packets are passed in and out of a general-purpose processor that communicates with keyboard-type devices, and if they exist, they are expected to be used.</td>

[0333]

<td>Pointing device (PD)</td><td>These packets are passed in and out of a general-purpose processor that communicates with the indication type device, and if it exists, it is expected to be used.</td>

<td>Link closed (LS)</td><td>Record that the actual link is closed and notify the general-purpose processor.</td>

<td>Display service request and status (DSRS)</td><td>This packet is sent as the first packet in the reverse link encapsulation packet.</td>

<td>Bit block transfer (BPT)</td><td>Interpret grouping parameters, such as video data format descriptors, determine which pixels to move first, and move pixels in the bitmap as needed.</td>

<td>Bitmap area filling (BAF)</td><td>Interpret the grouping parameters, explain the pixels through the color map if necessary, and write the pixel data to the appropriate location in the bitmap.</td>

<td>Bitmap pattern fill (BPF)</td><td>Interpret the grouping parameters, unpack the packed pixel data if necessary, interpret the pixels through the color map if necessary, and write the pixel data to the appropriate position in the bitmap.</td>

<td>Communication Link Channel (CLC)</td><td>Send this data directly to the general-purpose processor.</td>

<td>Display Service Request (DSR) during sleep</td><td>The general-purpose processor controls the low-level function of the sending request and detects contention when the link spontaneously restarts.</td>

<td>Interface type switching request (IDHR) and interface type confirmation (ΙΤΑ)</td><td>It is possible to transfer these packets to or from the general-purpose processor. The logic to receive this type of packet and use an acknowledgment to indicate the response is almost minimal. Therefore, this operation can also be implemented in the packet processor state machine. The resulting switch occurs as a low-level physical layer action, and is unlikely to affect the function or role of the general-purpose processor.</td>

<td>Execution type switching (ΡΤΗ)</td><td>It is possible to act on these packets either directly or by passing them to a general-purpose processor, again instructing the hardware to undergo mode changes.</td>

[0334] X. Reducing the reverse link data rate

[0335] The inventors have observed that in order to achieve the highly desired maximum or more optimized (scaled) reverse link data rate, certain parameters used by the host link controller can be adjusted or configured in some way. For example, during the time used to transmit the reverse link packet field of the reverse link encapsulation packet, the MDDI_Stb signal pair is repeatedly switched to create a periodic data clock that is half the forward link data rate. This happens because the host link controller generates the MDDI_Stb signal corresponding to MDDI_DataO as if it sent out all zeros. The MDDI_Stb signal is transmitted from the host to the display, where it is used to generate a clock signal for transmitting reverse link data from the display, and the reverse link data is sent back to the host using it. Figure 50 shows the typical amount of delay encountered in signal transmission and processing on the forward and reverse channels in a system using MDDI. In Figure 50, a series of delay values of 1.5 nanoseconds, 8.0 nanoseconds, 2.5 nanoseconds, 2.0 nanoseconds, 1.0 nanoseconds, 1.5 nanoseconds, 8.0 nanoseconds are shown as a series of delay values. Nanoseconds and 2.5 nanoseconds are respectively close to the processing part of Stb+/- generation, cable transmission to display, display receiver, clock generation, signal synchronization, DataO+/- generation, cable transmission to host, and host receiver level.

[0336] Depending on the forward link data rate and signal processing delay encountered, it may take more than one cycle time to complete the "round trip" effect or a set of events than the MDDI_Stb signal, causing undesirable time or The amount of cycles. To prevent this problem, the reverse rate divisor enables one bit time on the reverse link to span multiple cycles of the MDDI_Stb signal. This means that the reverse link data rate is lower than the forward link rate.

[0337] It should be noted that the actual signal delay length through the interface may vary depending on each specific host-client system or hardware used. Each system generally performs better by measuring the actual delay in the system with round-trip delay measurement packets, so the reverse rate divisor can be set to an optimal value.

[0338] The round-trip delay is measured by causing the host to send a round-trip delay measurement packet to the display. The display responds to the packet by sending a 1 sequence back to the host within a preselected measurement window or period in the packet, and the measurement window is called a measurement time period field. The detailed timing of this measurement has been described above. The round-trip delay is used to determine the rate at which reverse link data can be safely sampled.

[0339] The round-trip delay measurement includes determining, detecting, or counting the number of forward link data clock intervals that occur at the beginning of the measurement period field and when the host receives an Oxff.Oxff.OxOO response from the display. Between the start of the time period of the sequence. Note that the response from the display may be received 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 will cause bit errors on the reverse link caused by unreliable data sampling. An example of this situation is illustrated in Figure 51, where

The graphic form illustrates the MDDI_Data at the host, the MDDI_Stb at the host, the forward link data clock in the host, and the delay count signals. In Figure 51, the response sequence is received a fraction of the forward link clock cycle before the delay count increases from 6 to 7. If the delay is assumed to be 6, the host will always sample the reverse data after the bit transition or possibly in the middle of the bit transition. This can lead to incorrect sampling at the host. For this reason, the measured delay should be increased by one before using it to calculate the reverse rate divisor.

[0340] The reverse rate divisor is the number of MDDI_Stb cycles that the host should wait before sampling reverse link data. Since MDDI_Stb is cycled at half the rate of the forward link, the corrected round-trip delay measurement needs to be divided by 2, and then rounded up to the next integer. The relationship is expressed by the formula as follows:

<td>[0341]</td><td>reverse _ rate _ divisor = RoimdUpToNext]ntege( _ cut+]</td>

<td>[0342]</td><td>For the given example, this becomes:</td>

<td>[0343]</td><td>reverse _ rate _ divisor = RoundUpToNextlnteger^^-^</td>

<td>[0344][0345]</td><td>If the round-trip delay measurement used in this example is not 6 but 7, then the reverse rate divisor will also be equal to 4. The reverse link data is sampled by the host on the rising edge of the reverse link clock. This is the host and client (show</td>

A counter or similar known circuit or device used to generate 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 in the reverse link packet field of the reverse link encapsulation packet. This is illustrated in Figure 52 for the example given below. The counter increment at each rising edge of the MDDI_Stb signal and the number of counts that occur before they wrap around are set by the reverse rate divisor parameter in the reverse link encapsulation packet. Since the MDDI_Stb signal is converted 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 200 Mbps and the reverse rate divisor is 4, the reverse link data rate is expressed as:

[0346]

200 Mbps

4 =25Mbps

[0347] FIG. 52 shows an example of the timing of the MDDI_Data0 and MDDI_Stb signal lines in the reverse link encapsulation packet, where the packet parameters used in the description have the following values:

[0348] Packet length=1024 (0x0400)

[0349] Group Type=65 (0x41)

[0350] Reverse Link Flag=0

[0351] Parameter CRC=0xdb43 Turn 1 length=1 Turn 2 length=1 Reverse rate divisor=2 All zeros are 0x00

[0352] The packet data between the packet length and the parameter CRC field is:

[0353] 0x00, 0x04, 0x41, 0x00, 0x02, 0x01,0x01,0x43, Oxdb, 0x00,...

[0354] The first reverse link packet returned from the display is the display request and status packet, the packet length is 7, and the packet type is 70. The grouping starts with byte values 0x07, 0x00, 0x46..., and so on. However, only the first byte (0x07) can be seen in Figure 52. To illustrate the actual reverse link delay, the first reverse link packet is shifted in time in the figure by nearly one reverse link clock cycle. The dashed trace shows an ideal waveform with zero host-to-display round trip delay.

[0355] The strobe alignment byte is transmitted after the MS byte of the parameter CRC field, followed by the all-zero field. The strobe from the host switches from 1 to zero, and then returns to 1 when the data from the host changes to a level that forms a wider pulse. When the data changes

When it is zero, the strobe switches at a higher rate, and only changes in the data on the data line will cause changes at the end of the alignment field. The strobe is switched at a higher rate in the remaining part of the figure caused by the fixed 0 or 1 level of the data signal of the extended time period, and the transition falls on the pulse pattern (edge).

[0356] When the clock is started to accommodate reverse link packets, the host's reverse link clock is zero before turning to 1 time period. The arrow at the bottom of the figure indicates when the data was sampled, which will become apparent from the following disclosure. The first byte of the packet field shown (here 11000000) being transferred starts after turning 1, and the line level has stabilized since the host driver was disabled. The delay in the first bit path and the delay in bit 3 can be seen in the dotted line of the data signal.

[0357] In FIG. 53, a typical value of the reverse rate divisor based on the forward link data rate can be observed. 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 an area of edge characteristics, and the third area 5306 represents a setting that cannot be properly operated.

[0358] When operating either in the forward or reverse link with either interface type setting, the round-trip delay measurement and the reverse rate divisor setting are the same, because they are expressed and operated in units of actual clock cycles , Rather than the number of bits that have been transmitted or received.

[0359] XI. Steering and protection time

[0360] As mentioned earlier, the Turnaround 1 field in the reverse link encapsulation packet and the guard time 1 in the round-trip delay measurement packet specify the length value that allows the host interface driver to be disabled before the display interface driver is enabled. The Turnaround 2 and Guard Time 2 fields provide time values that allow the display driver to be disabled before enabling the host driver. The guard time 1 and guard time 2 fields are generally filled with a preset or pre-selected value of length, and it will not be adjusted. Depending on the interface hardware used, these values can be studied with empirical data and adjusted in some cases in order to improve operation.

[0361] Several factors play a role in determining the length of turnaround 1, and these are the forward link data rate and the maximum disable time of the MDDI_Data driver in the host. The maximum host drive disable time is specified in Table XI, which shows that the drive requires a maximum time of approximately 10 nanoseconds to disable and approximately 2 nanoseconds to enable. The minimum number of forward link clocks for the host driver to be disabled is expressed in the following relationship:

<td>[0362]</td><td>ηι 1 _t J- L] ForwardLinkDataRate _. ,C/oco to aisable_m =--HostDriverDisableDelay_ _ Interface TypeFactor_FWD</td>

<td>[0363][0364]</td><td>The allowable value range for turn 1 is expressed according to the following relationship:</td>

<td>Turn</td><td>_ Around _1&gt; RoundUpToNextlnteget 1⁰* _cut]· InterfaceTypeFactor_PWD ]</td>

<td>[0365]</td><td>The Interface Type Factor is 1 for type I and 2 for type II.</td>

It is 4 for type III and 8 for type IV.

[0366] Combining the above two formulas, it can be seen that the interface type factor item is eliminated, and turn 1 is defined as:

[0367]

Turnarounds = RoundUpToNe_XtInteger[ F Zhu is empty and empty to buy such as Zhu 2 Qin Li wrinkles light

[0368] For example, a 1500 Mbps Type III forward link will use the following turnaround 1 delay:

CN 101197652 B

<td>[0369]</td><td>Turn Around _ \ = RoundUpToNextIntegefΡ;] 9 nanoseconds] = 2 bytes</td>

<td>[0370][0371]</td><td>As the round-trip delay increases, the timing edge from the point when the host is disabled to when the display is enabled is improved. Turn to 2 The prisoners generally used to determine the length of time are the forward link data rate and the MDDI_Data in the display.</td>

The maximum disable time of the drive and the round-trip delay of the communication link. The calculation of the time required to disable the display driver is generally the same as the time discussed above for the host driver, and is defined according to the following relationship:

<td>[0372]</td><td>Clocks to dlsab%2= Fo^MdLinkDataRate DisplayDriverDisableDelay**InterfaceType Factor</td>

<td>[0373][0374]</td><td>And the allowable value range for turn 2 is expressed as:</td>

fr, n text Clocks to disable_Tjl·, + round trip delay +1

Turn_Around_2&gt;RoundUpToNextInteger ------------------- -----8, \InterfaceTypeFactor_FWD J Pi

[0375] For example, a 1500 Mbps Type III forward link with 10 forward link clocks generally uses turnaround 2 delays of the following order of magnitude:

[0376]

Clocks_to_disable_TA2 = .]. Nanosecond = 3.75

[0377]

Turn _ Around _2&gt; RoundUpToNextlnteger

3.75 + 10 + 1

[0378] XII. Effects of link delay and skew

[0379] The delay offset on the forward link between the MDDI_Data pair and MDDI_Stb will limit the maximum possible data rate, unless delay offset compensation is used. The difference in delay time that causes the timing offset is due to the controller logic, line drivers and receivers, and cables and connectors presented below.

[0380] A. Link timing analysis limited by offset (MDDI type T)

[0381] 1. Delay and offset example of Type-1 link

[0382] FIG. 57 shows a general interface circuit similar to that shown in FIG. 41 for adapting to a Type-1 interface link. In the picture

In 57, exemplary or general values for propagation delay and skew are shown for each of the multiple processing or interface stages of the MDDI type-1 forward link. The offset within the delay between MDDI_Stb and MDDI_DataO 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 and 5732 must change slightly after the clock edge so that it can be sampled reliably. The figure shows two cascaded delay lines 5732a and 5732b, which are used to solve two different problems related to the creation of the timing relationship. In actual implementation, these can be combined into a single delay element.

[0383] FIG. 58 illustrates data, strobe, and clock recovery timing on a Type-1 link for exemplary signal processing through an interface.

CN 101197652 Β

[0384] The significant total delay offset generally originates from or comes from the sum of the offsets in the following stages: transmitter flip-flop (TXFF) with flip-flop 5704.5706; transmitter driver with driver 5708, 5710 (TXDRVR) ; Cable 5702; Receiver line receiver (RXRCVR) with receivers 5722, 5724; and Receiver XOR logic (RXX0R). Delay l (Delayl) 5732a should match or exceed the delay of XOR gate 5736 in RXX0R level, and the latter should be determined according to the following relationship:

[0385] tpD-min(Delayl) 2 tpD-max(XOR)

[0386] It is desirable to meet this requirement so that the receiver flip-flop 5728.2732 does not change before its clock input. in case

This is valid if the hold time of RXFF is zero.

[0387]

[0388]

[0389] The maximum delay will also be zero.

[0390] The worst-case offset in the XOR stage of the receiver is in the case of data lag/gating advance, where the delay l (Delayl) is the maximum value, and the clock output of the XOR gate arrives according to the following relationship As early as possible: The purpose or function of Delay 2 is to compensate the hold time of the RXFF flip-flop according to the following relationship: t PD-min(Delay2) - (RXFF) In many systems this will be zero because the hold time is zero , Of course, in this case, the delay 2 (Delay2)

[°391] tSKEW-max (RXXOR) - tpn-max (Delayl) ^_tpD_min(XOR)

[0392] In this case, the data can vary between two bit periods n and n+1, very close to the time in which the bit n+1 is timed to the receiver flip-flop.

[0393] The maximum data rate (minimum bit period) of the MDDI Type-1 link is a function of the maximum offset foreseen by all drivers, cables, and receivers in the MDDI link plus the total data set in the RXFF stage. The total delay offset within the link up to the output of the RXRCVR level can be expressed as:

<td>[0394][0395][0396][0397][0398][0399][0400]</td><td>^SKEW-max (LINK) - ^SKEW-max (TXFF) ⁺tsKEW-max (TXDRVR) ⁺tsKEW-max (CABLE) ⁺The minimum bit period of tsKEW-max (RXRCVR) is given by the following formula: ΐβΙΤ-ηιίη - ^SKEW-max (LINK) ⁺tsKEW-max (RXXOR) ⁺tpD-max (Delay2) ⁺tsU(RXFF) In the example shown in Figure 57, t_SKEW__max(LINK) = 1.4 nanoseconds, the minimum bit period can be expressed as: t_BIT__min = 1. 4+0.3+0. 2+0.5 = 2.4 nanoseconds, or about 416Mbps. B. MDDI Type-11, III, and IV Link Timing Analysis Figure 59 shows a general interface circuit similar to that shown in Figures 41 and 57, which is suitable for Type-II, III and</td>

IV interface link. TXFF (5904), TXDRVR (5908), RXRCVCR (5922) and RXFF (5932, 5928, 2930) stages use additional components to suit additional signal processing. In Fig. 59, exemplary or general values of propagation delay and skew are shown for each of several processing or interface stages of the MDDI Type-11 forward link. In addition to affecting the duty cycle of the output clock

In addition to the offset within the delay between MDDI_Stb and MDDI_Data0, there is also an offset between these two signals and other MDDI_Data signals. The data at the D input of the receiver flip-flop B (RXFFB) stage composed of flip-flops 5928 and 5930 changes slightly after the clock edge, so that it can be sampled reliably. If MDDI_Data1 arrives earlier than MDDI_Stb and MDDI_Data0, MDDI_Data1 should be delayed so that it is at least sampled by the delay offset. In order to accomplish this, the Delay 3 delay line is used to delay the data. If MDDI_Data1 arrives later than MDDI_Stb and MDDI_Data0, it should also be delayed by Delay3, where the MDDI_Data1 change is moved closer to the next clock edge. This process determines the upper limit of the data rate of the MDDI type or IV link. Figures 60a, 60b, and 60c illustrate some exemplary different possibilities of the timing or offset relationship of two data signals and MDDI_Stb relative to each other.

[0401] When MDDI_DataX arrives as early as possible, in order to reliably sample data in RXFFB, follow the following criteria:

CN 101197652 Β

tBIT-min - tSKEW-max (LINK) ⁺tpD-max (Delay3) ⁺tsU(RXFFB) ^_tpD-min(XOR) So the upper limit of the link speed is: ^PD-max (Delay 3) ^PD-min(Delay3) And given hypothesis: tBIT-min(lower limit)-2 * t_SKEW-_max (_LINK) ⁺tpD-max (XOR) ⁺tsU (RXFFB) ⁺tH(RXFFB) In the above example, the lower limit of the minimum bit period is given by the following relationship: tBiT-min (low level)=2·1. 4+1. 5+0.5+0. 1 ⁼ 4.8 nanoseconds, which is about 208Mbps. This is much slower than the maximum data rate used by Type T links. MDDI's automatic delay offset compensation ability is set Delay3:

[0402] tpD-min(Delay3) 2 tSKEW-max (LINK) ⁺^Η (RXFFB) ⁺tpD-max (XOR)

[0403] The maximum link speed is determined by the minimum allowable bit period. This is most affected when MDDI_DataX arrives as late as possible. In this case, the minimum allowable cycle time is given by:

[0404]

[0405]

[0406]

[0407]

[0408]

[0409]

[0410]

[0411] The influence of the delay offset on the maximum link rate is greatly reduced.

[0412] XIII. Physical layer interconnection description

[0413] The physical connection used to realize the interface according to the present invention can be realized with commercially available parts, such as the part number 3260-8S2 (01) manufactured by Hirose Electric Co., Ltd. on the host side, and the display device by Hirose Electric Co., Ltd. The end-manufactured part number 3240-8P-Co Table XIII lists an exemplary type I interface pin assignment for this connector with a type I interface, or "pinout," and is illustrated in FIG. 61.

[0414] Table XIII

[0415]

<td>Signal name</td><td>Lead number</td><td>color</td><td>Signal name</td><td>Lead number</td><td>color</td>

<td>MDDI_Gnd</td><td>1</td><td>red</td><td>MDDIPwr</td><td>2</td><td>Black and red pair</td>

<td>MDDI_Stb+</td><td>3</td><td>green</td><td>MDDI_Stb-</td><td>4</td><td>Black and green pair</td>

<td>MDDI_DAT0+</td><td>5</td><td>blue</td><td>MDDI_DAT0-</td><td>6</td><td>Black and blue pair</td>

<td>MDDI_DAT1+</td><td>7</td><td>White</td><td>MDDI_DAT1-</td><td>8</td><td>Black and white pair</td>

<td></td><td></td><td></td><td>shield</td><td></td><td></td>

[0416] The shield is connected to the MDDI_Gnd in the host interface, and the drain wire in the cable is connected to the shield of the display connector.

However, the shielding and drain wires are not connected to the circuit ground inside the display.

[0417] In order to be small enough to be used with mobile communication and computing devices such as PDAs and wireless phones, or portable gaming devices, the interconnection elements or devices are selected or specified, which are not prominent or unsightly compared to the size of related devices. Any connector and circuit should be able to continue to be used in a typical user environment and allow small size and relatively low cost, especially for cables. The transmission element should supply data and strobe signals as differential NRZ data, which have a transmission rate of up to about 450 Mbps for Type I and Type II, and a transmission rate of up to 3.6 Gbps for the 8-bit parallel type IV version.

[0418] XIV. Operation

CN 101197652 Β

[0419] FIGS. 54a and 54b show an overview of the general steps used to process data and packets during an interface operation using an embodiment of the present invention, and an overview of the interface device for processing the packets in FIG. 55. In these figures, the process starts at step 5402 to determine whether the client and the host are connected by a communication channel, where the communication channel is a cable. This can occur through the use of periodic polling by the host, software or hardware that detects the presence of connectors or cables or signals at the host input (as seen at the USB interface), and other known techniques. If no client is connected to the host, it will simply enter a predetermined length of waiting state, enter a sleep mode, or be blocked for future use depending on the application. The latter requires the user to take action to reactivate the host. For example, when the host resides on a computer-type device, the user may have to click on a screen icon or request to activate the host's processing to find the client's program. Similarly, the simple insertion of a USB type connection, such as that used by a Type U interface, will activate the host processing.

[0420] Once the client is connected to the host, or vice versa, or is detected as being present, then either the host or the client is in step

Appropriate packet request service is sent out in 5404 and 5406. In step 5404, the client will either issue a display service request or issue a status packet. Note that, as described above, the link may have been previously closed or in sleep mode, so this may not be a complete initialization of the allowed communication link. Once the communication link is synchronized and the host attempts to communicate with the client, the client also needs to provide the display performance packet to the host, as shown in step 5408. The host can now begin to determine the type of support the client can provide, including the transfer rate.

[0421] Generally speaking, the host and client also negotiate the service mode type (rate/speed) to be used in step 5410, such as type I, type U, type II, and so on. Once the service type is established, the host begins to transmit information. In addition, the host can use the round-trip delay measurement packet to optimize the timing of the communication link in parallel with other signal processing, as shown in step 5411.

[0422] As mentioned earlier, all transmissions start with subframe header packets, which are transmitted in step 5412, followed by data types, here are video and audio stream packets, and filler packets, as shown in step 5414 Is transmitted. Audio and video stream data will be prepared in advance and mapped into packets, and filler packets will be inserted as needed to fill up the number of bits required by the media frame. The host can send packets such as the forward audio channel enable packet to the active sound device, or in addition, the host can use the other packet types described above to transmit instructions or information. Here, the transmission color map, bit block transmission, or step 5416 is shown. Other groups. In addition, the host and client can use appropriate packets to exchange data related to the keyboard or pointing device.

[0423] During operation, one of several different events may occur, which may cause the host or client to expect a different data rate or interface mode type. For example, a computer or other device that transmits data may encounter download conditions in processing data , It causes the preparation or presentation of the group to slow down. The display receiving the data will change from a dedicated AC power source to a more limited battery power source, and either cannot transmit data as quickly, process commands easily, or try the same degree of resolution or color depth under more limited power settings. Or, the restriction can be eliminated or disappeared, allowing any device to transmit data at a high rate. As this is increasingly desired, a request can be made to change to a higher transmission rate mode.

[0424] If these or other types of known conditions occur or change, the host or client may detect them and try to renegotiate the interface mode. This is shown in step 5420, where the host sends an interface type handoff request packet (Interface Type Handoff Request Packets) to the client to request a switch to another mode, and the client sends an Interface Type Acknowledge Packets to confirm After the detected change, the host then sends out a perform type handoff packet (Perform TypeHandoffPackets) to make a change to the specified mode. [0425] Although no specific processing sequence is required, the client and host can also exchange packets related to data directed to or received from a pointing device, a keyboard, or other user-type input devices mainly related to the client, but these elements

CN 101197652 Β

It can also exist on the host side. These groups are generally processed with general process or type components and not state machines (5502). In addition, some of the instructions discussed above can also be processed by general-purpose processors (5504, 5508).

[0426] After the data and instructions are exchanged between the host and the client, a decision is made at some point whether to transmit additional data, or whether the host or the client wants to stop the transmission service. This is shown in step 5422. If the link is about to enter or sleep state or is completely shut down, the host sends a Link Shutdown packet to the client, and both ends terminate data transmission.

[0427] The packets transmitted in the above operation process will be transmitted using the driver and receiver discussed above with respect to the host and client controllers. These line drivers and other logic elements are connected to the aforementioned state machine and general-purpose processor, as described in the overview of Figure 55. In Figure 55, the state machine 5502 and the general-purpose processor 5504 are also connected to other components not shown, such as dedicated USB interfaces, memory components, or other components residing outside the link controller with which they interact, including , But not limited to: data sources, and video control chips for visual display devices.

[0428] The processor and the state machine provide control for the enabling and disabling of the drivers discussed above regarding protection events, etc., to ensure the effective establishment and termination of the communication link, and packet transmission.

[0429] XV. Appendix

[0430] In addition to the format, structure, and content discussed above for the various structures and protocol groupings used to implement the embodiments of the present invention, more detailed field content of some grouping types are also given here. These are given here to further clarify their respective uses or operations, so that those skilled in the art can more easily understand the present invention and utilize it for various applications. Only some fields that have not been discussed are discussed further here.

[0431] A. For video stream grouping

[0432] The Display attributes field (1 byte) has a series of bit values, which are explained as follows. Bits 1 and 0 select how to route display pixel data. For the bit value "00" or "11", the data is displayed to both eyes, for the bit value "10", the data is only routed to the left eye, and for the bit value "01", the data is only routed to the right eye. Bit 2 indicates whether the pixel data (Pixel Data) is given in an interleaved format, and the row number (pixel Y coordinate) increases by 1 when advancing from one row to the next. When the bit value is "1", the pixel data is in an interleaved format, and the line number increases by 2 when it advances from one line to the next. Bit 3 indicates that the pixel data is in alternate pixel format. This is similar to the standard interleaving mode enabled by bit 2, but the interleaving is vertical rather than parallel. When bit 3 is 0, the pixel data is in the standard progressive format, and the column number (pixel X coordinate) is increased by Ιο when each continuous pixel is received. When bit 3 is 1, the pixel data is in the alternate pixel format, and the column number is Increase by 2 when each pixel is received. Bits 7 to 4 are reserved for future use and are generally set to zero.

[0433] The 2-byte X Start and Y Start fields (X Start and Y Start fields) specify the X and Y absolute coordinates (X Start, Y Start) of the first pixel in the pixel data field. The 2-byte X Left Edge and Y Top Edge fields (X Left Edge and Y Top Edge fields) specify the left edge coordinate X and the top edge coordinate Y of the screen window filled by the pixel data field, and the X right edge and Y top edge coordinate The edge fields (X RightEdge and Y Bottom Edge fields) specify the right edge coordinate X and the bottom edge coordinate Y of the update window.

[0434] The Pixel Count field (2 bytes) specifies the number of pixels in the following pixel data field

[0435] The Parameter CRC field (2 bytes) contains the CRC of all bytes from the packet length to the pixel count. If the CRC fails, the entire packet is discarded.

[0436] The Pixel Data field contains the original video information to be displayed, which is formatted in the manner described in the video data format descriptor. As discussed elsewhere, data is transmitted one "line" at a time.

CN 101197652 Β

[0437] The Pixel Data CRC field (2 bytes) only contains the 16-bit CRC of the pixel data_OIf the CRC verification of this value fails, the pixel data can still be used, but the CRC error count is increased by one.

[0438] B. For video stream grouping

[0439] The Audio Channel ID field (1 byte) identifies the specific audio channel to which the client device sends audio data. The physical audio channel is specified in this field or mapped by this field, and its value 0, 1, 2, 3, 4, 5, 6 or 7 means front left, front right, rear left, rear right, middle front, and subwoofer, respectively , Left surround, and Right surround channels. Audio channel ID 254 indicates that a single stream of digital audio samples is sent to the left front and right front two channels. This simplifies applications that use stereo headsets for voice communications, productivity-enhancing applications in PDAs, and any applications in which a simple user interface generates warning sounds. The value of the ID field varies from 8 to 253, and 255 is currently reserved for new designs that require additional assignments.

[0440] The Audio Sample Count field (2 bytes) specifies the number of audio samples in the packet.

[0441] The Bits Per Sample and Packing field contains 1 byte and specifies the interval format of the audio data. The commonly used format is bits 4 to 0 to define the number of bits per PCM audio sample. Then, bit 5 specifies whether the digital audio data samples are grouped. As mentioned above, Figure 12 illustrates the difference between grouped and byte-aligned audio samples. The value "0" of bit 5 indicates that each continuous PCM audio sample in the digital audio data field is byte-aligned with the interface byte boundary, and the value "1" indicates that each continuous PCM audio sample is packed with respect to the previous audio sample. This bit is only valid when the value defined in bits 4 to 0 (the number of bits per PCM audio sample) is not a multiple of eight. Bits 7 to 6 are reserved for use when additional assignments are desired by the system design, and are generally set to a value of zero.

[0442] The Audio Sample Rate field (1 byte) specifies the audio PCM sampling rate. The format used is the value 0 means 8000 (sps) sampling rate, value 1 means 16000 sps, value 2 means 24000 sps, value 3 means 32000 sps, value 4 means 40,000 sps, value 5 means 48000 sps, value 6 means 11025 sps, value 7 Represents 22050 sps, and the value 8 represents 44100, and the values 9 to 15 are reserved for future use, so they are now set to zero.

[0443] The Parameter CRC field (2 bytes) contains a 16-bit CRC of all bytes from the packet length to the audio sampling rate. If the CRC check fails normally, the entire packet is discarded. The digital audio data field contains the original audio samples to be played, and is usually in the form of a linear format such as an unsigned integer. The audio data CRC field (2 bytes) contains a 16-bit CRC of only audio data. If the CRC fails, the audio data can still be used, but the CRC error count is increased by one.

[0444] C. For user-defined flow grouping

[0445] A 2-byte Stream ID Number field (Stream ID Number field) is used to indicate a specific video stream. The content of Stream Parameters and Stream Data fields is defined by the MDDI device manufacturer. The 2-byte Stream Parameter CRC field (Stream Parameter CRC field) contains a 16-bit CRC of all bytes starting from the packet length to the audio encoding byte. If the CRC fails the check test, the entire packet is discarded. The 2-byte Stream Data CRC field contains only the CRC of the stream data. If the CRC fails to pass the check normally, the use of still streaming data is optional, depending on the requirements of the application. The use of streaming data depending on a good CRC requires buffering the streaming data before confirming that the CRC is good. If the CRC fails the check, the CRC error count is increased by one.

[0446] D. For colormap grouping

[0447] The Color Map Data Size field (2 bytes) specifies the color map in the group

The total number of color chart items in the data field. The number of bytes in the color map data is 3 times the size of the color map. The color map size is set to zero, and no color map data is sent. If the color map size is zero, the color map offset value is still sent out but ignored by the display. The Color Map Offset field (2 bytes) specifies the offset of the color map data from the start of the color chart of the display device within the group.

[0448] The 2-byte parameter CRC field (Parameter CRC field) contains the CRC of all bytes from the packet length to the audio encoding bytes. If the CRC check fails, the entire packet is discarded.

[0449] For the color map data field, each color map unit is a 3-byte value. The first byte of its value specifies the size of blue, the second byte specifies the size of green, and the third byte specifies the size of red. size. The color map size field specifies the number of 3-byte color map items in the color map data field. If a single color map cannot fit into a video data format and color map packet (Video Data Format and Color Map Packet), you can send out different color map data and color map offsets (Color Map Data and Color MapOffsets) in each packet. ) Multiple groups to specify the entire color map.

[0450] The 2-byte Color Map Data CRC field (Color Map Data CRC field) contains only color map data

CRCο If the CRC check fails, the color image data can still be used, but the CEC count is increased by one.

[0451] E. For reverse link encapsulation packets

[0452] The Reverse Link Flags field (1 byte) contains a set of flag bits to request information from the display. If a bit (bit 0 here) is set to one, the host uses the display performance packet to request specific information from the display. If the bit is zero, the host does not need information from the display. The remaining bits (bits 1 to 7 here) are reserved for future use and are set to zero.

[0453] The Reverse Rate Divisor field (1 byte) specifies the number of MDDI_Stb cycles that occur with respect to the reverse link data clock. The reverse link data clock is equal to the forward link data clock divided by twice the reverse rate divisor. The reverse link data rate is related to the reverse link data link and the interface type on the reverse link. For Type I interfaces, the reverse data rate is equal to the reverse link data clock. For Type II, Type III, and Type IV interfaces, the reverse data rate is equal to twice and four times the reverse link data clock, respectively. And eight times.

[0454] The Turn-Around 1 Length field (1 byte) specifies the total number of bytes allocated for Turn-Around 1. The recommended length of turn 1 is the number of bytes required by the MDDI_Data driver in the host to disable the output. This is based on the output disable time discussed above, the forward link data rate, and the forward link interface type selection used. A more complete description of the steering 1 setting is given above.

[0455] The Turn-Around 2 Length field (1 byte) specifies the total number of bytes allocated for the turn. The recommended length of Turn 2 is the number of bytes required by the MDDI_Data driver in the display to disable their output plus the round-trip delay. The description of the steering 2 setting is given above.

[0456] The Parameter CRC field (2 bytes) contains a 16-bit CRC of all bits from the packet length to the turn-around length. If the CRC fails the check, the entire packet is discarded.

[0457] The all zero field (AΠ Zero field) (1 byte) is set equal to zero, and is used to ensure that the MDDI_Data signal is in a zero state before the line driver is disabled in the first guard time period.

[0458] The diversion 1 field is used to establish the first diversion period. The number of bytes specified by the diversion length parameter is allocated by this field to allow the MDDI_Data line driver in the host to be disabled before the line driver in the client (display) is enabled. The host disables its MDDI_Data line driver during the turn to bit 0 of 1, and the client (display) immediately enables its line driver after turning to the last bit of 1. The MDDI_Stb signal works as if the steering cycle is all zero.

CN 101197652 Β

[0459] The Reverse Data Packets field contains a series of data packets sent from the client to the host. As mentioned earlier, filler packets are sent out to fill the remaining space not used by other packet types. [0460] The diversion 2 field is used to establish a second diversion period. The number of bytes specified by the diversion length parameter is allocated by this field.

[0461] The Driver Re-enable field uses 1 byte equal to zero to ensure all

The MDDI_Data signal is re-enabled before the packet length field of the next packet.

[0462] F. For display performance grouping

[0463] The Protocol Version field uses 2 bytes to specify the protocol version used by the client. The initial version is set equal to zero, and the minimum protocol version field (Minimum Protocol Versionfield) uses 2 bytes to specify the minimum protocol version that the client can use or interpret. The Display Data Rate Capability field (2 bytes) specifies the maximum data rate that the display can receive on the forward link of the interface, and is specified in the form of megabits per second (Mbps) . The Interface Type Capability field (1 byte) specifies the interface types supported on the forward and reverse links. This is currently represented by selecting bit 0, bit 1, or bit 2 to select the type II, type III, or type IV mode on the forward link, and bit 3, bit 4, or bit 5 to select the reverse link. Type II, Type III, or Type IV mode; bits 6 and 7 are inactive and set to zero. The Bitmap Width and Height field (2 bytes) specifies the width and height of the bitmap in pixels.

[0464] Monochrome Capability field (1 byte) is used for the number of resolution bits that can be displayed in a monochrome format. If the display does not use a monochrome format, the value is set to zero. Bits 7 to 4 are reserved for future use and are therefore set to zero. Bits 3 to 0 define the maximum number of gray-scale bits present in each pixel. These four bits can specify values from 1 to 15 for each pixel. If the value is zero, the monitor does not support the monochrome format.

[0465] The Colormap Capability field (3 bytes) specifies the maximum number of entries in the color map in the display. If the monitor cannot use the colormap format, the value is zero.

[0466] The RGB Capability field (2 bytes) specifies the number of bits of the resolution that can be displayed in the RGB format. If the monitor cannot use the RGB format, the value is zero. The RGB performance word consists of three separate unsigned values, among which: 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 redness of each pixel. Maximum number of bits. Currently, bits 15 to 12 are reserved for future use and are generally set to zero.

[0467] The YCr Cb Capability field (Y Cr Cb Capability field) (2 bytes) specifies the number of bits of the resolution that can be displayed in the Y Cr Cb format. If the display does not use the Y Cr Cb format, the value is zero. The Y CrCb performance word consists of three separate unsigned values, among which: 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, and bits 11 to 8 define the Y sample The maximum number of bits, and bits 15 to 12 are reserved for future use and are generally set to zero.

[0468] The Display Feature Capability Indicators field (Display Feature Capability Indicators field) uses 4 bytes, contains a set of flags, and is only a specific feature supported in the display. A bit set to 1 indicates that the performance is supported, and a bit set to zero indicates that the performance is not supported. The value of bit 0 indicates whether the Bitmap Block Transfer Packet is supported (packet type 71). The values of bits 1, 2, and 3 respectively indicate whether to support bitmap area filling grouping (packet type 72), bitmap pattern filling grouping (packing type 73), or communication link data channel grouping (packing type 74). The value of bit 4 indicates whether the display has the ability to make a color transparent, and the value of bit 5 and 6 indicate the display

Whether the display can receive video data or audio data in packet format, respectively, and the value of bit 7 indicates whether the display can send out the reverse link video stream from the camera. The values of bits 11 and 12 respectively indicate when the client communicates with the pointing device and can send and receive data packets from the pointing device, or when the client communicates with the keyboard and can send and receive keyboard data packets. Bits 13 to 31 are currently reserved for future use or alternative assignments useful to the system designer, and are generally set to zero.

[0469] The Display Video Frame Rate Capability field (1 byte) specifies the maximum video frame update performance of the display in frames per second. The host can choose to update the image at a rate lower than the value specified in this field.

[0470] The Audio Buffer Depth field (2 bytes) specifies the depth of the elastic buffer in the display dedicated to each audio stream.

[0471] The Audio Channel Capability field (2 bytes) contains a set of flags, indicating which audio channels are supported by the display (client). A bit set to 1 indicates that the channel is supported, and a bit set to zero indicates that the channel is not supported. The bit positions are assigned to different channels, so that the bit positions 0, 1, 2, 3, 4, 5, 6, and 7 represent the left front, right front, left rear, right rear, front center, subwoofer, left surround, and right, respectively. Surround channel. Bits 8 to 15 are currently reserved for future use and are generally set to zero.

[0472] The 2-byte Audio Sample Rate Capability field of the forward link includes a set of flags that indicate the audio sample rate performance of the client device. Bit positions are assigned to different rates, thus, bits 0, 1, 2, 3, 4, 5, 6, 7 and 8 are assigned to 8000, 16000, 24000, 32000, 40000, 48000, 11025, 22050, respectively per second And 44100 samples, of which bits 9 to 15 are reserved for future or alternative rate use as needed, so they are now set to "0". Setting one of these bits to "1" indicates that a specific sampling rate is supported, and setting one of these bits to "0" indicates that the sampling rate is not supported.

[0473] The Minimum Sub-frame Rate field (2 bytes) specifies the minimum sub-frame rate in frames per second. The minimum sub-frame rate enables the display status update rate to be sufficient to read certain sensors or pointing devices in the display.

[0474] The 2-byte microphone sampling rate performance field (Mic Sample Rate Capability field) of the reverse link includes a set of flags, indicating the audio sampling rate performance of the microphone in the client device. Due to MDDI, the client device microphone is configured to support a rate of at least 8000 samples per second. The bit positions of this field are assigned to different rates. Therefore, bits 0, 1, 2, 3, 4, 5, 6, 7 and 8 are used to represent 8000, 16000, 24000, 32000, 40000, 48000, 11025, 22050 and 44100 samples (SPS), of which bits 9 to 15 are reserved for future or alternative rate use, so they are now set to "0". Setting one of these bits to "1" indicates that a specific sampling rate is supported, and setting one of these bits to "0" indicates that the sampling rate is not supported. If no microphone is connected, the sampling rate performance bit for each microphone is set equal to zero.

[0475] The Content Protection Type field (2 bytes) contains a set of flags, indicating the type of digital content protection supported by the display. Currently, bit position 1 is used to indicate when DTCP is supported, bit position 1 is used to indicate when HDCP is supported, and bit positions 2 to 15 are reserved for the use of other protection schemes that are desired or available, so they are currently set to zero.

[0476] G. For display request and status grouping

[0477] The Reverse Link Request field (3 bytes) specifies the number of bytes required for the display in the reverse link in the next subframe to send information to the host.

[0478] The CRC Error Count field (1 byte) indicates how many CRC errors have occurred since the start of the media frame. The CRC count is reset when a subframe header packet with a subframe count of zero is sent. If the CRC is bad

The actual number of errors exceeds 255, and the value is saturated at 255.

[0479] The Capability Change field uses 1 byte to indicate the change in display performance. This can happen if the user connects an external device such as a microphone, keyboard, or display, or for some other reason. When bits [7:0] are equal to 0, the performance has not changed since the last time the display performance grouping was issued. However, when bits [7:0] are equal to 1 to 255, the performance has changed. The display performance grouping is checked to determine new display characteristics.

[0480] H. For bit block transmission packet

[0481] The Window Upper Left Coordinate X Value and Y Value field (Window Upper Left Coordinate X Value and Y Value field) uses 2 bytes, each of which specifies the X and Y values of the upper left coordinate of the window to be moved. The Window Width and Height field uses 2 bytes, each of which specifies the width and height of the window to be moved. The Window X Movement and Y Movement fields use 2 bytes, each of which specifies the number of pixels of the window that should be moved horizontally or vertically. A positive value of X moves the window to the right, a negative value makes it move to the left, a positive value of Y moves the window down, and a negative value makes it move up.

[0482] I. Fill grouping for bitmap area

[0483] The Window Upper Left Coordinate X Value and Y value fields (Window Upper Left Coordinate X Value and Y value fields) use 2 bytes, each of which specifies the X and Y values of the coordinates of the upper left corner of the window to be filled. Window Width and Height fields (2 bytes) specify the width and height of the window to be filled. The video data format descriptor field (Video Data Format Descriptorfield) (2 bytes) specifies the format of the pixel area padding value. The format is the same as the format of the same field in the video stream packet. The Pixel Area Fill Value field (4 bytes) contains the pixel value to be filled into the window specified by the above field. The format of the pixel is specified in the video data format descriptor field.

[0484] J. For bitmap hatch grouping

[0485] The Window Upper Left Coordinate X Value and Y value fields (Window Upper Left Coordinate X Value and Y value fields) use 2 bytes, each of which specifies the X and Y values of the coordinates of the upper left corner of the window to be filled. Window Width and Height fields (2 bytes each) specify the width and height of the window to be filled. Pattern Width and PatternHeightfields (2 bytes each) specify the width and height of the fill pattern respectively. The 2-byte Video Data Format Descriptor field (Video Data Format Descriptor field) specifies the format of the pixel area filling value. Figure 11 illustrates how the video data format descriptor is encoded. The format of the same field in the video stream packet is also the same.

[0486] The Parameter CRC field (2 bytes) contains all bytes from the packet length to the video format descriptor. If the CRC check fails, the entire packet is discarded. The pattern pixel data field (Pattern Pixel Data field) contains the original video information and specifies a fill pattern in the format specified by the video data format descriptor. The data is grouped into bytes, and the first pixel of each row must be byte-aligned. The hatch pattern data is sent one line at a time. The Pattern Pixel Data CRC field (2 bytes) only contains the CRC of the pattern pixel data. If the CRC fails, the pattern pixel data is still used, but the CRC error count should be increased by one.

[0487] K. Communication link data channel grouping

[0488] The Parameter CRC field (2 bytes) contains a 16-bit CRC of all bytes from the packet length to the video format descriptor. If the CRC check fails, the entire packet is discarded.

[0489] The Communication Link Data field contains the original data from the communication channel

CN 101197652 Β

data. This data is simply transferred to the computing device in the display.

[0490] The Communication Link Data CRC field (2 bytes) only contains the 16-bit CRC of the communication link data. If the CRC check fails, the communication link data is still used, but the CRC error count should be increased by one.

[0491] L. For interface type switching request packet

[0492] 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 way. If the value in bit 7 is equal to 0, the type switch request is used for the forward link, and if it is equal to 1, the type switch request is used for the reverse link. Bits 6 to 3 are reserved for future use and are generally set to zero. Bits 2 to 0 are used to define the type of interface to be used, where the value 1 represents the switch to type I mode, the value 2 represents the switch to type II mode, the value 3 represents the switch to type III mode, and the value 4 represents the switch to type Switching of IV mode. The values 0 and 5 to 7 are left to specify alternative modes or combinations of modes in the future.

[0493] M. Confirmation packet for interface type

[0494] The value of the Interface Type field (1 byte) confirms the new interface type to be used. The value in this field specifies the interface type in the following way. If bit 7 is equal to 0, the type switch request is used for the forward link, or if it is equal to 1, the type switch request is used for the reverse link. Bit positions 6 to 3 are currently reserved for assigning other interface types as needed, and are generally set to zero. However, bit positions 2 to 0 are used to define the type of interface to be used, where the value 0 indicates a negative confirmation, or the requested switch cannot be performed, and the values 1, 2, 3, and 4 indicate directions to type I, type II, and type III, respectively. And type IV mode switching. Values of 5 to 7 are reserved for future allocation of alternative modes as needed.

[0495] N. Switch grouping for execution type

[0496] The 1-byte Interface Type field (Interface Type field) indicates the new interface type to be used. The value in this field first specifies the interface type by using the value of bit 7 to determine whether the type switch is used for the forward or reverse link. The value "0" indicates that the type interface request is for the forward link, and the value "1" indicates that the interface request is for the reverse link. Bits 6 to 3 are reserved for future use, and are also generally set to a value of zero. However, bits 2 to 0 are used to define the type of interface to be used, where the values 1, 2, 3, and 4 indicate switching to Type I, Type II, Type III, and Type IV modes, respectively. The use of the values 5 to 7 of these bits is reserved for future allocation of alternative modes as needed.

[0497] 0. Enable grouping for the forward audio channel

[0498] The Audio Channel Enable Mask field (1 byte) contains a set of flags, indicating the audio channels to be enabled in the client. A bit set to 1 enables the corresponding channel, and a bit set to zero disables the corresponding channel. Bits 0 to 5 assign channels 0 to 5, respectively, for the left front, right front, left rear, right rear, front center, and subwoofer channels. Bits 6 and 7 are reserved for future use and are set to zero at the same time.

[0499] P. For reverse audio sampling rate grouping

[0500] The Audio Sample Rate field (1 byte) specifies the digital audio sampling rate. The value of this field is assigned to different rates, among which the values 0, 1, 2, 3, 4, 5, 6, 7 and 8 are used to specify 8000, 16000, 32000, 40000, 48000, 11025, 22050 and 44100 per second respectively Samples (SPS), values 9 to 254 are reserved for other rates as needed, so they are currently set to "0". The value 255 is used to disable reverse link audio streaming.

[0501] The Sample Format field (1 byte) specifies the format of the digital audio sample. When the bits [1:0] are equal to 0, the digital audio samples are in the linear format, when they are equal to 1, the digital audio samples are in the J-law format, and when they are equal to 2, the digital audio samples are in the A-law format. Bits [7:2] are reserved for alternative use as needed in the audio format allocation, and are generally set equal to zero.

CN 101197652 Β

[0502] Q. For digital content protection overhead grouping

[0503] The Content Protection Type field (1 byte) specifies the digital content protection method used. A value of 0 means Digital Transmission Content Protection (DTCP), and a value of 1 means High Bandwidth Digital Content Protection System (HDCP). The value range 2 to 255 is currently not specified, but is left to the use of alternative protection schemes as needed. The Content Protection Overhead Messages field (Content Protection Overhead Messages field) is a variable length field that contains content protection messages sent between the host and the client.

[0504] R. Enable grouping for transparent color

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

[0506] The Video Data Format Descriptor field (2 bytes) specifies the format of the pixel data padding value. Figure 11 illustrates how the video data format descriptor is encoded. This format is generally the same as the format of the same field in the video stream packet.

[0507] The Pixel Areal Fill Value field uses 4 bytes allocated for the pixel value to be filled in the window specified above. The value of this pixel is specified in the video data format descriptor field.

[0508] S. For round-trip delay measurement packet

[0509] The Parameter CRC field (2 bytes) contains a 16-bit CRC of all bytes from the packet length to the video format descriptor. If the CRC check fails, the entire packet is discarded.

[0510] The All Zero field (AΠ Zero field) (1 byte) contains zeros to ensure that all MDDI_Data signals are in the zero state before the line driver is disabled in the first guard time period.

[0511] The Guard Time 1 field (8 bytes) is used to allow the MDDI_Data line driver in the host to be disabled before enabling the line driver in the client (display). The host disables its MDDI_Data line driver during bit 0 of guard time 1, and the display enables its line driver immediately after the last bit of guard time 1.

[0512] The Measurement Period field is a 512-byte window used to allow the display to respond with 0xff, 0xff, and 0x0 at half the data rate used on the forward link. This rate corresponds to a reverse link rate divisor of 1. The display returns this response immediately at the beginning of the measurement period. The response will be received at the host just after the start of the first bit of the measurement period at the host, just at the round-trip delay of the link. The MDDI_Data line driver in the display is disabled immediately before and after the 0xff.0xff.0x0 response from the display.

[0513] The value in the Guard Time 2 field (2 bytes) allows the client MDDI_Data line driver to be disabled before enabling the line driver in the host. Guard time 2 always exists, but it is only needed when the round trip delay is the maximum amount that can be measured in the measurement period. The client disables its line driver during bit 0 of guard time 2, and the host enables its line driver immediately after the last bit of guard time 2.

[0514] The Driver Re-enable field (1 byte) is set equal to zero to ensure that all MDDI_Data signals are re-enabled before the packet length field of the next packet.

[0515] T. For Forward Link Offset Calibration Packet

[0516] The parameter CRC field (2 bytes) contains a 16-bit CRC of all bytes from the packet length (Packet Length) to the packet type (PacketType). If the CRC fails to check, the entire packet is discarded.

[0517] The calibration data sequence field (Calibrition Data Sequence field) contains a 512-byte data

Sequence, which causes the MDDI_Data signal to repeat during each data cycle. During the processing of the calibration data sequence, the MDDI host controller sets all MDDI_Data signals equal to the strobe signal. The display clock recovery circuit should only use MDDI_Stb instead of MDDI_Stb or MDDI_DataO to recover the data clock, while the calibration data sequence is received by the client display. According to the actual phase of the MDDI_Stb signal at the beginning of the calibration data sequence field, the calibration data sequence will generally be one of the following based on the interface type used when sending the packet:

[0518] Type I-0xaa, Oxaa... or 0x55, 0x55...

[0519] Type II-Oxcc, Oxcc... or 0x33, 0x33...

[0520] Type III-OxfO, OxfO... or OxOf, OxOf...

[0521] Type IV-Oxff, 0x00, Oxff, 0x00... or 0x00, Oxff, 0x00, Oxff...

[0522] Examples of possible MDDI_Data and MDDI_Stb waveforms for both Type-I and Type-II interfaces are illustrated in FIG. 62, respectively.

[0523] XVI. Conclusion

[0524] Although various embodiments of the present invention have been described above, it can be understood that they are given by way of example only, rather than limitation. Therefore, the broadness and scope of the present invention should not be limited by the above exemplary embodiments, but should only be defined in accordance with the appended claims and their equivalents.