High-speed data rate interface device and method

(Cross-reference of related applications) The patent application is entitled "Swithchable Threshold Differential Interface" filed on June 4, 2004, both delegated to and expressly incorporated herein by reference. Priority to patent provisional application No. 60 / 577,500 to be filed and patent provisional application No. 60 / 577,793 entitled "Swithchable Threshold Differential Interface" filed on June 7, 2004. Claim priority over the issue.

Embodiments of the invention in the present disclosure are digital signal protocols, processes, including integrated circuits and one or more electronic devices for communicating or transferring signals at high data rates between a host device and a client device. , Method steps, and equipment. More specifically, the present disclosure uses a low power, high data rate transfer mechanism with internal and external device applications to multimedia from a host or controller device to a client device for presentation or display to end users. And other types of techniques for transferring digital signals.

Computers, electronic game products and various video technologies (eg DVDs and high resolution VCRs) are becoming increasingly high resolution when containing several types of text, still images, video images, video-on-demand images, and Significant progress has been made in the last few years to prepare graphic images for presentations to end users of such devices. Similarly, these advances have forced the use of higher resolution electronic displays such as high resolution video monitors, HDTV monitors, or special image projection elements. Combining such visual images with high resolution or high quality audio data, such as when using other devices related to CD audio playback, DVD, surround sound, and audio signal output, is more realistic for the end user. Stick Content Used to create a rich or true multimedia experience.

In addition, highly mobile high quality sound systems such as MP3 players and music transport mechanisms have been developed for audio-only presentations to end users. This has resulted in raising the expectations of typical users of commercial electronics that are now accustomed to, or expecting, high quality or quality production from computers to televisions and telephones. In addition, various portable devices and wireless receivers are currently proposed for real-time or time-delayed playback of images from content providers such as telephones or cinemas, and sports franchises or facilities.

In typical video presentation scenarios that require electronic products, video data is transferred using previous techniques at speeds, typically about 1 to 10 kilobits per second, at best called low or medium speeds. To. This data is then either buffered for delayed (later) reproduction on the desired display device or stored in temporary or long-term storage. For example, an image is transferred "whole" or using the Internet using a program resident in a computer with a modem or Internet connection device to receive or transmit data useful for representing the image digitally. Good. Similar transfers can be made using a wireless device such as a wireless modem or wireless personal data assistant (PDA) or a portable computer with a wireless telephone.

Once received, the data is stored in a memory element, storage circuit or memory element such as RAM or flash memory, including an internal storage device or an external storage device such as a small hard disk, for playback. Depending on the amount of data and the image resolution, playback may start relatively quickly or be presented with a longer delay. That is, in some examples, the image presentation allows some real-time playback for very small or low resolution images that do not require a lot of data or use some type of buffering, as a result. Some data is presented after a short delay while more data is being transferred. Once the presentation has begun, the transfer is reasonably trustworthy to the end user of the display device, provided that the transfer link is uninterrupted or that there is no interference from other systems or users with respect to the transfer channel being used. If multiple users share a single communication path, such as a wired Internet connection, the transfer can be interrupted or slower than desired.

The data used to create either still images or video is often Jeepeg (Joint Photographic Experts Group) (JPEG), Mpegg (JPEG), to accelerate the transfer of data over communication links. Compressed using one of several well-known techniques, such as Motion Picture Experts Group) (MPEG), and techniques specified by well-known standards organizations or companies in the media, computer, and other telecommunications industries. To. This allows faster transfer of images or data using a smaller number of bits to transfer a predetermined amount of information.

Once the data is transferred to a "local" device such as a computer or other recipient device that has a storage mechanism such as memory or a magnetic storage element or optical storage element, the resulting information is decompressed (or a special decoding player). (Played using), decrypted if necessary, and prepared for the appropriate presentation based on the corresponding available presentation resolutions and control elements. For example, a typical computer video resolution with respect to a screen resolution of X pixels x Y pixels is generally available in a variety of other resolutions as desired or as desired, but is typically 480 pixels x 640. It ranges from as low as a pixel to 600x800 to 1024x1024.

Image presentations are the ability to manipulate images with respect to image content and certain predetermined color levels or color gradations (bits per pixel used to produce color) and brightness of a default video controller, and additional utilization. It is also affected by the overhead bit that is being used. A typical computer presentation, for example, will encounter other values, but will expect about 8 to 32 or more bits per pixel to represent a variety of colors (shades and hues).

From the above values, it can be seen that the default screen images each require a data transfer of about 2.45 megabits (Mb) to about 33.55 Mb in the range of lowest to highest typical resolutions and depths. When viewing a video or video type image at a rate of 30 frames per second, the amount of data required is approximately 73.7 to 1,006 megabits per second, or 9.21 to 125.75 megabytes per second. In addition, it may be desirable to present audio data along with images for multimedia presentations or as a separate high resolution audio presentation such as CD quality music. Interactive commands, controls, or additional signals that process the signal may also be utilized. Each of these options adds even more data to be transferred. Higher definition (HD) television and movie recordings may also add more data and control information. In any case, when you want to transfer high-quality or high-resolution image data and high-quality audio information or data signals to the end user to create a content-rich experience, presentation elements and such types High data transfer rate links are required between source or host devices that are configured to provide data.

Data rates of approximately 115 kilobytes (KBps) or 920 kilobits (Kbps) per second can be routinely processed by modern serial interfaces. Other interfaces, such as the USB serial interface, handle data transfers at speeds as high as 12Mbps, and special high-speed transfers such as transfers configured using the Institute of Electrical and Electronics Engineers (IEEE) 1394 standard are approximately 100MBps to 400MBps. It is done at the speed of. Unfortunately these speeds are mentioned above and are intended for use with future wireless data devices and services to provide high resolution, content-rich output signals for driving portable video displays or audio devices. It does not reach the desired high-speed data rate. This includes business computers and other presentations, gaming machines, etc. In addition, these interfaces require the use of a significant amount of host or system and client software to operate. The software protocol stack also creates an undesirably large amount of overhead, especially when intended for mobile wireless devices or telephone applications. Such devices have strict memory and power consumption limits as well as the computational power already imposed. In addition, some of these interfaces utilize complex connectors that are too heavy for highly aesthetically oriented mobile applications, add unsatisfactory bulky cables, and add cost, that is, simply too much power.

There are other known interfaces such as analog video graphics adapter (VGA), digital video interactive (DVI) or gigabit video interface (GVIF) interfaces. The first two of these are parallel interfaces that process data at even faster transfer rates, but also utilize heavy cables and consume large amounts of power, or about a few watts. None of these properties can be modified for use with portable consumer electronics. The third interface also consumes too much power and uses expensive or bulky connectors.

For some of the interfaces and other very fast data systems / protocols or transfer mechanisms associated with data transfer for fixed installation computer equipment, there is another major drawback. Dealing with the desired data transfer rate also requires operation at high power and / or high current levels. This greatly reduces the practicality of such techniques for highly mobile consumer goods.

In general, dealing with such data transfer rates using alternatives such as fiber optic connections and transfer elements is with much higher complexity than is desired for truly commercial consumer goods. It also requires many additional converters and elements that are costly. In addition to the generally expensive properties of optics, their power requirements and complexity hinder their general use for lightweight, low power portable applications.

What the industry has lacked for portable, wireless or mobile applications, whether it's voice, video, or multimedia-based, is for highly mobile end users. Is a technique for providing a high quality presentation experience. That is, when using a portable computer, radiotelephone, PDA or other highly mobile communication device or device, the current video presentation system or device and audio presentation system or device in use is simply the desired height. Unable to deliver output at quality level. The perceived quality that is often lacking is the result of the unobtainable high-speed data rates required to transfer high-quality presentation data. This is the transfer to more efficient, advanced or feature laden external devices for presentations to end users, and inside mobile devices such as computers and game machines and wireless devices such as mobile phones. It may also include transfers between the host and client.

In the latter case, significant progress has been made in adding even higher resolution built-in video screens and other special input and / output devices and connections to wireless devices such as so-called third generation phones, and to so-called laptop computers. there were. However, including bridges over rotary hinges or hinge-like structures that attach or connect video screens or other elements to the main enclosure, where the host and / or various other control and output components are present. Connect with a good built-in data bus. Generally, there are high bandwidth or high throughput interfaces. As an example, it is very difficult to build a high throughput data transfer interface using traditional techniques, for example, which may require up to 90 conductors to achieve the desired throughput in a radiotelephone. Is. Current challenges generally involve applying parallel type interfaces with relatively high signal levels. This makes the interconnect more expensive and less reliable, while potentially producing radiated emissions that can interfere with device functionality. This presents many manufacturing, cost, and reliability issues that must be overcome.

Such issues and requirements are, for example, the addition of communication or computational equipment to electrical equipment and other consumer equipment to provide advanced data capabilities, the Internet and data transfer connections or built-in entertainment. Also found in fixed location systems. Another example would be an airplane and a bus with individual video and audio presentation screens mounted on the seat back. However, in these situations it is often better to position the main storage, processing and communication control elements some distance from the visible screen or audio output with the interconnect link or channel for the presentation of information. It is more convenient, efficient, and easily practical. This link requires processing large amounts of data to achieve the desired throughput as described above.

Therefore, a new transfer mechanism is needed to increase the data throughput between the host device that provides the data and the client display device or element that presents the output to the end user.

Applicants have introduced new transfer mechanisms to U.S. Patent No. 6,760,772, which was issued to Zou et al. On July 6, 2004, and U.S. Patent Application No. 10 / 020,520, which was filed on September 6, 2002. Proposed in 10 / 236,657. Both of these are entitled "Generating And Implementing A Communication Protocol And Interface For High Data Rate Signal Transfer" and are delegated to and incorporated herein by reference to the assignee of the present invention. Also, "Generating And Implementing A Signal Protocol And Interface For Higher Data" There are also US patent applications 10 / 860,116, entitled Rates , filed June 2, 2004. The techniques described in those applications are transfer rates for large amounts of data in high-speed data signals. However, the ever-increasing demand for data rates, especially for video presentations, continues to grow. Even with other ongoing developments in data signaling technology, transfer rates and communication links are still even faster. Efforts must be made to improve efficiency and stronger communication links, and therefore continue to develop new or improved transfer mechanisms needed to increase the data throughput between host and client devices. There is a need to do.

The above-mentioned drawbacks and others present in the technology are due to embodiments of the present invention in which new protocols and data transfer means, methods and mechanisms have been developed to transfer data between a host device and a recipient client device at high speed. Be dealt with.

An embodiment of the present invention utilizes a plurality of or a series of packet structures to form a communication protocol for communicating a preselected set of digital control and presentation data between a host device and a client device. In the above, the purpose is a mobile data digital interface (MDDI) for transferring digital data between a host device and a client device at high speed. The signal communication protocol or link layer is used by the physical layer of the host or client link controller, receiver, or driver. At least one link controller or driver residing within the host device is coupled to the client device through a communication path or link to generate, transmit, and receive packets that form a communication protocol, and one or more. It is configured to form digital presentation data in different types of data packets. The interface provides bidirectional transfer of information between the host and client, which can reside within one common overall housing or support structure.

Implementations are generally all digital in nature, with the exception of differential drivers and receivers that can be easily implemented on digital CMOS chips, require as few signals as 6, and are convenient for system designers. Works at almost all data rates. Simplified physical layer and link layer protocols facilitate integration, and this simplicity with the addition of high variation states allows portable systems to have very low system power consumption.

To be useful for use and acceptance, the interface costs little to the device and can power the display through an interface that uses standard battery voltage, while consuming very little power and a pocket-sized form factor. Can deal with devices that have The interface is scalable to support resolutions above HDTV, supports simultaneous stereo video and 7.1 audio for display measures, performs conditional updates to any screen area, and supports multiple data types in both directions. To do.

In a further aspect of the embodiment of the invention, at least one link controller, receiver, device, or driver is placed within the client device and coupled to the host device through a communication path or link. The client link controller is also configured to generate, transmit, and receive packets that form a communication protocol, and to form digital presentation data in one or more types of data packets. Generally, the host or link controller utilizes a state machine to process data packets used in commands or certain types of signal creation and query processing, but the data used in communication protocols and less complex. A slower general purpose processor can be used to manipulate some of the packets that are not available. The host controller includes one or more differential line drivers. The client receiver, on the other hand, comprises one or more differential line receivers coupled to the communication path.

Packets are grouped together within a media frame that is communicated between a host device and a client device that have a predetermined fixed length, along with a predetermined number of packets that have various variable lengths. Each packet has a packet length field, one or more packet data fields, and a cyclic redundancy check field. The subframe header packet is forwarded or placed at the beginning of the forwarding of other packets from the host link controller. One or more video stream packets and voice stream packets are communication protocols for transferring video type data and voice type data from host to client, respectively, over forward links for presentations to client device users. Used by. One or more reverse link encapsulation type packets are used by the communication protocol to transfer data from the client device to the host link controller. These transfers in some embodiments include the transfer of data from an internal controller having at least one MDDI device to the internal video screen. Other embodiments include transfers to internal sound systems and transfers from various input devices, including joysticks and complex keyboards, to internal host devices.

Filler packets are generated by the host link controller to occupy a period of forward link transmission with no data. Multiple other packets are used by the communication protocol to transfer video information. Such packets include colormap packets, bitblock forwarding packets, bitmap area fill packets, bitmap pattern fills, and transparent color enable packets. User-defined stream packets are used by communication protocols to transfer interface user-defined data. Keyboard data and pointing device data type packets are used by communication protocols to transfer data to and from the user input device associated with the client device. Link-shutdown packets are used by communication protocols to terminate the transfer of data in either direction on the communication path.

Display power status packets are specific display controller hardware when a client such as a display is not used or is currently actively used to minimize drainage or system power consumption on system resources. Generated to provide a structure, means, or method for putting the ware into a low power state. In one embodiment, the client uses bit 9 of the client feature function indicator of the client function packet to indicate the ability to respond to a display power status packet.

One embodiment format for display power status packets. This type of packet is configured to have a packet length field, a packet type field, a hClientID field, a power status field, and a Cyclic Redundancy Check (CRC) field. This type of packet is commonly identified as a Type 75 field within a 2-byte type field. The 2-byte hClientID field contains the value or information reserved for the ClientID. The power state field identifies the information used to bring a particular display to a particular power state according to the value of a preselected bit. The 2-byte CRC field identifies or contains the CRC of all bytes in the packet, including the packet length.

The communication path usually includes or utilizes a series of four or five or more leads and a cable with one shield. In addition, printed wires or conductors can be used as desired, some of which are present on flexible substrates.

The host link controller requests display capability information from the client device to determine what kind of data and data type the client can handle through the interface. The client link controller uses at least one client functional packet to convey display capability or presentation functionality to the host link controller. Multiple transfer modes are used by the communication protocol, each allowing the transfer of up to a different number of bits of data in parallel over a predetermined period, each mode selected by negotiation between the host link controller and the client link controller. It is possible. These transfer modes are dynamically adjustable during the transfer of data, and the same modes used for forward links need not be used for reverse links.

In another aspect of some embodiments of the invention, the host device comprises a wireless communication device such as a radiotelephone, a wireless PDA, or a portable computer having a wireless modem arranged therein. A typical client device includes a microdisplay device and / or a portable video display such as a portable audio presentation system. In addition, the host may use storage means or elements for storing presentation data or multimedia data that is transferred to be presented to the client device user.

In yet another embodiment of some embodiments, the host device resides in a portable electronic device such as a wireless communication device such as a radiotelephone, wireless PDA or portable computer, with a driver, as described below. It is equipped with a controller or a communication link control device. A typical client device in this configuration is coupled to a client circuit or integrated circuit, or host, resides within the device, and has a built-in video display such as a high resolution screen for a mobile phone, and / or a portable audio presentation. It comprises a module in some kind of alternative input system or device that is coupled to the system.

Not only the various structures and operations of the present invention, but also additional features and advantages of the present invention are described in detail with reference to the accompanying drawings. In the figure, similar reference numbers generally indicate the same, functionally similar, and / or structurally similar elements or processing steps.

<figref num="1A">FIG. 5 illustrates a basic environment in which embodiments of the present invention may operate, including the use of a microdisplay device or projector in connection with a portable computer or other data processing device.</figref><figref num="1B">FIG. 6 illustrates a basic environment in which embodiments of the present invention may operate, including the use of audio presentation elements used in connection with microdisplay devices or projectors, and wireless transceivers.</figref><figref num="2A">FIG. 5 illustrates a basic environment in which embodiments of the present invention may operate, including the use of a built-in display or audio presentation device used in a portable computer.</figref><figref num="2B">FIG. 6 illustrates the basic environment in which the present invention may operate, including the use of built-in display elements or audio presentation elements used in wireless transceivers.</figref><figref num="3">FIG. 5 illustrates the overall concept of a mobile digital data interface for host-client interconnection.</figref><figref num="4">It is a figure which shows the structure of the packet which is effective for realizing the data transfer from a client device to a host device.</figref><figref num="5">It is a figure which shows the use of the MDDI link controller, and the type of the signal passed between a host and a client on a physical data link lead wire for type I interface.</figref><figref num="6">It is a figure which shows the use of the MDDI link controller, and the type of the signal passed between a host and a client on a physical data link lead wire for type 2 interface, type 3 interface, and type 4 interface.</figref><figref num="7">It is a figure which shows the structure of a frame and a subframe used to realize an interface protocol.</figref><figref num="8">It is a figure which shows the general structure of the packet used to realize an interface protocol.</figref><figref num="9">It is a figure which shows the format of a subframe header packet.</figref><figref num="10">It is a figure which shows the format and content of a filler packet.</figref><figref num="11">It is a figure which shows the format of a video stream packet.</figref><figref num="12">It is a figure which shows the format and contents of the video data format descriptor used in FIG.</figref><figref num="13">It is a figure which shows the use of the pack format and the unpack format of data.</figref><figref num="14">It is a figure which shows the format of the voice stream packet.</figref><figref num="15">It is a diagram showing the use of byte-aligned PCM format and packed PCM format for data.</figref><figref num="16">It is a figure which shows the format of the stream packet defined by a user.</figref><figref num="17">It is a figure which shows the format of a color map packet.</figref><figref num="18">It is a figure which shows the format of the reverse link encapsulation packet.</figref><figref num="19">It is a figure which shows the format of a client function packet.</figref><figref num="20">It is a figure which shows the format of a keyboard data packet.</figref><figref num="21">It is a figure which shows the format of a pointing device data packet.</figref><figref num="22">It is a figure which shows the format of the link shutdown packet.</figref><figref num="23">It is a figure which shows the format of a client request status packet.</figref><figref num="24A">It is a figure which shows the format of a bit block transfer packet.</figref><figref num="24B">It is a figure which shows the data flow of the typical raster operation which is effective for carrying out embodiment of this invention.</figref><figref num="25">It is a figure which shows the format of a bitmap area fill packet.</figref><figref num="26">It is a figure which shows the format of a bitmap pattern fill packet.</figref><figref num="27">It is a figure which shows the format of a read frame buffer packet.</figref><figref num="28">It is a figure which shows the format of a display power status packet.</figref><figref num="29">It is a figure which shows the format of the execution type handoff packet.</figref><figref num="30">It is a figure which shows the format of the forward voice channel enable packet.</figref><figref num="31">It is a figure which shows the format of the reverse voice sample rate packet.</figref><figref num="32">It is a figure which shows the format of the digital content protection overhead packet.</figref><figref num="33">It is a figure which shows the format of a transparent color and a mask setting packet.</figref><figref num="34">It is a figure which shows the format of the round-trip delay measurement packet.</figref><figref num="35">It is a figure which shows the timing of the event between the round-trip delay measurement packets.</figref><figref num="36">It is a figure which shows the sample implementation of the CRC generator and checker which is effective for realizing this invention.</figref><figref num="37A">It is a figure which shows the timing of the CRC signal of the apparatus of FIG. 36 at the time of transmitting a data packet.</figref><figref num="37B">It is a figure which shows the timing of the CRC signal of the apparatus of FIG. 36 at the time of receiving a data packet.</figref><figref num="38A">It is a figure which shows the typical behavior of the special low power difference receiver compared with the standard difference receiver.</figref><figref num="38B">It is a figure which shows the typical behavior of the special low power difference receiver compared with the standard difference receiver.</figref><figref num="39A">It is a figure which shows the processing step for a typical service request without a conflict.</figref><figref num="39B">It is a figure which shows the processing step of a typical service request which was confirmed after the link restart sequence started, which conflicts with the link start.</figref><figref num="40">It is a figure which shows how the data sequence can be transmitted using DATA-STB coding.</figref><figref num="41">It is a figure which shows the effective network for generating a DATA signal and STB signal from input data in a host, and then recovering data in a client.</figref><figref num="42A">It is a figure which shows the driver which transfers the signal which is effective for realizing one Embodiment, and the termination register.</figref><figref num="42B">It is a figure which shows the block diagram of the differential current mode driver.</figref><figref num="43A">It is a figure which shows the timing to enter hibernation.</figref><figref num="43B">It is a figure which shows the step and the signal level used by a host to provide a service from a host.</figref><figref num="43C">FIG. 5 shows the steps and signal levels used by a client to guarantee service from a host and by a host to provide such service.</figref><figref num="44">It is a figure which shows the relative interval between transitions in Data0, another data line (DataX), and a strobe line (Stb).</figref><figref num="45">FIG. 5 shows the presence of response delays that can occur when a host disables a host driver after packet forwarding.</figref><figref num="46">FIG. 5 illustrates the presence of response delays that can occur when a host enables a host driver to forward packets.</figref><figref num="47">It is a figure which shows the leak current analysis.</figref><figref num="48">It is a figure which shows the relative timing relation, and the switching characteristic of the enable time and disable time of a host output and a client output.</figref><figref num="49">It is a high-level diagram of signal processing steps and conditions that can achieve synchronization using a state machine.</figref><figref num="50">It is a figure which shows the typical delay amount which is encountered about the signal processing in the forward path and the reverse path in the system using MDDI.</figref><figref num="51">It is a figure which shows the round-trip delay measurement of a boundary.</figref><figref num="52A">It is a figure which shows the reverse link data rate change.</figref><figref num="52B">It is a figure which shows the example of the improved reverse data sampling.</figref><figref num="53">It is a figure which shows the graphic representation of the value of the reverse velocity divisor vs. forward link data rate.</figref><figref num="54A">It is a figure which shows the step which is taken by the operation of an interface.</figref><figref num="54B">It is a figure which shows the step which is taken by the operation of an interface.</figref><figref num="55">It is a figure which shows the outline of the interface device processing packet.</figref><figref num="56">It is a figure which shows the format of the forward link packet.</figref><figref num="57">It is a figure which shows the typical value of the propagation delay and distortion of the type I link interface.</figref><figref num="58">It is a figure which shows the Data, Stb, and clock recovery timing of the type I link for exemplary signal processing through an interface.</figref><figref num="59">It is a figure which shows the typical value for the propagation delay and distortion of the type 2, type 3 or type 4 link interface.</figref><figref num="60A">It is a diagram showing various possibilities for the ideal early data signal and the timing of MDDI_Stb with respect to each other.</figref><figref num="60B">It is a diagram showing various possibilities for the ideal slow data signal and the timing of MDDI_Stb with respect to each other.</figref><figref num="60C">It is a diagram showing various possibilities for the ideal slow data signal and the timing of MDDI_Stb with respect to each other.</figref><figref num="61">The figure which shows the typical type 2 forward link with the delay distortion compensation circuit for typical signal processing through an interface.</figref><figref num="62A">It is a figure which shows the possible MDDI_Data waveform and MDDI_Stb waveform for the type 1 interface.</figref><figref num="62B">It is a figure which shows the possible MDDI_Data waveform and MDDI_Stb waveform for the type 2 interface.</figref><figref num="63">FIG. 5 shows a high-level diagram of alternative signal processing steps and conditions that can be synchronized using a state machine.</figref><figref num="64">It is a figure which shows the relative timing during a series of clock cycles, and the timing of various reverse link packet bits and devalues.</figref><figref num="65">It is a figure which shows the exemplary error code transfer processing.</figref><figref num="66">It is a figure which shows the device which is effective for error code transfer processing.</figref><figref num="67A">It is a figure which shows the error code transfer processing for code overload.</figref><figref num="67B">It is a figure which shows the error code transfer processing for code reception.</figref><figref num="68A">It is a figure which shows the processing step for the wake-up started by a host.</figref><figref num="68B">It is a figure which shows the processing step for the wake-up which is started by a client.</figref><figref num="68C">It is a figure which shows the processing step for the wake-up which is started by a host and a client in a race condition.</figref><figref num="69">It is a figure which shows the format of the request VCP characteristic packet.</figref><figref num="70">It is a figure which shows the format of a VCP characteristic response packet.</figref><figref num="71">It is a figure which shows the format of the VCP feature response packet list.</figref><figref num="72">It is a figure which shows the format of a set VCP characteristic response packet.</figref><figref num="73">It is a figure which shows the format of the request valid parameter packet.</figref><figref num="74">It is a figure which shows the format of a valid parameter response packet.</figref><figref num="75">It is a figure which shows the format of the scaled video stream function packet.</figref><figref num="76">It is a figure which shows the format of the scaled video stream setup packet.</figref><figref num="77">It is a figure which shows the format of the scaled video stream acknowledgment packet.</figref><figref num="78">It is a figure which shows the format of the scaled video stream packet.</figref><figref num="79">It is a figure which shows the format of a special status request packet.</figref><figref num="80">It is a figure which shows the format of a valid status response list packet.</figref><figref num="81">It is a figure which shows the format of a personal display function packet.</figref><figref num="82">It is a figure which shows the element at the point of the field curvature list.</figref><figref num="83">It is a figure which shows the format of a client error report packet.</figref><figref num="84">It is a figure which shows the format of an error report list item.</figref><figref num="85">It is a figure which shows the format of a client identification packet.</figref><figref num="86">It is a figure which shows the format of the alternative display function packet.</figref><figref num="87">It is a figure which shows the format of a register access packet.</figref><figref num="88A">It is a figure which shows the use of two display buffers to reduce a visible artifact.</figref><figref num="88B">It is a figure which shows the use of two display buffers to reduce a visible artifact.</figref><figref num="88C">It is a figure which shows the use of two display buffers to reduce a visible artifact.</figref><figref num="89">It is a figure which shows two buffers with display refresh faster than image transfer.</figref><figref num="90">It is a figure which shows two buffers with display refresh slower than image transfer.</figref><figref num="91">It is a diagram showing two buffers with display refresh that is much faster than image transfer.</figref><figref num="92">It is a figure which shows three buffers with display refresh faster than image transfer.</figref><figref num="93">It is a figure which shows three buffers with display refresh slower than image transfer.</figref><figref num="94">It is a figure which shows one buffer with display refresh faster than image transfer.</figref><figref num="95">It is a figure which shows the host-client connection through a daisy chain and a hub.</figref><figref num="96">It is a figure which shows the client device connected through the combination of a hub and a daisy chain.</figref><figref num="97">It is a figure which shows the color map.</figref><figref num="98">It is a figure which shows the use of a plurality of clients in a data transfer configuration.</figref><figref num="99">It is a figure which shows the use for the use of the unterminated stub on the transmission line with two clients.</figref>

I. Overview A general object of the present invention is to use a "serial" type data link or channel as described below to achieve high speed or very high speed on a short distance communication link between a host device such as a display element and a client device. It is to provide a mobile display digital interface (MDDI) that provides a cost-effective, low-power transfer mechanism that enables high-speed data transfer. The mechanism is thinly flexible with a small connector that is particularly effective in connecting an internal (inside the housing or support frame) display or output element or device, or input device to a central controller, or communication element or device. Useful for cable implementation. In addition, this connection mechanism connects an external display element or device, such as a wearable microdisplay (goggles or projector) or other type of visual, audio, or sensing information display device, to a portable computer, wireless communication device, or entertainment device. Very useful to do.

The terms mobile and display are related to protocol naming, but it is understood that this is for convenience only in that it has a standard name that is easily understood by those skilled in the art working with interfaces and protocols. There must be. Related to the Video Electronics Standards Association (VESA) standard and various applications of that standard. However, after considering the embodiments presented below, many non-mobility, non-display related applications will benefit from the application of this protocol and the resulting interface structure, resulting in an interface structure or transfer. It will be readily appreciated that the mechanisms, and MDDI labels, are not intended to imply the nature or effectiveness of the invention, or restrictions on various embodiments.

The advantages of embodiments of the present invention are techniques for data transfer that are highly flexible, yet low complexity, low cost, reliable, well adapted to the environment and very robust. It is a point to be provided.

Embodiments of the invention can be used in a wide variety of situations, typically for communicating or transferring large amounts of data for audio, video or multimedia applications from a host or source device, in which case such data , Generated and manipulated or processed to transfer to a specific device, for example, or stored at high speed to a client or receiving device such as a video display, projection element, audio speaker, or other display device. To. Typical applications described below are from any of the portable computers or radiotelephones or modems to wearable microdisplay appliances such as small video screens or goggles or helmets containing small projection lenses and screens, or The transfer of data from the host to the client device within such a component. A processor as well as from a variety of internal input devices, or external input devices that utilize clients, to hosts located internally (located within the housing or support structure of the same device) or connected by cables or conductors. Or a built-in screen or other presentation element from the controller.

The properties or attributes of MDDI are such that they are unrelated to any particular display or presentation technique. This is an extremely flexible mechanism for transferring data at high speed regardless of the internal structure of the data or the functional aspect of the data or commands it implements. This allows the combined audio and video, or joystick, to adapt to the specificity of a particular client device, such as a unique display request for a particular device, or for some audiovisual (AV) systems. , The timing of transferred data packets can be adjusted to meet the requirements of specific input devices such as touchpads. As long as the selected protocol is followed, the interface is very agnostic to display elements or client devices. In addition, aggregate serial link data, or data rates, can vary by orders of magnitude, allowing communication system or host device designers to optimize costs, power requirements, client device complexity, or client device update speeds. ..

Data interfaces are currently presented primarily for use in transferring large amounts of high speed data over "wired" signal links or small cables. However, in some applications, wireless links, including optical-based links, may also be utilized if configured to use the same packets and data structures developed for the interface protocol, with sufficiently low power. The desired level of transfer can be sustained at consumption or complexity that remains practical.

II. Environment Typical applications are shown in FIG. 1A showing a portable computer or laptop computer 100 communicating data with display devices 104 and 106 and a radiotelephone or PDA device 102, along with audio reproduction systems 108 and 112, respectively. It can be seen in Figure 1B. Further, FIG. 1A shows a potential connection to a large display or screen 114 or image projector 116 that can also be connected to the wireless device 102, which is shown in one figure for clarity only. The radio device has previously stored a particular amount of multimedia type data in a storage element or storage device for later presentation for display and / or listening by the end user of the radio device, which is currently capable of receiving data. A typical wireless device is mostly used for voice and simple text communication, so it has a slightly smaller display screen and a simple voice system (speaker) to communicate information to the user of device 102. ..

The computer 100 has a much larger screen, but still has an unsuitable external sound system, which is inferior to other multimedia presentation devices such as high definition televisions or movie screens. Computer 100 is used for illustration purposes, and other types of processors, interactive video games or consumer electronics can also be used with the present invention. The computer 100 can utilize wireless models or other built-in devices for wireless communication, or can connect to such devices using cables or wireless links as desired, but is not limited thereto.

This makes presentations of more complex or "rich" data a valid or enjoyable experience. Therefore, the industry is developing other mechanisms and devices to present information to end users and provide the minimum level of desired enjoyment or positive experience.

As mentioned above, multiple types of display devices have been developed or have been developed to present information to the end user of device 100. For example, one or more companies have developed a set of wearable goggles that project an image in front of the device user to present a visual display. When properly placed, such a device effectively "projects" a "virtual image" that is much larger than the element that provides the visual output, as perceived by the user's eyes. That is, a very small projection element allows the user's eyes (s) to "see" an image on a much larger scale than is possible on a typical liquid crystal display (LCD) screen or the like. By using larger virtual screen images, it is also possible to use images with much higher resolution than is possible with a more limited LCD screen display. Other display devices may include, but will not be limited to, small LCD screens or various flat panel display elements, projection lenses and display drivers for projecting images onto surfaces and the like.

Connected to or connected to wireless device 102 or computer 100 to transfer signals to another user, or instead to transfer signals somewhere else or to present output to another device that stores them, or of wireless device 102 or computer 100. There may also be additional elements associated with use. For example, the data may be stored in flash memory in optical form, for example using a writable CD medium, or in a magnetic medium such as in a magnetic tape recorder and similar equipment for later use.

In addition, many radios and computers now have built-in MP3 music decoding capabilities as well as other advanced sound decoders and sound systems. Portable computers utilize CD playback and DVD playback functions in principle, and some also have a small dedicated flash memory reader for receiving pre-recorded audio files. The problem with having such a feature is that digital music files promise a highly feature-rich experience, only if the decryption and playback processes can be aligned. The point is to do. The same applies to digital video files.

An external speaker 114, which could be added with additional elements such as a subwoofer, or "surround sound" speakers for front and rear sound projection to assist audio reproduction, is shown in Figure 1A. At the same time, the speaker or earphone 108 is shown as built into the support frame or mechanism of the microdisplay device of FIG. 1B. Other audio or sound reproduction elements can be used, including power amplifiers or audio shaping devices, as will be known.

In any case, as described above, transferring high quality or high resolution image data and high quality audio information or data signals from the data source to the end user over one or more communication links 110. Higher data rates are required when desired. That is, the transfer link 110 is clearly a potential bottleneck in data communication as described above, limiting system performance because current transfer mechanisms usually do not achieve the desired high data rates. .. For example, as mentioned above, in the case of higher resolution such as 1024 pixels x 1024 pixels, if you use 24 to 32 bits of color gradation per pixel and a data rate of 30 fps, the data rate will exceed 755 Mbps or more. You can get closer. In addition, such images may be presented as part of a multimedia presentation containing audio data and possibly interactive games or communications, or a variety of commands, controls or signals, quantity or data. And further increase the data rate.

Fewer cables or interconnects required to establish a data link also means that the mobile device associated with the display is more accessible and likely to be adopted by a larger user base. it is obvious. This is especially true when multiple devices are commonly used to establish a complete audiovisual experience, and more particularly as the quality level of displays and output devices increases.

Another typical application for the aforementioned and other improvements in video screens and other output and input devices, along with audio reproduction systems 136 and 146, communicate data with "built-in" displays 134 and 144, respectively. A portable computer or laptop computer 130 and a wireless telephone or PDA device 140 are shown in FIGS. 2A and 2B.

In Figures 2A and 2B, small cut-out internal views of the overall electronic device or product make them video display elements or corresponding clients across some known type of rotary connection used throughout the electronics industry today. A general purpose communication link that connects to a screen with, here used to indicate the location of one or more internal hosts and controllers within a portion of the device with 138 and 148. It can be seen that the amount of data involved in these transfers requires a large number of leads to form links 138 and 148. Today's growing use of advanced color and graphic interfaces, display elements on such devices for parallel or other known interface technique types that can be used to transfer such data. It is estimated that such communication links are approaching more than 90 leads to meet the need to do so.

Unfortunately, the higher data rates are both in terms of the amount of raw data that needs to be transferred per unit time and the production of a reliable and cost-effective physical transfer mechanism. Beyond the technologies currently available for transferring data.

What is needed is for a data transfer link or communication path between the presentation element and the data source that allows for consistently (further) low power, light weight, and the simplest and most economical cable routing structure possible. Techniques, structures, means, or methods for transferring data at higher speeds. Applicants can transfer data to the desired display, microdisplay or voice transfer element at very high speeds while maintaining the desired low power consumption and complexity while also allowing mobile devices, portable devices or fixed position devices to be transferred We have developed new techniques or methods and devices to achieve these and other goals.

III. High-speed digital data interface system architecture Signal protocols and system architectures have been devised to provide very fast data transfer speeds with low power signals in order to create new device interfaces and utilize them efficiently. The protocol is based on a common frame structure with packets, a structure that is linked together to form a protocol for communicating a preselected set of data or data types with a command or operation structure imposed on the interface. There is.

A. Overview Devices connected by MDDI links or communicating over MDDI links are called hosts and clients, and other output and input devices are also intended, but clients are usually some type of display device. Data from the host to the display travels in the forward direction (called forward traffic or link), and data from the client to the host travels in the reverse direction (reverse traffic or link) as enabled by the host. This is depicted in the basic configuration shown in Figure 3. In FIG. 3, the host 202 is connected to the client 204 using a bidirectional communication channel 206 depicted as having a forward link 208 and a reverse link 210. However, these channels are formed by one common set of leads whose data transfer is effectively switched between forward and reverse linking operations. This significantly reduces the number of leads and can immediately address one of the many problems faced by current high-speed data transfer techniques in low-power environments such as for mobile electronic devices.

As described elsewhere, the host comprises one of several types of devices that can benefit from using the present invention. For example, the host 202 will be a portable computer in the form of a portable device, laptop device, or similar mobile computing device. It could be a personal data assistant (PDA), a paging device, or one of many radiotelephones or modems. Alternatively, the host 202 may be a portable DVD or CD player, or a portable entertainment or presentation device such as a gameplay device.

In addition, the host can reside as a host device or control element in a variety of other widely used or planned products for which high speed communication links are desired with the client. For example, a host could be used to transfer data from a video recorder to a storage-based client for improved response, or to a high-resolution large screen for presentations at high speed. Electrical products such as refrigerators that incorporate a bluetooth connection to an on-board inventory system or calculation system and / or other household equipment shall have improved display capabilities when operating in internet mode or bluetooth connection mode. Or an electronic computer system or electronic control system (host) resident somewhere in the cabinet, while wiring to the in-the-door display (client) and keypad or scanner (client) Reduced writing needs for. In general, one of ordinary skill in the art will improve old equipment with a faster data rate transport of information that leverages a limited number of leads available with either new added or existing connectors or cables. You will understand the variety of modern electronic devices and household products that may benefit from the use of this interface, as well as the ability to do so.

At the same time, the client 204 may be equipped with various devices useful for presenting information to the end user or from the user to the host. Microdisplays built into goggles or glasses, projection devices built into hats or helmets, small screens or holographic elements built into vehicles such as windows or windshields, or various speakers, headphones, or high A sound system or the like for presenting quality sound or music. Other presentation devices include projectors or projection devices used to present information for conferences or for movie and television images. Another example is a device or system that actually has little "input" other than contact or sound from the user, or a touchpad or sensitive device that may be required to transfer large amounts of information from the user, voice. It will be the use of recognition input devices, security scanners, etc. In addition, docking stations for computers and car kits or desk kits, and holders for wireless phones may act as interface devices to end users or other devices and devices, especially when high speed networks are involved. Either a client (an output device such as a mouse or an input device) or a host may be used to assist in the transfer of data.

However, those skilled in the art aim to provide end users with high quality images and sounds in terms of either memory and transport, or presentation during playback, the present invention is not limited to these devices. It will be easy to recognize that there are many other devices on the market that are proposed for use. The present invention is effective in increasing the data throughput between various elements or devices in order to cope with the high data rates required to achieve the desired user experience.

The MDD interfaces and communication signal protocols of the present invention are host processors, controllers, or (eg) circuit components and devices or devices to reduce cost or complexity and associated power and control requirements or restrictions on their connections. To simplify the interconnection between displays in the device housing or structure (called built-in mode), and to increase reliability not only for or for connections to external elements, devices or devices (called built-in mode). May be used for (called external mode).

The collective serial link data rate of each signal pair utilized by this interface structure can vary by orders of magnitude, allowing system or equipment designers to determine the cost, power, and implementation for a given application or purpose. Make it easy to optimize complexity and display update speed. MDDI attributes are independent of display or other presentation equipment (target client) technology. The timing of data packets transferred through the interface can be easily adjusted to accommodate specific client specificities such as display devices, sound systems, storage and control elements, or combined timing requirements of audiovisual systems. This allows you to have a system with very low power consumption, while having a framebuffer to utilize the MDDI protocol at least at some level is not a requirement for diverse clients.

B. Interface type MDD interfaces are intended to address at least four, and perhaps five or more, of some different physical type of interface in the telecommunications and computer industries. Other labels or names may be applied by one of ordinary skill in the art, depending on the particular application in which they are used or the industry to which they are associated, but these are simply types 1, type 2, type 3 and type 4. It is named. For example, a simple voice system may use fewer connections than a more complex multimedia system and may refer to features such as "channels" separately.

The type 1 interface is a 6-wire or other type of wire or conductive element, that is, a portable medium player such as a mobile phone or radiotelephone, a PDA, an electronic game, and a CD player, or an MP3 player, and a similar device or It is configured as an optimal interface for equipment used in similar types of electronic consumer technology. In one embodiment, the interface is more suitable for laptop computers, laptops, or desktop computers and similar devices or applications, does not require rapid data updates, and does not have an internal MDDI link controller. Can be configured as. This type of interface is also distinguishable by the use of an additional 2-wire universal serial bus (USB) interface found on most personal computers, which is extremely effective in adapting existing operating systems or software support.

Type 2, Type 3, and Type 4 interfaces are suitable for high performance clients or devices, and larger and more complex cable fabrics with additional twisted pair leads to provide adequate shielding and low loss transfer for data signals. Use lines.

Type 1 interfaces deliver signals that can include display, voice, control and restricted signaling information, and are typically used for mobile clients or client devices that do not require high resolution full speed video data. The Type 1 interface can easily support Super Video Graphic Array (SVGA) resolution at 30 fps with 5.1 channel audio, with a minimum configuration of 2 sets for data transmission and 1 set for power transmission, for a total of 3 sets. It is possible to use only wire sets. This type of interface is primarily for devices such as mobile wireless devices where USB hosts cannot be used within such devices for connecting and transferring signals. In this configuration, the mobile radio is an MDDI host device, typically the "master" that controls the communication link from the host that sends data (forward traffic or link) to the client for presentation, display, or playback. Work as.

In this interface, the host from the client by sending a special command or packet type to the client that allows it to occupy the bus (link) for a specified period of time and send data to the host as a reverse packet. Allows communication data to be received by the host (reverse traffic or link). This is depicted in Figure 4 where a type of packet (discussed below), called an encapsulated packet, is used to handle the forwarding of a reverse packet over a forwarding link and create a reverse link. The time interval allocated by the host to poll the client for data is scheduled by the host and is based on the requirements of each specified application. This type of half-duplex bidirectional data transfer is especially advantageous when the USB port cannot be used to transfer information or data from the client.

High-performance displays that allow HDTV or similar high resolution require a data stream at a rate of approximately 1.5 Gbps to support full-motion video. The type 2 interface supports high data rates by transmitting 2 bits in parallel, the type 3 transmits 4 bits in parallel, and the type 4 interface transfers 8 bits in parallel. The Type 2 and Type 3 interfaces use the same cables and connectors as Type 1, but can operate at twice and four times the data rate to support even higher performance video applications on portable devices. The 4-inch interface is suitable for very high performance clients or displays and requires a slightly larger cable with additional twisted pair data signals.

The protocol used by MDDI is type 1, type 2, type 3 or by negotiating what is usually the best data rate available to each type 1, type 2, type 3 or type 4 host. Allows communication with type 4 clients. The capabilities or available functions of what is called the least functional device are used to set the performance of the link. In general, even if the host and client both use a Type 2, Type 3, or Type 4 interface, both will start operating as a Type 1 interface. The host then determines the capabilities of the target client and negotiates a handoff or reconfiguration action depending on which of the two, three, or four modes appropriate for the particular application.

In general, the host uses the appropriate link-layer protocol (discussed further below) and usually lowers it to a slower mode to save power, that is, resets its behavior again, or high-resolution display content. It is possible to raise to a faster mode to support faster transfers such as. For example, the host may interface type when the system switches from a power source such as a battery to AC power, or when the source of the display medium switches to a lower or higher resolution format, or a combination or other condition or event thereof. That is, the interface type may be changed when it can be regarded as the basis for changing the transfer mode.

It is also possible for the system to use one mode in one direction and another mode in the other direction to communicate data. For example, type 1 mode could be used to transfer data from a peripheral such as a keyboard or pointing device to a host device, and type 4 interface mode could be used to transfer data to a display at high speed. It will be appreciated by those skilled in the art that hosts and clients may communicate outgoing data at various speeds.

In many cases, users of the MDDI protocol may distinguish between "external" mode and "internal mode". External mode describes the use of protocols and interfaces to connect a host within a device to clients outside the device, up to about 2 meters from the host. In this situation, the host may send power to an external client so that both devices can easily operate in a mobile environment. The internal mode describes when a host is connected to a client contained within the same device, such as in a common housing or support frame or some kind of structure. One example is a portable in a wireless phone or other wireless device, or where the client is a display or display driver, or an input device such as a keypad or touchpad, or a sound system, and the host is a central controller, graphic engine or CPU element. It may be an application example of a computer or a game device. Since the client is located much closer to the host in the internal mode application as opposed to the external mode application, there is usually no requirement to describe the power connection to the client in such a configuration.

C. Physical interface structure The general arrangement of the device or link controller for establishing communication between the host device and the client device is shown in Figures 5 and 6. In FIGS. 5 and 6, MDDI link controllers 402 and 502 are shown mounted inside the host device 202 and MDDI link controllers 404 and 504 are shown mounted inside the client device 204. As mentioned above, the host 202 is connected to the client 204 using a bidirectional communication channel 406 with a series of leads. As described below, both the host controller and the link controller use a single circuit design that can be configured, tuned, or programmed to correspond as either a host controller (driver) or a client controller (receiver). Can be manufactured as an integrated circuit. This allows for even lower costs for larger manufacturing of single circuit devices.

In FIG. 6, the MDDI link controller 502 is attached to the host device 202'and the MDDI link controller 504 is attached to the client device 204'. As mentioned above, the host 202'is connected to the client 204' using a bidirectional communication channel 506 with a series of leads. As mentioned above, both the host controller and the client link controller can be manufactured using a single circuit design.

The signals passed between the host and the client, such as a display device, on the MDDI link or between the physical wires used are also shown in Figures 5 and 6. As can be seen in FIGS. 5 and 6, the primary path or mechanism for transferring data through MDDI uses a data signal called MDDI_Data0 +/- MDI_Stb +/-. Each of these is a low voltage data signal transferred by a differential set of wires in the cable. There is only one transition in either MDDI_Data0 or MDDI_Stb pairs for each bit transmitted on the interface. Since this is a voltage-based transfer mechanism rather than a current-based one, static current consumption is near zero. The host drives the MDDI_Stb signal on the client display.

Data can flow on the MDDI_Data pair in both forward and reverse directions, that is, it is a bidirectional transfer path, but the host is the master or controller of the data link. The MDDI_Data0 and MDDI-Stb signal paths are operated in differential mode for maximum noise rejection. The data rate for signals on these lines is determined by the rate of the clock transmitted by the host and is variable in the range from about 1 kbps to over 400 Mbps.

The type 2 interface includes one additional set of data or leads or paths beyond that of type 1 called MDDI_Data1 +/-. The type 3 interface includes two additional data sets or signal paths beyond that of the type 2 interface called MDDI_Data2 +/- and MDDI_Data3 +/-. The Type 4 interface contains four more data sets or signal paths beyond that of the Type 3 interface called MDDI_data4 +/-, MDDI_Data5 +/-, MDDI_Data6 +/-, and MDDI_Data7 +/-, respectively. In each of the interface configurations, the host can power the client or display using a set of wires or signals represented by HOST_Pwr and HOST_Gnd. As described further below, power transfer is MDDI_Data4 + / 1, if desired, when an interface "type" is used that utilizes even less conductors that are available or exist for other modes. , MDDI_Data +/- 5, MDDI_Data6 +/-, or MDDI_Data7 +/- can be addressed with several configurations on the wire. Power transfer is usually utilized in an external mode and some applications may differ, but usually there is no need for an internal mode.

A summary of the signals passed between the host and client (display) over the MDDI link for the various modes is shown in Table I below according to the interface type.<tables num="1"><img file="JP2010226725A_D0001.tif" /></tables>

Also note that the HOST_Pwr / Gnd connection for transfers from the host is usually provided in external mode. Such distribution is because internal application examples or modes of operation typically have clients that draw power directly from other internal resources and do not use MDDI to control power distribution, as will be apparent to those skilled in the art. It will not be described in more detail here. However, as will be appreciated by those skilled in the art, it is certainly possible to allow power to be distributed through the MDDI interface, for example to allow for some kind of power control, synchronization or interconnection convenience.

Cable wires typically used to achieve the structure and operation are approximately 1.5 meters long, typically 2 meters or less, each containing three twisted pair wires, which are also multi-strand wires. .. The wire size is not constrained to a particular size, but electrical specifications or constraints should be satisfied with respect to maximum total resistance, maximum capacitance per foot, impedance of each pair, and crosstalk.

Foil shield covering is wrapped or formed over a set or group of three twisted pairs, here an additional drain wire. Twisted pair and shield drain leads, as is well known in the art, have an insulating layer that covers the entire cable, with the shield terminated at the client connector that connects to the shield for the client. The wires are paired like HOST_Gnd and HOST_Pwr, MDDI_Stb + MDDI_Stb-, MDDI_Data0 and MDDI_Data0-, MDDI_Data + and MDDI_Data1-, and so on. However, as will be understood in the art, various conductors and cable wires may be used to realize the embodiments of the present invention, depending on the specific application. For example, in some applications, even thick outer coatings or even metal layers may be used to protect the cables. On the other hand, thin, flat conductive ribbon type structures are also well suited for other applications.

One or more clients are connected to one host device when used in "internal mode" as an internal or interconnect mode, device, protocol, device, or technology for data transfer, as described below. Is possible. For internal mode operation, it is permissible to have this kind of setting. However, in this case, only one client is configured or can return the signal for the MDDI interface and the MDDI data signal to the host. In this case, the other client acts only as a receiver for the signal from the host, not as a source or driver for the MDDI data signal.

One application that uses many clients for one host is in the area of visual display panels or video, such as LCD panels on wireless devices such as mobile phones. Many such wireless devices are designed with two LCD panels. One is the main information or image, i.e. the main large display. The other is that the main or main display is used, for example, when the phone is on standby or in inactive mode waiting for a call, or when it is active to make a call. A small display used to show phone status, caller ID, date and time, or other features while you are away.

Each LCD panel contains or is connected to an MDDI client connected to an MDDI host. The main LCD panel can send packets back to the host, while the subpanel only receives packets from the host. Since this is an internal mode application, it is not essential that the subpanel be able to send its features or status to the host. This is because the host already knows the characteristics of the client device in advance.

Figure 98 shows an example of using more than one client, in this case two clients, in a data transfer configuration. In FIG. 98, the host 9800 is connected to the clients 9806,9808 via conductors, cables, or buses 9802,9804, respectively. Each pair of MDDI_Data and MDDI_Stb behaves as described herein and may transfer data at high data rates using disclosed inventive signal protocols with packets, forwarding relationships, and mechanisms described below. it can. Similarly, commands, settings, and request information from the client can be communicated in order to confirm the display function and the like. In this embodiment, the client 9806 is an illustrated appliance, device, device that utilizes a host, or an LCD display device or certain panel that acts as the "main" or main display panel for the host and client. Is associated with, formed as part of, or connected to. The client 9808, on the other hand, is formed or connected as part of a device, host and device utilizing the illustrated host, an LCD display or some kind of panel that acts as the "main" or main display. ..

It should be easily understood that the two display elements or devices do not have to be the same or of the same type or nature, but are merely two separate display devices for which their use is desired. For example, they may be different types of LCD panels or LCD-based display elements. Others, on the other hand, use another type of display technology from CRT tubes, as desired. FIG. 98 shows each client communicating via another bus or each set of leads 9810,9812 to transfer information and / or instructions or control information or signals to each display element or panel. As mentioned above, the client can be configured as part of the circuit used to implement the panel controllers 9814,9816. Alternatively, it is formed or secured as part of a wire or element, circuit in the area of the panel.

When forming circuits or elements of a panel, such clients are placed on the panel by forming suitable transistors for other elements or by retrofitting circuit modules that are obvious to experts in the art. There are several possible scenarios for doing so. In addition, the client and panel controller are separate elements in many applications and can be seen or generated as a single module or integrated circuit element, other device or element. Pixels arranged in a physical array via a panel, that is, image display elements, form what is referred to as an LCD panel in the figure. Here, one of the two panels acts as the main or main LCD panel, and the other acts as a sub, additional, or auxiliary panel (which can be a backup for redundancy if desired). Therefore, the main client and the sub-client were associated. At any given time, or period of time, only one client communicates information or signals back to the host. Otherwise, the host does not know exactly if this information comes from a different client or from which client. Further protocol versions may use the client ID or identification designation to address more sophisticated control through the client, or optionally switching between clients. As shown herein, there are many reserved ID parts in the packet. In general, using a subpanel does not require or use the same type of reply signal or communication with the host at this time. However, the present invention does not interfere with the control or change of the primary and secondary states over a period of time, for example, depending on the command, failure mode, etc., if necessary. Moreover, if this is done for an internal mode of operation, the characteristics of the delay factor are generally known in advance and the previous main display can be selected as a new main display that is no longer used in that mode.

D. Data type and speed To achieve an interface that is effective for a range of user experiences and applications, the Mobile Digital Data Interface (MDDI) provides control information, and combinations thereof, along with various client and display information, voice transducers, keyboards, pointing devices and mobile displays. It provides support for many other input or output devices that may be integrated into the device or operate in conjunction with a mobile display device. MDDI is designed to handle various potential types of streams of data that travel between the host and client, either forward or backward, using a minimum number of cables or leads. Both isochronous streams and asynchronous streams (updates) are supported. Many combinations of data types are conceivable as long as the aggregate data rate is less than or equal to the maximum desired MDDI link rate limited by the maximum serial rate and the number of data airs used. These may include, but are not limited to, those items listed in Tables II and III below.<tables num="2"><img file="JP2010226725A_D0002.tif" /></tables><tables num="3"><img file="JP2010226725A_D0003.tif" /></tables>

The interface is not fixed, but can be extended to support the transfer of various information "types", including user-defined data, for future system flexibility. Specific examples of data addressed are full-motion video in either full-screen or partial-screen bitmap field or compressed video format, slow static bits to save power and reduce implementation costs. Maps, PCM or compressed audio data at various resolutions or speeds, pointing device locations and selections, as well as user-definable data that must still be defined. Such data may be transferred along with control or status information to detect the function of the device or to detect operating parameters.

Embodiments of the present invention include watching a movie (video display and audio), using a personal computer with limited personal display (graphic display, which may be combined with video and audio), and playing a video game on a personal computer, console. Or in the form of a personal device (video graphics display or synchronized video and audio), a video phone (two-way slow video and audio), a still digital photographic camera, or a camcorder for capturing digital video images. Use a PDA that is docked to a projector to "surf" the Internet using a device, make a phone call, computer or presentation, or docked to a desktop docking station connected to a video monitor, keyboard and mouse. To advance technology for use in data transfer, including but not limited to productivity enhancements or entertainment applications with mobile phones, smartphones, or PDAs, including wireless pointing devices and keyboard data.

High-speed data interfaces, as described below, are presented in that large amounts of AV-type data are provided on communication or transfer links, usually configured as wirelines or cable-type links. However, the signal structure, protocol, timing, or transfer mechanism could be adjusted to provide a link in the form of an optical or wireless medium if it can sustain the desired level of data transfer. Is easily revealed.

MDDI signals use a concept known as the Basic Signal Protocol or Common Frame Rate (CFR) for structures. The idea behind using a common frame rate is to pulse synchronously to a simultaneous isochronous data stream by sending subframe header packets at a rate that can be used to derive frame timing or clocks for multiple streams. Is to give. The rate at which the subframe header packet is transmitted is the common frame rate. Client devices can use this common frame rate as a time reference. Low CFR increases channel efficiency by reducing overhead for sending subframe headers. High CFR, on the other hand, reduces latency and allows smaller, more flexible data buffers for voice samples. The CFR of the present invention is dynamically programmable and may be set as one of many values suitable for isochronous streams used in a particular application. That is, the CF value is chosen to best suit the default client and host configuration, as desired.

Table IV shows the number of bytes typically required for each adjustable or programmable subframe for isochronous data streams that are likely to be used for applications such as video or microdisplay.<tables num="4"><img file="JP2010226725A_D0004.tif" /></tables>

A partial count of bytes per subframe is easily obtained using a simple programmable M / N counter structure. For example, a count of 26-2 / 3 bytes per subframe is achieved by transferring two frames of 27 bytes, one subframe of 26 bytes each following. Smaller CFRs may be chosen to yield an integer of bytes per subframe. However, in general, in order to realize a simple M / N counter in hardware, in an integrated circuit chip or an electronic module used to realize some or all of the embodiments of the present invention. It should require less area than is required for a large audio sample FIFO buffer.

An exemplary application that depicts the effects of various data transfer rates and data types is a karaoke system. In the case of karaoke, a system in which one or more end users sing along with a music video program. The lyrics of the song are displayed somewhere on the screen, usually at the bottom, so that the user can see the lyrics being sung and the timing of the song. This application requires a video display with occasional graphic updates, and mixing one or more of the user's voices with a stereo audio stream.

Assuming a common frame rate of 300Hz, each subframe consists of 92,160 bytes of video content and 588 bytes of audio content (based on 147 16-bit samples of stereo) on the forward link to the client. , An average of 26.67 (26-2 / 3) bytes of audio is sent back from the microphone to the mobile karaoke machine. Asynchronous packets are sent between the host and perhaps a head-mounted display. This includes a bottom 1/4 screen height where the lyrics text is updated at 1/30 of a 30 second interval, and various other control and state commands that are sent to the subframe if the lyrics text is not updated.

Table V shows how the data is allocated within the subframe of the karaoke example. The total speed used is chosen to be approximately 279 Mbps. The slightly higher rate of 280Mbps allows the transfer of another approximately 400 bytes of data per subframe, allowing the use of extraordinary control and status messages.<tables num="5"><img file="JP2010226725A_D0005.tif" /></tables>

III. (Continued) High-speed digital data interface system architecture E. Link layer The data transferred using the MDDI high-speed serial data signal consists of a stream of time-division packets that are linked one after the other. The MDDI link controller normally automatically sends a filler packet, thus maintaining a stream of packets, even if there is no data to send to the sending device. The use of a simple packet structure ensures reliable isochronous timing for video or audio signals or data streams.

A group of packets is contained within a signal element or structure called a subframe, and a group of subframes is contained within a signal element or structure called a media frame. A subframe contains one or more packets, depending on their respective size and data transfer application, and a media frame contains another subframe. The maximum subframe provided by the protocol utilized by the embodiments presented herein is approximately 2.³²-1, or 4,294,967,295 bytes, with a maximum media frame size of about 2¹⁶-1, or 65,535 subframes.

Special subframe header packets contain a unique identifier that appears at the beginning of each subframe, as described below. The identifier is also used to acquire frame timing on the client device when communication between the host and client is initiated. Link timing acquisition is described in more detail below.

Normally, the display screen is updated once per media frame while the full motion video is displayed. The display frame rate is the same as the media frame rate. The link protocol supports full motion video over 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 displaying a web page or email, the display screen may only need to be updated from time to time. In those situations, it is advantageous to send a single subframe and then shut down or deactivate the link to minimize power consumption. The interface also supports effects such as stereo vision and handles graphics primitives.

Subframes allow the system to periodically enable the transmission of high priority packets. This allows simultaneous isochronous streams to coexist with a minimum amount of data buffering. This is one advantage that the embodiment provides for the display process, allowing multiple data streams (high-speed communication such as video, audio, control, status, pointing device data, etc.) to essentially share one common channel. To do so. It transfers information using relatively few signals. It also allows special effects to be present on the display technology such as horizontal sync pulses and blanking intervals for special effects on CRT monitors or other client technologies.

F. Link controller The MDDI link controller shown in Figures 5 and 6 is manufactured or assembled for a completely digital implementation, with the exception of the differential line receiver used to receive MDDI data and strobe signals. .. However, the differential line driver and differential line receiver can be realized in the same digital integrated circuit with a link controller, such as when creating a CMOS type IC. No analog functionality or phase-locked loop (PLL) is required for bit recovery or to implement hardware for the link controller. Host controllers and client link controllers include very similar functionality, with the exception of client interfaces that include state machines for link synchronization. Therefore, embodiments of the present invention allow for the practical advantage of being able to create a single controller design or circuit that can be configured as either a host or a client, and can reduce overall link controller manufacturing costs.

IV. Interface Link Protocol A. Frame structure The signal protocol or frame structure used to implement forward link communication for packet transfer is depicted in FIG. As shown in FIG. 7, information or digital data is grouped into elements known as packets. Multiple packets are similarly grouped together to form what is called a "subframe", and multiple subframes are similarly grouped together to form a "media" frame. To control the formation of frames and the transfer of subframes, each subframe begins with a predetermined packet, specifically called a subframe header packet (SHP).

The host device chooses the data rate used for the default transfer. This speed can be dynamically changed by the host device based on both the host's maximum transfer capability, that is, the data retrieved by the host from the source, and the client's maximum capability, that is, the other device to which the data is transferred. ..

A recipient client device designed to work with the MDDI or the signal protocol of the invention, or capable of handling the MDDI or the signal protocol of the invention, determines the maximum or current maximum data transfer rate it can use. In addition to the data types available and supported features that can be queried by the host to do so, the default slower minimum speed may also be used. This information could be forwarded using Client Function Packets (DCPs) as described further below. The client display can transfer data using the interface at or within the minimum data rate range selected in advance, or communicate with other devices, and the host is the full functionality of the client device. Run the query using data rates within this range to locate.

Bitmaps and other status information that defines the nature of the client's video frame rate feature can be forwarded to the host in status packets so that the host can configure the interface as efficiently or optimally as practically, or optionally. Desirable within system constraints.

When the host has no (more) data to transfer in the current subframe, or when the host cannot transfer fast enough to keep up with the data transmission rate chosen for the forward link. Send a filler packet. Since each subframe begins with a subframe header packet, the end of the previous subframe contains a packet that exactly fills the previous subframe (out of ten filler packets). If the packet lacks room for the beta to carry the original data, the filler packet will be the last packet in the subframe, or next at the end of the previous subframe subframe, before the subframe header packet. Is likely to be. Ensuring that within a subframe there is enough space left for each packet to be transmitted within that subframe is the task of the control operation within the host device. At the same time, once the host device begins sending data packets, the host must be able to successfully complete packets of that size within the frame without causing a data underrun situation.

In one aspect of the embodiment, subframe transmission has two modes. One mode is a periodic subframe mode, a periodic timing epoch used to send live video and audio streams. In this mode, the subframe length is defined as non-zero. The second mode is an asynchronous or aperiodic mode in which the frame is used to provide bitmap data to the client only when new information is available. This mode is defined by setting the subframe length to zero in the subframe header packet. When using periodic mode, subframe packet reception may start when the client synchronizes to the forward link frame structure. This corresponds to the "in sync" state defined according to the phase diagram described below with reference to FIG. 49 or FIG. 63. In asynchronous aperiodic subframe mode, reception begins after the first subheader packet is received.

B. Overall packet structure Packet formats or structures used to devise communication or signal protocols implemented by this embodiment, or methods or means for data transfer, have an extensible interface and additional packet structures are desired. It is presented below, keeping in mind that it can be added as it is. Packets are referred to or classified as various "packet types" in terms of their function at the interface, that is, the commands, information, values, or data they transfer or relate to. Therefore, each packet type indicates a predetermined packet structure of the packet being forwarded and the defined packet used in manipulating the data. As will be readily apparent, packets may have a preselected length or may have a variable or dynamically variable length depending on their respective functions. Packets could be given different names, even if the same functionality were still achieved, as would occur if the protocol was changed while it was accepted by the standard. The bytes or byte values used in various packets are configured as multi-bit (8-bit or 16-bit) unsigned integers. A summary of the packets used, along with their "type" names listed in order of type, is illustrated in Tables VI-1 to VI-4.

Each table represents a general "type" of packets in the overall packet structure for ease of description and understanding. There are no restrictions or other effects implied or expressed for the present invention by these groupings, and packets can be organized in many other ways as desired. The direction in which packet forwarding is considered valid is also noted.<tables num="6"><img file="JP2010226725A_D0006.tif" /></tables><tables num="7"><img file="JP2010226725A_D0007.tif" /></tables><tables num="8"><img file="JP2010226725A_D0008.tif" /></tables><tables num="9"><img file="JP2010226725A_D0009.tif" /></tables>

It is clear from the other descriptions in the text that subframe headers, fillers, reverse encapsulation, link shutdown, client functionality and client requests and status packets are each important for external mode operation and communication for external mode. It is also required in many embodiments of the interface. However, reverse encapsulation, link shutdown, client functionality, client requests and status packets are also considered or preferably considered as options for internal mode operation. This results in yet another type of MDDI protocol that allows for very high speed data communication with a reduced set of communication packets and the corresponding simplification of control and timing.

A packet is the common basic structure or overall set of the smallest fields, depicted in Figure 8, with a packet length field, a packet type field, a data byte field (s), and a CRC field. Has. As shown in Figure 8, the packet length field contains information in the form of a multi-bit or multi-byte value that specifies the total number of bits in the packet, that is, its length between the packet length field and the CRC field. .. In one embodiment, the packet length field contains a 16-bit or 2-byte wide unsigned integer that specifies the packet length. A packet type field is another multi-bit field that specifies the type of information contained in a packet. In an exemplary embodiment, this is a 16-bit or 2-byte wide value in the form of a 16-bit unsigned integer, with data types such as display features, handoffs, video or audio streams, status, etc. specify.

The third field is a data byte field containing bits or data being transferred or transmitted as part of the packet between the host device and the client device. The format of the data is specifically specified for each packet type according to the particular type of data being transferred, and may be separated into a series of additional fields, each with its own formatting requirements. That is, each packet type will have a given format for this part or field. The last field is a CRC field that contains the results of a 16-bit cyclic redundancy check calculated on the data byte field, packet type field, and packet length field used to check the integrity of the information in the packet. Is. In other words, it is calculated for the entire packet except for the CRC field itself. The client typically stores a total count of CRC errors detected and reports this count to the host in client requests and status packets (see below).

In general, these field widths and arrangements are designed to keep 2-byte fields aligned on even-byte boundaries and 4-byte fields aligned on 4-byte boundaries. This makes it easy to build packet structures within the host and client main memory space without violating the data type alignment rules encountered for most or commonly used processors or control circuits. Or allow the packet structure to be associated with the host and client.

During packet forwarding, the field begins with the least significant bit (LSB) and ends with the last transmitted most significant bit (MSB). Parameters that are longer than 1 byte are transmitted using the least significant bit first, so that the same bit transmission pattern is 8 in length so that the LSB is used for shorter parameters that are transmitted first. It will be used for parameters that exceed the bits. The data fields of each packet are usually sent in the order specified in the later sections below, the first field listed is sent first, and the last field described is sent last. .. The data on the MDDI_Data0 signal path is aligned with bit "0" of the bytes transmitted on the interface in either mode 1, type 2, type 3 or type 4.

When manipulating data for a display, the data for an array of pixels is transmitted first in rows and then in columns, as is traditionally done in electronics technology. In other words, all pixels appearing on the same line in the bitmap are sent in the order in which the leftmost pixel is sent first and the rightmost pixel is sent last. After the rightmost pixel in a row is sent, the next pixel in the sequence is the leftmost pixel in the following row. Pixel rows are typically transmitted from top to bottom for most displays, although other configurations can be addressed as needed. In addition, the conventional method followed here in processing bitmaps is to set a reference point by naming the upper left corner of the bitmap a location or offset "0,0". The X and Y coordinates used to position or locate in the bitmap increase in value as they approach the right and bottom of the bitmap, respectively. The first row and first column (upper left corner of the image) start with an index value of zero. The scale of the X coordinate increases toward the right side of the image when viewed by the user of the display, and the scale of the Y coordinate increases toward the bottom of the image.

The display window is the visible part of the bitmap, the pixel part of the bitmap that the user can see on the physical display medium. Display windows and bitmaps are often the same size. The upper left corner of the display window always shows the bitmap pixel location "0,0". The width of the display window corresponds to the X-axis of the bitmap, and the width of the display window is less than or equal to the width of the corresponding bitmap in the case of the present embodiment. The height of the window corresponds to the Y-axis of the bitmap, and the height of the display window is less than or equal to the height of the corresponding bitmap in the case of this embodiment. The display window itself is not addressable within the protocol as it is only defined as the visible part of the bitmap.

The relationship between bitmaps and display windows is well known in computer, electronics, internet communications, and other electronics-related technologies. Therefore, no additional explanation or illustration of these principles is provided here.

C. Packet definition 1. Subframe header packet The subframe header packet is the first packet of any subframe and has the basic structure as depicted in FIG. Subframe header packets are used for host-client synchronization, and every client must be able to receive and interpret this packet, while every host must be able to create this packet. As can be seen in one embodiment of FIG. 9, this type of packet includes a packet length field, a packet type field, a unique word field, a reserved 1 field, a subframe length field, a protocol version field, a subframe count field, and a media frame count. The fields are usually structured to have in that order. In one embodiment, this type of packet is typically identified as a 15359 type (0x3bff hexadecimal) packet and uses a preselected fixed length of 20 bytes without the packet length field.

The packet type field and the unique word field each use a 2-byte value (16-bit unsigned integer). Together, the 4-byte combination of these two fields forms a unique 32-bit word with good autocorrelation. In one embodiment, the actual unique word is 0x005a3bff, where the lower 16 bits are transmitted first as the packet type and the uppermost 16 bits are transmitted later.

A reserved 1 field contains 2 bytes reserved for future use, usually composed at this point, with all bits set to zero. One purpose of this field is to align subsequent 2-byte fields with 16-bit word addresses and 4-byte fields with 32-bit word addresses. The least significant byte is reserved to indicate whether the host can address multiple client devices. A value of zero for this byte is reserved to indicate that the host can only work with a single client device.

The subframe length field contains 4 bytes of information or a value that specifies the number of bytes per subframe. In one embodiment, this field length may be set to zero to indicate that only subframes are sent by the host before the link is shut down and idle. The value of this field can be changed dynamically "on the fly" when transitioning from one subframe to the next. This feature is useful for making minor timing adjustments with synchronous pulses to deal with isochronous data streams. If the CRC of the subframe header packet is not valid, the link controller must use the subframe length of the previously known good subframe header packet to estimate the current subframe length.

The protocol version field contains 2 bytes that specify the protocol version used by the host. The protocol version field is set to "0" to specify that the first or current version of the protocol is being used. This value changes over time as new versions are created, and some version fields have already been upgraded to a value of "1". The version value will become known, but will probably or generally follow the current version number for an approved standard document covering an interface such as MDDI.

The subframe count field contains 2 bytes that specify the sequence number indicating the number of subframes transmitted after the start of the media frame. The first subframe of the media frame has a subframe count of zero. The last subframe of the media frame has a value of n-1, where n is the number of subframes per media frame. The value of the subframe count field is equal to the subframe count sent in the previous subframe packet plus one, except for the first subframe of a media frame with a value of zero. Note that if the subframe length is set to zero (indicating aperiodic subframes), then the subframe count must also be set equal to zero.

The media frame count field contains 4 bytes (32-bit unsigned integer) that specify a sequence number indicating the number of media frames transmitted after the start of the transferred media item or data. The first media frame of a media item has a media frame count of zero. The media frame count is incremented immediately before the first subframe of each media frame and the maximum media frame count (eg, 2 media frames).^3-1= 4,294,967,295) is used and then completed and returned (wraps back). The media frame count value may usually be reset by the host at any time to meet the needs of the end application.

2. Filler packet A filler packet is a packet that is forwarded to or from a client device when there is no other information available to send on either the forward or reverse link. It is recommended that the filler packet have the minimum length to allow maximum flexibility in sending other packets when needed. At the very end of a subframe or reverse link-encapsulated packet (see below), the link controller sets the size of the filler packet to fill the remaining space to maintain packet integrity. Filler packets are useful for maintaining timing on a link when the host or client has neither information to send or exchange. All hosts and clients need to be able to send and receive this packet in order to use the interface effectively.

A typical embodiment of the filler packet format and content is shown in FIG. As shown in FIG. 10, this type of packet is structured to have a packet length field, a packet type field, a filler byte packet, and a CRC field. In one embodiment, this type of packet is usually identified as type 0, which is indicated by a double and type field. The bits or bytes in the filler byte field include a variable number of all zero bit values to allow the filler packet to be of the desired length. The smallest filler packet does not contain bytes in this field. That is, the packet consists only of packet length, packet type, and CRC, and in one embodiment uses a preselected fixed length of 6 bytes or a packet length of 4. The CRC value is calculated for every byte in the packet, including the packet length, which may be excluded for some other packet type.

3. Video stream packet Video stream packets carry video data to update the normally rectangular area of a display device. The size of this area can be as small as a single pixel or as large as the entire display. Since all the context required to display a stream is contained within the video stream packet, there may be an almost unlimited number of streams that are displayed simultaneously and limited by system resources. The format of one embodiment of the video stream packet (video data format descriptor) is shown in FIG. As can be seen in FIG. 11, in one embodiment, this type of packet has a packet length (2 bytes) field, a packet type field, a bClientID field, a video data descriptor field, a pixel display attribute field, an X left edge field, and Y. It is structured to have an upper edge field, an X right edge field, a Y lower edge field, an X start field and a Y start field, a pixel count field, a parameter CRC field, a pixel data field and a pixel data CRC field. This type of packet is usually identified as type 16 as shown in the 2-byte type field. In one embodiment, the client demonstrates the ability to receive a video stream packet using the RGB, black and white, and Y Cr Cb functional fields of the client functional packet.

In one embodiment, the bClientID field contains 2 bytes of information reserved for the client ID. Since this is a newly developed communication protocol, the actual client ID is not yet known or fully communicable. Therefore, the bits in this field are usually set equal to zero until such an ID value becomes known, at which point the ID value can be inserted or used as will be apparent to those skilled in the art. In general, the same process applies to the client ID field described below.

As mentioned above, the formats and contents used to implement the behavior of the exemplary video data descriptor fields are shown in FIGS. 12A-12E. In FIGS. 12A-12E, the video data format descriptor field contains 2 bytes in the form of a 16-bit unsigned integer that specifies the format of each pixel in the pixel data of this stream of this packet. Different video stream packets may use different pixel data formats, that is, different values may be used in the video data format descriptor, as well as the stream (area of display) changing its data format on the fly. Good things can be considered. The pixel data format must follow at least one of the client's valid formats as defined in the client function packet . The video data format descriptor defines a pixel format for this packet only that does not imply that a certain format will continue to be used for the life of a particular video stream.

Figures 12A through 12D depict how the video data format descriptor is encoded. As used in these figures, and in this embodiment, when bits [15:13] are equal to "000" as shown in Figure 12A, the video data is described in video data format with the number of bits per pixel. It consists of an array of black and white pixels defined by bits 3 to 0 of the child word. Bits 11-4 are usually reserved for future use or use and are set to zero in this situation. Instead, when the bit [15:13] is equal to the value "001" as shown in Figure 12B, the video data consists of an array of color pixels, each specifying a color through a color map (palette). In this situation, bits 5 to 0 of the video data format descriptor word define the number of bits per pixel, and bits 11 to 6 are usually reserved for future use or use and set equal to zero. When bits [15:13] are instead equal to the value "010" as shown in Figure 12C, the video data has the number of bits per red pixel determined by bits 11-8 and the number of bits per green pixel. Consists of an array of color pixels defined by bits 7-4 and the number of bits per blue pixel defined by bits 3-0. In this situation, the total number of bits in each pixel is the sum of the number of bits used for red, green and blue.

However, when the bit [15:13] is instead equal to the value or string "011" as shown in Figure 12D, the video data is of 4: 2: 2 YCbCr format video data containing brightness and chrominance information. It consists of an array, the number of bits per pixel of luminance (Y) is defined by bits 11 to 8, the number of bits of the Cb component is defined by bits 7 to 4, and the number of bits of the Cr component is defined by bits 3 to 0. .. The total number of bits in each pixel is the total number of bits used for red, green and blue. The Cb and Cr components are transmitted at half the speed of Y. In addition, the video sample in the pixel data portion of this packet is organized as follows. That is, Cbn, Yn, Crn, Yn + 1, Cbn + 2, Yn + 2, Crn + 2, Yn + 3, ..., where Cbn and Crn are associated with Yn and Yn + 1, and Cbn + 2 and Crn + 2 are associated with Yn + 2 and Yn + 3, and so on.

Yn, Yn + 1, Yn + 2, and Yn + 3 are the brightness values of four consecutive pixels in a single row from left to right. If one row of the window referenced by the video stream packet has an odd number of pixels (X right edge-Y left edge +1), the Y value corresponding to the last pixel in each row is followed by the next row. Followed by a Cb value of 1 pixel, the Cr value is not sent because of the last pixel in the row. It is recommended that windows using the Y Cb Cr format have a width that is even pixels. The pixel data in the packet must contain an even number of pixels. It is odd when the last pixel of the pixel data corresponds to the last pixel of the row in the window specified in the video stream packet header, that is, when the X location of the last pixel of the pixel data is equal to the right edge of X. Alternatively, it may include an even number of pixels.

When bit [15:13] is instead equal to the value "100", the video data consists of an array of Bayer pixels whose number of bits per pixel is defined by bits 3 to 0 of the video data format descriptor word. The pixel group pattern is defined by bits 5 and 4, as shown in Figure 12E. The order of the pixel data may be horizontal or vertical, and the pixels in the row or column may be transmitted in forward or reverse order, as defined by bits 8-6. Bits 11-9 must be set to zero. A group of four pixels in a group of pixels that take the Bayer format often resembles what is called a single pixel in some display techniques. However, one pixel in Bayer format is just one of the four colored pixels in the pixel group mosaic pattern.

For all five formats shown, the bit 12 shown as a "P" specifies whether the pixel data sample is packed or byte-aligned pixel data. A value of "0" in this field indicates that each pixel in the pixel data field is byte-aligned with the MDDI byte boundary. A value of "1" indicates that each pixel and each color within each pixel of the pixel data is packed in contrast to past pixels or colors within the pixel, leaving no unused bits. The differences between the byte-aligned data format and the packed pixel data format are shown in more detail in Figure 13, in contrast to the packed pixel format where the byte-aligned data leaves no unused parts. , It is clear that the unused part of the data subframe is left.

4. Voice stream packet Audio stream packets carry audio data that is played through the client's audio system or for a stand-alone audio presentation device. Various audio data streams may be assigned to different audio channels of the sound system, such as front left, front right, center, rear left, and rear right, depending on the audio system used. A complete complement to the audio channel is provided for headsets that include enhanced spatial-acoustic signal processing. The client demonstrates the ability to receive a voice stream packet using the voice channel function field and the voice sample rate field of the client function packet. The format of the audio stream packet is shown in Figure 14.

As shown in FIG. 14, in one embodiment, this type of packet includes a packet length field, a packet type field, a bClientID field, a voice channel ID field, a reserved 1 field, a voice sample count field, a bit per sample and a packing field. It is structured to have an audio sample rate field, a parameter CRC field, a digital audio data field and an audio data CRC field. In one embodiment, this type of packet is usually identified as packet type 32.

The bClientID field contains 2 bytes of information reserved for the client ID as used in the past. The reserved 1 field contains 2 bytes reserved for future use, all bits are set to zero, and usually consist of this point.

The bit per sample and packing fields contain 1 byte in the form of an 8-bit unsigned integer that specifies the packing format of the audio data. The commonly used format is for bits 4 to 0 to determine the number of bits per PCM audio sample. Bit 5 then specifies whether the digital audio data sample is packed. The difference between the packed audio sample and the byte-aligned audio sample, which uses a 10-bit sample here, is shown in Figure 15. A value of "0" indicates that each PCM audio sample in the digital audio data field is byte-aligned with the MDDI byte boundary, and a value of "1" indicates that each continuous PCM audio sample is a past audio sample. Indicates that it is packed in contrast to. This bit is usually valid only when the value defined by bits 4 to 0 (the number of bits per PCM audio sample) is not a multiple of 8. Bits 7-6 are reserved for future use and are usually set at a value of zero.

5. Reserved stream packet In one embodiment, packet types 1-15, 18-31, and 33-55 are defined for use in future versions or variants of the packet protocol as desired for the various applications encountered. Reserved for stream packets. Again, this is part of making MDDI more flexible and effective in the face of ever-changing technology and system design compared to other techniques.

6. User-defined stream packet Eight data stream types, known as types 56 through 63, are reserved for use in proprietary applications that may be defined by the equipment manufacturer for use with MDDI links. These are known as user-defined stream packets. Such packets may be used for any purpose, but hosts and clients must use such packets only in situations where the consequences of such use are very well understood or known. Must be. The specific definition of stream parameters and data for these packet types is left to the specific equipment manufacturer or interface designer who realizes or seeks to use such packet types. Some exemplary uses of user-defined stream packets are to convey test parameters and test results, factory calibration data, and proprietary special use data. The format of the user-defined stream packet as used in one embodiment is shown in FIG. As shown in FIG. 16, this type of packet may have a packet length (2 bytes) field, a packet type field, a bClientID number field, a stream parameter field, a parameter CRC field, a stream data field and a stream data CRC field. It is structured in.

7. Color map packet The colormap packet specifies the content of the colormap look-up table used to present the color for the client. Some applications may require a color map that is larger than the amount of data that can be transmitted in a single packet. In these cases, multiple colormap packets may be forwarded, each containing a different subset of the colormap, by using the offset and length fields described below. The format of the colormap packet in one embodiment is shown in FIG. As shown in FIG. 17, this type of packet has a packet length field, a packet type field, a hClientID field, a colormap item count field, a colormap offset field, a parameter CRC field, a colormap data field, and a data CRC field. It is structured like this. In one embodiment, this type of packet is typically identified as packet type 64 (video data format and colormap packet) as specified in the packet type field (2 bytes). The client demonstrates the ability to receive colormap packets using the colormap size and colormap width fields of the client function packet.

8. Reverse link encapsulation packet In an exemplary embodiment, the data is forwarded in the reverse direction using a reverse link encapsulation packet. The forward link packet is transmitted and the MDDI link operation (forwarding direction) is changed or redirected around the middle of the packet so that the packet can be transmitted in the opposite direction. The format of the reverse link encapsulated packet in one embodiment is shown in FIG. As shown in FIG. 18, this type of packet includes packet length field, packet type field, hClientID field, reverse link flag field, reverse rate divisor field, turn 1 length field, turn change 2 length field, and parameters. It is structured to have a CRC field, an all-zero field, a one-direction turn field, a reverse data packet field, two turn-around fields, and two all-zero fields. In one embodiment, this type of packet is usually identified as packet type 65. In external mode, every host must be able to generate this packet and receive the data, and every client should be able to efficiently take advantage of the desired protocol and the resulting speed. Must be able to receive and send to the host. Implementation of this packet is optional for internal mode, but the host uses a reverse link-encapsulated packet to receive data from the client.

The MDDI link controller operates specifically during the transmission of a reverse link encapsulated packet. MDDI usually has a strobe signal that is always driven by the host as a controller for the link. The host behaves as if it were sending zeros for each bit of the diversion part and the reverse data packet part of the reverse link encapsulation packet. The host toggles the MDDI_Strobe signal at each bit boundary during the two diversions and during the time allotted to the reverse data packet. That is, the host toggles MDDI_Stb from the beginning of the all zeros 1 field to the end of the all zeros 2 field (this is the same behavior as if it were sending all zeros data).

The host disables its MDDI data signal line drivers and generally ensures that they are completely disabled before the last bit of the turnaround 1 field. It then re-enables the line drivers during the turn-around 2 field, generally ensuring that they are fully re-enabled before the last bit of the turn-around 2 field. The client reads the diversion length parameter and invokes a data signal towards the host immediately after the last bit of the diversion 1 field. That is, the client clocks the new data in the link at the specific rise of the MDDI strobe, as specified in the following description of the packet content, and elsewhere. The client uses the packet length and turnaround length parameters to know the length of time it has available to send a packet to the host. The client may send a filler packet or drive the data line to zero when there is no data to send to the host. When the data line is driven to zero, the host interprets this as a zero-length (non-valid length) packet and the host does not accept any more packets from the client during the current reverse link encapsulation packet period. ..

In one embodiment, the reverse link request field of the client request and status packets is used to inform the host of the number of bytes the client needs in the reverse link encapsulation packet to send the data back to the host. Good. The host attempts to allow the request by allocating at least that number of bytes in the reverse link encapsulated packet. The host may send multiple reverse link encapsulated packets in one subframe. The client may send client requests and status packets almost always, and the host interprets the reverse link request parameter as the total number of bytes requested in one subframe.

9. Client function packet The host usually needs to know the capabilities of the client (display) with which it is communicating in order to configure the link from the host to the client in the optimal or desired way. It is recommended that the display send a client function packet to the host after the forward link synchronization has been obtained. Transmission of such packets is considered mandatory when requested by the host with the reverse link flag in the reverse link encapsulated packet. Client feature packets are used to inform the host of the client's capabilities. In external mode, any host should be able to receive this packet and every client should be able to send this packet to take full advantage of this interface and protocol. Client functions such as displays, keyboards, or other input / output devices in this situation must already be clear at the time of manufacture or integration into a single component or device of some type and to the host. Inplaymentation of this packet is optional for internal mode, as it must be known.

The format of the client function packet in one embodiment is depicted in FIG. As shown in FIG. 19, in this embodiment, this type of packet is a packet length field, a packet type field, a cClientID field, a protocol version field, a minimum protocol version field, a pre-calibration data rate feature field, an interface type. Functional field, Alternate (Alt) number of displays field, Reserved 1 field, Post-calibration data rate Functional field, Bitmap width field, Bitmap height field, Display window width field, Display window height field, Colormap size field, Color Map RGB width field, RGB function field, black and white function field, reserved 1 field, Y Cr Cb function field, Bayer function field, reserved 2 field, client feature function field, maximum video frame rate field, minimum video frame rate field, minimum subframe rate field, voice buffer depth field, voice channel function field, voice sample rate function Field, audio sample resolution field, microphone sample resolution field, microphone sample rate function field, keyboard data format field, pointing device data format field, content protection type field, manufacturer name field, product code field, reservation 3 field, serial number field It is structured to have a week of manufacture field, a year of manufacture field and a CRC field. In an exemplary embodiment, this type of packet is usually recognized as type 66.

10. Keyboard data packet Keyboard data packets are used to send keyboard data from the client device to the host. Wireless (or wired) keyboards may be used with a variety of displays or audio devices, including, but not limited to, head-mounted video displays / audio presentation devices. The keyboard data packet relays keyboard data received from one of a plurality of known keyboard-like devices to the host. This type of packet can also be used in a forward link to send data to the keyboard. The client demonstrates the ability to send and receive keyboard data packets using the keyboard data fields of client function packets.

The format of the keyboard data packet is shown in FIG. 20 and contains a variable number of bytes of information from or for the keyboard. As shown in FIG. 20, this packet is structured to have a packet length field, a packet type field, a bClientID field, a keyboard data format field, a keyboard data field, and a CRC field. Here, this type of packet is usually identified as packet type 67.

bClientID is a reserved field as described above and CRC is executed on every byte of the packet. The keyboard data format field contains a double-byte value that describes the keyboard data format. Bits 6 to 0 must be the same as the keyboard data format of the client function packet. This value is not equal to 127. Bits 15-7 are currently set to zero because they are reserved for future use.

11. Pointing device data packet Pointing device data packets are used as a method, structure, or means for transmitting location information from a wireless mouse or other pointing device from a client to a host. Data can also be sent to the pointing device over a forward link using this packet. An exemplary format of a pointing device data packet is shown in FIG. 21 and contains a variable number of bytes of information from or for the pointing device. As shown in FIG. 21, this type of packet is structured to have a packet length field, a packet type field, a bClientID field, a pointing device format field, a pointing device data field, and a CRC field. In an exemplary embodiment, this type of packet is usually identified as packet type 68 in a 1-byte type field.

12. Link shutdown packet Link shutdown packets are sent from the host to the client as a means or means of indicating that the MDDI data and strobes have been shut down and entered a low power consumption "hibernation" state. This packet shuts down the link and is useful for saving power after a static bitmap has been sent from the mobile communication device to the display, or when there is no additional information to forward from the host to the client for the time being. Normal operation resumes when the host sends the packet again. In one embodiment, the first packet transmitted after hibernation is a subframe header packet. The format of the client status packet is shown in Figure 22. As shown in FIG. 22, this type of packet is structured to have a packet length field, a packet type field, a CRC field and a total zero field. In one embodiment, this type of packet is typically identified as packet type 69 in a 1-byte type field.

The packet length field uses 2 bytes to determine the total number of bytes in a packet that does not include the packet length field. In one embodiment, the packet length of this packet depends on the interface type or link mode in effect when the link shutdown packet is sent. Therefore, a typical packet length is 20 bytes in type 1 mode (22 bytes in total in a packet), 36 bytes in type 2 mode (38 bytes in total in a packet), and a type 3 mode link. In the case, it is 68 bytes (70 bytes in total in the packet), and in the case of 4-inch mode, it is 132 bytes (134 times in total in the packet).

All zero fields use a variable number of bytes to ensure that the MDDI_Data signal is at the logical zero level for a sufficient amount of time before disabling the host line driver, and the client uses only MDDI_Stb. Allows the clock to begin recovering. The length of all zero fields depends on the link operating mode or interface type that is in effect when the link shutdown packet is sent. The length of all zero fields is intended to generate 64 pulses on MDDI_Stb for any interface type setting. Therefore, the total zero field for each interface type is 16 bytes for type 1, 32 bytes for type 2, 64 bytes for type 3, and 128 bytes for type 4.

The CRC field uses 2 bytes, including a 16-bit CRC consisting of bytes from packet length to packet type.

In the low power hibernation state, the MDDI_Data0 driver is disabled to a high impedance state starting after the 16th to 48th MDDI_Stb cycles or after the last bit of all zero fields. For Type 2, Type 3, or Type 4 links, the MDDI_Data1 to MDDI_DataPwr7 signals are also placed in a high impedance state at the same time that the MDDI_Data0 driver is disabled. Either the host or the client "wakes up" the MDDI link from hibernation as described elsewhere, which is an important development for the invention and an advantage of the invention. ..

As described in the definition of all zero fields, MDDI_Stb toggles for 64 cycles following the MSB in the CRC field of the link shutdown packet to facilitate regular shutdown in the client controller. One cycle is either a low-high transition followed by a high-low transition or a high-low transition followed by a low-high transition. The MDDI_Stb driver in the host is disabled after all zero fields have been sent.

13. Client requests and status packets The host usually requires a small amount of information from the client so that it can optimally configure the link from the host to the client. It is recommended that the client send client requests and status packets to the host on a subframe-by-subframe basis. Clients are generally advised to send this packet as the first packet within a reverse link encapsulation packet to ensure that it is delivered to the host. Also, forwarding of this packet is achieved when requested by the host with the reverse link flag in the reverse link encapsulated packet. Client requests and status packets are used to report errors and status to the host. For external mode operation, every host must be able to receive this packet and every client must be able to send this packet in order to make good or optimal use of the MDDI protocol. It is also recommended for internal operations that are internal hosts and internal clients, but there should be support for packets and it is not required.

The format of client requests and status packets is shown in Figure 23. As shown in FIG. 23, this type of packet should have a packet length field, a packet type field, a cClientID field, a reverse link request field, a feature change field, a client busy field, a CRC error count field, and a CRC field. It is structured in. This type of packet is typically identified as packet type 70 in the 1-byte type field and uses a preselected fixed length of usually 12 bytes.

The reverse link request field may be used to inform the host of the number of bytes required by the client in the reverse encapsulated packet to send back the host's data. The host must attempt to allow the request by allocating at least that number of bytes in the reverse link encapsulation packet. The host may send multiple reverse link-encapsulated packets within a subframe to deal with the data. The client may send client requests and status packets at any time, and the host interprets the reverse link request parameter as the total number of bytes requested in one subframe. Additional details and specific examples of how reverse link data is sent back to the host will be described below.

14. Bit block transfer packet Bitmap block forwarding packets generally provide means, structures, or methods for scrolling an area of a display in any direction by copying blocks of pixels from one rectangular area to another. A client with this function reports the function with bit 0 of the display feature function indicator field of the client function packet. The format of one embodiment of the bit block transfer packet is shown in FIG. As shown in Figure 24, this type of packet is a packet length field, a packet type field, a hClientID field, a pixel data attribute field, a raster action field, an upper left X value field, an upper left Y value field, a window width field, a window. It is structured to have a height field, a window X move field, a window Y move field, and a CRC field. This type of packet is usually identified as a 71-type packet, and one embodiment uses a preselected fixed length of 15 bytes. The 2-byte hClientID field contains the value or information reserved for the client ID as described. This field is generally reserved for future use, so other values may be set or used by experts in the art to transfer the desired information, but bits. Is generally set to zero by setting to the logical zero level.

In one embodiment, the 2-byte pixel data attribute field has a value that specifies where the pixel data should be updated. Here, bit 1 and bit 0 select the display on which the pixel data is updated. If the client's main display does not support stereo images, the client can cause the pixel data in the main display to act on one of the 01, 10, or 11 bit combinations. A value of 11 is recommended to be used to address the primary display on clients that do not support the stereo display feature. If bit [1: 0] has the value 11 (both logical 1), the pixel data is updated in both the left and right eye framebuffers. If bit [1: 0] has the value 10 (logical 1, logical 0), the pixel data is updated in the framebuffer for the left eye only. If bit [1: 0] has the value 01 (logical 0, logical 1), the pixel data is updated in the framebuffer for the right eye only. If bit [1: 0] has the value 00 (both logical 0), the pixel data is updated in the framebuffer of another display identified by bits 8-11.

In one embodiment, bit 2 of the pixel data attribute field identifies whether the buffer for the left or right eye is the source of the image for this behavior. Bit 2 is only applicable if bit [1: 0] is not equal to 00. This is generally implemented to mean that if the destination of the image is one of the alternate displays, it is not the source data from the primary image. Bit 2 distinguishes between the left-eye framebuffer and the right-eye framebuffer, or identifies it as a data source between the left-eye framebuffer and the right-eye framebuffer. If bit 2 is equal to 0, the left eye framebuffer is the data source, but if bit 2 is equal to 1, the right eye framebuffer is the data source.

Bit 3 of the pixel data attribute field identifies whether the buffer used to refresh the display, or the offline image buffer, is the source of the image for this operation. Bit 3 also applies to alternative displays if they utilize offline image buffers. However, it does not support source data from the primary image buffer if the image destination is an alternate display. Or vice versa. If bit 3 is equal to the value 0, the logical zero level, then the image buffer used to refresh the display is the data source. If bit 3 is equal to the value 1, or logical 1 level, then the offline image buffer is the data source.

Bits 7 and 6 of the pixel data attribute field act as display update bits that identify the framebuffer. Pixel data is updated or written in this framebuffer. The effect of the frame update bit will be described in detail later. If bit [7: 6] is '01' (logic 0, logic 1), pixel data is written to the offline image buffer. If bit [7: 6] is '00' (both logical 0), pixel data is written to the image buffer used to refresh the display. If bit [7: 6] is '11' (both logical 1), pixel data is written to the image buffer. If bit [7: 6] is '10', it is treated as an invalid value. These bits are currently reserved for future use. In this situation, the entire command is ignored and the framebuffer is not updated.

Bits 11-8 of the pixel data attribute field are 4-bit unsigned integers. This identifies the alternate client location, or alternate display, where the pixel data should be updated. Bits 0 and 1 are set equal to 00 (both logical 0s) for the client to interpret bits 11-8 as the number of alternate displays. If bit 1 and bit 0 are not equal to 00, bits 8 to 11 are generally set to a logical zero value or a logical zero level. Bits 4-5 and 12-15 are reserved for future use and are generally set to logical zero values or logical zero levels.

In one embodiment, a 2-byte raster action field specifies how pixels at the source and destination positions are combined to generate new pixel values that are written to the destination image position. Raster operation defines how the equally sized source and destination areas in the framebuffer are combined into the destination area. The destination image area is also one of two images to be composited. The second of the two images is called the source image. If the client does not support the raster operation field identified in the client function packet, the host generally sends the packet with bits 3 to 0 equal to 3, and the client ignores bits 3 to 0.

In one embodiment, bits 3 to 0 are shown in Table VII by using these bits or to select these bits to select the behavior shown next to the value, as shown in Table VII. Used to identify the actual raster behavior by setting it equal to one of the values. That is, each identified bit [3: 0] value listed in the first column results in the behavior identified in the second column and defined in the third column for clarification.<tables num="10"><img file="JP2010226725A_D0010.tif" /></tables>

Bits 9-8 are used to determine if the destination pixel was written to the destination location when it is related to transparent color. Bit 4 of the client feature feature indicator in the client feature packet indicates whether the transparent color and transparent mask features are supported by the client. Similarly, the display feature function indicator field of the alternate display feature packet indicates whether the transparent color and transparent mask features are supported by the identified alternate display. If the transparent color and transparent mask functions are not supported, raster operation behaves as if bit [9: 8] is set to 00. The behavior identified by bit [9: 8] applies to whether raster behavior is supported by the client device. If the client does not support raster operation, the resulting destination pixel considered for the operation defined by bit [9: 8] is equal to the source pixel value only. This behavior is similar to setting bit [3: 0] to 3.

If the value of bit [9: 8] is equal to 00, the transparent color is not used. The resulting destination pixel is written to the destination pixel position without considering the value of the transparent color or transparent mask. The transparent color is defined by the transparent color and the mask setting packet. A value of bit [5: 4] equal to 01 is currently reserved for future use and used, if available to a skilled person in the art to set the relevant use. It has not been. If the value of bit [5: 4] is equal to 10, the destination pixel obtained as a result of the calculation by raster operation, and if the transparent mask and ANDed source pixel are equal to the transparent color, the resulting pixel Is not written to the destination pixel position. Otherwise, it is written to the destination pixel position. If the value of bit [9: 8] is equal to 11, the resulting pixel is written to the destination pixel position if the resulting destination pixel of the raster operation calculation is equal to the transparent color. Otherwise, the resulting pixels will not be written to the destination pixel position.

Bits 15-10 and 7-4 are reserved for future use and are generally set equal to a logical zero value or a logical zero level.

The remaining fields are used to identify the X and Y coordinates of the upper left corner of the window to be moved, the width and height of the window to be moved, and the number of pixels of the window to be moved in each of the horizontal and vertical directions. used. Positive values in the latter two fields move the window to the right and down, and negative values move the window to the left and up, respectively. The CRC field (here 2 bytes) contains the 16-bit CRC of all bytes in the packet, including the packet length.

15. Bitmap area fill packet Bitmap area fill packets provide a means, structure, or method for easily initializing a display area into a single color. A display having this function reports the function in bit 1 of the client feature function indicator field of the client function packet. One embodiment of the bitmap area fill packet format is shown in FIG. As shown in Figure 25, in this case, this type of packet is a packet length field, a packet type field, a hClient field, a video data format descriptor field, a pixel data attribute field, a raster action field, an upper left X value field, It is structured to have an upper left Y value field, a window width field, a window height field, a pixel area fill value field, and a CRC field. This type of packet is usually identified as packet type 72 in a double-byte field.

The 2-byte hClient field contains the information or value reserved for the client ID, as described. Since this field is generally reserved for future use, we generally set the current value to zero by setting the bit to the logical zero level. However, it may be set or used in other values by experts in the art and used for the transfer of desired information.

In this 2-byte embodiment, the video data format descriptor field specifies the format of the pixel area fill value. This format is the same as the same fields in the video stream packets already described and illustrated. The pixel area fill value field (4 bytes) contains the pixel values that fill the window specified by the parameters in the packet. The format of this pixel is specified within the video data format descriptor field. An example of a pixel format for pixel area fill values is the same as shown above. When the Y Cb Cr format is selected, the transparent color and transparent mask shall contain subfields of pixels 1 and 2 Cb, pixel 1Y, pixels 1 and 2 Cr, and pixel 2Y, to be precise. The number of bytes allocated to the transparent color value is determined by the video data format descriptor field.

The pixel data attribute field and the raster operation field function in the same manner as the same field in the bitmap block transfer packet described above, and the details will be described later.

The remaining fields are used to identify the X and Y values of the coordinates of the upper left corner of the moving window. The left coordinate X and Y values fields on the window use 2 bytes respectively to identify the X and Y values of the coordinates of the upper left corner of the window to be filled. The window width and window height fields (2 bytes each) specify the width and height of the window to be filled. The CRC field (here 2 bytes) contains the 16-bit CRC of all bytes in the packet, including the packet length.

16. Bitmap pattern fill packet Bitmap pattern fill packets provide a means or structure for easily initializing a display area to a preselected pattern. A display having this function reports the function in bit 2 of the client feature function field of the client function packet. The upper left corner of the fill pattern is aligned with the upper left corner of the window to be filled, unless the horizontal or vertical pattern is offset by a non-zero value. If the window to be filled is wider or taller than the fill pattern, the pattern may be repeated horizontally or vertically many times to fill the window. The right or bottom of the last repeating pattern is truncated as needed. If the window is smaller than the fill pattern, the upper right or lower right of the fill pattern may be truncated to fit the window.

If the horizontal pattern offset is non-zero, the pixels between the left corner of the window plus this left corner plus the horizontal pattern offset are filled with the rightmost pixel pattern. The horizontal pattern offset should be less than the pattern width. Similarly, if the vertical pattern offset is non-zero, the pixels between the top of the window and this top plus the vertical pattern offset are filled with the bottom pixel pattern. The vertical pattern offset should be less than the pattern height.

One embodiment of the bitmap fill packet format is shown in FIG. As shown in Figure 26, this type of packet has a packet length field, a packet type field, a hClientID field, a video data format descriptor field, a pixel data attribute field, a raster action field, an upper left X value field, and an upper left Y. Structured to have value field, window width field, window height field, pattern width field, pattern height field, horizontal pattern offset field, vertical pattern offset field, parameter CRC field, pattern pixel data field and pixel data CRC field Has been done. In certain embodiments, this type of packet is typically identified as packet type 73 in a single-byte field.

The 2-byte hClientID field contains the information or value reserved for the ClientID as described. This field is generally reserved for future use, so the current value is generally set to zero by setting the bit to the logical zero level.

The 2-byte video data format descriptor field identifies the format of the pixel area fill value. FIG. 11 shows how the video data format descriptor is encoded. This format is the same as the same field in a video stream packet.

Pixel data attribute fields and raster action fields function in the same way as the same fold in a bitmap transfer packet as described above, the details of which will be described later.

The remaining fields of the Bitmap pattern fill packet were identified as the X and Y values of the coordinates of the upper left corner of the window to be filled, the width and height of the window to be filled, the pattern width and height used as the fill pattern. Used to identify the horizontal and vertical offsets of the pixel data pattern from the left and top edges of the window to be filled, respectively. The pattern CRC field (here 2 bytes) contains the 16-bit CRC of all bytes in the packet from the packet length to the video format descriptor. If this CRC fails the check, all packets shall be discarded. The pattern pixel data CRC field contains a 16-bit CRC consisting only of pattern pixel data. If this CRC fails the check, the pattern pixel data will continue to be used, but the CRC error count will be incremented. The pattern pixel data field contains raw video information that identifies the fill pattern within the format specified by the video data format descriptor.

17. Read frame buffer packet Read framebuffer packets provide a structure, means, or method for selecting, determining, or identifying a rectangular area of the in-client framebuffer that is sent back to the host via a reverse link. The format of the returned pixel data is the original format of the display, which format is generally specified in the data format descriptor field of the video stream packet sent to the host via the reverse link. The pixel data returned to the host is from the currently displayed image buffer. The client uses as many video stream packets as possible within as many reverse link encapsulation packets as possible to return to the display area identified by the readframe buffer packets, if necessary. A client having this function displays or reports the function using bit 3 of the client feature function display field of the client function packet.

The format of the embodiment for read frame buffer packets is shown in FIG. As shown in Figure 27, this type of packet includes a packet length field, a packet type field, a hClientID field, a display data attribute field, an X left edge field, a Y top field, an X right edge field, a Y bottom field, and a CRC. It is structured to have a field. In one embodiment, this type of packet is typically identified as packet type 74 in the type field.

The 2-byte packet length field specifies the total number of bytes in a packet that does not include the packet length field. In one embodiment, the packet length field is fixed at 16. The 2-byte hClientID field contains the value or information reserved for the ClientID, as previously used. This field can be used by experts in the art to transfer the desired information, but is generally reserved for future use and the current value has a bit of '0' (logical zero). It is set to zero by setting it to level or zero state).

In one embodiment, the 2-byte display data attribute field has a value that identifies where the pixel data is read. Here, bit 0 selects the framebuffer in which the pixel data begins to be read. If bit 0 is equal to the value 0 (logical zero), pixel data is read from the framebuffer of the alternate display identified by bits 8-11. If bit 0 is equal to the value 1 (logical 1), the pixel data is read from the framebuffer of the main display.

In one embodiment, bit 2 of the display data attribute field specifies whether the buffer for the left eye frame buffer or the right eye frame buffer is the source of the data to be read. In general, if the main display supports stereo images, only bit 2 is applicable. If bit 2 is equal to 0 (logical zero level), the left eye framebuffer is the data source, but if bit 2 is equal to 1 (logical 1 level), the right eye framebuffer is the data source.

Bit 3 of the display data attribute field identifies whether the image source for that operation is the buffer used to refresh the display or the offline image buffer. Bit 3 also adapts to the alternate display if the alternate display uses an offline image buffer. However, it does not support source data from the main image buffer if the image destination is an alternate display. Or vice versa. If bit 3 is equal to the value 0, the logical zero level, then the image buffer used to refresh the display is the data source. If bit 3 is equal to the value 1, or logical 1 level, then the offline image buffer is the data source.

Bits 11-8 of the display data attribute field specify an alternate client location or display from which the pixel data is read. Bit 0 is set equal to the value 0 (logical zero) so that the client can interpret bits 11-8 as the number of alternate displays. If bit 0 is not equal to 0, then bits 8-11 are generally set to a logical zero value or level. Bits 1, 4-7, and 12-15 are reserved for future use and are generally set to the logical zero level or zero value.

In one embodiment, the 2-byte X left edge field and Y top edge field identify the left edge X coordinate and the top Y coordinate of the screen window filled by the pixel data field. On the other hand, the X right edge field and the Y bottom edge field specify the X coordinate of the right edge of the updated window and the Y coordinate of the bottom edge.

In one embodiment, the 2-byte CRC field identifies or includes the CRC of all bytes in a packet containing the packet length.

18. Display power status packet Display power status packets are controlled by a particular client when a client such as a display is not used or is currently actively used to minimize drainage or system power consumption on system resources. It provides a structure, means, or method for bringing the controller hardware associated with, or connected to, a client, into a low power state. This type of packet is most useful for interfaces or interface structures for external mode setting or operation, and for protocol applications. In these applications, the external device probably operates with limited power resources, such as a battery, or has other power constraints and anxieties, such as overheating in a limited space. Therefore, the minimum operating state is desired during the period, when it is not active, or when it is not in use. In one embodiment, the client demonstrates the ability to respond to a display power status packet using bit 9 of the client feature function indicator field of the client function packet.

FIG. 28 shows the format of one embodiment for display power status packets. As shown in FIG. 28, in one embodiment, this type of packet is configured to have a packet length field, a packet type field, a hClientID field, a power state field, and a CRC field. This type of packet is commonly identified as a type 75 packet in a 2-byte type field and uses a preselected fixed length of 8 bytes. The 2-byte hClientID field contains the value or information reserved for the ClientID, as already mentioned. This field is reserved for future use and can be used by experts in the art to transfer the desired information, but currently the bit is '0' (logical zero level or state). ) Is set to zero.

The power status field, which is 2 bytes here, identifies the information used to bring a particular device, part of the hardware, or equipment associated with a client, such as a display, to a particular power state. .. When used for a display, bit 0 in this field specifies whether this packet applies to the main display or an alternate display. If bit 0 is equal to 1, the packet applies to the main display. If bit 0 is equal to 0, then the packet applies to the alternate display identified by bits 11-8. Bit 1 is reserved for future use and is generally set to zero.

Bits 3 and 2 of the power state field identify the power state of the display selected by bits 11 and 8 and bit 0. If bit [3: 2] has a value of '00', the selected display will not be illuminated during this state, will consume the least amount of power, and will contain the contents of the framebuffer. Retention is not guaranteed. If bit [3: 2] has a value of '01', the selected display will not be illuminated during this state, a relatively small amount of power will be consumed, and the contents of the framebuffer will be retained. Guaranteed. The display consumes more power in this state than in state 00. The client can use bit 10 of the client feature feature indicator field of the client feature packet to indicate its ability to support state 01. If bit [3: 2] in the power state field has a value of '10', the selected display is illuminated to display the image from the associated framebuffer. The value '11' in bit [3: 2] is a value or state reserved for future use and is not used.

If you are an expert in the art, the use of this packet is most useful for display applications, but the invention is not limited to displays, but other hardware that uses MDDI and is controlled or communicated by clients. You will recognize that there may be other uses, settings, or conditions required or required in connection with the element. In these states, the bits described above can have similar functions, but as will be understood, they can activate the first and second of those elements and set the power level.

In one embodiment, bits 11-8 of the power state field are 4-bit unsigned integers that identify alternative displays to which the power state applies. Bit 0 is set to a theoretical zero value so that the client interprets bits 11-8 as the number of alternate displays. If bit 0 is equal to 1, bits 11-8 are zero.

Bits 7-4 and 15-12 are reserved for future use and are generally set to theoretical zero levels or theoretical zero values for current applications or designs.

The 2-byte CRC field contains the packet length and identifies or contains the CRC of all bytes in the packet.

A summary of display power states generally supported by interface structures or protocols is shown in Table VIII. As can be seen, various combinations of client feature function bits 10 and 9 are used to establish, set, or trigger one of the desired power states. Marks present at predetermined row and column positions indicate that the display power state identified at the top of the column is supported by a combination of client feature function indicator bits. It can be seen that the first and third rows of Table VIII show that only power status "10" is allowed if the client does not have the ability to support display power status packets. Even if the display power state is never sent to the display, one mark indicates that the display is in the "always on" state and will not be replaced by the low power state with this bit set. ..<tables num="11"><img file="JP2010226725A_D0011.tif" /></tables>

19. Execution handoff packet An executable handoff packet is a means, structure, or method used by a host to instruct a client to handoff to the mode specified in this packet. This should be one of the interface type settings supported by the client, as described in Client Feature Packets. Hosts and clients should switch to specific forward and reverse link interface types immediately after this packet is sent. The format of one embodiment of the executable handoff packet is shown in FIG. Hosts and clients that support interface types other than type 1 should have support for this packet. It is generally recommended that the host read the client request and status packet just before sending the executable handoff packet to ensure that the client is in sync with the host.

As shown in FIG. 29, in one embodiment, this type of packet is configured to have a packet length field, a packet type field, an interface type field, a reserved 1 field, a delay filler field, and a CRC field. .. This type of packet is typically identified as a type 77 packet within a 2-byte type field and uses a 6-byte preselected fixed length outside the packet length and delay filler fields.

In one embodiment, the interface type field uses a 1-byte value to identify the new interface type used or applied for the link. The value in this field identifies or displays the interface type by the method shown below. Bits 2 through 0 define the interface type used in the forward link. Here, value 1 means or specifies a handoff to type 1 mode, value 2 to type 2 mode, value 3 to type 3 mode, and value 4 to type 4 mode. Bits 5 to 3 define the interface type used in the reverse link, value 1 to type 1 mode, value 2 to type 2 mode, value 3 to type 3 mode, value 4 to type Mean or specify each handoff to 4 modes. Bits 0,5,7 are currently reserved for future use.

The delay filler prepares or configures the client to switch to a part of the system for use or configuration to use a new interface type that is set at the beginning of the packet immediately following the execution interface type handoff packet. Generated as a means, structure, or method that gives sufficient time for. This field contains 8-bit values or bit groups that are all set to the logical zero level or equal to the logical zero value. The number of bytes used in this field is chosen to be a field of length equal to 64MDDI_Stb cycles. The length of the delay filler field is 16 bytes for the type 1 forward link interface type, 32 bytes for the type 2 interface, 64 bytes for the type 3 interface, and the type 4 forward link interface type. Based on the interface type setting for forward links, which is 128 bytes if specified or used.

The reserved 1 field (1 byte here) is reserved for future use when communicating information. All bits in this field are generally set to the logical zero level. The purpose of such fields is, for now, to align all subsequent 2-byte fields with 16-bit word addresses and 4-byte fields with 32-bit word addresses. The CRC field (here 2 bytes) contains the 16-bit CRC of all bytes in the packet, including the packet length.

20. Forward voice channel enable packet This packet provides a structure, method, or means that allows a host to enable or disable a client's voice channel. This feature allows a client (eg, a display) to power off a voice amplifier or similar circuit element to save power when there is no sound output by the host. This is fairly difficult to achieve implicitly using the presence or absence of an audio stream simply as an indicator. The default state when the client system is powered up is that all audio channels are enabled. The format of one embodiment of the forward voice channel enable packet is shown in FIG. As shown in FIG. 30, this type of packet is structured to have a packet length field, a packet type field, a hClientID field, a voice channel enable mask field, and a CRC field. This type of packet is typically identified as packet type 78 in a 1-byte field and uses a preselected fixed length of 4 bytes.

21. Reverse voice sample rate packet Packets of this type provide structures, methods, and means that allow a host to enable or disable voice channels within a client. This feature is useful and allows the client to power off the audio amplifier to save power in the absence of audio output by the host. It is very difficult to perform absolutely with the presence or absence of an audio stream. The default state, when the client system is powered on or connected to a host, has all audio channels enabled. The voice system connected to the host and client receives a forward voice channel enable packet with at least one of the bits in the voice channel enable mask field that has transitioned from 0 to 1 after the client receives a state or value transition. Within about 100 milliseconds or less, the output of the audio signal must be prepared or able to be output in the intended or desired manner. The client indicates the ability to respond to a forward voice channel enable packet using the value set in bit 15 of the voice channel function field of the client function packet.

This packet allows the host to enable or disable the reverse link audio channel and configure audio data samples for this stream. The host chooses a sample rate that is defined as valid in the client function packet. If the host chooses an invalid sample rate, the client may not send a voice stream to the host and the appropriate error, error value, or error signal may be sent to the host in a client error report packet. The host may disable the reverse link audio stream by setting the sample rate to a value of 255. The default state assumed when the client system is first powered up or connected is that the reverse link audio stream is disabled. The format of one embodiment of the reverse voice sample rate packet is shown in FIG. As shown in FIG. 31, this type of packet is structured to have a packet length field, a packet type field, a hClientID field, a voice sample rate field, a reserved 1 field, and a CRC field. This type of packet is typically identified as packet type 79 and uses a preselected fixed byte of 4 bytes.

22. Digital Content Protection Overhead Packet This packet provides a structure, method, or means that allows the host and client to exchange messages regarding the digital content protection method being used. Currently, two types of content protection are being considered: Digital Transmission Content Protection (DTCP) or High Bandwidth Digital Content Protection System (HDCP), where space is reserved for future alternative protection scheme names. The method used is specified by the content protection type parameter of this packet. The format of one embodiment of the digital content protection overhead packet is shown in FIG. As shown in FIG. 32, this type of packet is structured to have a packet length field, a packet type field, a bClientID field, a content protection type field, a content protection overhead message field, and a CRC field. This type of packet is usually identified as packet type 80.

23. Transparent color enable packet A transparent color enable packet is a structure, method, or means used to specify which color is transparent on a display and to disable the use of transparent color to display an image. In one embodiment, the client or display having this function reports its function in the client feature function field 4 of the client function packet. When a pixel with a transparent color value is written to the bitmap, the color does not change from the past value. The format of the transparent color enable packet is shown in Figure 33. As shown in FIG. 33, in one embodiment, this type of packet has a packet length field, a packet type field, a hClientID field, a display data attribute field, a reserved 1 field, a data format descriptor field, and a transparent color value. It is structured to have fields, transparent mask value fields, and CRC fields. This type of packet is typically identified as packet type 81 in a 1-byte field and uses a fixed length of 16 bytes, which is preselected.

The hClinetID field is reserved for use as a future ClientID and is generally set to a zero value (logical zero bit).

In one embodiment, the 2-byte display data attribute field has a value that identifies where the transparent pixel color applies. Here, bit 0 selects the display to which the transparent pixel color is applied. If bit 0 is equal to the value 0 (logical zero), the transparent pixel color is applied to the alternate display identified by bits 8-11. If bit 0 is equal to the value 1 (logical 1), a transparent pixel color is provided to the main display.

In one embodiment, bit 1 selects or specifies whether the transparent color field or mask field contains a transparent color or transparent mask. If bit 0 is equal to zero (logical zero), the transparent color field or mask field contains the transparent color value used in the next raster operation or when decoding a video stream packet or a scaling video stream packet. .. If bit 0 is equal to 1 (logical 1), the transparent color or mask field contains the transparent mask value used in the next raster operation or when decoding a video stream packet or a scaling video stream packet. ..

Bits 11-8 of the display data attribute field specify the display or alternate client location to which the transparent pixel color is applied. Bit 0 is set equal to the value 0 (logical zero) so that the client interprets bits 11-8 as the number of alternate displays. If bit 0 is not equal to 0, bits 8 to 11 are generally set equal to the logical zero value or level and are ignored.

Bits 7 to 2 and bits 15 to 12 of the display data attribute field are reserved for future use and are generally set to logical zero levels or zero values.

A 2-byte reserved 1 field is reserved for future use. All bits in this field are generally set to zero (logical zero level or state). In one embodiment, one purpose of this field is to align all subsequent 2-byte fields to 16-bit word addresses and 4-byte fields to 32-bit word addresses.

In one embodiment, the video data format descriptor field of the transparent color enable packet uses 2 bytes to identify the format of the transparent color value. FIG. 11 shows how the video data format descriptor is encoded. This format is generally the same as the same field in a video stream packet.

In one embodiment, the transparent color value field is several bytes for the pixel value used as the transparent color value in the next raster operation or when decoding a video stream packet or a scaling video stream packet. Used to identify or assign (in this example, specified as the packet length, for a field with no value, divided by 2 to share with the transparent mask field 12). The format of the value is specified in the video data format descriptor field. An example of a pixel format for transparent colors is the same as shown above. When the Y Cb Cr format is selected, the transparent color and transparent mask generally have the exact subfields for pixels 1 and 2 Cb, pixel 1Y, pixels 1 and 2 Cr, and pixel 2Y, as shown earlier. Included in. The number of bytes allocated for the transparency value is determined by the video data format descriptor field.

In one embodiment, the transparent mask value field is several bytes for the pixel value used as the transparent mask in the next raster operation or when decoding a video stream packet or a scaling video stream packet (this). In the example, it is specified as the packet length and is for a field with no value and is used to identify or assign 12) divided by 2 to share with the transparent mask field. The format of this value is the same as the format of the transparent color value specified in the video data format identifier field. The number of bytes allocated to this field is determined by the video data format descriptor field. The length of this field is the same as the length of the transparent color value field.

In one embodiment, the transparent color or mask value field is 4 bytes for the pixel value used as the value of either the transparent color or the transparent mask specified by bit 1 of the display data attribute field. Use or assign. The format of this pixel is specified in the video data format identifier field.

The CRC field uses 2 bytes to include or represent the CRC of all bytes in the packet containing the packet length.

24. Round trip delay measurement packet A round-trip delay measurement packet provides a structure, method, or means used to measure a host-to-client (display) propagation delay, plus a delay back from the client (display) to the host. This measurement includes delays inherent in line drivers and line receivers, as well as interconnect subsystems. The measurements are usually used to set the redirection delay and the reverse link velocity divisor parameter to the reverse link encapsulation packet described above. This packet is most useful when the MDDI link is operating at the maximum speed intended for a particular application. Packets are transmitted at low data rates in type 1 mode to increase the range of round-trip delay measurements. The MDDI_Stb signal behaves as if all zero data was transmitted between the following fields. That is, both guard times, all zeros, and the measurement period. This causes MDDI_Stb to toggle at half the data rate so that it can be used as a periodic clock within the client during the measurement period.

In one embodiment, the client typically exhibits the ability to support a round-trip delay measurement packet by using bit 18 of the client feature function indicator field of the client function packet. It is recommended that all clients support round trip delay measurements, but the host can know the worst case round trip delay based on the maximum cable delay and based on the maximum driver and receiver delay. Since this is an aspect of known design elements (copper length, network type, features, etc.) of the device in which the interface is used, the host reciprocates prior to the MDDI link used in internal mode. You may also know the delay.

The format of the round-trip delay measurement packet is shown in Figure 34. As shown in FIG. 34, in one embodiment, this type of packet has a packet length field, a packet type field, a hClientID field, a parameter CRC field, a guard time 1 field, a measurement period field, a total zero field, and a guard. It is configured to have a time 2 field. This type of packet is typically identified as packet type 82 and uses a preselected fixed length of 200 bits.

The timing of the events that occur during the round-trip delay measurement packet is shown in Figure 35. In Figure 35, the host sends a round-trip delay measurement packet indicated by the presence of a parameter CRC field followed by a guard time 1 field and a strobe alignment field. Delay 3502 occurs before the packet reaches the client display unit or processing network. When the client receives the packet, it sends 30 bytes of the 0xff, 0xff and 0x0 patterns as accurately as possible at the beginning of the measurement period as determined by the client. The actual time the client begins sending this sequence is delayed from the beginning of the measurement period from the host's point of view. This amount of delay is essentially the time it takes for a packet to propagate through a line driver and receiver and interconnect subsystems (cables, leads). A similar amount of delay 3504 occurs for patterns where the pattern propagates from the client to the host and returns.

To accurately determine the round-trip delay time to and from the client, the host detects the beginning of the 0xff, 0xff, and 30-byte 0x0 sequences upon arrival after the start of the measurement period. Count the number of forward link bit time periods that occur up to. This information is used to determine the amount of time that the round-trip delay signal passes from the host to the client and back again. When a type 2-4 reverse link or mode is used, the host will allow the data rate and round-trip delay distortion to affect the arrival time of each bit separately if sufficient. Measure and store round-trip delay values for all MDDI_Data pairs.

Both the host and the client drive the MDDI_DATA line to a logical zero level during both guard times to keep it in place. The host and client enable and disable times during both guard times ensure that the MDDI_Data signal is at a low level that is valid for any valid round-trip delay time.

Both the host and the client drive the line to the logical zero level during the guard time and keep the MDDI_Data line in the defined state. The host and client enable and disable times during both guard times ensure that the MDDI_Data signal is at a low level that is valid for any valid round-trip delay time.

25. Forward link distortion calibration packet In one embodiment, the forward link distortion calibration packet allows the client or display to calibrate itself for differences in the propagation delay of the MDDI_Data signal with respect to the MDDI_Stb signal. Without delay distortion compensation, the maximum data rate is usually limited to take into account the potential worst-case variability of these delays. Normally, this packet is sent only when the forward link data is configured at a speed of about 50 Mbps or less. After sending this packet to calibrate the display, the data rate is enhanced beyond 50Mbps. If the data rate is set too high during the distortion compensation process, the display will turn off the delay distortion compensation setting for more than one bit, resulting in incorrect data clocking, a bit period alias. May be synchronized with. The highest data rate type interface or maximum possible interface type is selected before sending the forward link distortion calibration packet so that all existing data bits are calibrated. The client uses bit 19 of the client feature function indicator field of the client feature packet to indicate its ability to support forward link distortion calibration packets.

Before performing distortion calibration, the host should not send data faster than the rate specified by the precalibration data rate function field of the client function packet. However, after calibration is facilitated, the host may send data up to the rate defined by the post-calibration data rate feature field. It is recommended that the host send forward link distortion calibration packets at regular intervals to compensate for changes in relative delay between different signal pairs due to temperature changes.

One embodiment of the forward link distortion calibration packet format is shown in FIG. As shown in Figure 56, this type of packet has a packet length (2 bytes) field, a packet type field, a hClientID field, a parameter CRC field, a zero 1 field, a calibration data sequence field and a zero 2 field. It is structured like this. This type of packet is usually identified as type 83 in the type field.

Virtual control panel The Virtual Control Panel (VCP) allows the host to set specific user controls on the client. By allowing these parameters to be adjusted by the host, the client's user interface has a screen that allows the user to adjust parameters such as voice volume or display brightness by one or more microprocessors within the client. Rather, it can be simplified because it can be generated by the host software. The host has the ability to read the client's parameter settings and find the range of valid values for each control. The client generally has the ability to report to the host which control parameters can be adjusted.

Control codes (VCP codes) and commonly specified related data values are utilized to specify client controls and settings. The MDDI-specified VCP code is expanded to 16 bits to store proper data field alignment in the packet definition and to support supplemental values that are unique to this interface or future enhancements in the future. ..

26. VCP feature request packet The VCP feature request packet provides a means, mechanism or method for the host to request the current settings of a particular control parameter or all valid control parameters. In general, the client responds to the VCP packet with the appropriate information in the VCP feature response packet. In one embodiment, the client demonstrates the ability to support VCP feature request packets using bit 13 of the client feature feature indicator of the client feature packet.

The format of the VCP feature request packet is shown in Figure 69. As can be seen in FIG. 69, this type of packet is structured to have a packet length field, a packet type field, a hClientID field, a display selector field, a monitor control command set (MCCS) VCP code field and a CRC field. There is. This type of packet is typically identified in one embodiment as type 128 shown in a 2-byte field. The packet length, which specifies the total number of bits in a packet that does not include the packet length field, is typically fixed at 10 bits for this type of packet.

The hClientID field is reserved for use as a client ID in future implementations and is generally set to zero.

In one embodiment, the VCP feature response packet specifies the display to which the VCP packet applies. Bit 0 in the display selector field selects the display to which the VCP packet fits. If bit 0 is equal to 0, the VCP packet fits the alternate display identified by bits 11-8. On the other hand, if bit 0 is equal to 1 and logical 1 level, the VCP packet fits the main display. Currently, bits 7 to 1 of the display selector field are reserved for future use and are generally set to zero values. That is, the bits are set to the logical zero level.

Bits 11-8 of the display selector field use a 4-bit unsigned integer value to identify an alternative display to which the VCP packet fits. If bit 0 of the display selector field is equal to 0 (logical zero level), the client interprets bits 11-8 as the number of alternate displays. If bit 0 is not equal to 0, bits 11-8 are set to zero and ignored. Bits 15-12 are reserved for future use and are generally set to zero values. That is, each bit is set to the logical zero level.

In one embodiment, the MCCS VCP code field comprises two bytes of information that identifies the MCCS VCP control code parameters. A value in the range 0-255 causes the VCP feature response packet to return with a single item in the VCP feature response list that corresponds to the identified MCCS code. The MCCS VCP code consisting of 65535 (0xffff) requires a VCP feature response packet with a VCP feature response list containing feature response list items for each control supported by the client. For this field, values between 256 and 65534 are reserved for future use and are not currently in use.

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

27. VCP feature response packet The VCP feature response packet provides a means, mechanism or method for a client to respond to a host request with the current settings of a particular control parameter or all control parameters. Generally, the client sends a VCP feature response packet in response to a VCP feature request packet. This packet determines the current settings for a particular parameter, determines the effective range for a particular control, determines if a particular control is supported by the client, or is a control supported by the client. It is useful for determining the set of. When a VCP feature request is sent that references a particular control that is not implemented within the client, the VCP feature response packet is returned with a single VCP feature response list item that corresponds to the unimplemented control with the appropriate error code. In one embodiment, the client demonstrates the ability to support VCP feature response packets using bit 13 of the client feature feature field of the client feature packet.

The format of the VCP feature response packet in one embodiment is shown in Figure 70. As can be seen in Figure 70, this type of packet now has a packet length field, a packet type field, a cClientID field, a display selector field, an MCCS version field, a response sequence number field, a VCP feature response list field, and a CRC field. It is structured. Usually in one embodiment, this type of packet is identified as type 129 as shown in the 2-byte field.

The cClientID field contains information reserved for the client ID. This field is reserved for future use and is usually set to zero.

In one embodiment, the 2-byte display selector field in the VCP feature response packet specifies the display to which the VCP packet applies. Bit 0 in the display selector field selects the display to which the VCP packet applies. If bit 0 is equal to 0, the VCP packet fits the alternate display identified by bits 11-8. On the other hand, if bit 0 is equal to 1 and logic 1 level, the VCP packet fits the main display. Currently, bits 7 to 1 of the display selector field are reserved for future use and are generally set to zero values. That is, each bit is set to the logical zero level.

Bits 11-8 of the display selector field use a 4-bit unsigned integer value to identify an alternative display to which the VCP packet fits. If bit 0 of the display selector field is equal to 0 (logical zero level), the client interprets bits 11-8 as the number of alternate displays. If bit 0 is not equal to 0, bits 11-8 are set to zero and ignored. Bits 15-12 are reserved for future use and are generally set to zero. That is, each bit is set to the logical zero level.

The MCCS version field contains 2-byte information that specifies the version of the VESA MCCS specification implemented by the client.

The 2-byte response sequence number field contains information or data that specifies the sequence number of the VCP feature response packet returned by the client. The client returns one or more VCP feature response packets in response to the VCP feature request packet, with an MCCS control code value of 65535. The client may spread or forward the feature response list with multiple VCP feature response packets. In this case, the client should assign a sequence number or identifier to each contiguous packet. The sequence number of the VCP feature response packet transmitted in response to a single VCP feature request packet generally starts at zero and increments by one. The VCP feature list item in the last VCP feature response packet is an MCCS equal to 0xffff to identify that the packet is the last packet. It must contain the VCP control code value and contains the highest sequence number of the group of packets returned. If only one VCP feature response packet is sent in response to a VCP feature request packet, the response sequence number within that single packet is generally set to zero, and the VCP feature response list is a VCP feature response list equal to 0xffff. Contains list items that have the MCCS VCP code within the item. The maximum and current values fields in the VCP feature response list item packet (Figure 71) are set to zero if the MCCS VCP control code is equal to 0xffff.

The VCP feature response list field is a group of bytes containing one or more VCP feature response list items, while the number of features in the list field is the VCP feature response list in the VCP feature response list in this packet. Contains 2 bytes to specify the number of items. The format of a single VCP feature response list item in one embodiment is shown in Figure 71.

As shown in Figure 71, each VCP feature response list item is exactly 12 bytes in length and includes an MCCS VCP code field, a result code field, a maximum value field, and a current value field. The 2-byte MCCS VCP control field contains data or information that specifies the MCCS VCP control code parameters associated with this list item. In this embodiment, only the control code values specified in the VESA MCCS specification version 2 and later are considered valid. The 2-byte result code field contains information that specifies the error code associated with requesting information for the specified MCCS VCP control. A value of "1" means that the specified control is not implemented on the client, while a value of "0" in this field means that there are no errors. Additional values in this field from 2 to 65535 are currently reserved for future use and implementation of other applications to be considered by the technology, but will not be used for the time being.

The 4-byte maximum value field specifies the maximum possible value at which the specified MCCS control can be set. This value is set to zero if the required control is not achieved within the client. If the length of the returned value is less than 32 bits (4 bytes), the value is placed inside a 32-bit integer and the most significant (unused) byte is left set to zero. The 4-byte current value presentation field contains information that specifies the current value of the specified MCCS VCP continuous (C) or discontinuous (NC) control. This value is set to zero if the requested control is not implemented on the client, or if control is achieved but is of the table (T) data type. If the specified MCCS VCP corresponds to a discontinuous control or table data type, this maximum field is set or selected to zero.

28. VCP feature setting packet The VCP feature setting packet provides a means, mechanism or method for the host to set the VCP control value for both continuous control and discontinuous control within the client. In one embodiment, the client demonstrates the ability to support VCP featured packets using bit 13 of the client feature feature field of the client feature packet.

The format of the VCP feature setting packet in one embodiment is shown in FIG. As can be seen in Figure 72, this type of packet now has a packet length field, a packet type field, a hClientID field, a display selector field, an MCCS VCP code field, a number of values in the list, a control value list field, and a CRC field. It is structured in. This type of packet is typically identified as type 130, as indicated by a 2-byte field, and is 20 bytes long, excluding the packet length field.

In one embodiment, the hClientID field uses a double-byte value to specify it again as the ClientID or to act as the ClientID. This field has been reserved for future specifications and is currently set to zero.

In one embodiment, the 2-byte display selector field in the configured VCP feature packet specifies where to apply the VCP packet. Bit 0 in the display selector field selects the display to which the VCP packet fits. If bit 0 is equal to 0, the VCP packet fits the alternate display identified by bits 11-8. On the other hand, if bit 0 is equal to 1, that is, at logical 1 level, the VCP packet fits the main display. Currently, bits 7 to 1 of the display selector field are reserved for future use and are generally set to zero values. That is, the bits are set to the logical zero level.

Bits 11-8 of the display selector field identify an alternative display to which the VCP packet fits. If bit 0 of the display selector field is equal to 0 (logical zero level), the client interprets bits 11-8 as the number of alternate displays. If bit 0 is not equal to 0, bits 11-8 are set to zero and ignored. Bits 15-12 are reserved for future use and are generally set to zero values. That is, each bit is set to the logical zero level.

The MCCS VCP code field for the configured VCP feature packet uses 2-byte information or value to specify the MCCS VCP code parameter to be adjusted. The value field in the 2-byte list contains information or values that specify the number of 16-bit values present in the control value list. The control value list usually contains one item unless the MCCS control code is related to a table in the client. For non-table-related controls, the control value list will contain values that specify new values to be written to the control parameters specified by the MCCS VCP code field. For table-related controls, the format of the data in the control value list is specified by the parameter description in the specified MCCS VCP code. If the list contains a value greater than 1 byte, the least significant bit is sent first consistently with the method defined elsewhere. Finally, the 2-byte CRC field contains the 16-bit CRC of all bytes in the packet, including the packet length.

29. Valid parameter request packet The valid parameter request packet is used as a means or structure to help the client request that it return a valid parameter response packet containing a list of parameters supported by the specified discontinuous (NC) or table (T) control. Will be done. This packet must specify only non-contiguous (NC) controls or controls related to the client's table and must not specify an MCCS VCP code value of 65535 (0xffff) to specify all controls. .. If an unsupported or invalid MCCS VCP code is specified, the appropriate error value is returned in the valid parameter response packet. In one embodiment, the client demonstrates the ability to support a valid parameter request packet using bit 13 of the client feature function field of the display function packet.

The format of the valid parameter request packet in one embodiment is shown in FIG. As shown in FIG. 73, this type of packet is structured to have a packet length field, a packet type field, a hClientID field, a display selector field, an MCCS VCP code field and a CRC field. This type of packet is usually identified in one embodiment as type 131, as shown in the double type field.

As shown in the 2-byte packet length field, the packet length is usually set to have the total number of bytes in the packet without including the packet length field of 8. The hClientID specifies the client ID again, but is currently reserved for future use and is set to a zero value or logical zero level as will be apparent to those skilled in the art.

In one embodiment, the 2-byte display selector field in the request valid parameter packet specifies where to apply the VCP packet. Bit 0 in the display selector field selects the display to which the VCP packet fits. If bit 0 is equal to 0, the VCP packet applies to the alternate display identified by bits 11-8. On the other hand, if bit 0 is equal to 1, i.e. logical 1 level, the VCP packet fits the main display. Currently, bits 7 to 1 of the display selector field are reserved for future use and are generally set equal to zero. That is, the bits are set to the logical zero level.

Bits 11-8 of the display selector field identify an alternative display to which the VCP packet fits. If bit 0 of the display selector field is equal to 0 (logical zero level), the client interprets bits 11-8 as the number of alternate displays. If bit 0 is not equal to 0, bits 11-8 are set to zero and ignored. Bits 15-12 are reserved for future use and are generally set to zero values. That is, each bit is set to the logical zero level.

The 2-byte MCCS VCP code field of the request valid parameter packet contains a value that specifies the discontinuous MCCS VCP control code parameter to be queried. The value of this field should correspond to the discontinuous control provided by the client. Values 256-65535 (0xffff) are usually considered reserved or invalid and are considered unrealized controls in the error response. The CRC field, which is 2 bytes here, includes the CRC of all bytes in the packet including the packet length.

30. Valid parameter response packet The valid parameter response packet is transmitted in response to the valid parameter request packet. It is used as a means, method or structure for identifying valid settings for discontinuous MCCS VCP control or control that returns table contents. If the control is about a table in the client, the VCP parameter response list simply contains a specific list of requested sequential table values. If the contents of the table do not fit into a single valid parameter response packet, multiple packets with sequential response sequence numbers can be sent by the client. In one embodiment, the client demonstrates the ability to support a valid parameter response packet using bit 13 of the client feature function field of the client function packet.

The host may request the contents of the table as follows: The host sends a VCP featured packet configuration that includes the required or desired parameters such as read / write parameters, look-up table (LUT) offset, and RGB selection. A valid parameter request packet specifying the desired control is then sent by the host, and then the client returns one or more valid parameter response packets containing table data. This sequence of operations performs a similar function as the table read function described in the MCCS operation model.

If a particular client parameter is not supported by the client, in one embodiment the corresponding field of this packet will contain the value 255. For parameters used by the client, the corresponding field must contain the value of the parameter within the client.

The format of the valid parameter response packet of one embodiment is shown in FIG. As can be seen in Figure 74, this type of packet is a packet length field, a packet type field, a cClientID field, a display selector field, an MCCS VCP code field, a response code field, a sequence number response field, a number value field in a list, a VCP parameter. It is structured to have a response list field and a CRC field. This type of packet is typically identified for an embodiment as type 132 as shown in the 2-byte field.

The cClientID field is reserved for future client IDs, as is known from the above description.

In one embodiment, the 2-byte display selector field contains information about where to apply the VCP packet. Bit 0 in the display selector field selects the display to which the VCP packet applies. If bit 0 is equal to 0, the VCP packet fits the alternate display identified by bits 11-8. On the other hand, if bit 0 is equal to 1 and logical 1 level, the VCP packet fits the main display. Currently, bits 7 to 1 of the display selector field are reserved for future use and are generally set equal to zero. That is, the bits are set to the logical zero level.

Bits 11-8 of the display selector field identify an alternative display to which the VCP packet fits. If bit 0 is equal to 0 (logical zero level), the client interprets bits 11-8 as the number of alternate displays. If bit 0 is equal to 0, bits 11-8 are set to zero and ignored. Bits 15-12 are reserved for future use and are generally set to zero values. That is, each bit is set to the logical zero level.

In one embodiment, the 3-byte MCCS VCP code packet contains a value that identifies the discontinuous MCCS VCP control code parameter described by this packet. If an invalid MCCS VCP control code is identified by a request valid parameter packet, the invalid parameter value is also identified in this field with the appropriate value in the response code field. If the MCCS control code is invalid, the VCP parameter response list will have zero length. The response code field is the specified MCCS Contains 2-byte information or values that specify the nature of the response associated with the request for information about VCP control. If the value of this field is equal to 0, the error is not considered to be in this data type and the last valid parameter response packet in the sequence is sent, which has the highest response sequence number. If the value of this field is equal to 1, no error is considered to be present, but another valid parameter response packet with a higher sequence number is sent. If the value of this field is equal to 2, the specified control is not considered to be implemented on the client. If the value of this field id is equal to 3, then the specified control is not discontinuous control (it is continuous control that always has a valid set of all values from zero to its maximum value). Values in this field equal to 4 to 65535 are reserved for future use and should not normally be used.

The 2-byte response sequence number field specifies the sequence number of the valid parameter response packet returned by the client. The client returns one or more valid parameter response packets in response to the valid parameter request packet. The client may expand the VCP parameter response list on multiple valid parameter response packets. In this latter case, the client assigns a sequence number to each consecutive packet and sets the response code to 1 for all but the last packet in the sequence. The last valid parameter response packet in the sequence has the highest response sequence number and the response code contains the value 0.

The Number of Values field in the 2-byte list specifies the number of 16-bit values that exist in the VCP parameter response list. If the response code is not equal to zero, then the number parameter of the values in the list is zero. The VCP parameter response list field contains a list of 2-byte values from 0 to 32760 that represent the set of valid values for discontinuous control specified by the MCCS control code field. The definition of discontinuous control code is specified in the VESA MCCS specification. Finally, in the present embodiment, the CRC field includes a 16-bit CRC of all bytes in the packet including the packet length.

Scaling video stream image MDDI or a protocol mechanism, structure, means, or method provides support for a scaled video stream image that allows the host to send the image to a client that is scaled larger or smaller than the original image. Copied to the main image buffer. An overview of scaled video stream functionality and related protocol support can be found elsewhere. The ability to support scaled video streams is defined by or within the scaling video stream feature sent in response to special status request packets.

The header of the scaling video stream packet described below is slightly different from the simpler video stream packet, which has a header that contains the entire context needed to display the image. This scaled video stream packet uses a setup packet that defines the source and destination window size and location, and another scaled video stream packet that sends pixel data. The client allocates an internal storage associated with each stream to store stream parameters from the setup packet and a portion of the pixel data associated with each stream. The storage capacity required for each stream depends on the size of the source and target images and the values identified in the setup packet. For this reason, the protocol is designed to allow clients to perform dynamic memory allocation for the storage associated with each scaling video stream.

It is useful to send the video stream to a display with a size derived from the program source and have a display scale and position. Performing real-time scaling of multiple video images is very complex and the client cannot optionally support this feature.

31. Scaling video stream feature packets Scaling Video Stream Features Packets define the characteristics of a scaling video stream source image within or used by a client. Scaling video stream feature packets are generally shown in Figure 79. As can be seen in FIG. 79, in one embodiment, the scaling video stream function packet is a packet length field, a packet type field, a cClientID field, a maximum number of streams field, a source maximum X size field, a source maximum Y size field, an RGB function field, Black and white function field, reserved 1 field, Y Cr It is structured to have a Cb functional field, a reserved 2 field and a CRC field. In one embodiment, the packet length includes a 2-byte cClientID field and a CRC field that are reserved for use with the client ID and otherwise set to zero, as shown in the length field. Selected to be a fixed 20 bytes. In one embodiment, the client demonstrates the ability to support a scaled video stream feature packet with a parameter value of 143 in the valid parameter response list of the valid status response list packet.

The 2-byte maximum stream count field contains a value that identifies the maximum number of simultaneous scaling video streams that may be allocated at one time. In one embodiment, the client must reject the request to allocate the scaling video stream if the maximum number of scaling video streams has already been allocated. If less than the maximum number of scaling video streams are allocated, the client may reject the allocation request based on other resource limits on the client.

The source maximum X size field and the Y size field (2 bytes) specify the maximum width and height values for the scaling video stream source image, represented as many pixels, respectively.

The RGB function field uses a value to specify the number of bits of resolution that can be displayed in RGB format. If the scaling video stream cannot use the RGB format, this value is set equal to zero. Bits 5-12 are reserved for future use in future feature definitions and are usually set to zero, but the RGB feature word is bit 3 that defines the maximum number of blue bits (blue brightness) for each pixel. 3 separate unsigned bits from 0 to 0, bits 7 to 4 that define the maximum number of green bits (green brightness) for each pixel, and bits 11 to 8 that define the maximum number of red bits (red brightness) for each pixel It consists of values.

The 1-byte black-and-white function field contains a value that specifies the number of resolution bits that can be displayed in the black-and-white format. This value is set to zero if the scaled video stream cannot use the black and white format. Bits 7-4 are reserved for future use, so as will be appreciated by those skilled in the art, this may change over time but is zero (0) for current applications. Must be set to. Bits 3 to 0 define the maximum number of grayscale bits that can exist in each pixel. These four bits allow you to specify that each pixel consists of 1 to 15 bits. If the value is zero, the black and white format is not supported by the scaling video stream.

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

The 2-byte Y Cb Cr functional field contains a value that specifies the number of resolution bits that can be displayed in the Y Cb Cr format. This value is zero if the scaling video stream cannot use the Y Cb Cr format. The Y Cb Cr function word consists of three separate unsigned values. That is, bits 3 to 0 that define the maximum number of bits that specify the Cr sample, bits 7 to 4 that define the maximum number of bits that specify the Cb sample, and bits 11 to 8 that define the maximum number of bits that specify the Y sample. is there. And bits 15-12 are reserved for future use and are usually set to zero.

The 1-byte functional bit field contains a set of flags that specify the features associated with the scaling video stream. The flags are defined as follows: Bit 0 covers the pixel data of the scaling video stream packet and can be in pack format. The packed and byte-aligned data is shown above in FIG. Bit 1 is reserved for future use and is usually set to zero. Bit 2 is also reserved for future use and set to zero. Bit 3 covers a scaling video stream that can be specified in the colormap data format. The same colormap table is used for the scaling video stream as it is used for the main image buffer and the alpha-cursor image plane. Colormaps are constructed using colormap packets described elsewhere. And bits 7-4 are reserved for future use and are usually set to zero.

The reserved 2 field (1 byte here) is reserved for future use in providing values related to scaling video stream packet information or data. Therefore, all values in this field are currently set to logical "0". One purpose of this field is to align all subsequent 2-byte fields to 16-bit word addresses and 4-byte fields to 32-bit word addresses.

32. Scaling video stream setup packet Scaling video stream setup packets provide the means, structure, or method used to define the parameters of a scaling video stream, and information for the client to allocate internal storage for image buffering and scaling. To use. The stream may be deallocated by sending this packet with the X and Y image size fields equal to zero. The deallocated scaling video stream may later be reassigned with the same or different stream parameters. In one embodiment, the client uses a parameter value of 143 in the valid parameter response list of the valid status response list packet, and a non-zero value in the maximum stream count field of the scaling video stream feature packet to scale the video stream. Shows the ability to support setup packets.

The format of the scaling video stream setup packet is generally shown in Figure 80. As can be seen in FIG. 80, in one embodiment, the scaling video stream setup packet has a packet length field, a packet type field, a hClient field, a stream ID field, a visual data format descriptor field, a pixel data attribute field, and an X left edge field. , Y upper edge field, X right edge field, Y lower edge field, X image size field, Y image size field, and CRC field.

The 2-byte packet length field specifies the total number of bytes in the packet that does not include the packet length field. In one embodiment, this packet length is fixed at 24. The 2-byte packet type field uses the value 136 to identify the packet as a scaling video stream setup packet. The 2-byte hClientID field is reserved for future use as a client ID, usually for the time being, or until the protocol user decides which ID value should be used, as is known. All bits are set to the logical zero value.

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

In one embodiment, the video data format descriptor field uses 2 bytes to specify the format of each pixel of the pixel data of the stream of the packet. The pixel data format shall be at least one of the valid formats of the alpha-cursor image plane that can be defined in the alpha cursor image function packet, or any other predefined pattern as commonly defined within the other packets described above. Must be compliant. The video data format descriptor defines a pixel format dedicated to the current packet and does not imply that a certain format will continue to be used for the life of a particular video stream. FIG. 12 illustrates how the video data format descriptor is encoded, as described above for the other packets.

For example, as shown in FIGS. 12A-12D, for use in one embodiment, if bit [15:13] is equal to '000', the video data consists of an array of black and white pixels. Here, many bits per pixel are defined by bits 3 to 0 in the video data format descriptor. Bits 11-4 are generally reserved for future use or application and are set to zero in this case. On the other hand, if bit [15:13] is equal to the value '001', the video data consists of an array of color pixels, each identifying a color from a color map (palette). In this case, bits 5-0 of the video data format descriptor define the number of bits per pixel, and bits 11-6 are generally reserved for future use or application and are set equal to zero. .. If bit [15:13] is equal to the value '010', the video data consists of an array of color pixels. Here, the bit numbers for the red pixels are defined in bits 11-8, the bit numbers for the green pixels are defined in bits 7-4, and the bit numbers for the blue pixels are defined in bits 3-0. To. In this case, the total number of each pixel is the total number of bits used for red, green, and blue.

However, as shown in Figure 12D, if bit [15:13] is equal to a value or string '011', the video data comes from an array of 4: 2: 2 YCbCr format video data with luminance and chrominance. Become. Here, the bit number of each pixel of luminance (Y) is defined by bits 11 to 8, the bit number of the Cb component is defined by bits 7 to 4, and the bit number of the Cr component is defined by bits 3 to 0. To. The total number of bits in each pixel is the total number of bits used for red, green, and blue. The Cb and Cr components are sent at half the rate of Y. Further, the video sample in the pixel data part of this packet is configured as Cbn, Yn, Crn, Yn + 1, Cbn + 2, Yn + 2, Crn + 2, Yn + 3, .... Here, Cbn and Crn are related to Yn and Yn + 1, and Cbn + 2 and Crn + 2 are related to Yn + 2 and Yn + 3. Yn, Yn + 1, Yn + 2, and Yn + 3 are the brightness values for four consecutive pixels from left to right in one row.

I explained all four formats. Bit 12, indicated as P in the figure, identifies whether the pixel data sample is packed or the byte-arranged pixel data. A value of '0' in this field indicates that each pixel in the pixel data field is byte-aligned at the MDDI byte boundary. A value of '1' indicates that each pixel in the pixel data and each color within each pixel is packed with respect to the previous pixel or the color within a pixel that leaves no unused bits.

In one embodiment, the 2-byte pixel data attribute field is generally set to logical zero and interpreted with bit 1 and bit 0 reserved for future use, as follows: Bit 2 then indicates whether the pixel data is in interlaced format. When bit 2 is 0, the pixel data is in standard gradual format. The line number (pixel Y coordinate) is incremented by 1 from one line to the next. When bit 2 is 1, the pixel data is in interlaced format. The line number (pixel Y coordinate) is incremented by 2 from one line to the next.

In one embodiment, bit 3 indicates whether the pixel data is in an alternative pixel format. This is similar to the standard interlace mode enabled by bit 2, but the interlace is vertical instead of horizontal. When bit 3 is 0, pixel data is generated or placed in standard gradual format. The column number (pixel X coordinate) is incremented by 1 when each successive pixel is received. When bit 3 is 1, pixel data is generated or placed in an alternative pixel format. The column number (pixel X coordinate) is incremented by 2 as each pixel is received.

Bits 4 to 15 are also reserved for future use and are generally set to a logical zero level or value for the current application or design.

33. Scaling video stream acknowledgment packets The scaled video stream acknowledgment packet allows the client to confirm receipt of the scaled video stream setup packet. The client supports scaling video stream acknowledgment packets via the parameter value 143 in the valid parameter response list of the valid status response list packet and through the non-zero value in the maximum stream number field of the scaling video stream feature packet. Can show ability.

The format of the scaled video stream acknowledgment packet is generally shown in Figure 81. As can be seen in FIG. 81, in one embodiment, the scaling video stream acknowledgment packet is structured to have a packet length field, a packet type field, a cClient field, a stream ID field, an ACK code field, and a CRC field. The 2-byte packet length field identifies the packet as a scaled video stream acknowledgment packet with a packet type of 137, while a value of 10 for this packet type is used to specify the total number of bytes, excluding the packet length field. Will be done.

The 2-byte cClientID field is reserved for future use for the client ID and is usually set to zero. The 2-byte stream ID field specifies a unique identifier for the stream ID. This is the same value assigned by the host for the scaling video stream setup packet.

The 2-byte acknowledgment code field provides a value containing code that describes the result of an attempt to update the specified scaling video stream. In one embodiment, the code is defined as follows:

0-Stream allocation attempt was successful. 1-Stream deallocation attempt was successful. 2-Invalid attempt to assign a stream ID that has already been assigned. 3-Invalid attempt to unassign a stream ID that has already been deallocated. 4-Client does not support scaling video streams. 5-Stream packets are inconsistent with client functionality. 6-Stream ID value is greater than the maximum allowed by the client. 7-Insufficient resources available within the client to allocate the specified stream. The 2-byte CRC field contains the CRC of all bytes in the packet, including the packet length.

34. Scaling video stream packets Scaling video stream packets are used to send pixel data associated with a special scaling video stream. The size of the reference area referenced by this packet is defined by the scaling video stream setup packet. The client scales through the valid parameter value 143 in the valid parameter response list of the valid status response list packet and using the successful scaling video stream allocation response in the Ack code field of the scaling video stream acknowledgment packet. It can demonstrate the ability to support video stream packets.

The format of one embodiment of the scaling video stream packet is generally shown in FIG. 78. As can be seen in FIG. 78, the scaling video stream packet is a packet length field, a packet type field, a hClientID field, a stream ID field, a pixel data attribute field, a pixel count field, a parameter CRC field, a pixel data field, and a pixel data CRC field. It is structured to have. The 2-byte packet type field uses the value 18 to identify the packet as a scaling video stream packet. The hClientID field is reserved for the client ID and is usually set to zero. As mentioned above, the 2-byte stream ID field specifies a unique identifier for the stream ID. This value is specified by the host in the scaling video stream setup packet and is confirmed in the scaling video stream acknowledgment packet.

In one embodiment, the 2-byte pixel data attribute field has values that identify the pixel data path and display update or buffer position. In one embodiment, these values are interpreted as follows. That is, bit 1 and bit 0 select the display on which the pixel data is routed. At bit value '11' or bit value '00', pixel data is displayed for or for both eyes. If the bit value is '10', the pixel data is sent only to the left eye, and if the bit value is '01', the pixel data is sent only to the right eye.

Bits 7 and 6 are display update bits that identify the framebuffer in which the pixel data is written. The effect of the frame update buffer is described in more detail elsewhere herein. If bit [7: 6] is '01', the pixel data is written to the offline image buffer. If bit [7: 6] is '00', the pixel data is written to the image buffer used to refresh the display. If bit [7: 6] is '11', pixel data is written to all image buffers. If bit [7: 6] is '10', it is treated as an invalid value. These bits are currently reserved for future use. In this case, the pixel data is ignored and is not written to any of the image buffers. Bits 15-14 and 11-8 are reserved for future use and are generally set to logical zero levels or logical zero values.

In one embodiment, bits [13:12] or bits 13 and 12 are associated with a transparent color and transparent mask and are used to identify whether the destination pixel should be written to the destination location. To. If bit [13:12] is equal to the value 00, the transparent color is not used. The resulting destination pixel is written to the destination pixel position without considering the value of the transparent color or transparent mask. The transparent color is defined by the transparent color and the mask setting packet. The value 01 for bit [13:12] is reserved for future use and is generally not used or considered as a valid state. If bit [13:12] is equal to the value 10, the destination pixel is written to the destination position if the transparent mask and ANDed source image pixels are not equal to the transparent color. In this case, the resulting pixels are not written to the destination pixel position. If bit [13:12] is equal to the value 11, the destination pixel will not be written to the destination pixel position unless the source image pixel ANDed with the transparency mask is equal to the transparency color. In this case, the resulting pixel is written to the destination pixel position.

The 2-byte pixel count field specifies the number of pixels in the following pixel data fields. The 2-byte parameter CRC field has the CRC of all bytes from packet length to pixel count. If the CRC cannot be checked, the entire packet is dropped. The 2-byte pixel data field contains raw video information that must be scaled and then displayed. The data is formatted as described by the video data format descriptor field. Data is sent one line at a time, as defined in the past.

The 2-byte pixel data CRC field contains a CRC of pixel data only. If this CRC cannot be checked, pixel data shall still be used, but the CRC error count shall be incremented.

35. Special status request packet A special status request packet provides a means, mechanism or method for a host to request that a client send a function or status packet back to the host, as specified in this packet. The client returns the next reverse link capsule or the type of packet specified within the packet. The client generally sets bit 17 in the client feature feature field of the client feature packet if the client has the ability to respond to special status request packets. A convenient method used by the host to determine all types of status packets that a client can reply to or forward is to use the valid status response list packets described. The client can demonstrate the ability to respond with a valid status response list packet using bit 21 of the client feature feature field of the client feature packet.

The format of one embodiment of the special status request packet is generally shown in FIG. 79. As can be seen in FIG. 79, the special status request packet is structured to have a packet length field, a packet type field, a hClientID field, a status packet ID field, and a CRC field. The packet length field specifies the total number of bytes in the packet that does not include the packet length field, and is usually fixed at a value of 10 for this packet type. The packet type 138 identifies the packet as a special status request packet. The hClientID field (2 bytes) is reserved for future use for the client ID and is set to zero for the time being. On the other hand, the 2-byte status packet ID field specifies the function to send to the host or the type of status packet. Typical packet types are 66-Client Function Packets are sent by the client. 133-Alpha-Cursor image function Packet is sent to the client. 139-A valid status response list packet is sent that identifies the exact type of feature packet and status packet that the client can send. 141-Personal Client Function Packets are sent by the client. 142-Client error report A packet is sent by the client. 143-Scaling video stream feature Packets are sent by the client. 144-A client identification packet is sent by the client.

Packet types 56-63 can be used for manufacturer-specific feature and status identifiers.

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

36. Valid status response list packet The valid status response list packet provides the host with a structure, means, or method having a list of status packets and functional packets that the client has the ability to reply to. The client can demonstrate its ability to support valid status response list packets by using bit 21 of the client feature feature field of the client feature packet.

The format of one embodiment of the valid status response list packet is generally shown in FIG. As can be seen in FIG. 80, the valid status response list packet is structured to have a packet length field, a packet type field, a cClientID field, a number of values field in the list, a valid parameter response list field, and a CRC field. .. The packet length of this type of packet is usually fixed at a value of 10, and a type value of 139 identifies the packet as a valid status response packet. The cClientID field is reserved for future use as a client ID and is usually set to zero. The number field in the 2-byte list specifies the number of items in the valid parameter response list below.

The valid parameter response list field contains a list of 2-byte parameters that specify the types of functional or status packets that the client can send to the host. If the client indicates that it can respond to a special status request packet (using bit 21 of the client feature feature field of the client feature packet), then it is at least the client feature packet (packet type = 66) and valid status. A response list packet (packet type = 139) can be sent. The packet types that can be sent by the client and may be included in this list are as follows, along with their respective assignments for the purposes of one embodiment.

66-Client feature packet 133-Alpha-Cursor image function packet 139-Valid status response list packet that identifies the exact type of feature packet and status packet that the client can send 141-Personal Display Function Packet 142-Client error report packet 143-Scaled video stream feature packets 144-Client identification packet 145-Alternative display feature packets.

Packets 56-63 can be used for manufacturer-specific features and status identifiers.

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

37. Personal display function packet The personal display function packet provides a set of parameters that describe the function of a personal display device such as a head-mounted display or display glasses. This allows the host to customize the display information according to the client's specific capabilities. On the other hand, the client demonstrates the ability to send a personal display function packet by using the corresponding parameter of the valid parameter response list of the valid status response list packet.

The format of one embodiment of the personal display function packet is generally shown in FIG. As can be seen in FIG. 81, the personal display function packet includes a packet length field, a packet type field, a cClientID field, a subpixel layout field, a pixel shape field, a horizontal field, a vertical field, a visual axis crossing field, and a left and right image field. It is structured to have a see-through field, a maximum brightness field, an optical function field, a minimum IPD field, a maximum IPD field, an IFeld point field of a curvature list, and a CRC field. The packet length of this packet is always 68. The packet type value of 141 identifies the packet as a personal display display function packet. The cClientID field is reserved for future use and is usually set to zero for the time being.

In one embodiment, the subpixel layout field uses the following values to specify the physical layout of the subpixels from top to bottom and from left to right. That is, 0 indicates no subpixel layout is defined, 1 indicates red, green, blue stripes, 2 indicates blue, green, red stripes, 3 indicates red in the upper left and lower right. Blue, and one shows a quad pixel with a 2x2 subpixel array of two green subpixels in the lower left and the other in the upper right, where 4 is a 2x2 subpixel array of red in the lower left and blue in the upper right. And one for the upper left, the other for the lower right, two green subpixels, 5 for the delta (triad), and 6 for the red, green, and blue overlays (eg, field sequential color LCOS display). ) Indicates a mosaic, values from 7 to 255 are usually reserved for future use.

In one embodiment, the pixel shape field specifies the shape of each pixel, which is composed of subpixels of special configuration, using the following values, where 0 indicates that the subpixel shape is undefined. 1 indicates a circle, 2 indicates a square, 3 indicates a rectangle, 4 indicates an ellipse, 5 indicates an ellipse, and values 6 to 255 give the desired shape, as can be understood by those skilled in the art. Reserved for future use in indicating.

In one embodiment, a 1-byte horizontal field of view (HFOV) field specifies a horizontal field of view in increments of 0.5 degrees (for example, if the HFOV is 30 degrees, this value is 60). No HFOV is specified if this value is zero.

In one embodiment, the 1-byte Vertical Field of View (VFOV) field specifies the vertical field of view in 0.5 degree increments (for example, if the VFOV is 30, this value is 60). If this value is zero, no VFOV is specified.

In one embodiment, the 1-byte visual crossing field specifies a visual crossing in 0.01 diopter (1 / m) increments (eg, if the visual crossing is 2.22 meters, this value is 45). If this value is zero, no axis crossing is specified.

In one embodiment, the 1-byte left / right image overlap field specifies the percentage of left and right image overlap. The permissible range of image duplication in percent is from 1 to 100. Values 101-255 are invalid and are not commonly used. If this value is zero, no image duplication is specified.

In one embodiment, the 1-byte see-through field specifies the see-through percentage of the image. Percentage see-through tolerances range from 0 to 100. Values 101-254 are invalid and are not used. If this value is 255, no see-through percentage is specified. The A1 byte maximum brightness field specifies the maximum brightness in increments of 20 knits (for example, if the maximum brightness is 100 knits, this value is 5). If this value is zero, no maximum brightness is specified.

In one embodiment, the 2-byte optics flag field includes various fields that specify the optics of the display. These bit values are usually assigned according to: Bits 15-5 are received for future use and are generally set to the logical zero state. Bit 4 selects spectacle focus adjustment, a value of "0" means that the display does not have spectacle focus adjustment, and a value of "1" means that the display has spectacle focus adjustment. Bits 3 and 2 select binocular function according to: A value of 0 means that the display is binocular and can only display two-dimensional (2D) images, and a value of 1 means that the display is binocular and can display three-dimensional (3D) images. , 2 means that the display is for monocular use, 3 is reserved for future use. Bits 1 to 0 select left-right curvature of field symmetry, and a value of 0 means that no curvature of field is defined. If this field is zero, all field curvature values from A1 to E5 are set to zero except for point C3, which specifies the focal length of the display or is set to zero, and the focal length is set to zero. Indicates that it is not specified. A value of 1 means that the left and right displays have the same symmetry. 2 means that the left and right displays are mirrored on the vertical axis (column C), and 3 is reserved for future use.

In one embodiment, the 1-byte interpupillary distance (IPD) minimum field specifies the minimum interpupillary distance in millimeters (mm). If this value is zero, the minimum interpupillary distance is not specified. The 1-byte interpupillary distance (IPD) maximum field specifies the maximum interpupillary distance in millimeters (mm). If this value is zero, the maximum interpupillary distance is not specified.

The point list field of curvature of field specifies the focal length in the range of 1 to 65535 (for example, 1 is 0.001 diopter and 65535 is 65.535 diopter) at a thousandth of the diopter (1 / m) 25. Contains 2-byte parameters of. The 25 elements of the field curvature point list are called A1 through E5, as shown in Figure 82. The points are evenly distributed in the active area of the display. Column C corresponds to the vertical axis of the display and row 3 corresponds to the horizontal axis of the display. Columns A and E correspond to the left and right edges of the display, respectively. Lines 1 and 5 correspond to the upper and lower edges of the display, respectively. The order of the 25 points in the list is as follows. A1, B1, C1, D1, E1, A2, B2, C2, D2, E2, A3, B3, C3, D3, E3, A4, B4, C4, D4, E4, A5, B5, C5, D5, E5.

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

38. Client error report packet The client error report packet acts as a mechanism or means for allowing the client to provide the host with a list of operational errors. The client may detect a wide range of errors during its normal operation as a result of receiving a particular command from the host. Examples of these errors include: The client may have been instructed to operate in a mode it does not support, the client may have received a packet containing certain parameters that are out of range or beyond the client's capabilities. At one point, the client may have been instructed to enter mode in an improper order. Client error report packets can be used to detect errors during normal operation, but to system designers and consolidators to diagnose problems in host and client system development and integration. Most effective. The client uses a parameter value of 142 in the valid parameter response list of the valid status response list packet to indicate its ability to send a client error report packet.

The format of one embodiment of the client error report packet is generally shown in FIG. As can be seen in FIG. 83, the client error report packet is structured to have a packet length field, a packet type field, a cClientID field, a list item count field, an error code list field and a CRC field. A packet type value of 142 identifies the packet as a client error report packet. The cClientID field is reserved for future use and is usually set to zero for the time being. The list item number field (2 bytes) specifies the number of items in the following error code list. The error code list field (8 bytes in this case) is a list containing one or more error report list items. The format of a single error report list item is shown in Figure 84.

In one embodiment, each error report list item is exactly 4 bytes in length, as shown in FIG. 84, and has a structure in one embodiment that includes: That is, the 2-byte display error code field, which specifies the type of error being reported, and the 2-byte error subcode field specify a higher level of detail about the error defined by the client error code packet. A special definition of each client error code is defined by the client manufacturer. The error subcode need not be defined for each display error code, and in those cases where no error subcode is defined, the value is set to zero. The specific definition of each error subcode is defined by the client manufacturer.

39. Client identification packet The client identification packet allows the client to return identification data in response to a special status request packet. In one embodiment, the client demonstrates the ability to send a client identification packet using the parameter 144 in the valid parameter response list of the valid status response list packet. It is useful for the host to be able to determine the manufacturer name and model number of the client device by reading this data from the client. The information may be used to determine if the client has special features that cannot be described in the client feature packet. There are potentially two ways, means or mechanisms for reading identification information from a client. One is due to the use of client function packets that contain fields similar to the fields in the base EDID structure. The other method is by using a client identification packet that contains a denser set of information that is compared to similar fields in the client function packet. This allows the host to identify manufacturers who have not been assigned a three-letter EISA code and allows the serial number to contain alphanumeric characters.

The format of one embodiment of the client identification packet is generally shown in FIG. As can be seen in FIG. 85, the client identification packet is a packet length field, a packet type field, a cClientID field, a week of manufacture field, a year of manufacture field, a manufacturer name field, a product name length field, a serial number length field, and a manufacturer name character. It is structured to have a column field, a product name string field, a serial number string field, and a CRC field.

The 2-byte packet type field contains a value that identifies the packet as a client identification packet. This value is chosen to be 144 in one embodiment. The cClientID field (2 bytes) is again reserved for future use for the client ID and is usually set to zero. The CRC field (2 bytes) contains the 16-bit CRC of all bytes in the packet, including the packet length.

The 1-byte manufacturing week field contains a value that determines the manufacturing week of the display. In at least one embodiment, this value is in the range 1-53 if it is supported by the client. If this field is not supported by the client, it is usually set to zero. The 1-byte year of manufacture field contains a value that determines the year of manufacture of the client (display). Other base years could be used, but this value is offset from the starting year 1990. Years in the range 1991 to 2245 can be represented by this field. Example: Year 2003 corresponds to a manufacturing year value of 13. If this field is not supported by the client, it must be set to a value of zero.

The manufacturer name length field, product name length field, and serial number length field are the length of the manufacturer name string field containing any null-terminated or null-padded character, and the length of the product name string field containing any null-terminated or null-padded character. Contains a 2-byte value each that specifies the length and the length of the serial number string field, each containing a null-terminated or null-padded character.

The manufacturer name string field, product name string field, and serial number string field each contain an ASCII string that specifies the manufacturer, product name, and alphanumeric serial number, respectively. , Product name field, and a variable number of bytes specified by the serial number field. Each of these strings is terminated with at least one null character.

40. Alternate display function packet Alternate display function packets are used as a means, structure, or method of indicating the functionality of an alternative display attached to an MDDI client controller. It is sent in response to a special status request packet. When prompted, the client device sends an alternate display feature packet for each supported alternate display. If the client has more than one alternative display, although inefficient, some configurations use multiple request-specific status packets if desired, but the client has one request-specific status packet. Depending on, the alternative display function packet is sent, generated, and provided for each display. The client sends an alternate display function packet. Here, it may also be referred to as "discontinuous order" based on the value of the alternative display number field. The client can demonstrate the ability to send an alternate display feature packet via the parameter value 145 in the valid parameter response list of the valid status response list packet.

For MDDI systems operating in internal mode, it is possible to have multiple displays connected to the MDDI client controller. An application of the example is a mobile phone with a large display on the inside and a small display on the outside of the flip. Internal mode clients do not need to return alternate display feature packets for two potential reasons. First, the host may already be programmed or informed of its functionality during manufacturing. Because they are used in a common device or enclosure. Second, these two assemblies do not make it easy for the client to be disconnected or disconnected from the connection to the host. And the host may at least know that it contains a hard code copy of the client functionality or does not change due to changes within the client that may occur.

The Alternate Display Number field in the client feature packet is used to report that multiple displays are installed and that the alternate display feature packet reports the functionality of each alternate display. The video stream packet contains 4 bits in the pixel data attribute field to accommodate each alternate display in the client device.

The format of one embodiment of the alternative display function packet is generally shown in FIG. As can be seen in FIG. 86, the alternate display function packet includes a packet length field, a packet type field, a cClientID field, a number of alternate displays field, a reserved 1 field, a bitmap width field, a bitmap height field, a display window width field, and a display. Structured to have window height field, color map RGB width field, RGB functional field, black and white functional field, reserved 2 field, Y Cb Cr functional field, Bayer functional field, reserved 3 field, display feature functional field and CRC field Has been done. A packet type value of 145 identifies the packet as an alternate display function packet. The cClientID field is currently reserved for the client ID for future use and is typically set to zero by setting the bit to the logical zero level.

The Alternate Display Number field uses 1 byte to indicate the identity of the alternate display as an integer in the range 0-15. The first alternative display is generally designated number 0, and the other alternative displays are identified by a unique alternative display number, which is the total number of alternative displays with the maximum number used minus one. Values greater than the total number of alternative displays minus 1 are not used. Example: A mobile phone with a primary display and a caller ID display connected to an MDDI client has one alternate display, so the number of alternate displays for the caller ID display is zero and it replaces the client function packet. The number of displays field has a value of 1.

Reserved 1 field (1 byte) is reserved for future use. Therefore, all bits in this field are currently set to zero, the logical zero level. In one embodiment, one purpose of this field is to align all subsequent 2-byte fields to 16-bit word addresses and 4-byte fields to 32-bit word addresses.

The bitmap width field uses 2 bytes to specify the width of the bitmap, expressed as the number of pixels. The bitmap height field uses 2 bytes to specify the height of the bitmap, expressed as the number of pixels. The display window width field uses 2 bytes to specify the width of the display window, expressed as the number of pixels. The display window height field uses 2 bytes to specify the height of the display window, expressed as the number of pixels.

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

Bits 3 to 0 define the maximum number of blue bits in each pixel for which values 0 to 8 are considered valid. Bits 7-4 define the maximum number of green bits in each pixel for which values 0-8 are considered valid. Bits 11-8 define the maximum number of red bits in each pixel for which values 0-8 are considered valid. Bits 14-12 are reserved for future use and are usually set to zero. Bit 15 is used to indicate the client's ability to accept colormap pixel data in packed or unpacked format. When bit 15 is set to logical 1 level, this indicates that the client can accept colormap pixel data in either packed or unpacked format. If bit 15 is set to logical zero, this indicates that the client can only accept colormap pixels in unpacked format.

The RGB function field uses 2 bytes to specify the number of bits of resolution that can be displayed in RGB format. In one embodiment, this value is set equal to zero if the client cannot use the RGB format. The RGB function word consists of three separate unsigned values: Bits 3 to 0 define the maximum number of blue bits in each pixel (blue brightness), bits 7 to 4 define the maximum number of green bits in each pixel (green brightness), and bits 11 to 8 Defines the maximum number of red bits (red brightness) in each pixel. Bits 14-12 are reserved for future use and are set to zero. Bit 15 is used to indicate the client's ability to accept RGB pixel data in packed or unpacked format. When bit 15 is set to logical 1 level, this indicates that the client can accept RGB pixel data in either packed or unpacked format. When bit 15 is set to logical zero, this indicates that the client can accept RGB pixel data in unpacked format alone.

The 1-byte black-and-white functional field contains a value or information for specifying the number of bits of resolution that can be displayed in the black-and-white format. If the client cannot use the black and white format, this value is set equal to zero. Bits 6-4 are reserved for future use and are usually set to zero. Bits 3 to 0 define the maximum number of grayscale bits that can exist in each pixel. These four bits allow you to specify that each pixel consists of 1 to 15 bits. If the value is zero, the black and white format is not supported by the client. Bit 7 indicates that the client accepts black and white pixel data in either packed or unpacked format when set to 1. If bit 7 is set to zero, this indicates that the client can accept black and white pixel data in unpacked format only.

The Reserved 2 field is a 1-byte wide field reserved for future use, and normally all bits in this field are set to the logical zero level. In one embodiment, the purpose of having this field is to align all subsequent 2-byte fields to 16-bit word addresses and 4-byte fields to 32-bit word addresses.

The 2-byte Y Cb Cr function field specifies the number of resolution bits that can be displayed in the Y Cb Cr format. This value is zero if the client cannot use the Y Cb Cr format. The Y Cb Cr function word consists of three separate unsigned values: Bits 3 to 0 define the maximum number of bits that specify the Cb sample, bits 7 to 4 define the maximum number of bits that specify the Cr sample, and bits 11 to 8 define the maximum number of bits that specify the Y sample. However, bits 14-12 are reserved for future use and are set to zero. Bit 15 indicates that the client can accept Y Cb Cr pixel data in either packed or unpacked format when set to 1. If bit 15 is set to zero, this indicates that the client can accept Y Cb Cr pixel data in unpacked format only.

The 2-byte Bayer function field specifies the resolution, pixel group, and number of bits in pixel order that can be transferred in Bayer format. This value is set to zero if the client cannot use the Bayer format. The Bayer feature field consists of the following values: Bits 3 to 0 define the maximum number of brightness bits present in each pixel, bits 5 to 4 define the pixel group pattern that may be needed, and bits 8 to 6 define the required pixels. Defines the order, bits 14-9 are reserved for future use and set to zero. Bit 15 indicates that the client can accept Bayer pixel data in either packed or unpacked format when set to 1. If bit 15 is set to zero, this indicates that the client can accept Bayer pixel data in unpacked format only.

The reserved 3 fields, which are 2 bytes here, are reserved for future use. Therefore, all bits in this field are set to or equal to the logical zero level or zero value. In one embodiment, the purpose of having this field in a packet now is to align the next 2-byte field with a 16-bit word address and the 4-byte field with a 32-bit word address.

The display feature feature indicator field, which is 4 bytes here, contains a set of flags that indicate whether a particular feature in the alternate display is supported. A bit set to 1 indicates that a particular or current feature is supported, and a bit set to zero indicates that this feature is not supported.

In one embodiment, the display feature function field uses 4 bytes containing a set of flags indicating a specific function in a supported alternative display. Bitsets set to logical 1 level indicate that this feature is supported. On the other hand, a bit set to the logical zero level indicates that this feature is not supported. In one embodiment, the value of bit 0 indicates whether a bitmap block forwarding packet (packet type 71) is supported. The values of bits 1, 2 and 3 indicate whether or not a bitmap area fill packet (packet type 72), a bitmap pattern fill packet (packet type 73), or a read frame buffer packet (packet type 74) is supported, respectively. Is shown. The value of bit 4 indicates whether the alternate display has the ability to make one color transparent using transparent color enable packets.

In this embodiment, the value of bit 10 in the display feature function field indicates whether the alternate display has the ability to support display power state 01. The display power state is set using bits [3: 2] in the power state field of the display power status packet described above. The display power state 01 is a state in which the selected display is not lit and the minimum amount of power is consumed. And during this state, the contents of the framebuffer, if any, are generally guaranteed, i.e., kept properly.

The value of bit 13 of the display feature feature field is such that the alternate display supports VCP feature packets, request VCP feature packets, VCP feature response packets, set VCP feature packets, request valid parameter packets, and valid parameter response packets. Indicates whether or not it has the ability to set one or more video parameters. The value of bit 14 indicates whether the alternate display has the ability to write pixel data to the offline display framebuffer, as shown in FIG. 88A. When this bit is set to logical 1 level, the display update bit (bits 7 and 6 of the pixel data attribute field of the video stream packet) can be set to the value '01'.

The value of bit 15 in the display feature function field indicates when the alternate display has the ability to write pixel data only to the display framebuffer used to refresh the display image, as shown in Figure 88B. If this bit is set to logical 1, the display update bit (bits 7 and 6 of the pixel data attribute field of the video stream packet) can be set to the value '00'. The value of bit 16 indicates when the alternate display has the ability to write pixel data from a single video stream packet to all display framebuffers, as shown in Figure 88C. If this bit is set equal to logical 1 level, the display update bit (bits 7 and 6 of the pixel data attribute field of the video stream packet) can be set to the value '11'.

In one embodiment, the value of bit 21 of the display feature feature field is a bitmap if the following packets are supported by the alternate display to be identified by bits 2,1,0 or the field. Indicates when the user has the ability to use the raster operation fields of pattern-filled packets (packet type 73), bitmap area-filled packets (packet type 72), and bitmap block-forwarded packets (packet type 71). In one embodiment, if bit 21 has a logical zero level or value and these packets are supported, then the alternate display does not have the ability to use raster operating fields and the alternate display is generally It only has the ability to copy or write to the pixel location identified by these packets.

In one embodiment, bits 9-5, 11,12,20-17,31-22 of the display feature feature fields are currently reserved for future use or are available for system designers. Another setting, generally equal to zero value or logical zero level.

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

41. Register access packet The register access packet provides either the host or the client with the means, mechanism or method of accessing the configuration and status registers on the opposite end of the MDDI link. These registers can be unique to each display or device controller. These registers are already present in many displays that require a configuration, operation mode, and have other useful and required settings. Register access packets allow MDDI hosts or clients not only to write to registers, but also to request that MDDI links be used to read registers. When a host or client requests a register read, the other side sends the register data in the same packet type, indicating that this is data read from a particular register using the read / write information field. You also have to respond. Register access packets may be used to read or write multiple registers by specifying a register count greater than 1. The client demonstrates the ability to support register access packets using bit 22 of the client feature feature field of the client feature packet. The client uses the encapsulated packet to send a register access packet. This indicates what appears as a packet in the packet configuration or structure.

The format of one embodiment of the register access packet is generally shown in FIG. As can be seen in FIG. 87, the register access packet now has a packet length field, a packet type field, a bClientID field, a read / write information field, a register address field, a parameter CRC field, a register data list field and a register data CRC field. It is structured. A packet type value of 146 identifies the packet as a register access packet. The bClientID field is reserved for future use and is usually set to zero for the time being.

In one embodiment, the 2-byte read / write information field acts as a function to specify a particular packet as either a write or read, or a response to a read, and provides a count of data values.

Bits 15-14 act as read / write flags. If bit [15:14] is "00", this packet contains data written to the register addressed by the register address field. The data written to the specified register is contained in the register data list field. If bit [15:14] is "10", then this is a request for data from one or more registers addressed by the register address field. If bit [15:14] is [11], the packet contains the requested data in response to a register access packet with read / write flag bits 15:14 set to "10". .. The register address field contains the address of the register corresponding to the first register data list item, and the register data list field contains data read from one or more addresses. If bit [15:14] is "01", then this is treated as an invalid value, which is reserved and not used for the future, but if you are an expert in the art. , Will understand how to apply it for future use.

Bits 13: 0 use a 14-bit unsigned integer to specify the number of 32-bit register data items sent in the register data list field. If bit 15:14 is equal to "00", then bit 13: 0 is the number of 32-bit register data items contained in the register data list field written to the register starting at the register specified by the register address field. specify. If bit 15:14 is equal to "10", bit 13: 0 specifies the number of 32-bit register data items that the receiving device sends to the device requesting that register be read. The register data list field in this packet contains no items and is zero length. If bit 15:14 equals "11", bit 13: 0 specifies the number of 32-bit register data items read from the registers contained in the register data list field. Bit 15:14 is currently not set equal to "01", which is considered an invalid value, it is considered an invalid value, otherwise it is reserved for future designation or use.

The register access field uses 4 bytes to indicate the register address to be written or read. If you address a register whose addressing is less than 32 bits, the high-order bits are set to zero.

The 2-byte parameter CRC field contains the CRC of all bytes from packet length to register access. If this CRC cannot be checked, the entire packet is dropped.

The register data list field contains a list of 4-byte register data values written to the client register or values read from the client device register.

The 2-byte register data CRCF field contains the CRC of the register data list only. If this CRC cannot be checked, the register data may still be used, but the CRC error count will be incremented.

D. Packet CRC The CRC field may also appear at the end of the packet after more critical parameters in the packet that may have significantly larger data fields, thus increasing the likelihood of errors in transit. For packets with two CRC fields, the CRC generator will make sure that the CRC calculation after the long data field is not affected by the parameters at the beginning of the packet when only one is used. It will be reinitialized later.

Packets with many bit errors have a small chance of producing a good CRC. The chances of finding a good CRC for packets with errors are 7x10 for very long packets with many errors.^-6Approaching. Depending on the design, MDDI links have very low or zero error rates. The CRC is intended to be used to monitor the health of the link and is not intended to detect errors with respect to a particular packet to determine if the packet should be retransmitted.

In an exemplary embodiment, the polynomial used for CRC calculations is known as CRC-16, i.e. X16 + X15 + X2 + X0. A sample implementation of the CRC generator and checker 3600 that is effective in realizing the present invention is shown in FIG. In Figure 36, the CRC register 3602 is initialized to the value 0x0001 just before the transfer of the first bit of the packet, which is the input on the Tx_MDDI_Data_Before_CRC line, and then in the register where the packet bytes first start at LSB. Is shifted to. Note that the register bit numbers in this figure correspond to the order of the polynomials used, not the bit positions used by MDDI. It is more efficient to shift the CRC register in a single direction, resulting in CRC bit 15 at bit position 0 of the MDDI CRC field and CRC register bit 14 at the MDDI CRC field bit until MDDI bit position 14 is reached. For example, it is displayed at position 1.

As an example, the packet content of the client request and status packets is 0x000c, 0x0046, 0x000, 0x0400, 0x00, 0x00, 0x0000 (or 0x0c, 0x00, 0x46, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, When submitted using the inputs of the multiplexers 3604 and 3606 and the AND gate 3608 (represented as a sequence of bytes such as 0x00, 0x00), the resulting CRC output on the Tx_MDDI_Data_With_CRC line is 0xd9aa (or 0xaa, 0xd9). (Represented as a sequence like).

When the CRC generator and checker 3600 are configured as one CRC checker, the CRC received on the Rx_MDDI_Data line is input to the multiplexer 3604 and the exclusive OR (XOR) gate 3612, NOR gate 3610, AND gate 3608, and It is compared bit by bit with the value found in the CRC register using AND gate 3614. If there is an error such as output by AND gate 3614, the CRC is incremented once for each packet containing the CRC error by connecting the output of gate 3614 to the input of register 3602. Note that the example circuit shown in Figure 36 can output multiple CRC error signals within the default CHECK_CRC_NOW window (see Figure 37B). Therefore, the CRC error counter usually counts only the first CRC error within each interval when CHECK_CRC_NOW is active. When configured as a CRC generator, the CRC records the exit time from the CRC register at the time that coincides with the end of the packet.

The timing of the input and output signals and the enable signal are illustrated graphically in FIGS. 37A and 37B. CRC generation and data packet transmission are shown in Figure 37A, along with the states (0 or 1) of the Gen_Reset, Check_CRC_Now, Generate_CRC_Now and Sending_MDDI_Data signals, as well as the Tx_MDDI_Data_Before_CRC and Tx_MDDI_Data_With_CRC signals. Receiving a packet of data and checking the CRC value is shown in Figure 37B along with the status of the Gen_Reset signal, Check_CRC_Now signal, Generate_CRC_Now signal, and Sending_MDDI_Data signal, as well as the Rx_MDDI_Data and CRC error signals.

E. Error code overload for packet CRC Whenever only data packets and CRC are being forwarded between the host and client, there is no error code being addressed. The only error is the loss of synchronization. Otherwise, you must wait for the link to time out due to a lack of good data transfer paths or pipelines before resetting the link and proceeding. Unfortunately, this takes a lot of time and is somewhat inefficient.

For use in one embodiment, a new technique has been developed in which the CRC portion of the packet is used to transfer error code information. This is generally shown in Figure 65. That is, one or more error codes are created by a processor or device that processes a communication process or a data transfer that indicates a particular predetermined error or malfunction that may occur within a link. When an error is encountered, the appropriate error code is created and forwarded using the bits for CRC of the packet. That is, the CRC value is overloaded or overwritten with the desired error code that can be detected at the receiving end by an error monitor or checker that monitors the value of the CRC field. In cases where the error code matches the CRC value for some reason, the error compliment is forwarded to prevent confusion.

In one embodiment, in order to provide a robust error warning detection system, the error code may be forwarded several times using a series of packets, usually all, which are forwarded or transmitted after the error is detected. This happens until the error-causing state is removed from the system, at which point the regular CRC bits are transferred without being overloaded with another value.

This technique of overloading CRC values uses a minimum amount of extra bits or fields while providing a much quicker response to system errors.

As shown in FIG. 66, the presence or absence of an error in a communication link or process using an error detector or detection means 6602 capable of forming part of another network described above or known. A CRC overwrite mechanism or device 6600 that detects reality is shown. An error code generator or means 6604 that can be formed as part of another network or can use techniques such as a look-up table to store preselected error messages has been detected as occurring. Create one or more error codes to indicate a particular given error or malfunction. It is easily understood that the devices 6602 and 6604 can be formed as a single circuit or device, or as part of a programmed step of steps for other known processors and elements, as desired.

A CRC value comparator or comparison means 6606 is shown to check to see if one or more selected error codes are the same as the CRC value being transferred. If so, the code compliment generator or generator or device provides error code compliments so that they are not mistaken for the original CRC pattern or value and do not confuse or complicate the detection scheme. Used for. The error code selector or selection means element or device 6610 appropriately selects error codes or values that are desired to be inserted or overwritten, or their respective compliments. Error Code CRC Overlater or Overwriting Mechanism or Means 6612 receives the data stream, packet and desired code to be inserted and the corresponding or appropriate CRC value to transfer the desired error code to the receiving device. Is a device that overwrites.

As mentioned, the error code may be forwarded several times using a series of packets, so the overwriter 6612 leverages or needs a memory storage element to maintain a copy of the code during processing. These codes may be recalled from past elements or other known storage locations that can be used to store or retain the value as desired or as desired.

The general-purpose processing and overwrite mechanism of FIG. 66 is realized, and more details are shown in FIGS. 67A and 67B. In Figure 67A, one or more errors are detected in step 6702 of the communication data or process, and an error code is selected in step 6704 to indicate this condition. At the same time, or at the appropriate time, the CRC value to be replaced is checked in step 6706 and compared to the desired error in step 6708. The result of this comparison is, as mentioned above, a determination as to whether the desired code or other representative value is the same as the existing CRC value. If this is the case, the process proceeds to step 6712, which is selected as a compliment, or in some cases a code for inserting another representative value as desired. Once it is determined in steps 6710 and 6714 which error code or value should be inserted, the appropriate code is selected for insertion. These steps are drawn separately for clarity, but are usually a single choice based on the output of the decision in step 6708. Finally, in step 6716, the appropriate value is overridden in the CRC location for forwarding while the packet is targeted by the process.

On the packet receiver side, the packet CRC value is monitored in step 6722, as shown in Figure 67B. In general, the CRC value is a system for determining whether a data transfer error has occurred, whether to request retransmission of one or more packets, whether to suppress additional operations, and so on. The inside is monitored by one or more processes, some of which are mentioned above. The information can also be used to detect the presence of an error by comparing the value to a known or preselected error code or representative value as part of such monitoring. Instead, a separate error detection process and monitor can be implemented. If the code is believed to exist, it is extracted, or otherwise noted in step 6724 for additional processing. A decision as to whether this is the actual code or a compliment can be made in step 6726, in which case additional step 6728 is used to convert the value to the desired code value. .. The resulting extraction code, compliment, or other recovered value in either case is then used to detect what error occurred from the code sent in step 6730.

V. Link hibernation MDDI links can quickly enter hibernation and wake up quickly from hibernation. This responsiveness allows communication systems or devices to frequently put MDDI links into hibernation to reduce power consumption. Because it can be woken up again very quickly for use. In one embodiment, when the external mode client wakes up from hibernation for the first time, it does so at a strobe pulse timing that matches the 1 Mbps rate at the data rate. That is, the MDDI_Stb pair should toggle at a 500kHz rate. Once the client's characteristics are discovered or notified by the host, the host generally wakes up the link at any rate, from 1 Mbps to the maximum rate at which the client can operate. The internal mode client wakes up at any rate at which both the host and the client can operate. This is generally also applicable the first time an internal mode client wakes up.

In one embodiment, when the link wakes up from hibernation, the host and client exchange a sequence of pulses. These pulses can be detected using a low speed line receiver that consumes only a fraction of the current as a differential receiver that is required to receive the signal at maximum link operating speed. Since either the host or the client can wake up the link, the wakeup protocol is designed to handle possible conflicts if both the host and the client attempt to wake up at the same time. Will be done.

While the link is in or continues to be in hibernation, the difference driver between MDDI_Data and MDDI_Stb is disabled in a high impedance state and the difference voltage between all the difference pairs is zero volt. The difference line receiver used to detect the sequence of pulses during wakeup from hibernation has an intentional voltage offset. In one embodiment, the threshold between logic 1 and logic 0 levels in these receivers is about 125 mV. This results in an undriven diff pair seen as a logical zero level during the link wakeup sequence. However, as the expert understands, a normal logic 1 level driven by a difference driver is still interpreted as a logic 1 level by a difference receiver with a 125 mV offset. An example of the behavior of a special low power differential receiver with a 125 mV offset compared to a standard differential receiver with a zero input offset is shown in Figure 38. This waveform is not representative of common MDDI signals, but is shown here only to clarify, or illustrate, the differences between the two types of differential receivers.

To enter the hibernation state, the host sends a 64MDDI_Stb cycle after the CRC of the link shutdown packet. The host disables the MDDI_Data0 output of the host in the range of 16 to 56 MDDI_Stb cycles after CRC (including output disable propagation delay). The host completes sending a 64MDDI_Stb cycle after the CRC of the link shutdown packet and before starting the wakeup sequence. In one embodiment, the initiation of wakeup by a host is defined as a host that must wait at least 100ns after MDDI_Data0 reaches a valid logical 1 level before driving a pulse on MDDI_Stb. In one embodiment, the client waits at least 60 MDDI_Stb cycles after the CRC of the link shutdown packet before attempting to drive MDDI_Data0 to logical 1 level to wake up the host.

In order to "wake up" from the hibernation state, some actions or processes are performed. MDDI_Stb was inactive after MDDI_Stb was activated and was driven to logical 1 level for approximately 70 MDDI_Stb cycles (range 60-80), although other periods could be used as desired. It keeps MDDI_Data0, but when the client, here the display, needs data or communication, services from the host, it generates a request pulse by driving the MDDI_Data0 line to a logical 1 state for about 70 μsec to 1000 μsec. The client then disables the MDDI_Data0 driver by putting it in a high impedance state.

If, unlikely, MDDI_Stb is active during hibernation, the client may only drive MDDI_Data0 into a logical 1 state for 70 MDDI_Stb cycles (range 60-80). This action causes the host to launch or restart data traffic on the forward link (208) and poll the client for its status.

After detecting the presence of the request pulse, the host must first start a boot sequence that drives MDDI_Stb to the logical zero level and MDDI_Data0 to the logical high level for at least about 200 ns. Then, during toggle, MDDI_Stb continues to drive MDDI_Data0 to logical 1 level for about 150 MDDI_Stb cycles (range 140-160) and to logical zero for about 50 MDDI_Stb cycles. The client must not send a service request pulse if it detects MDDI_Data0 for more than 80 MDDI_Stb cycles in the logical 1 state. When the client detects MDDI_Data0 at logical 1 level during 60-80 MDDI_Stb cycles, the host begins to search for the interval that drives MDDI_Data0 to logical zero level during 50 MDDI_Stb cycles. After the host drives MDDI_Data0 to the logical zero level for the duration of the 50MDDI_Stb cycle, the host begins sending packets on the link. The first packet sent is a subframe header packet. The client begins searching for subframe header packets after MDDI_Data0 is at the logical zero level for 40 MDDI_Stb cycles at 50 cycle intervals. The nature of time selection and time interval tolerances associated with hibernation processing and activation sequences is as described below (see 68A-C below).

The host first initiates a wakeup by enabling MDDI_Stb and at the same time drives it to the zero level of argument. MDDI_Stb should not be driven to logic 1 level until a pulse is output, as described below. After MDDI_Stb reaches the logical zero level, the host enables MDDI_Data0 and at the same time drives it to the logical 1 level. MDDI_Data0 should not be driven to the logical zero level during the wakeup process during the period of the 50MDDI_Stb pulse until it is driven to the logical zero level, as described below. The host should wait at least 200ns after MDDI_Data0 reaches a valid logical 1 level before driving the pulse on MDDI_Stb. This time relationship occurs while considering the worst-case output delay. This effectively ensures that the client has sufficient time to fully enable the MDDI_Stb receiver after being awakened by a logical 1 level on MDDI_Data0 driven by the host.

An example of the processing steps for a typical client service request event 3800 with no race condition is Figure 39A, where the events are named for convenience of illustration using the letters A, B, C, D, E, F and G. It is drawn in. The process starts at point A when the host sends a link shutdown packet to inform the client device that the link is transitioning to a low power hibernation state. In the next step, the host enters a low power hibernation state by disabling the MDDI_Data0 driver and setting the MDDI_Stb driver to logical zero as indicated by point B. MDDI_Data0 is driven to logical zero level by a high impedance bias network. After some time, the client sends a service request pulse to the host by driving MDDI_Data0 to the logical 1st level as seen at point C. The host still asserts the logical zero level using the high impedance bias network, but the driver in the client forces the line to the logical one level. Within 50 μsec, the host recognizes the service request pulse and asserts a logical 1 level on MDDI_Data0 by enabling its driver, as seen at point D. The client then stops trying to assert the service request pulse, and the client puts its driver in a high impedance state, as seen at point E. The host drives MDDI_Data0 to the logical zero level for 50 μsec, as indicated by point F, and begins creating MDDI_Stb in a manner consistent with the logical zero level of MDDI_Data0. The client begins searching for subframe header packets after MDDI_Data0 is at the logical zero level for 40 MDDI_Stb cycles. After asserting MDDI_Data0 to the logical zero level and driving MDDI_Stb for 50 μsec, the host subflies as indicated by point G.

A similar example is shown in Figure 39 where the service request is asserted after the link restart sequence has started and the event is also named using the letters A, B, C, D, E, F and G. This represents the worst case scenario where the request pulse or signal from the client is likely to destroy the subframe header packet. The process starts at point A when the host sends a link shutdown packet again to inform the client device that the link is transitioning to a low power hibernation state. In the next step, the host enters a low power hibernation state by disabling the MDI_Data0 driver and setting the MDDI_Stb driver to the logical zero level, as indicated by point B. As mentioned above, MDDI_Data0 is driven to the logical zero level by the high impedance bias network. After some time, the host initiates the link restart sequence by driving MDDI_Data0 to logical 1 level for 150 μsec, as seen at point C. Before 50 μsec elapses after the start of the link restart sequence, the display also asserts MDDI_Data0, which has a duration of 70 μsec, as seen at point D. This happens because the display needs to request service from the host and the host is unaware that it has already started the link restart sequence. The client then stops trying to assert the service request pulse, and the client puts its driver in a high impedance state, as seen at point E. The host continues to drive MDDI_Data0 to the logical 1st level. The host drives MDDI_Data0 to the logical zero level for 50 μsec, as shown at point F, and also begins to create MDDI_Stb consistently with the logical zero level at MDDI_Data0. After asserting MDDI_Data0 to the logical zero level and driving MDDI_Stb for 50 μsec, the host subflies.

From the above description, it can be seen that past solutions required the host to experience two states as part of the wakeup sequence. In the first state, the host drives the MDDI_Data0 signal high for 150 μs, then activates the MDDI_Stb line while driving the MDDI_Data0 signal low for 50 μs, and then begins sending MDDI packets. To do. This process works well to stay on the cutting edge in terms of achievable data rates using MDDI equipment and methods. However, as mentioned above, further speed in terms of faster response times to conditions or faster selection of next steps or processes is the ability to simplify processing or elements and is always required. ing.

Applicants have discovered a new method of invention for wakeup processing and timing in which the host uses clock cycle-based timing for signal toggle. In this configuration, the host initiates a toggle of MDDI_Stb from 0 to 10 μsec after the host drives the MDDI_Data0 signal high at the beginning of the sleeve release sequence and does not wait until the signal is driven low. During the wakeup sequence, the host toggles MDDI_Stb as if the MDDI_Data0 signal was always at logical zero level. This effectively eliminates the concept of time from the client side, allowing the host to go from the past 150 μs and 50 μs periods for the first two states to 150 and 50 clock cycles between these periods. Change.

The host becomes responsible for driving the data line high and begins transmitting strobe signals within a 10-clock cycle as if the data line were zero. After the host drives the data line high for 150 clock cycles, the host drives the data line low for 50 clock cycles while continuing to transmit the strobe signal. The host can start sending the first subframe header packet after completing both of these processes.

On the client side, the client implementation can now use the generated clock to calculate the number of clock cycles where the data line is initially high and then low. The number of clock cycles that need to occur in the high data line drive state is 150, and the number of clock cycles that need to occur in the low data line drive state is 50. That is, for a proper wakeup sequence, the client must be able to count at least 150 continuous clock cycles on the high data line, followed by at least 50 continuous clock cycles on the low data advantage. Once these two conditions are met, the client can begin searching for a unique word in the first subframe. This pattern of interruptions is used as the basis for returning the counter to its initial state of re-searching for the first 150 consecutive clock cycles of the high data line.

The client implementation of the present invention for host-based wake from hibernation is very similar to the initial boot case, except that the clock rate is not forced to start at 1 Mbps as described above. .. Instead, the clock rate can be set to resume at any past speed when the communication link enters hibernation. When the host begins transmitting the strobe signal as described above, the client must be able to recount at least 150 consecutive clock cycles on the high data line, followed by at least 50 consecutive clock cycles on the low data line. It doesn't become. Once these two conditions are met, the client can start searching for a unique word.

The client implementation of the present invention for client-based wake from hibernation is similar to host-based wake, except that it is invoked by driving a data line to the client. The client can drive the data line asynchronously without using a clock to wake the host device. Once the host recognizes that the data line is being driven high by the client, it can initiate its sleeve release sequence. The client can count the number of clock cycles generated by or during the wake process by the host. Once the client counts 70 consecutive clock cycles of high data, it can stop driving the data line high. At this point, the host should already have a high data line. The client can count another 80 continuous clock cycles of the next highest data line to reach 150 clock cycles of the next highest data line, and then 50 clock cycles of the next lowest data line. You can look for it. Once these three conditions are met, the client can start looking for a unique word.

The advantage of this new implementation of the wake process is that it eliminates the need for time measuring devices. Whether this is an oscillator, a capacitor discharge circuit, or other such known device, the client no longer needs such an external device to check its startup status. .. This saves money and circuit area when implementing controllers, counters, etc. on the client device board. This may not be an advantage for the client, but for the host this technique should potentially simplify the host in terms of ultra-high density logic (VHDL) used for the core network. .. The power consumption of using data lines and strobe lines as wake notification and measurement sources is also low because the core elements do not need to be running on the external network to wait for the host-based wake. The number of cycles or clock periods used is exemplary and other periods can be used as will be apparent to those skilled in the art.

The advantage of this new implementation of the wake process is that it eliminates the need for time measuring devices. Whether this is an oscillator, a capacitor discharge circuit, or other such known device, the client no longer needs such an external device to check its startup status. .. This saves money and circuit area when implementing controllers, counters, etc. on the client device board. This may not be an advantage for the client, but for the host this technique should potentially simplify the host in terms of ultra-high density logic (VHDL) used for the core network. .. The power consumption of using data lines and strobe lines as wake notification and measurement sources is also low because the core elements do not need to be running on the external network to wait for the host-based wake.

To clarify and explain the behavior of this new technique, the timing of various behaviors with respect to MDDI_Data0, MDDI_Stb and clock cycles is shown in Figures 68A, 68B and 68C.

An example of a typical host-initiated wake processing step without contention is shown in Figure 68A, where the event is again conveniently named in the figure using the letters A, B, C, D, E, F and G. It is shown. The process starts at point A when the host sends a link shutdown packet to the client device to inform it that the link is transitioning to a low power hibernation state. In the next step, point B, the host MDDI_Stb has approximately 64 cycles (or as desired for system design) to allow the client to complete processing before stopping MDDI_Stb from toggle. Toggle to stop the recovered clock in the client device. The host initially sets MDDI_Data0 to the logical zero level and then disables the MDDI_Data0 output in the range of 16 to 48 cycles (usually including output disable propagation delay) after CRC. It may be desirable to put the fast receiver for MDDI_Data0 and MDDI_Stb in the client into a low power state 48 cycles after the CRC and before the next step (C).

The host enters a low power hibernation state at point or step C by disabling the MDDI_Data0 and MDDI_Stb drivers and putting the host controller in a low power hibernation state. The MDDI_Stb driver can also be set to the logical zero level (using a high impedance bias network) as desired, or toggled during hibernation. The client is also in a low power level hibernation state.

After some time, the host initiates the link restart sequence at point D by enabling the MDDI_Data0 and MDDI_Stb driver outputs. The host drives MDDI_Data0 to logical 1 level and MDDI_Stb to logical zero level for as long as the driver takes to fully enable its respective output. The host typically waits approximately 200 nanoseconds after these outputs reach the desired logic level before driving the MMDI = Stbde pulse. This allows client time to prepare for reception.

With the host drive enabled and MDDI_Data0 driven to logical 1 level, the host initiates a toggle of MDDI_Stb for the duration of the 150MDDI_Stb cycle, as seen at point E. The host drives MDDI_Data0 to the logical zero level for 50 cycles, as indicated by point F, and the client begins looking for subframe header packets after MDDI_Data0 has been at the logical zero level for 40 MDDI_Stb cycles. The host initiates data transmission on the forward link by transmitting a subframe header packet as indicated by point G.

An example of a typical host-initiated wake processing step without contention uses the letters A, B, C, D, E, F, G, H, and I to name the event again for convenience in the figure. It is shown in Figure 68B. As mentioned above, the process starts at point A when the host sends a link shutdown packet to inform the client that the link transitions to a low power state.

At point B, the host toggles MDDI_Stb for approximately 64 cycles (or as desired by the system design) to allow the client to complete processing before stopping MDDI_Stb from toggle. Stop the recovered clock in the device. The host initially sets MDDI_Data0 to the logical zero level as well, and then disables the MDDI_Data0 output in the range of 16 to 48 cycles (usually including output disable propagation delay) after CRC. After 48 cycles after CRC and before the next step (C), it may be desirable to put the fast receiver for MDDI_Data0 and MDDI_Stb in the client into a low power state. The client hibernates the fast receiver for MDDI_Data0 and MDDI_Stb at any time after the rising edge of the 48th MDDI_Stb cycle after the CRC of the link shutdown packet. It is recommended that the client hibernate the fast receiver for MDDI_Data0 and MDDI_Stb at any time after the CRC of the link shutdown packet and before the rising edge of the 64th MDDI_Stb cycle.

The host enters the low power hibernation state at point or step C by disabling the MDDI_Data0 and MDDI_Stb drivers and putting the host controller into the low power hibernation state. If desired, the MDDI_Stb driver can be set to a logical zero level (using a high impedance bias network) or kept toggled during hibernation. The client is also in a low power level hibernation state.

After some time, the client enables the MDDI_Stb receiver and offsets on the MDDI_Stb receiver to ensure that the received version of MDDI_Stb is at the client's logical zero level before the host enables its MDDI_Stb driver. The link restart sequence is also started at point D by enabling. In order to ensure the reception of valid differential signals as desired and to suppress erroneous signals, it may be desirable for the client to enable the offset slightly before enabling the receiver. .. The client drives the MDDI_Data0 line to the logical 1 level while enabling the MDDI_Data0 driver. If offset is enabled and the standard MDDI_Stb differential receiver is enabled for less than 200 ns, MDDI_Data0 and MDDI_Stb are allowed to be enabled at the same time.

Within approximately 1 msec, within point E, the host recognizes the service request pulse from the client and the host initiates the link restart sequence by enabling the MDDI_Data0 and MDDI_Stb driver outputs. The host drives MDDI_Data0 to logical 1 level and MDDI_Stb to logical zero level as long as the driver takes to enable its respective output. The host typically waits approximately 200 nanoseconds after these outputs reach the desired logic level before driving the pulses with MDDI_Stb. This gives the client time to prepare for reception.

With the host driver enabled and MDDI_Data0 driven to logical 1 level, the host begins to output pulses at MDDI_Stb for a duration of 150 MDDI_Stb cycles, as seen at point F. When the client recognizes the first pulse on MDDI_Stb, it disables the offset on its MDDI_Stb receiver. The client continues to drive MDDI_Data0 to logical 1 level for 70 MDDI_Stb cycles and disables the MDDI_Dat0 driver at point G. The host continues to drive MDDI_Data0 to the logical 1 level for an additional 80 MDDI_Stb pulse, and at point H, drives MDDI_Data0 to the logical zero level.

As seen at points G and H, the host drives MDDI_Data0 to the logical zero level for 50 cycles, and the client begins looking for subframe header packets after MDDI_Data0 has been at the logical zero level for 40 MDDI_Stb cycles. After driving MDDI_Stb for 50 cycles, the host initiates data transmission on the forward link by transmitting a subframe header packet as seen at point I.

An example of the processing steps for a typical host-activated sleeve release where there is contention from the client, that is, the client also wants to wake the link, is shown in Figure 68C. The event is renamed for convenience in the figure using the letters A, B, C, D, E, F, G, H and I. As mentioned above, the process starts at point A when the host sends a link shutdown packet to inform the client that the link is transitioning to a low power state so that the client can complete the process. To point B, where MDDI_Stb is toggled for about 64 cycles (or as desired for system design), then disabling the MDDI_Data0 and MDDI_Stb drivers and putting the host controller into a low power hibernation state. By doing so, the host goes to point C where it enters a low power hibernation state. After some time, the host initiates the link restart sequence at point D by enabling the MDDI_Data0 and MDDI_Stb driver outputs and toggles MDDI_Stb for a period of 150 MDDI_Stb cycles, as seen at point E.

Up to 70 MDDI_Stb cycles after point E, here at point F, the client also drives MDDI_Data0 to logical 1 level because the client is not yet aware that the host is driving MDDI_Data0 to logical 1 level. This happens because the client has a desire to service but is unaware that the host it is trying to communicate with has already started the link restart sequence. At point G, the client stops driving MDDI_Data0 and puts its driver in a high impedance state by disabling its output. The host continues to drive an additional 80 cycles MDDI_Data0 to the logical 1 level.

The host drives MDDI_Data0 to the logical zero level for 50 cycles as indicated by point H, and the client begins looking for subframe header packets after MDI_Data0 has been at the logical zero level for 40 MDD_Stb cycles. .. The host initiates the transfer of data over the forward link by sending a subframe header packet as shown at point I.

VI. Interface electrical specifications In an embodiment of the example, the non-return-to-zero (NRZ) format is encoded using a data-strobe signal or DATA-STB format that allows clock information to be embedded within the data and strobe signals. The clock can be recovered without using a complex transfer lock loop network. Although other leads, printed wiring, or transfer elements can be used as described above, the data is propagated over bidirectional differential links and is usually achieved using wireline cables. The strobe (STB) signal is propagated on a unidirectional link driven only by the host. The strobe signal always toggles a value (0 or 1) when there is a continuous state 0 or 1 that remains the same on the data line or signal.

An example of how a data sequence such as bits "1110001011" can be transmitted using DATA-STB coding is shown graphically in FIG. In Figure 40, the DATA signal 4002 is shown in the top row of the signal timing chart and the STB signal 4004 is shown in the second row, which are properly aligned each time (common). Starting point). Over time, a state change occurs on the data line 4002 (signal), then the STB (strobe) line 4004 (signal) maintains its past state, thus the first "1" of the data signal. The "state" correlates with the initial "0" state of its starting value, the STB (strobe) signal. However, if the state or level of the data signal does not change, the STB signal toggles to the opposite state or "1" in this example, as in the case of FIG. 40 where the data provides another "1" value. That is, there is only one transition per bit cycle between DATA and STB. Therefore, since the DATA signal stays at "1", the STB signal again transitions to "0" this time, and when the DATA signal changes the level to "0", it retains this level or value. .. The STB signal toggles to the opposite state, or "1", in this example, because when the data signal stays at "1", the DATA signal changes or holds a level or value. And so on.

Upon receiving these signals, an exclusive OR (XOR) operation is shown at the bottom of the timing chart for a relative comparison between the desired data signal and the strobe signal, DATA to create the clock signal 4006. Executed with (data) signal and STB (strobe) signal. Generate a DATA output or signal and STB output or signal from the input data at the host, then recover or recapture the DATA signal and STB signal from the data at the client. An example of a valid network for this is shown in Figure 41.

If there is a change in state that occurs for DATA, the STB retains its previous state. However, if DATA does not change, the STB toggles against the opposite state. In other words, there is always one and only transition between DATA and STB per bit cycle. At the receiving end of the link, a clock signal (CLK signal in FIG. 40) is generated by performing an exclusive OR of DATA and STB. The use of data strobe codes has advantages over conventional systems that use data and clocks. This is because data strobe coded signals are about twice as tolerant of delaying distortion as systems that use data and clocks. Distortion at MDDI_Stb +/- can be caused by differences due to path delays between the driver and receiver at the host and client, as well as differences due to delays through the connections of MDDI_Data0 +/- and MDDI_Stb +/-. A quantitative analysis of the timing adversely affected by strain and other shortcomings in the MDDI_Data0 +/- and MDDI_Stb +/- pathways will be described in detail later.

For Type 2, Type 3, and Type 4 modes, MDDI_Data0 +/- and MDDI_Stb +/- behave like Type 1 with the property that they have one and only transition per bit cycle. Other MDDI_Data signals pass data at the same rate and phase as MDDI_Data0. The restored clock in the client generated from the exclusive OR of MDDI_Data0 +/- and MDDI_Stb +/- is also used to sample MDDI_Data01 +/- to MDDI_Data07 +/-.

A typical circuit that can be used to generate DATA and STB from the input data and then restore the input data from the DATA and STB is shown in FIG. In FIG. 41, the transmission portion 4100 is used to generate and transmit the original DATA and STB via the intermediate signal path 4102. The receiving portion 4120, on the other hand, is used to receive the signal and restore the data. As shown in FIG. 41, in order to transfer data from the host to the client, a DATA signal is input to the two D-type flip-flop circuit elements 4104, 4106 together with a clock signal that triggers the circuit. The two flip-flop circuit outputs (Q) are then split into differential pairs of MDDI_Data0 + and MDDI_Data0- and MDDI_Stb + and MDDI_Stb- signals using the differential line drivers 4108,4110 (voltage mode), respectively. A third input exclusive NOR (XNOR) gate, circuit, or logic element 4112 is connected to receive the DATA and output of both flip-flops and also produces an MDDI_Stb + signal, MDDI_Stb- signal. Produces an output that provides data input to the flip-flops of. For convenience, the XNOR gate installs an inversion bubble to indicate that it is effectively inverting the Q output of the flip-flop that produces the strobe.

In the receiving portion 4120 of FIG. 41, the MDDI_Data0 + signal, MDDI_Data0- signal and MDDI_Stb + signal, MDDI_Stb- signal are received by two differential line receivers 4122 and 4124, respectively, which generate a single output from the differential signal. .. The output of the amplifier is then input to each of the two inputs Exclusive OR (XOR) gate, circuit, or input of logic element 4126 that generates the clock signal. The clock signal, through delay element 4132 DATA (data) of two D-type flip for receiving the delayed version of the signal is used to trigger each flop circuits 4128 and 4130, one of which (4128) is data " The other (4130) yields a "0" value, while the other (4130) yields a data "1" value. The clock also has an output independent of the XOR logic. Since the clock information is distributed between the DATA line and the STB line, neither signal transitions between states faster than half the clock rate. The clock is regenerated using the exclusive OR processing of the DATA and STB signals, so the system effectively when the clock signal is transmitted directly on a single dedicated data line. Withstands twice the amount of distortion between the input data and the clock compared to the situation in.

The delay elements in the data recovery circuit illustrated in FIG. 41 or FIG. 57 are more challenging to implement, unlike the synchronous data capture circuits commonly used for conventional clock-data communication links. However, the data-strobe code allows the data rate to be approximately doubled without the need to use delayed distortion calibration. The significant propagation delay of the elements of the data recovery circuit is easy to achieve because it is associated with other delays in the same circuit. This can be easily implemented in a custom circuit, for example by using a simple logic element in an I / O pad circuit. This is because it is only necessary to generate a route that has a longer delay than the delays in other routes.

MDDI data pairs, namely MDDI_Stb + and MDDI_Stb- signals, are operated in differential mode to maximize immunity from the negative effects of noise. Each difference pair is terminated in parallel with the characteristic impedance of the cable or conductor used to carry the signal. Generally, all parallel terminations reside within the client device. This is close to a differential receiver for forward traffic (data sent from the host to the client), but it is a cable or other conductor for reverse traffic (data sent from the client to the host). , Or at the drive end of the transfer element. For reverse traffic, the signal is driven by the client, reflected by the high impedance receiver at the host, and terminated at the client. As mentioned above, the data from the reverse link or the reverse data can be transferred or transmitted at a data rate greater than the reciprocal of the round trip delay in the cable. The MDDI_Stb + and MDDI_Stb- signals are driven only by the host.

An exemplary configuration of drivers, receivers and effective elements to achieve termination as part of the MDDI of the present invention is shown in FIG. 42A. This exemplary interface uses low voltage sensing, here 200 mV, with less than 1 volt step-out and low power emissions. The driver for each signal pair has a differential current output. While receiving an MDDI packet, the MDDI_Data and MDDI_Stb pair uses a conventional differential receiver with a zero volt differential voltage threshold. In the hibernation state, the driver output is disabled and a parallel terminating resistor sets the differential voltage at each signal pair to zero volt. During hibernation, the special receiver on the MDDI_Data0 pair has a positive 125 mV offset input differential voltage threshold. This causes the hibernation line receiver to interpret the undriven signal pair as a logical zero level.

The differential voltage of a differential pair is defined as the difference between the voltage for the positive (+) signal minus the voltage for the negative (-) signal. The name of the difference pair signal using either "+" or "-" indicates the positive signal or the negative signal of the pair, respectively. The output current of the difference pair driver is defined as the current flow of the positive (+) output. The current through the negative (-) output of the difference driver is always of equal magnitude, but in the opposite direction to the current through the positive (+) output of the same difference driver.

FIG. 42B shows an example of a block diagram of a differential current mode driver that can be used to implement according to some embodiments of the present invention. The switched differential output stage routes the current source to either positive or negative driver output. The 0.35 volt voltage source keeps the measured output voltage above 0.35 volt with respect to ground at all times.

Often the host or client moves the delta pair to logical 1 level or logical zero level to ensure a valid logical level on the pair when the data flow direction changes (host to client or client to host). Drive at the same time. The output voltage range and output specifications are satisfied by the simultaneously driven outputs driven to the same logic level. In some systems, a small current needs to be driven into the termination difference pair to generate a small offset voltage during hibernation and at some time when the link wakes up from the hibernation state. In such a situation, the enabled offset current bias circuit is I_ESD-and-Rx, I_Ex-Hi-Z, And I_external-ESDDrives a current level called. I_ESD-and-RxIs the internal EDS diode and difference receiver input and is generally I_ESD-and-Rx1 μA. I_Ex-Hi-ZIs the differential driver output in the high impedance state, generally I_Ex-Hi-Z1 μA. I_external-ESDIs a leak through an external ESD protection diode, generally I_external-ESD3 μA.

Each of these leak currents is shown in FIG. As mentioned above, the pull-up and pull-down circuits must achieve the minimum differential voltage in the worst case leak condition where everything happens at the same time. The total leak is 4 μA in the internal mode without the external ESD protection diode and 10 μA in the external mode with the external ESD protection.

The electrical parameters and characteristics of the differential line driver and line receiver are described in Table IXa-IXd as typical embodiments. Functionally, the driver transfers the logic level directly to the positive output and the reciprocal of the input to the negative output at the input. The input-to-output delay is well matched to the differentially driven differential line. In most implementations, the voltage amplitude at the output is less than the amplitude at the input to minimize power consumption and electromagnetic radiation. In one embodiment, the minimum voltage amplitude is about 0.5V. However, other values may be used as will be known to those of skill in the art, and the inventors intend smaller values in some embodiments, depending on design constraints.

The differential line receiver has the same characteristics as the high speed voltage comparator. In FIG. 41, an input without bubbles is a positive input and an input with bubbles is a negative input. The output is logical 1 if (Vinput +)-(Vinput-) is greater than zero. Another way to explain this is with a differential amplifier with very large (practically infinite) gain, where the output is clipped at logical 0 and 1 voltage levels.

Delay distortion between the various pairs must be minimized in order for the differential transmission system to operate at the highest potential speed.<tables num="12"><img file="JP2010226725A_D0012.tif" /></tables><tables num="13"><img file="JP2010226725A_D0013.tif" /></tables><tables num="14"><img file="JP2010226725A_D0014.tif" /></tables><tables num="15"><img file="JP2010226725A_D0015.tif" /></tables>

FIG. 42 shows a host controller 4202 and a client or display controller 4204 that are forwarding packets over communication link 4206. The host controller is a set of three drivers 4210, 4212, and a series of three drivers not only to receive the transferred client data signal, but also to receive the transferred host DATA and STB signals. Use 4214. The client, on the other hand, applies the three drivers 4230,4232,4234. The driver involved in the passage of host data (4212) utilizes the enable signal input to allow the activation of a normal communication link only when transfer from the host to the client is desired. The STB (strobe) signal is formed as part of the data transfer, so no additional enable signal is utilized by its driver (4212). Each input of the client DATA driver and STB driver (4132,4230) has a terminating impedance or resistor 4218,4220 spaced apart from each other. Driver 4234 in the client controller is used to prepare the data signal being transferred from the client to the host. Here, driver 4214 is on the input side and processes the data.

A special receiver (driver) 4216,4236 is coupled or connected to the data line to generate or use a 125 mV voltage offset as described elsewhere as part of the hibernation control described elsewhere. These offsets cause the hibernation line receiver to interpret the undriven signal pair as a logical zero level.

The driver and impedance can be formed as discrete components or as part of an application specific integrated circuit (ASIC) that acts as a circuit module or even a more costly encoder or decoder solution.

It is easy to see that power is transferred from the host device to the client device, the display, using signals called HOST_Pwr and HOST_Gnd on a set of leads. The HOST_Gnd portion of the signal acts as a reference ground and a signal for the power return path or display. The HOST_Pwr signal acts as a client device power source driven by the host device. In an exemplary configuration, for low power applications, the client device can draw up to 500mA. The HOST_Pwr signal can be provided from a portable power source, including, but not limited to, a lithium-ion battery or a battery pack resident in the host device, and may range from 3.2 volts to 4.3 volts for HOST_Gnd.

VII. Timing characteristics A. Overview Applies to enter hibernation state (no service requested, desired, not needed) and initiated by either the host or the client to secure service for the client from the host Steps and signal levels are shown in FIGS. 43A, 43B, and 43C, respectively. In Figures 43A, 43B, and 43C, the first part of the signal depicted is the link shutdown packet being forwarded from the host, and the data line is then logically zero using a high impedance bias circuit. Driven to state. The data is not sent by the client, the host to which the driver is disabled. Since MDDI_Stb is active during the link shutdown packet, a series of strobe pulses for the MDDI_Stb signal line can be seen at the bottom. Once this packet is finished, the host drives the bias and logic circuits to zero, so the logic level changes to zero. This represents the last signal transfer from the host or the termination of the service, which could have occurred at any time in the past and is included to indicate the state of the signal before the service was suspended and started. .. When it is desired that the signal can be transmitted simply to reset the communication link to the proper state without the "known" past communication being initiated by this host device.

As shown in Figure 43A and as described above for the link shutdown packet, in the low power hibernation state, the MDDI_Data0 driver is 16th to 48th after the last bit of all zero fields in the link shutdown packet. MDDI_Stb Disabled to a high impedance state beginning after a cycle or pulse. For Type 2, Type 3, or Type 4 links, the signals from MDDI_Data1 to MDDI_DataPwr7 are also placed in a high impedance state at the same time that the MDDI_Data0 driver is disabled. As described in the definition of all zero fields, MDDI_Stb toggles for the 64 cycles following the MSB in the CRC field of the link shutdown packet (or as desired by the system design) so that the client completes the process. And facilitate regular shutdowns on the client controller. One cycle is a transition from low to high, followed by a transition from high to low. Alternatively, the transition from high to low is followed by the transition from low to high. After all zero fields have been sent, the MDDI_Stb and MDDI_Data0 drivers in the host are disabled and the host enters a low power hibernation state. After some time has passed, the host initiates a link restart sequence and initiates a wakeup request by enabling the MDDI_Data0 and MDDI_Stb lines or driver output, as shown in Figures 43B and 43C. Initiate MDDI_Stb toggle as part of one of the hosts.

As shown in Figure 43B, after a period of time with the signals output from the driver for disabled MDDI_Data0 and MDDI_Stb, the host will t while the line is being driven to logical zero._{stb-dagta-enbl}By enabling the MDDI_Stb driver for the specified period of time, it wakes up from hibernation or starts service until it is fully enabled and the MDDI_Data0 driver is enabled. The host has MDDI_Data0, but t_{client-startup}Keeps MDDI_Stb at the logical zero level after reaching the logical 1 level or high level that occurs over the period specified as. t_{client-startup}At the end of the period, the host toggles the MDDI_Stb signal or line. The host t while the client does not drive MDDI_Data0_restart-highDrives the MDDI_Data0 line high and logical 1 level for the period specified as. And t_restart-lowDrives the MDDI_Data0 line to a low, or logical zero level, for the period specified. After this, the first forward traffic begins with the subframe header packet and the forward traffic packet is forwarded. MDDI_Stb signal is t_restart-lowActive during the period and the next subframe header packet.

As shown in Figure 43C, after a period of time with the signals output from the driver for disabled MDDI_Data0 and MDDI_Stb, the client will perform t as described above before the host enables that MDDI_Stb driver._{stb-dagta-enbl}Initiates a wakeup from hibernation or a service request by enabling an offset at the output signal or MDDI_Stb receiver for the period specified as. The client then asks t while the line is being driven to the logical zero level before the host initiates the MDDI_Stb toggle._host-detectEnables the MDDI_Data0 driver for the period specified as.

t_restart-highBy driving MDDI_Data0 to logical 1 or higher level for a period of time, t before the host initiates a toggle of MDDI_Stb with the link launch sequence._stb-startupAfter responding by holding MDDI_Stb at the logical zero level for the specified period, then t_host-detectDuring that time, a certain amount of time elapses or is required before the host detects the request. When the client recognizes the first pulse on MDDI_Stb, it disables the offset in its MDDI_Stb receiver. The client sets MDDI_Data0 at logical 1 level or t until it finds the host driving the line._{client-detect}Continues to drive for the specified period. In this regard, the client deasserts this request and disables the MDDI_Data0 driver so that the output from the client goes back to the logical zero level and the host can drive MDDI_Data0. As mentioned above, the host sets MDDI_Data0, t_restart-highDuring that time, it continues to drive to the logical 1st level, after the first forward traffic begins with the subframe header packet, then t_restart-lowDuring that time, drive the MDDI_Data0 line low. MDDI_Stb signal is t_restart-lowAnd active during the next subframe header packet.

Table X shows the typical time or processing period of the various period lengths mentioned above, and the relationship between the exemplary minimum and maximum data rates.<maths num="1"><img file="JP2010226725A_D0016.tif" /></maths>

Here, Link_Data_Rate is the bit rate of a single data pair.<tables num="16"><img file="JP2010226725A_D0017.tif" /></tables>

Those skilled in the art are familiar with the functions of the individual elements shown in FIGS. 41 and 42, and it is easy for those skilled in the art to confirm the functions of the elements of FIG. 42A in the timing diagrams of FIGS. 43A, 43B, and 43C. The details of the series termination and hibernation resistors shown in Figure 42A, as understood in, are not necessary to explain how that information performs data-strobe coding and recovers the clock from it. Therefore, it is omitted from Fig. 41.

B. Data-Strobe Timing Forward Link The switching characteristics of data transfer from the host driver output to the forward link are shown in Table XI-1. Table XI-1 presents the typical time for the desired minimum and maximum vs. specific signal transitions in tabular form to occur. For example, the minimum time is about t_tbit-0.5nsec, maximum is about t_tbit+ 0.5nsec, but the typical length of time that a transition occurs from the beginning to the end of a data value (output of "0" or "1"), t_tddThe Data0 to Data0 transition called-(host-output) is t_tbitIs. The relative spacing between transitions on Data0, other data lines (DataX), and strobe lines (Stb) is t, respectively._tds-(Host-Output), t_tss-(Host-Output), t_tsd-(Host-Output), t_tddx-(Host-Output), t_tdx-(Host-Output), t_tdxs-(Host-Output), and t_tsdx-(Host-Output) shows Data0 to strobe, strobe to strobe, strobe to Data0, Data0 to non-Data0, non-Data0 to non-Data0, non-Data0 to strobe, and strobe to non-Data0 transition. It is depicted in Figure 44.<tables num="17"><img file="JP2010226725A_D0018.tif" /></tables>

Typical MDDI timing requirements for client receiver input of the same signal transferring data over a forward link are shown in Table XI-2. The same signal is described, but the time is delayed, so no new figure is needed to explain the signal characteristics or meaning of each label, as will be understood by those skilled in the art.<tables num="18"><img file="JP2010226725A_D0019.tif" /></tables>

Figures 45 and 46 illustrate the existence of response delays that can occur when a host enables or disables a host driver, respectively. For hosts forwarding certain packets, such as reverse link-encapsulated packets or round-trip delay measurement packets, the parameters CRC packets, strobe alignment packets, and all-zero packets shown in FIG. 45 as forwarded, etc. , The host discapsulates the line driver after the desired packet has been forwarded. However, as shown in FIG. 45, this is probably achievable in the presence of certain control or circuit elements, but the line condition is not necessarily instantaneous from "0" to the desired higher value. However, the response requires a period called the host driver disable delay period. It can occur virtually instantly so that the length of this period is 0 nanoseconds (nsec), but it is the desired maximum period length that occurs during a guard time of 1 packet period or a turnaround of 1 packet period. It will spread more easily over a longer period of 10 nsec.

Looking at FIG. 46, it can be seen that the signal level change occurred when the host driver was enabled to forward packets such as reverse link encapsulation packets or round trip delay measurement packets. Here, after a guard time of 2 packets or a turnaround of 2 packets, the host driver is enabled and begins to drive the level, here "0", to its value before the first packet is sent. , Approaches or reaches a period called the host driver enable delay period that occurs during the driver re-enable period.

A similar process occurs for drivers and for signal transfers for client devices, here displays. General guidelines for the length of these periods and their relationships are shown in Table XII below.<tables num="19"><img file="JP2010226725A_D0020.tif" /></tables>

C. Host and client output enable and disable times FIG. 48 is a diagram showing the relative timing relationship between the enable time and disable time between the host output and the client output, the reverse link encapsulation packet structure and period, and the switching characteristics. The driver output function or operation is in the case of host output enable time t_host-enableAnd for host output disable time t_host-disableAnd for client output enable time t_{client-enable}And for client output disable time t_{client-disable}Are labeled respectively. A typical time for a signal transition is described below. The minimum period for these operations will be zero nanoseconds. The general or maximum value determined from the interfaced system design will probably be on the order of 8 nanoseconds or more.

The length of these periods (host and client enable / disable times) and general guidelines for their relationships are shown in Table XIII.<tables num="20"><img file="JP2010226725A_D0021.tif" /></tables>

VIII. Implementation of link control (link controller operation) A. State machine packet processor Packets being forwarded over the MDDI link are reliably handled at even lower speeds as desired, but are dispatched very quickly, typically at speeds above about 300 Mbps. The speed of this type of bus or transfer link is too fast to be controlled by currently commercially available (economical) general purpose microprocessors and the like. Therefore, a practical implementation to achieve this type of signal transfer analyzes the input packet stream to create packets that are forwarded or redirected to the appropriate audiovisual subsystem in which they are intended. To utilize programmable state machines. Such devices are well known and typically use circuits dedicated to a limited number of operations, functions or states in order to achieve the desired high speed or ultrafast operation.

A general purpose controller, processor, or processing element can be used to better act or manipulate some information, such as control packets or status packets with lower speed requirements. When those packets (control, status, or other predetermined packet) are received, the status machine will have the desired result while the voice and visual packets are forwarded to their appropriate destination for treatment. They need to be passed to a general purpose processor through a data buffer or similar processing element so that they can be affected to provide (effects). In the future, when a microprocessor or other general-purpose controller, processor, or processing element is manufactured to achieve faster data rate processing capabilities, the state, usually as a program stored on a storage element or medium. Alternatively, a state machine described below may also be realized using software control of such a device.

General-purpose processor functions are available processing power or excess for microcomputers (CPUs) in computer applications, or for controllers, processors, digital signal processors (DSPs), specialized circuits, or ASICs found in wireless devices, etc. A cycle of CPUs found in a computer to reduce hardware complexity and cost by leveraging the processing power of the CPU found in the computer for some modems or graphics processors to perform some function. It can be realized in some embodiments by utilizing the processing power. However, this cycle sharing or use can negatively affect the processing speed, timing, or overall operation of such devices, so in many applications, dedicated circuits or dedicated circuits for this general purpose processing or The element is preferred.

Client signal processing is synchronized with forward link channel timing to ensure that the image data is displayed on the display (microdisplay) or that all packets transmitted by the host device are received. That is, the signal arriving at the client and the client circuit need to be substantially time synchronized for proper signal processing. In one embodiment, the high level diagram achieved by the signal is illustrated in FIG. In Figure 49, they are classified as one ASYNC FRAME (asynchronous frame state) 4904, two synchronous acquisition states (ACQUIRING SYNC STATES) 4902 and 4906, and three synchronous states (IN-SYNC STATES) 4908, 4910, and 4912. State The possible forward sync "state" of the machine 4900 is shown.

As indicated by initiating step or state 4902, a display or client, such as a presentation device, starts in a preselected "out of sync" state and is detected in the first subframe header packet. Search for unique words. It should be noted that this out-of-sync state represents the minimum communication setting, or the "backward" setting in which the Type 1 interface is selected. If a unique word is found during the search, the client saves the subframe length field. There is no check for the CRC bit for processing this first frame or until synchronization is obtained. If this subframe length is zero, synchronization state processing proceeds corresponding to state 4904, which is now referred to as the "asynchronous frame" state, which indicates that synchronization has not yet been achieved. This step of processing is named having the encounter cond3 in FIG. 49, ie condition 3. Otherwise, if the frame length is greater than zero, synchronization state processing proceeds to state 4906, where the interface state is set as "find one synchronization frame". This step of processing is named encounter cond5, condition 5 in Figure 49. Further, if the state machine sees a frame header packet and a good CRC decision for a frame length greater than zero, the process proceeds to "find one sync frame". This is named conference cond6, condition 6 in Figure 49.

In each situation where the system is in a state other than "out of synchronization", the interface state is changed to the "in sync" state 4908 when a packet with good CRC results is detected. This step in the process is named cond1, that is, the condition 1 in Figure 49 was encountered. On the other hand, if the CRC of any packet is incorrect, synchronization state processing proceeds to or returns to interface state 4902 in the "NO SYNC FRAME" state. This part of the process is named the encounter cond2, or condition 2, the phase diagram of Figure 49.

B. Sync acquisition time The interface can be configured to determine that synchronization has been lost and deal with a certain number of "synchronization errors" before returning to the "NO SYNC FRAME" state. In Figure 49, the state machine is once "IN-SYNC". When "STATE" is reached and no error is detected, it continuously encounters cond1 results and remains in "IN-SYNC" state. However, once one cond2 result is detected, the process changes state to "1 synchronization error" state 4910. At this point, if the process results in detecting another cond1 result, the state machine will return to the "synchronizing" state, otherwise it will encounter another cond2 result and "TWO-SYNC-ERRORS (2). (Synchronization error)" Go to state 4912. When cond1 occurs again, the process returns the state machine to the "IN-SYNC" state. Otherwise, another cond2 is encountered and the state machine returns to the "out of sync" state. When the interface encounters a "link shutdown packet", this causes the link to terminate the data transfer and "no synchronization frame" because there is nothing to synchronize with cond4 in the phase diagram of Figure 49, or meeting condition 4. It is also understandable to return to the state.

It is understood that it is possible to repeat a "fake copy" of a unique word that may appear somewhere in the subframe at a fixed location. In that situation, the CRC on the subframe header packet must also be valid when the MDD interface processing is processed to go to the "IN SYNC" state, so the state machine synchronizes to the subframe. Very unlikely to do.

The subframe length in the subframe header packet is set to zero to indicate that the host sends only one subframe before the link is shut down and MDDI is put into hibernation or configured. May be done. In this case, the client must receive the packet immediately on the forward link after detecting the subframe header packet and only one subframe is sent before the link transitions to the idle state. In normal or typical operation, the subframe length is non-zero and the client is in those states where the interfaces are collectively shown in Figure 49 as the "IN-SYNC" state. It only processes forward link packets in between.

The external mode client device belongs to the host while the host is already sending the forward link data sequence. In this situation, the client must synchronize with the host. The time it takes for the client to synchronize to the forward link signal is variable depending on the subframe size and forward link data rate. The likelihood of detecting a "fake copy" of a unique word as part of random or even random data within a forward link is greater than when the subframe size is larger. At the same time, slower forward link data rates reduce the ability to recover from false positives and increase the time it takes to do so.

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

One possible problem is that if the host uses incorrect round-trip delay measurements, it will spoil all of the reverse data transmissions that continue to be received from the client, even though the forward link looks good. is there. This is an extreme case where the host attempts to send a round-trip delay measurement packet when the client is out of sync with the forward link, or causes significant changes in the differential driver and receiver propagation delays that affect the round-trip delay. It can be caused by changes in ambient temperature. Intermittent cable or connector connection defects also cause the client to temporarily lose synchronization and then regain synchronization. During this time, reception of the round-trip delay measurement packet may fail. Subsequent reverse link packets will not be properly restored by the host.

Another type of problem that can occur is that if the client temporarily loses synchronization, the host sends a link shutdown packet before the client can reacquire synchronization. The host is in hibernation while the client cannot enter hibernation. This is because it has not received a link shutdown packet and has no clock because the link is in hibernation.

A technique or embodiment available to overcome such problems is to ensure that the client is in sync with the forward link before putting the link into hibernation state. If the MDDI host is unable to do this, or does not have the opportunity, for example in the event of a power loss, or the link is abruptly broken due to separation, breakage, or disconnection of a working cable, conductor, or connector. If so, the host should first attempt to ensure that the client is in sync before initiating the round-trip delay measurement process or sending a reverse link-encapsulated packet.

The host can determine forward link integrity by observing the status packets sent by the client and the CRC error count field in the client request. This packet is requested by the host from the client. However, in the event of a large link defect or break, the client will be less responsive due to the inability to properly decrypt the packet. Or it will receive completely. Requests for CRC error counts using status packets and client requests sent within reverse link encapsulation packets act as a first integrity check, a kind of first line of defense. In addition, the host can send a round-trip delay measurement packet to see if the assumptions about the client out of synchronization are valid. If the client does not respond to the round-trip delay measurement packet, the host will conclude that the client can start the process of exiting and returning to synchronization.

By periodically sending backward link-encapsulated packets to clients with bit 1 set to 1 in the reverse link flag field, the CRC error count on the client is continuously monitored, and the client hosts client requests and status packets. It is generally recommended to request a return to.

Once the host concludes that the client has definitely lost synchronization with the forward link, the host waits until the next subframe header before attempting to send any packet except the filler packet. This is done to give the client enough time to detect or find one unique word contained in the subframe header packet. Following this, the host assumes that the client would have reset itself. Because it wouldn't find the unique word in the right place. In this regard, the host follows the subframe header packet with the round-trip delay measurement packet. If the client still does not respond correctly to the round-trip delay measurement packet, the host repeats the resynchronization process. In the correct response, the client sends the identified sequence back to the host at the measurement cycle of the round-trip delay measurement packet. If this sequence is not received, attempts to receive the reverse data in the reverse link encapsulation packet will fail. Successive failures of this property indicate other system errors that must be addressed in another way and are not part of link synchronization in this regard.

However, after a successful round-trip delay measurement packet, if the host still sees no response in the reverse link-encapsulated packet or sees corrupted data, retransmit the round-trip delay measurement packet. Should ensure that the reverse data sampling is correct. If repeated attempts are unsuccessful, in one embodiment it is recommended to reduce the reverse data rate by increasing the reverse rate inverse value.

It is recommended that the host should perform a link defect detection and possibly link resynchronization step before putting the MDDI link into hibernation state. This generally ensures that the round-trip delay measurement packet that is executed later when the link is restarted is successful. If the host does not have a reason to suspect a link defect or a correct response to the reverse link encapsulated packet and a zero forward link CRC error is reported by the client, the host will follow all accordingly. Alternatively, assume that it is working or functioning properly (eg, without link defects) and proceed with the power down / hiburnation process.

Another way the host can test for synchronization is for the host to send a round-trip delay measurement packet to see the proper response from the client. If the appropriate response is received by the host, the client can reasonably assume that it is interpreting the forward link packet correctly.

C. Initialization As mentioned above, at "boot", the host configures the forward link to operate at or below the minimum required data rate of 1 Mbps, subframe length and media frame rate. Is appropriately configured for the default application. That is, both forward and reverse links start working using the Type 1 interface. These parameters will typically be used temporarily while the host determines the functionality or desired configuration for the client display (or other type of client device). The host causes the display or client to set the request flag bit "0" to a value of 1 (1) in order to request that the client function packet respond on the forward link followed by a reverse link encapsulation packet. Sends or forwards subframe header packets with. Once the display has acquired synchronization on the forward link (or with the forward link), it sends client function packets and client request and status packets over the reverse link or channel.

The host examines the contents of the display function packet to determine how to reconstruct the link with the best or desired level of performance. The host examines the protocol version field and the minimum protocol version field to ensure that the host and display use mutually compatible protocol versions. The protocol version usually remains as the first two parameters of the display feature packet so that compatibility can be determined even when elements of other protocols are incompatible or not fully understood to be compatible.

In internal mode, the host can know the client parameters in advance without having to receive the client function packet. The link can be launched at any data rate that both the host and the client can operate. In many embodiments, the system designer will most likely choose to initiate the link at the maximum achievable data rate in order to expedite the data transfer, but this is not required and used in many situations. It may not be done. For internal mode operation, the frequency of the strobe pulse used during the link restart from the hibernation sequence usually matches the desired rate.

D. CRC processing For all packet types, the packet processor state machine ensures that the CRC checker is properly or accurately controlled. It also increments the CRC error counter when one or more errors are detected as a result of the CRC comparison, which resets the CRC counter at the beginning of each subframe being processed.

E. Synchronous check alternative loss While the series of steps or states described above results in higher data rates or throughput rates, the alternative sequences or state changes that the client uses to declare that there is a loss of synchronization with the host In fact, we have found that it can be used to achieve even higher data rates or throughput. Embodiments of the new invention have the same basic structure, although the state has been changed to change the state. In addition, new counters have been implemented to help check for subframe synchronization. These steps and states are presented with respect to State Machine Figure 63, which shows a set of states and conditions that are effective in establishing the operation or state machine of the method. "ACQUIRING-SYNC STATES" part and "IN-SYNC" Only the "STATES" part is shown for clarity. In addition, they use the same numbering because the resulting states are substantially the same, as are the state machines themselves. However, the conditions for changing the state (and the operation of the state machine) change slightly, and as a result, two figures (1, 2, 3, 4, 5 and) are considered for convenience in identifying the differences. Everything is renumbered for clarity between 6 to 61, 62, 63, 64, 65). One state (4904) and condition (6) are not used in the figure because the ASYNC FRAME state is not considered in this description.

In FIG. 63, in a preselected "out of sync" state 4902 as shown in FIG. 49, the system or client (for display or presentation) starts at state machine 5000. The first state change to change the state from the unsynchronized state 4902 is in condition 64, which is the discovery of a synchronization pattern. Assuming that the CRC of the subframe header also forwards this packet forward (satisfying condition 61), the state of the packet processor state machine can be changed to the syncing state 4908. A system error, condition 62, shifts the state machine to state 4910 and the second occurrence to state 4912. However, it was discovered that a CRC failure of the MDDI packet caused the state machine to move out of sync state 4908 and into one sync error state 4910. Another CRC failure of the MDDI packet drives it into two synchronous failure states 4912. The packet decrypted with the correct CRC value returns the state machine to the syncing state 4908.

What has changed is to take advantage of CRC values or decisions for "any" packet. That is, instead of simply observing the subframe header packets, the state machine is made to look up the CRC value for each packet to determine the loss of synchronization. In this configuration or process, synchronization loss is not determined using unique words and simply subframe header CRC values.

The new interface implementation allows MDD interface links to recognize synchronization failures much faster and therefore also recover from them even faster.

To make this system even more robust, clients need to add or leverage subframe counters. The client checks for the presence of a unique word when it is expected to arrive or occur in the signal. If the unique field word does not occur when it is correct, the client will experience a synchronization failure much faster than if it had to wait for more than one packet count or subframe length (here 3). I can recognize what I did. If a test of the unique word shows that it does not exist, in other words the timing is incorrect, the client can immediately declare a sync link loss and go into the out-of-sync state. The process of checking for the existence of an exact unique word adds condition 65 (cond65) to the state machine, stating that the unique word is incorrect. If the subframe packet is expected to be received by the client and does not match, the client immediately moves to out-of-sync state 4902 and typically encounters multiple sync errors (conditions) back and forth through states 4910 and 4912. 62) You can save the additional time waiting.

This change uses an additional counter or counting function within the client core to count the subframe length. In one embodiment, a countdown function is used to interrupt the transfer of any packet currently being processed to check for subframe-specific words when the counter expires. Instead, the counter can be counted and the count is compared to the desired maximum or specific desired value, at which point the current packet is checked. This process protects the client from decrypting erroneously received packets on the client with unusually long packet lengths. If the subframe length counter needs to interrupt some other packet that was being decrypted, the packet must not cross the subframe boundary, so the loss of synchronization can be determined.

IX. Packet processing For the various packets described above received by the state machine, it undertakes a specific processing step or sequence of steps to achieve the operation of the interface. Forward link packets are typically processed according to the exemplary processing listed in Table XIV below.<tables num="21-1"><img file="JP2010226725A_D0022.tif" /></tables><tables num="21-2"><img file="JP2010226725A_D0023.tif" /></tables><tables num="21-3"><img file="JP2010226725A_D0024.tif" /></tables>

X. Reverse link data rate deceleration By the inventors, the particular parameters used for the host link controller can be adjusted or configured in a special way to achieve the highly desirable maximum or even more optimized (scaled) reverse link data rate. Was observed. For example, during the time used to transfer the reverse data packet field of a reverse link encapsulated packet, the MDDI_Stb signal set toggles to create a periodic data clock at half the forward link data rate. .. This happens because the host link controller produces an MDDI_Stb signal that corresponds to the MDDI_Data0 signal as if it were transmitting all zeros. The MDDI_Stb signal is transferred from the host to the client and the reverse data is sent back to the host when it is used to generate a clock signal from the client to transfer the reverse link data. An illustration of the typical amount of delay encountered for signal transfer and processing in the forward and reverse paths in a system utilizing MDDI is shown in Figure 50. In Figure 50, a series of delay values, 1.5nsec, 8.0nsec, 2.5nsec, 2.0nsec, 10nsec, 15nsec, 8nsec and 25nsec, are Stb +/- generation, cable transfer for display, display receiver, clock creation, signal time, respectively. Shown near the processing part for recording, Data0 +/- generation, cable transfer to client, and client receiver stage.

Depending on the forward link data and the signal processing delays encountered, completing this set of "round-trip" effects or events can take more than one cycle with the MDDI_Stb signal, time or cycle. It leads to the consumption of an undesired amount of time or cycle. To avoid this problem, the reverse rate divisor allows one bit time on the reverse link to span multiple cycles of the MDDI_Stb signal. That is, the reverse link data is less than the forward link rate.

It should be noted that the actual length of signal delay through the interface may vary depending on each particular host-client system or the hardware used. Although not required, each system usually works better by using round-trip delay measurement packets to measure the actual delay in the system so that the reverse rate divisor can be set to the optimum value. be able to. The host supports either basic data sampling, which is easier but runs slower, or improved data sampling, which supports more complex but faster reverse data rates. Client features that support both methods are considered as well.

The round-trip delay is measured by having the host send a round-trip delay measurement packet to the client. The client responds to this packet by sending a sequence of 1s back to the host inside or during a preselected measurement window within that packet called the measurement period field. The detailed timing of this measurement has been described above. Round trip delays are used to determine the rate at which reverse link data can be safely sampled.

A round-trip delay measurement determines the number of forward link data clock intervals that occur between the beginning of the measurement period field and the beginning of the time period when the 0xff, 0xff, 0x00 response sequence is rereceived by the host from the client. , Detecting, or counting. Note that the response from the client can be received for only a short period of the forward link clock period before the measurement count is likely to increment. If this uncorrected value is used to calculate the reverse rate divisor, it will cause a bit error in the reverse link due to unreliable data sampling. An example of this situation is the signal representing MDDI_Data at the host, MDDI_Stb at the host, the forward link data clock inside the host, and the delay count, and the resulting pixels are written to the destination pixel location shown graphically. It is indicated by. In Figure 51, the response sequence was received from the client for part of the forward link clock period before the delay count increased from 6 to 7. If the delay is considered to be 6, the host samples the reverse data immediately after the bit transition, or perhaps in the middle of the bit transition. This will result in incorrect sampling on the host. For this reason, the measurement delay must usually be incremented by 1, before it can be used to calculate the reverse data divisor.

The reverse rate divisor is the number of MDDI_Stb cycles that the host must wait before sampling the reverse link data. Since MDDI_Stb circulates at a rate that is half the forward link rate, the corrected round-trip delay measurement must be divided by 2 and then rounded up to the next integer. Expressed as a formula, this relationship is as follows.<maths num="2"><img file="JP2010226725A_D0025.tif" /></maths>

For the example shown, this would be:<maths num="3"><img file="JP2010226725A_D0026.tif" /></maths>

If the round-trip delay measurement used in this example was 7 as opposed to 6, the reverse rate divisor would also be equal to 4.

The reverse link data is sampled by the host at the rising edge of the reverse link clock. To create a reverse link clock, there are counters or similar known circuits or devices that are present on both the host and the client (display). The counter is initialized so that the first rise of the reverse link clock occurs at the beginning of the first bit of the reverse link packet field of the reverse link encapsulated packet. This is shown in FIGS. 52A and 52B for the examples described below. The counter increments at each rise of the MDDI_Stb signal, and the counts that occur until they wrap around are set by the reverse rate divisor parameter in the reverse link-encapsulated packet. Since the MDDI_Stb signal toggles 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 follows.<maths num="4"><img file="JP2010226725A_D0027.tif" /></maths>

Examples showing the timing of the MDDI_Data0 and MDDI_Stb signal lines in a reverse link-encapsulated packet are shown in FIGS. 52A and 52B, and the packet parameters used in the figure have the following values.

Packet length = 1024 (0x0400) Direction change 1 length = 1 Packet type = 65 (0x41) Direction change 2 length = 1 Reverse link flag = 0 Reverse rate divisor = 2 Parameter CRC = 0xdb43 All zeros are 0x00 The packet data between the packet length field and the parameter CRC field is as follows. 0x00, 0x04, 0x41, 0x00, 0x02, 0x01, 0x01, 0x43, 0xdb, 0x00, ... The first reverse link packet returned by the client is a client request and status packet with a packet length of 7 and a packet type of 70. This packet starts with byte values 0x07, 0x00, 0x46, ... etc. However, only the first byte (0x07) is visible in FIGS. 52A and 52B. This first reverse link packet has been moved approximately one reverse link clock period time in the figure to indicate the actual reverse link delay. The ideal waveform for a client round trip delay with zero host is shown as a dotted trace.

The MS bytes of the parameter CRC field are forwarded, preceded by the packet type, followed by all zero fields. The strobe from the host switches from 1 to zero and to 1 as the data from the host changes levels, forming a wider pulse. When the data reaches zero, the strobe switches at an even higher rate, and only changes in the data in the data line cause changes near the end of the alignment field. For a long period of time, the strobe switches faster for the rest of the figure due to the fixed 0 or 1 level of the data signal, making a falling transition to the pulse pattern (edge).

The host's reverse link clock is zero until the end of one diversion period in which the clock is invoked to handle the reverse link packet. The arrows at the bottom of the figure indicate when the data will be sampled as will be apparent from the rest of the disclosure. The first byte of the forwarded packet field (here 11000000), which started after turn 1, is shown, and the line level is stabilized from the disabled host driver. The delay in passing the first bit is seen from the dotted line for the data signal, as seen for bit 3.

In FIG. 53, a typical value of the reverse rate divisor can be observed based on the forward link data rate. The actual reverse rate divisor is obtained as a result of the reciprocating link measurement to ensure proper reverse link operation. The third region 5306 indicates a setting value that is unlikely to function properly, the first region 5302 corresponds to the region of safe operation, and the second region 5304 corresponds to the region of marginal performance.

Round-trip delay measurements and reverse rate divisor settings are expressed in units of the actual clock period rather than the number of bits they are transmitted or received, and are either forward or reverse links to operate. It is the same while working with any of the interface type settings in.

In general, the maximum possible reverse rate divisor is half the number of bits that can be sent within the measurement window of a round-trip delay measurement packet using the Type 1 interface, in this example:<maths num="5"><img file="JP2010226725A_D0028.tif" /></maths>

Also, the improved reverse data sampling method can be applied as an alternative example that allows the reverse bit time to be smaller than the round trip delay. In this technique, the host can not only measure the round-trip delay, but also phase the response from the client with respect to the "ideal" bit boundary consisting of the zero-delay link and the client. Knowing the phase of the client device response allows the host to determine a relatively safe time to sample the reverse data bits from the client. This round-trip delay measurement indicates to the host the position of the first bit of the reverse data with respect to the beginning of the reverse data packet field.

An example embodiment of improved reverse data sampling is shown graphically in FIG. 52B. The ideal reverse data signal with zero round trip delay is shown as a dotted line waveform. The actual round-trip delay between 3.5 and 4.5 MDDI_Stb cycles is shown as the difference in delay between the solid waveform and the ideal. This is the same delay as measured using the round-trip delay measurement packet, which is the measured round-trip delay value equal to the 7 forward link bit times. In this embodiment, the reverse data bits have a 2MDDI_Stb pulse length. This is 4 forward link bit times and corresponds to a reverse rate divisor equal to 2. For improved reverse data sampling, it is convenient to use a preselected 2 for the reverse rate divisor instead of calculating as described. This looks like a practically optimal choice for improved reverse data sampling. This is because the ideal sampling point can be easily determined using the conventional measurements described above.

An ideal sampling point for reverse data is the remainder where the entire round trip delay is divided by the number of forward link clocks per reverse bit, i.e. the forward link clock per reverse bit of the round trip delay. It can be easily calculated by taking the modulo by. Then, by subtracting 1 or 2, a safe point away from the data transition is obtained. In this example, 7mod4 = 3, so 3-1 = 2 or 3-2 = 1. This safe sampling point is one or two forward link bit times from the edge of the "ideal" bit boundary for zero round trip delay. The drawing shows sampling points at two forward link bit times from the ideal bit boundary, as indicated by a series of vertical arrows at the bottom of the timing diagram. The first sampling point adds an offset for safe sampling to the first ideal bit boundary after the measured round trip delay. In this example, the round-trip delay measurement is 7, and the next ideal bit boundary is the 8th bit time, so add 1 or 2 for a safe sampling point. Thereby, the first bit shall be sampled at 9 or 10 forward link bit times after the start of the reverse data packet field.

XI. Direction change and guard time The redirect 1 field in the reverse link encapsulated packet disables the host driver and enables the client driver at the same time. The guard time 1 field in the round-trip delay measurement packet allows overlap between the host and the client, so the client driver can be enabled before the host interface driver is disabled. The diversion 2 field in the reverse link encapsulation packet can ensure that the data in the previous field is fully transmitted by the client before the host driver is enabled. The guard time 2 field gives a time value or duration that allows the client and host drivers to drive simultaneously at the logical zero level. The guard time 1 field and guard time 2 field are generally filled with preset or preselected values for lengths that do not mean to be adjusted. Depending on the interface hardware used, these values may be developed or adjusted using empirical data to improve behavior.

Change direction 1 Multiple factors contributed to the determination of the length of turnaround 1, which are the forward link data rate, the maximum disable time of the MDDI_Data driver in the host, and the client driver enablement, which is generally the same as the host disable time. It's time. The length of one turn field is 24 t_BITIs selected to be (Table XIII). The length of the number of forward link bytes in a redirection 1 field is determined using the interface type factor and is calculated using the following relationship.<maths num="6"><img file="JP2010226725A_D0029.tif" /></maths>

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

Change direction 2 The factors that determine the length of time normally used for turnaround 2 are specified to be the same as the round-trip delay of the communication link, the maximum disable time of the MDDI_Data driver in the client, and the client driver disable time. The enable time of the host driver. The maximum host driver enable time and client driver disable time are specified. Round trip delay is t_BITIt is measured in units of. The minimum length specified by the number of forward link bytes of turn 2 is calculated according to the following relationship.<maths num="7"><img file="JP2010226725A_D0030.tif" /></maths>

For example, a type 3 forward link with a reciprocating delay called a 10 forward link clock typically uses a diversion 2 delay according to the following rules.<maths num="8"><img file="JP2010226725A_D0031.tif" /></maths>

XII. Alternative reverse link timing While the timing and protection frequency bands mentioned above strive to achieve high data transfer rate interfaces, we have modified the reverse timing discovery to allow reverse bit lengths shorter than the round trip time. I found a technique.

As presented above, past approaches to reverse link timing have the number of clock cycles sampled from the last bit of guard time 1 of the reverse timing packet, with the first bit sampling at the rising edge of the IO clock. Is configured to count up to. It is the clock signal (s) used to time the MDDI inputs and outputs. Therefore, the calculation for the reverse rate divisor is shown below.<maths num="9"><img file="JP2010226725A_D0032.tif" /></maths>

This provides a bit width equal to the round trip delay that results in a very reliable reverse link. However, it has been shown that reverse links can be operated at higher speeds, that is, higher data transfer rates, which the inventors desire to use. The new technique of the present invention allows the additional features of the interface to be leveraged to reach even higher speeds.

This is achieved by having the host count the number of clock cycles until 1 is sampled, but the host samples the data lines both on and off during the reverse timing packet. This allows the host to choose the most effective or even optimal sampling point of the reverse bits to ensure that the bits are stable. That is, finding the most effective or optimal rising edge for sampling data for reverse traffic reverse encapsulated packets. The optimal sampling point depends on both the reverse link divisor and whether the first one was detected at the rising edge or the falling edge. With the new timing method, the host can simply look for the first edge of the 0xFF 0xFF 0x00 pattern sent by the client for reverse link timing to determine where to sample in the reverse encapsulated packet. become able to.

An example of the arriving reverse bits and how they look for various reverse rate divisors is shown in FIG. 64, along with the many clock cycles that have occurred since the last bit of guard time 1. In Figure 64, when the first edge occurs between rising and falling (named rising / falling), it is the only rising that occurs within the period of the reverse bit, so the reverse direction of 1. The optimal sampling point for rate divisors, or optimal sample points, is the clock cycle edge named "b". For a reverse rate divisor of 2, the cycle edge "c" is closer to the bit edge than "b", so the optimal sampling point is probably still the clock cycle leading edge "b". For a reverse rate divisor of 4, the optimal sampling point is probably the clock cycle edge "d", as it is probably even closer to the back edge of the stabilized reverse bit.

Returning to Figure 64, however, when the first edge occurs between the falling edge and the rising edge (named falling / rising), the optimal sampling point for the reverse rate divisor of 1 is the reverse bit. Since it is the only rising edge in the period, it is the sampling point clock cycle edge "a". In the case of a reverse rate divisor of 2, the optimal sampling point is the edge "b", and in the case of a reverse rate divisor of 4, the optimal sampling point is the edge "c".

As the reverse rate divisor grows larger and larger, the closest to the middle must be the rising edge, making it easier to see or select the optimal sampling point as well.

The host can use this technique to find out the number of rising clocks before the rising data of the timing packet data is observed on the data line. As a result, it is whether the edges occur between rising and falling, or between falling and rising, and what the reverse rate divisor is, how many to add a number counter. Based on whether the additional clock cycles of are added, it can be reasonably guaranteed that the bits will always be sampled as close to the middle as possible.

Once the host has selected or determined the number of clock cycles, it can "consider" a variety of reverse rate divisors with the client to determine if a particular reverse rate divisor works. The host (and client) can start with a divisor of 1 and check the RC of the reverse status packet received from the client to determine if this reverse rate works properly for transferring data. .. If the CRC is bad, there is probably a sampling error and the host can increase the reverse rate divisor and try again to request the status packet. If the second requested packet has been corrupted, the divisor can be incremented again and the request can be made again. If this packet is successfully decrypted, this reverse rate divisor can be used for all future reverse packets.

This method is effective and useful because the reverse timing must not change from the initial round trip timing estimate. If the forward link is stable, the client must continue to decrypt the forward link packet in the event of a reverse link failure. Needless to say, this method does not guarantee a perfect reverse link, so it is the host's responsibility to set the reverse link divisor for the link. In addition, the divisor depends primarily on the quality of the clock used to create the IO clock. If the clock has a significant amount of jitter, the chances of a sampling error are high. This error probability increases with the amount of clock cycles of the round trip delay.

This implementation seems to work best for type 1 reverse data, but type 2 because the distortion between the data lines is so great that only one data set cannot perform the link at the best speed. Type 4 reverse data can be problematic. However, perhaps the data rate does not need to be slowed down according to the method described above, which also uses types 2 to 4 for operation. This method may also work best if there is duplication in each data line to select the ideal or optimal clock sample location. This method will continue to work if they are at the same sample time for each data set. Two different techniques may be used if they are in different sample periods. The first is to select the desired or even more optimized sample location for each data point, even if it is not the same for each data set. The host can then reconstruct the data stream after sampling all of the bits from the set of data sets. That is, type 2 has 2 bits, type 3 has 4 bits, and type IV has 8 bits. The other option is for the host to increase the reverse rate divisor so that the data bits per data set can be sampled at the same clock edge.

XIII. Effects of link delay and distortion Delay distortion on the forward link between the MDDI_Data pair and MDDI_Stb can limit the maximum possible data rate unless delay distortion compensation is used. The delay differences that cause timing distortion are due to controller logic circuits, line drivers and receivers, and cables and connectors as outlined below.

A. Distortion-limited link timing analysis (MDDI1 type) 1.1 Examples of type link delay and distortion A typical interface circuit similar to the interface circuit shown in FIG. 41 is shown in FIG. 57 to address a type 1 interface link. In FIG. 57, exemplary or typical values for propagation delay and distortion are shown for each of the multiple processes or interface stages of the MDDI1 forward link. The delay distortion between MDDI_Stb and MDDI_Data0 deforms the duty cycle of the output clock, as shown in Figure 58. In some cases, this makes the set time for the RXFF stage very small. The data at the D input of the receiver flip-flop (RXFF) stage using flip-flops 5728, 5732 changes slightly after the clock edge to ensure that it can be sampled. The figure shows two cascaded delay lines 5732a and 5732b used to solve two different problems associated with creating this timing relationship. In the actual implementation, these may be combined into a single delay element.

Data, Stb (strobe) and clock recovery timing on type 1 links for exemplary signal processing through the interface are shown in Figure 58.

Significant total delay distortion usually results from or results from the sum of the following stages of distortion. That is, a transmitter flip-flop (TXFF) with flip-flops 5704, 5706, a transmitter driver (TXDRVR) with drivers 5708, 5710, a cable 5702, a receiver line receiver (RXRCVR) with receivers 5722, 5724, and a receiver. It is an XOR logic circuit (RXXOR). The delay 1 5732a must match or exceed the delay of the XOR gate 5736 in the RXXOR stage as determined by the following relationships:<maths num="10"><img file="JP2010226725A_D0033.tif" /></maths>

It is desirable to meet this requirement so that the D input of receiver flip-flops 5728, 5732 does not change before its clock input. This is effective when the holding time of RXFF is zero.

The purpose or function of Delay 2 is to compensate for the holding time of the RXFF flip-flops according to the following relationships:<maths num="11"><img file="JP2010226725A_D0034.tif" /></maths>

In many systems, this is zero because the retention time is zero, and of course the maximum delay for delay 2 may also be zero.

The worst-case distortion contribution in the receiver XOR stage is data-delay / strobe-early case, where delay 1 is the maximum and the clock output from the XOR gate occurs as early as possible according to the following relationship: It is in.<maths num="12"><img file="JP2010226725A_D0035.tif" /></maths>

In this situation, the data can vary between n and n + 1 for a 2-bit period, which is very close to the time that bit n + 1 is recorded in the receiver flip-flop.

The maximum data rate (minimum bit duration) of an MDDI type 1 link is a function of the maximum distortion encountered through all drivers, cables, and receivers in the MDDI link with the RXFF stage plus total data setup. The total delay distortion of the link to the output of the RXRCVR stage can be expressed as:<maths num="13"><img file="JP2010226725A_D0036.tif" /></maths>

Here, "cable" represents various conductors or interconnects or wires and the corresponding delay, and the minimum bit period is<maths num="14"><img file="JP2010226725A_D0037.tif" /></maths>

Specified by.

In the example shown in Figure 57, in external mode, t_{SKEW-max (LINK)}= 100psec, and the minimum bit period can be expressed as follows.

t_BIT-minIt is stated as = 1000 + 2.125 + 625 + 125 + 200 + 0 + 100 = 2300psec, that is, about 434Mbps. In the example shown in Figure 57, in internal mode, t_{SKEW-max (LINK)}= 500psec, and the minimum bit period can be expressed as follows.

t_BIT-minIt is stated as = 500 + 2.125 + 625 + 125 + 200 + 0 + 100 = 1800psec, that is, about 555Mbps.

If the host uses delayed distortion calibration packets<maths num="15"><img file="JP2010226725A_D0038.tif" /></maths>

Clock jitter requirements and maximum delay symmetry for hosts using distortion calibration consisting of and maximum delay distortion requirements for hosts using distortion calibration.<maths num="16"><img file="JP2010226725A_D0039.tif" /></maths>

There are additional demands for delay symmetry, delay distortion, and clock jitter in host devices as defined by.

B.MDDI type 2, type 3 and type 4 link timing analysis A typical interface circuit similar to the interface circuit shown in FIGS. 41 and 57 is shown in FIG. 59 to address Type 2, III, and IV interface links. Additional elements are used in the TXFF (5904), TXDRVR (5908), RXRCVCR (5922) and RXFF (5932, 5928, 5930) stages to handle additional signal processing. In FIG. 59, exemplary or typical values for propagation delay and distortion are shown at each of the multiple processing or interface stages of the MDDI2 forward link. In addition to the distortion in the delay between MDDI_Stb and MDDI_Data0 that affects the duty cycle of the output clock, there is also distortion between these two signals and the other MDDI data signals. The data at the D input of the receiver flip-flop B (RXFFB) stage consisting of flip-flops 5928 and 5930 is modified after the clock edge to ensure that it can be sampled. If MDDI_Data1 arrives earlier than MDDI_Stb or MDDI_Data0, MDDI_Data1 must be delayed, at least by the amount of delayed distortion. To achieve this, the data is delayed using a delay 3 delay line. If MDDI_Data1 arrives after MDDI_Stb and MDDI_Data0 and is delayed by 3 minutes, the point where MDDI_Data1 changes moves closer to the next clock edge. This process determines the upper limit of the data rate for MDDI type 2, type 3 or type 4 links. Some exemplary different possibilities for the timing or distortion relationships of the two data signals and MDDI_Stb with respect to each other are shown in FIGS. 60A, 60B and 60C.

Delay 3 is set according to the following to ensure that RXFFB samples data when MDDI_DataX arrives as early as possible.<maths num="17"><img file="JP2010226725A_D0040.tif" /></maths>

The maximum link speed is determined by the minimum allowed bit period. This is most affected if MDDI_DataX arrives as late as possible. In that case, the minimum permissible cycle time is indicated by:<maths num="18"><img file="JP2010226725A_D0041.tif" /></maths>

Therefore, the upper limit of the link speed is<maths num="19"><img file="JP2010226725A_D0042.tif" /></maths>

And if you think about the following<maths num="20"><img file="JP2010226725A_D0043.tif" /></maths>

In the example shown above, the lower limit of the minimum bit period is indicated by the following relationship.<maths num="21"><img file="JP2010226725A_D0044.tif" /></maths>

That is, it is about 174 Mbps.

This is much slower than the maximum data rate that can be used with type 1 links. MDDI's automatic delay distortion compensation feature significantly reduces the effect of delay distortion on the maximum link rate factor for which you are trying to set valid data. The distortion calibrated between MDDI_Data0 and MDDI_Stb is<maths num="22"><img file="JP2010226725A_D0045.tif" /></maths>

And the minimum bit period is<maths num="23"><img file="JP2010226725A_D0046.tif" /></maths>

Is.

Where TB or t_{b b}Represents the signal jitter from the bit boundary to the minimum output level. Asymmetry simply refers to the asymmetric nature of the internal delay of the delta receiver or through the delta receiver. TP4 is associated with electrical characteristics and is efficiently defined to test the connection or interface (pins of the MDDI controller device in the client) for the difference line driver, and the purpose as a receiver for the client. ing. It represents a convenient or predetermined point. From here the signal delay is measured and characterized for the links across the rest of the system. In one embodiment, the parameter t in TP4_BThe maximum value of is for the external mode<maths num="24"><img file="JP2010226725A_D0047.tif" /></maths>

And about the internal mode of the client transmitter<maths num="25"><img file="JP2010226725A_D0048.tif" /></maths>

And about the external mode of the client receiver<maths num="26"><img file="JP2010226725A_D0049.tif" /></maths>

Is.

Label TP4 is a simple and useful interface and link for numbering various test points (TPs). In one embodiment, this test point is defined to be the same for both internal and external modes. There is a corresponding "TP0" for or associated with the connection or interface pins of the MDDI controller device in the host, including the delta line driver and receiver. In this embodiment, the parameter T at TP0_BThe maximum value of is in internal mode<maths num="27"><img file="JP2010226725A_D0050.tif" /></maths>

For host receiver external mode<maths num="28"><img file="JP2010226725A_D0051.tif" /></maths>

For host transmitters<maths num="29"><img file="JP2010226725A_D0052.tif" /></maths>

It is defined by the relationship of.

In the example shown in Figure 59,<maths num="30"><img file="JP2010226725A_D0053.tif" /></maths>

And the minimum bit period is<maths num="31"><img file="JP2010226725A_D0054.tif" /></maths>

It is about 606 Mbps.

When MDDI_Data1 arrives, the associated programmable delay is adjusted to the optimum setting using the accuracy of one tap to reliably sample the data in RXFFB as soon as possible, with additional taps. Delays are added for safety. The maximum link speed is determined by the minimum allowed bit period. This is most affected if MDDI_Data1 arrives as late as possible. In this case, the minimum permissible cycle time is<maths num="32"><img file="JP2010226725A_D0055.tif" /></maths>

Will be. Where TA or t_ARepresents the signal jitter from the bit boundary to the central intersection.

In the example shown in Figure 59, the lower boundary of the minimum bit period based on sampling MDDI_Data1 is<maths num="33"><img file="JP2010226725A_D0056.tif" /></maths>

Is.

In one embodiment, the typical total delay time for clock jitter, delay asymmetry, and delay distortion in an internal mode host is<maths num="34"><img file="JP2010226725A_D0057.tif" /></maths>

Defined as, in external mode,<maths num="35"><img file="JP2010226725A_D0058.tif" /></maths>

It is defined as.

On the other hand, the set time in the client device in internal mode (t)_B-TP4), Delay asymmetry, and typical total delay time for delay distortion<maths num="36"><img file="JP2010226725A_D0059.tif" /></maths>

And in the case of external mode,<maths num="37"><img file="JP2010226725A_D0060.tif" /></maths>

Is. Here, the term TBD is a flexible place that holds labels for the future as defined by various well-known features and operational requirements dependent values required for external mode connections.

Similar to FIG. 59, with a delay distortion compensating circuit, a typical interface circuit of the MDDI type 2 forward link embodiment is shown in FIG. An additional element, the selectable delay elements 6102,6104, is used after the RXRCVCR stage with the calibration input drivers 6106,6108. The calibration input drivers 6106 and 6108 are coupled to AND gates 6112 and 6114, respectively. The output of AND gate 6112,6114 is connected to XOR gate 6116. The XOR gate 6116 provides an input to the RXFFA stage, as shown. These devices are used to adapt to further signal processing. Drivers 6108,6106 allow configuration for signal paths. The delay elements 6102,6104, on the other hand, allow a selectable amount of delay to be used or input for the signal transfer path for each output of the driver 5724,5924.

In this example, variable delays 6102,6104 are used to precisely adjust the relative arrival times of the data and strobe signals. By arranging the arrival times of these signals, the data at the input of the D flip-flops (5728,5730,5928,5930) in the receiver can be well set in advance. When the client device receives the calibration data sequence field of the forward link distortion calibration packet, a simple state machine examines the simultaneous transitions for all of the differential pair signals to determine the optimal adjustable delay setting. This state machine uses a sequential approximation algorithm to adjust the variable delay to find the point where the data is safely sampled. It then adjusts the delay by advancing the safest setting by one tap, ensuring reliable operation (which is one less tap on the MDDI_Stb path and one more tap on the MDDI_Data path). The calibration data sequence field contains a very large number of simultaneous transitions for all of the diff pairs to facilitate this.

In the example given in Figure 61, the lower boundary of the minimum bit period based on sampling MDDI_Data1 is<maths num="38"><img file="JP2010226725A_D0061.tif" /></maths>

Is.

This is a significant improvement over uncalibrated link timing for MDDI_Data1. However, one possible determinant for the maximum data rate for the delayed strain calibration link is usually limited by the ability to keep the delay between MDDI_Stb and MDDI_Data0 constant, as shown in the example above. There are many possible improvements to the strain compensation architecture described, for example to provide precise adjustments for delay 5 in Figure 61.

When delay distortion compensation is used, there is generally an upper limit on the amount of differential distortion allowed or allowed in the output of the host driver. Without this limitation or constraint, the amount of differential distortion would be in an extremely large range, requiring correction in the client device for host devices operating at very low data rates. Since the main use of distortion compensation is to reduce delay distortion so that the device can operate at high speeds, the upper limit of delay distortion is generally the system or for hosts that use delay distortion compensation. Specified by the device designer. The total amount of distortion compensation used by the client device is the sum of the following three parameters: That is, the maximum difference distortion in the host driver output, which is the maximum delay distortion of the TXFF + TXDRVR stage shown in Fig. 61, and the maximum difference distortion in the interconnection subsystem from TPO to TP4, which is the maximum delay distortion of the CABLE stage in Fig. 61. , The maximum differential distortion in the client between the differential receiver input and the data sampling circuit. The latter parameter is the maximum delay distortion from the input of the RXRCVR stage in FIG. 61 to the input of the RXFFA and RXFFB stages.

XIV. Physical layer interconnection description The physical connections that are effective for realizing the interface according to the present invention are part number 3260-8S2 (01) manufactured by Hirose Electric Company Ltd. on the host side and Hirose Electric Co., Ltd. on the client device side. This can be achieved by using commercially available parts such as part number 3240-8P-C manufactured by (Hirose Electric Company Ltd.). An exemplary interface pin assignment, or "pinout," for such connectors used with Type 1 / Type 2 interfaces is listed in Table XV.<tables num="22"><img file="JP2010226725A_D0062.tif" /></tables>

The shield is connected to HOST_Gnd in the host interface, and the shield drain wire in the cable is connected to the shield of the client connector. However, the shield and drain wires are not connected to the circuit ground inside the client.

The interconnect element or element is small enough to be used with PDAs and radiotelephones, or mobile communication devices and computing devices such as handheld game consoles, without getting in the way compared to the relative device size and without a bad taste. Selected or designed to be. All connectors and cabling must be durable enough to be used in a typical consumer environment, address small size, especially for cabling, and be relatively low cost. The transfer element must deal with data and strobe signals, which are differential NRZ data with transfer rates up to 450 Mbps for type 1 and type 2 and up to 3.6 Gbps for the 8-bit parallel 4-type version.

For internal mode applications, either there are no connectors in the same orientation with respect to the wires used, or such connecting elements tend to be very small. One example is a zero-insertion force "socket" for accepting elements that house either integrated circuits or host or client devices. Another example is a "pin" or "contact" that resides on a printed circuit board with a variety of interconnect leads and extends from a housing that is soldered to the contacts on the leads for interconnecting integrated circuits. If you have.

For example, in the internal mode described above, if you focus on connecting two clients, for cabling, connections, and certain factors when deploying the main client for better data transfer and communication. Attention should be paid. The cable or connection connecting the clients forms a transmission line essentially composed of unterminated stubs as illustrated in the configuration illustrated in FIG. Figure 99 shows two stubs, or stubs.₁And stub₂The host 9902 connected to the lead wire 9904 that branches to 9904 is shown. stub₁And stub₂Supply or transfer signals from the host to clients located at positions B and A, respectively. Also, for purposes of illustration only, not limited to any embodiment or application of the present invention, the client is here as part of an LCD controller or LCD display element or panel, connected to and associated with them. It has been shown or communicated with them. When these two client devices are connected in internal mode, the primary client device that sends and receives for the MDDI_Data pair and is located with the termination register (impedance) should be located or connected to the "termination" of the cable. is there. The "termination" of the cable is identified as "position A" in Figure 99 and is length L._stub1Is the length L_stub2Shorter or equal to. Other clients (or, in some cases, multiple other clients) are located or connected to the "termination" of the branch from the cable. The cable is located between the end and the host. The host is shown as "Position B" in Figure 99. FIG. 99 generally shows how such transmit line stubs are defined by experts in the art for the applications of the embodiments. Those who utilize the devices and techniques of the various embodiments of the invention generally ensure that the signal quality meets any constraint or requirement, taking into account the minimum rise time of the driver output signal and the speed factor of the transmit line. Such a configuration should be implemented by limiting the length of the stubs on the transmit line to ensure proper high speed operation and error-free (or minimal) communication.

XV. Operation A summary of common steps taken in processing data and packets during operation of an interface using embodiments of the present invention is shown in FIGS. 54A and 54B, along with an overview of the interface device that processes the packets of FIG. It is shown. In these figures, the process begins at step 5402, which determines whether the client and host are connected using a communication path, here a cable. This can be done by using periodic polling by the host, using software or hardware that detects the presence of connectors or cables or signals at the input to the host (as seen for USB interfaces). It may occur with other known techniques. If no client is connected to the host, it simply goes into a given length of standby, hibernation mode, or takes action to reactivate the host to the user, depending on the application. It may be deactivated to wait for future use that may require that. For example, when a host resides on a computer-type device, the user may have to click a screen icon or request a program to activate host processing in order to find a client. Again, a simple plug-in with a USB connection could activate host processing, depending on the capabilities and configuration of the host or resident host software.

Once the client is connected to the host and vice versa, or is detected as present, either the client or the host sends the appropriate packet requesting service in steps 5404 and 5406. The client will be able to send either a client service request packet or a status packet in step 5404. As mentioned above, it is noted that the link could have been shut down in the past or was in hibernation mode so that it is not a complete initialization of the subsequent communication link. Once the communication link is synchronized and the host attempts to communicate with the client, the client also provides the client function packet to the host, as in step 5408. The host can now begin determining the type of support, including the transfer rate that the client can handle.

Generally, the host and client also negotiate the type of service mode (speed / speed) used, for example type 1, two, etc. in step 5410. Once the service type is established, the host can start transferring information. In addition, the host may use a round-trip delay measurement packet to optimize the timing of the communication link in parallel with other signal processing as illustrated in step 5411.

As mentioned above, all transfers are forwarded in step 5412, followed by the type of data, here video and audio stream packets, and the filler packets shown to be forwarded in step 5414. Start with the indicated subframe header packet. Audio and video data are previously created or mapped into packets, and filler packets are inserted as needed or as desired to fill in the required number of bits for a media frame. The host can send packets, such as forward voice channel enable packets, to activate the sound device. In addition, the host can transfer commands and information using the other packet types mentioned above, here colormap forwarding, bitmap block forwarding, or other packets in step 5416. In addition, the host and client can use the appropriate packets to exchange data related to the keyboard or pointing device.

During operation, one of several different events leading to a host or client wishing for a different data rate or type of interface mode may occur. For example, a computer or other device that communicates data will encounter load conditions when processing data that causes slowdowns in packet creation or presentation. Client devices that receive data change from dedicated AC power to more restricted battery power and cannot transfer data quickly, process commands easily, or have similar resolution or under more limited power settings. Color gradation will not be available. Instead, the restrictions are eliminated or disappear, allowing the device to transfer data at even higher speeds. This is more desirable and can require a change to a faster transfer rate mode.

If these or other types of known conditions occur or change, either the host or the client may detect them and attempt to renegotiate the interface mode. This is shown in step 5420, where the host sends an interface type handoff request packet to a client that needs a handoff to another mode, and the client sends an interface type acknowledgment packet confirming that a change is required. , The host sends an executable handoff packet to change to the specified mode.

Such elements may be on the host side, but do not require a specific order of processing, but the client and host are for pointing devices, keyboards, or other user-based input devices that are primarily associated with the client. , Or packets related to the data received from them can also be exchanged. These packets are typically processed using general purpose processor type elements rather than state machines (5502). In addition, some of the commands mentioned above will also be processed by general purpose processors (5504, 5508).

After the data and commands have been exchanged between the host and the client, at some point a decision is made as to whether additional data should be transferred or whether the host or client should stop servicing the transfer. Will be done. This is shown in step 5422. If the link either goes into hibernation or is shut down altogether, the host sends a link shutdown packet to the client and both sides end the transfer of data.

The packet transferred in the operation process is transferred using the driver and receiver described above in relation to the host controller and the client controller. These line drivers and other logic elements are connected to the state machine and general purpose processor described above, as shown in the outline of FIG. In Figure 55, the state machines 5502 and general purpose processors 5504 and 5508 further include, but are not limited to, a dedicated USB interface, memory element, or data source and video control chip for the view display device, the link controller with which they interact. It may be connected to other elements (not shown) such as other components resident outside the.

Processors and state machines provide control over driver enablement and disabling as described above with respect to guard times to ensure efficient establishment or termination of communication links and packet forwarding.

XVI. Display framebuffer Video data buffering requirements are different for video video images compared to computer graphics. Pixel data is most often stored in a local framebuffer within the client so that the image on the client can be refreshed locally.

When full-motion video is displayed (almost every pixel in the display changes each media frame), the image on the display is refreshed from the second framebuffer, but usually in one framebuffer. It is preferable to store incoming pixel data in it. Three or more display buffers may be used to eliminate visible artifacts as described below. Once the entire image is accepted in one framebuffer, the buffer role is interchangeable, the newly received image is then used to refresh the display, and the other buffers are filled with the next frame of the image. To. This concept is shown in Figure 88A where pixel data is written to the offline image buffer by setting the display update bit to "01".

In other applications, the host does not need to repaint the entire image, only a small part of the image needs to be updated. In this situation, it is desirable to write new pixels directly to the buffer used to refresh the display, as detailed in Figure 88B.

In an application with a fixed image with a small video window, write the fixed image in both buffers (display update bit equal to "11") as shown in Figure 88C, and later set the display update bit to "01". It is easiest to write the video pixels to the offline buffer by setting.

The following rules describe the valid operation of the buffer pointer while simultaneously writing new information to the client and refreshing the display. There are three buffer pointers. That is, current_fill refers to the buffer currently filled from the data on the MDDI link. just_filled refers to the most recently filled buffer. being_displayed refers to the buffer currently used to refresh the display. All three buffer pointers may contain values from 0 to N-1, where N is the number of display buffers and N 2. The operation on the buffer pointer has N as a coefficient. For example, when N = 3 and current_fill = 2, incrementing current_fill sets current_fill to 0. For the simple case where N = 2, just_filled is always the complement of current_fill. Performs the following operations in the specified order at any MDDI media frame boundary (subframe header packets with a subframe count field equal to zero): Set just_filled equal to current_fill and current_fill to current_fill + 1.

MDDI video stream packets are buffered according to the following structure or methodology. That is, when the display update bit is equal to "01", the pixel data is written to the buffer specified by current_fill. When the display update bit is equal to "00", the pixel data is written to the buffer specified by just_filled. And when the display update bit is equal to "11", the pixel data is written to all buffers. The display is refreshed from the buffer specified by the being_displayed pointer. The behavior of the display refresh process setting being_refreshed equal to just_filled after the display refreshes the last pixel of one frame refresh epoch and before it starts refreshing the first pixel in the next frame refresh epoch. To execute.

A packet with a pixel data attribute field contains a set of display update bits that specify the framebuffer in which the pixel data is written. The client function packet has three additional bits that indicate which combination of display update bits is supported by the client. In many cases, images created by a computer need to be incrementally updated based on user input or derived from information received from a computer network. The display update bit combinations "00" and "11" support this mode of operation by causing pixel data to be written to the displayed framebuffer or both.

When dealing with a video image, Figure 89 shows how the video image uses a set of framebuffers when the video data is sent over the MDDI link with the display update bit equal to "01". Is displayed. When a media frame boundary is detected on the MDDI link, the display refresh process begins refreshing from the next framebuffer when the refresh process for the currently refreshed frame is complete.

An important assumption related to Figure 89 is that the images are read in the same order that the client uses to read the pixels from the framebuffer to refresh the display (usually top left, line by line, bottom right corner of the screen). The point is that it is received from the host as a continuous stream of transmitted pixels. This is an important detail when the display refresh operation and the image transfer operation refer to the same frame buffer.

It is necessary that the display refresh frame rate exceeds the image transfer frame rate in order to avoid displaying a partial image. FIG. 90 shows how image fragmentation can occur at a slower display refresh rate, that is, how display refresh is slower than image transfer.

For images that include a combination of computer graphics images and video video images, the video pixel data may contain a small portion of the media frame. This will be important in situations where the display refresh operation and the image transfer refer to the same framebuffer. These situations may match the pixels read from the buffer to refresh the display to the pixels written to the buffer two frames before, or they are immediately written to the same framebuffer. In FIG. 91, it is shown by the shading of diagonal parallel lines.

Using three framebuffers on the client solves the problem of small windows with contention for access to the framebuffers, as shown in Figure 92.

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

Using a single buffer for video-video images is somewhat problematic, as shown in Figure 94. In the case of display refresh, which is faster than image transfer to the buffer, the upper part of the frame in which the refreshed image is written is shown, and the lower part of the image is the frame transferred in the past. For faster display refreshes (preferable mode of operation) than image transfer, examples of frames showing similar split images will be more frequent.

XVII. Multiple client support The current protocol version does not appear to directly support multiple client devices. However, most packets contain a reserved client ID field that can be used to address a particular client device in a system with multiple clients. Currently, for many applications, this client ID or these client IDs is set to zero. The subframe header packet also contains a field to indicate whether the host supports multiple client systems. Therefore, multiple client devices are connected and addressed in future applications of MDD interfaces or protocols to help system designers plan for future compatibility with multiple client hosts or clients. There are styles that can be done.

In systems with multiple clients, clients using the client's daisy chain as shown in Figure 95, or using a hub, or using a combination of these techniques as shown in Figure 96. Is useful to be connected to the host. It may also be useful for the host to display an error message and manage the connected clients, for example, an error message when one or more clients requesting address 0 are connected. .. Note that this example does not apply to multi-client systems where the display is expected or configured to act as the sole client.

VXIII. Addendum In addition to the formats, structures, and contents described above for the various packets used to implement the architectures and protocols for embodiments of the present invention, more detailed field content or behavior is here some of the packet types. Presented for. These are presented herein to further clarify the use or operation of each of them so that those skilled in the art can more easily understand and utilize the invention for various applications. There is. Only a few of the fields that have not been described are further described here. In addition, these fields are presented with exemplary definitions and values related to the embodiments presented above.

However, such values should not be construed as a limitation of the invention and represent one or more embodiments that are effective in implementing interfaces and protocols, all embodiments being practiced together or simultaneously. You don't have to. Other values can be used in other embodiments to achieve the desired presentation of data or data rate transfer results, as will be appreciated by those skilled in the art.

A. For video stream packets In one embodiment, the pixel data attribute field, which is here 2 bytes, has a set of bit values interpreted as: Bits 1 and 0 select how the display pixel data is sent. For a bit value of "11", the pixel data is displayed for both eyes or for both eyes, for a bit value of "10", the pixel data is sent only to the left eye, and for a bit value of "01", the pixel data is For a bit value of "00" sent only to the right eye, the data is sent to the alternate display as specified by bits 8-11 as described below. If the main display within or operated by or used by the client does not support stereo images or certain formats of images, then the command should have the impact desired by the display. It cannot be embedded effectively. In this state or setting, the client should route the pixel data to the main display regardless of the bit value, i.e. any bit combination of '01', '10', '11'. This is because the resulting command or control is not executed by this display. Although not required in this embodiment, it is recommended that the value '11' be used to address the main display in these clients that do not support stereo display functionality.

Bit 2 means that the value "0" means that the pixel data is in standard gradual format, and the row number (pixel Y coordinate) is incremented by 1 as you move from one row to the next. , Indicates whether the pixel data is presented in interlaced format. When a bit has a value of "1", the pixel data is in interlaced format and the line number is incremented by 2 as it goes from one line to the next. Bit 3 indicates that the pixel data takes an alternative pixel format. This is similar to the standard interlace mode enabled on bit 2, but the interlace is vertical instead of horizontal. When bit 3 is "0", the pixel data is in standard gradual format and the column number (pixel X coordinate) is incremented by 1 when each successive pixel is received. When bit 3 is "1", the pixel data takes an alternative pixel format and the column number is incremented by 2 when the pixel to write is received.

Data is transferred to or from the internal display for wireless phones or similar devices or portable computers or other devices such as those described above, or data is embedded in the device or directly. Bit 4 indicates whether the pixel data is related to the display or related to the camera, as it is being transferred to or from the camera coupled to. When bit 4 is "0", pixel data is being transferred to or from the display framebuffer. When bit 4 is "1", pixel data has been transferred to or from some type of camera or video device, such devices are well known in the art.

Bit 5 is used to indicate when the pixel data contains the next contiguous row of pixels in the display. This is considered the case where bit 5 is set equal to "1 ". When bit 5 is set to "1", the X left edge, Y top edge, X right edge, Y bottom edge, X start, and Y start parameters are undefined and ignored by the client. When bit 15 is set to logical 1 level, this indicates that the pixel data in this packet is the last row of pixels in the image. Bit 8 of the client feature feature indicator field in the client feature packet indicates whether this feature is supported.

Bits 7 and 6 are display update bits that specify the framebuffer in which the pixel data should be written. More specific effects will be explained elsewhere. If the bit value is "01", the pixel data is written to the offline image buffer. For a bit value of "00", the pixel data is written to the image buffer used to refresh the display. For a bit value of "11", pixel data is written to all image buffers. Bit values or combinations of "10" are treated as invalid values or specifications, pixel data is ignored and not written to any of the image buffers. This value may be used for future applications of the interface.

Bits 8 to 11 are used to specify an alternative display, or display location to which the pixel data is routed. Bits 0 and 1 are set equal to "00" for the display client to interpret bits 8 to 11 as the number of alternate displays. If bits 0 and 1 are not equal to "00", bits 8-11 are set to the logical zero level.

Bits 13 and 12 are related to the transparency color and the transparency mask and are therefore used to specify whether the destination pixel is written to the destination location. If bit [13:12] has or is equal to the value of 00 (both logical zero levels), the transparent color is not used. The resulting destination pixel is written to the destination pixel position without considering the value of the transparent color or transparent mask. The transparent color is defined by the transparent color enable packet described herein. Bit [13:12], which is the value of 01 (logical zero level, logical 1 level), is currently reserved for future use and is not used. If bit [13:12] has a value of 10 (1 logical level, 0 logical level), the resulting destination pixel will be a transparent color if the source image pixel logically ANDed with the transparent mask. If not equal to, then the destination pixel position is written and the resulting pixel is not written to the destination pixel position. If bit [13:12] has a value of 11 (both logical 1), the resulting destination pixel is if the source image pixel logically ANDed with the transparent mask is not equal to the transparent color. Is not written to the destination pixel position. In this case, the resulting pixel is written to the destination pixel position.

Bit 14 is reserved for future use and is usually set to the logical zero level. Bit 15 is used with bit 5 as described above. Setting bit 15 to logical 1 indicates that the pixel row in the pixel data field is the last row in the frame of data. The next video stream packet with bit 5 set to logical 1 corresponds to the first row of pixels in the next video frame.

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

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

The parameter CRC field (2 bytes) contains the CRC of all bytes from packet length to pixel count. If this CRC cannot be checked, the entire packet is dropped.

The pixel data field must be displayed and contains raw video information that is formatted as described by the video data format descriptor field. Data is transmitted one "row" at a time, as described elsewhere. When bit 5 of the pixel data attribute field is set to logical level 1, this pixel data field contains exactly one row of pixels. Here, the first pixel is transmitted according to the leftmost pixel, and the last pixel is transmitted according to the rightmost pixel.

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

B. For audio stream packets In one embodiment, the audio channel ID field (1 byte) uses an 8-bit unsigned integer value to identify the particular audio channel for which audio data is transmitted by the client device. Physical audio channels indicate 0, 1, 2, 3, 4, 5, respectively, indicating front left channel, front right channel, rear left channel, rear right channel, front center channel, subwoofer channel, surround left channel and surround right channel, respectively. This field specifies or maps to a physical channel as a value of 6 or 7. An audio channel ID value of 254 indicates that a single stream of digital audio samples will be sent to both the front left and front right channels. This allows stereo headsets to be used for voice communications, productivity-enhancing applications used in PDAs, or simple user interfaces to be used for other applications that generate alert sounds. Simplify communication for the example. Values for the range 8 to 253 and 255 ID fields are currently reserved for use where new designs desire additional designation, as expected by those skilled in the art.

A reserved 1 field (1 byte) is usually reserved for future use, and all bits in this field are set to zero. One function of this field is to align all subsequent 2-byte fields to 16-bit word addresses and 4-byte field 2 to 32-bit word addresses.

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

The bits per sample and the packing field contain 1 byte that specifies the packing format of the audio data. In one embodiment, the commonly used format is that bits 4 to 0 define the number of bits per PCM audio sample. Bit 5 then specifies whether the digital audio data sample is packed. As mentioned above, FIG. 12 shows the differences between the packed sample and the byte-aligned audio sample. A value of "0" in bit 5 indicates that each PCM audio sample in the digital audio data field is byte-aligned with the interface byte boundary, and a value of "1" indicates that each continuous PCM audio sample is past. Indicates that it is packed for the audio sample of. This bit is valid only when the value defined for bits 4 to 0 (the number of bits per PCM audio sample) is not a multiple of 8. Bits 7 to 6 are reserved for applications where the system design desires additional designation and are usually set at a value of zero.

The audio sample rate field (1 byte) specifies the audio PCM sample rate. The formats used are 0 for a speed of 8,000 samples (sps) per second, 1 for 16,000sps, 2 for 24,000sps, 3 for 32,000sps, and 4 for 40,000sps. A value of 5 indicates 48,000sps, a value of 6 indicates 11,025sps, a value of 7 indicates 22,050sps, and a value of 8 indicates 44,100sps, and values 9 to 255 are reserved for future use. Currently set to zero.

The parameter CRC field (2 bytes) contains a 16-bit CRC of all bytes from packet length to voice sample rate. If this CRC cannot be checked properly, the entire packet will be dropped. The digital audio data field contains the raw audio sample to be reproduced and usually takes the form of a linear format as an unsigned integer. The audio data CRC field (2 bytes) contains a 16-bit CRC containing audio data only. If this CRC cannot be checked, the audio data is still available, but the CRC error count is incremented.

C. For user-defined stream packets In one embodiment, the 2-byte stream ID number field is used to identify a stream defined by a particular user. The contents of stream parameter fields and stream data fields are typically defined by the MDDI equipment manufacturer. The 2-byte stream parameter CRC field contains a 16-bit CRC of all bytes of the stream parameter starting from the packet length to the voice coding byte. If this CRC cannot be checked, the entire packet is dropped. Both stream parameter fields and stream parameter CRC fields may be discarded if they are not required by the end use of MDDI, that is, they are considered optional. The 2-byte stream data CRC field contains the CRC for stream data only. If this CRC cannot be checked properly, the use of stream data is optional, depending on the requirements of the application. The use of stream data subject to good CRC usually requires buffering the stream data until the CRC is confirmed to be good. The CRC error count is incremented if the CRC does not check.

D. For colormap packets The 2-byte hClientID field contains information or values reserved for the client ID as used in the past. This field is usually reserved for future use, so the current value is set to zero by setting the bit to "0".

The 2-byte colormap item count field uses a value to specify the total number of 3-byte colormap items contained in the colormap data field or the colormap table entries present in the colormap data in this packet. .. In this embodiment, the number of bytes of color map data is three times the color map item count. The colormap item count is set equal to zero to not send colormap data. If the colormap size is zero, the colormap offset value is usually still transmitted, but it is ignored by the display. The colormap offset field (4 bytes) specifies the offset of the colormap data in this packet from the beginning of the client device's colormap table.

The 2-byte parameter CRC field contains the CRC of all bytes from packet length to voice coding bytes. If this CRC cannot be checked, the entire packet is dropped.

For colormap data fields, the width of each colormap location is specified by the colormap item size field, where in one embodiment the first part specifies the blue scale and the second part specifies the green scale. And the third part specifies the scale of red. The colormap size field specifies the number of 3-byte colormap table items that exist in the colormap data field. If a single colormap cannot fit into one video data format and colormap packet, the entire colormap is specified by sending multiple packets with different colormap data and colormap offset within each packet. You can. The number of blue, green, and red bits in each colormap data item is the same as specified in the colormap RGB width field of the display function packet.

The 2-byte color map data CRC field contains the CRC of the color map data only. If this CRC cannot be checked, the colormap data is still available, but the CRC error count is incremented.

Each colormap data item must be sent in the following order: That is, in blue, green, and red, the least significant bit of each component is transmitted first. The individual red, green, and blue components of each color map item must be packed, and each color map item (least significant bit of the blue component) must be byte-aligned. Figure 97 shows an example of a colormap data item with 6-bit blue, 8-bit green, and 7-bit red. For this example, the colormap item size of the colormap packet is equal to 21, and the colormap RGB width field of the client function packet is equal to 0x0786.

E. For reverse link encapsulated packets The parameter CRC field (2 bytes) contains a 16-bit CRC of all bytes from packet length to diversion length. If this CRC cannot be checked, the entire packet is dropped.

In one embodiment, the reverse link flag field (1 byte) contains a set of flags to request information from the client and specify the reverse link type. If a bit (eg bit 0) is set to logical 1 level, the host requests the information specified by the client, but if the bit is set to logical zero level, the host does not need information from the client. .. Bit 0 (zero) is used to indicate when the host requests a client function packet. It is typically sent by the client to the host in the reverse data packet field. Bit 1 is used to indicate when the host requested a client request and a status packet. It is sent by the client to the host in the reverse data packet field. The remaining bits (bits 1-7 here) are reserved for future use and set to zero. However, more bits can be used as desired to set the flag for the reverse link.

The reverse rate divisor field (1 byte) specifies the number of MDDI_Stb cycles that occur in connection with 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 clock and is the interface type for the reverse link. In the present embodiment, in the case of the 1-type interface, the reverse data rate is equal to the reverse link data clock, and in the case of the 2-type, 3-type and 4-type interfaces, the reverse data rate is twice the reverse link data clock. , Equal to 4x and 8x.

All zero fields contain a group of bytes that are set equal to zero in the value by setting bits at the logical zero level, here 8 and all MDDI_Data signals are sent by the client during one turn field. Used to ensure that the logical zero level is long enough to initiate clock recovery using only MDDI = Stb before disabling the host line driver. In one embodiment, the length of all zeros and one field is greater than or equal to the number of forward link byte transmissions in the cable round trip delay.

The turn 1 long field (1 byte) specifies the total number of bytes allocated for turn 1 and establishes the first turn period. The diversion 1 length parameter applies the number of bytes specified by the diversion 1 length parameter assigned to enable the MDDI_Data line driver in the client before the line driver in the host is disabled. To do. The client enables its MDDI_Data line driver during bit 0 of diversion 1 and the host disables its output so that it is completely disabled before the last bit of diversion 1. The MDDI_Stb signal behaves as if MDDI_Data0 is at the logical zero level for the entire turnover period. A more complete description of the turning 1 setting is given above.

The reverse data packet field contains a series of data packets that are forwarded from the client to the host. The client may send a filler packet or drive the MDDI_Data line to a logical zero state or level when there is no data to send to the host. In this embodiment, when the MDDI_Data line is driven to zero, the host interprets it as a zero-length (not valid length) packet, and the host adds from the client for the duration of the current reverse link-encapsulated packet. Do not accept packets.

The turn 2 long field (1 byte) specifies the total number of bytes allocated to turn 2 to establish a second turn period. The recommended turnaround 2 length is the time required for the host to enable the MDDI_Data driver plus the number of bytes required for the round trip delay. The length of diversion 2 can be a value calculated to allow sufficient time to process the reverse link packet in the host, or even greater than the minimum required.

The diversion 2 field consists of the number of bytes as specified by the diversion length parameter. The host waits at least a round-trip delay before enabling the MDDI_Data line driver during turn 2. The host generally enables the MDDI_Data line driver to be fully enabled before the last bit of turnaround 2. The client generally disables its output so that it is completely disabled before the last bit of diversion 2. The purpose of the redirect 2 field is to ensure that the remaining amount of data from the reverse data packet field is transmitted or forwarded by the client. During changes in different systems implementing the amount of allocated safety margin and the interface, both the host and the client, as described for in-host or line receivers in the host, are part of the turnaround two-field period During that time, it would be possible not to drive the MDDI_Data signal to the logical zero level. The MDDI_Stb signal behaves virtually as if MDDI_Data0 is at the logical zero level for the entire two turnover periods. The explanation of the setting of the direction change 2 is described above.

The inverse data packet field contains a series of data packets that are forwarded from the client to the host. As mentioned above, filler packets are sent to fill the remaining space unused by other packet types.

The all-zero 2 field contains a group of bytes (8 in this embodiment) that are set equal to the value zero by setting the bit at the logical zero level, and all MDDI_Data signals are hosted after the diversion 2 field. Used to ensure that the line driver is enabled and then at the logical zero level for a sufficient amount of time to recover the clock using both MDDI_Data0 and MDDIStb.

F. For client function packets As described for one embodiment, the protocol version field specifies the protocol version used by the client. The minimum protocol version field uses 2 bytes to specify the minimum protocol version used or interpreted by the client, but currently the initial version is set equal to 1 and as is known, the new version. Is generated and changes over time. In this case, the zero value is also a valid value. The Precalibration Data Rate feature field (2 bytes) specifies the maximum data rate that a client can receive for each data pair on a forward link before performing a forward link distortion configuration, in megabytes per second (Mbps) format. Specified by. If the client supports forward link distortion calibration packets, the Post-calibration Data Rate feature field indicates the data rate at which the client can perform post-distortion calibration.

In one embodiment, the interface type function field (1 byte) specifies the interface types supported by forward and reverse links. Bits set to '1' indicate that the specified interface type is supported, and bits set to '0' indicate that the specified type is not supported. Hosts and clients should support at least type 1 on the forward and reverse lines. It is not necessary to support adjacent regions of interface types. For example, supporting only types 1 and 3 in an interface would be perfectly valid, but supporting types 3 and 4 would not be valid. Also, the forward and reverse links do not have to operate using the same interface type. However, if the link exits hibernation, both forward and reverse links will be available until another mode is negotiated, selected, or approved for use by both the host and the client. It should start working in type 1 mode.

The supported interfaces, in one embodiment, are bits for forward link to select between type 2 (2 bits), type 3 (4 bits), or type 4 (8 bits) mode, respectively. Currently by selecting 0, bit 1, or bit 2, and selecting bit 3, bit 4 or bit 5 to select either type 2, 3 or 4 mode, respectively, in the reverse link. As shown, bits 6 and 7 are reserved and are set to zero at this point.

In one embodiment, the alternate display count field of the client function packet uses 1 byte. This value ranges from 0 to 16 and values 17 to 255 are reserved for future use and are not currently in use. This will combine more than one display and indicate or report that the alternate display feature packet reports the functionality of each alternate display. The Alternate Display Count field uses 1 byte, with the first alternate display typically specified as number 0, and the maximum used (after starting with a 0 value) being 1 from the total number of alternate displays. A unique alternative display that is a subtraction number The identification display of the alternative display is shown using other alternative displays identified by a numerical value.

The post-calibration data rate function field, in one embodiment, uses 2 bytes to allow the client to perform a forward link distortion calibration and then receive on each data pair on the forward MDDI link. Specify the data rate of. This rate is also specified as a number of megabytes per second. If the client device does not support forward link distortion calibration packets, this field is set equal to zero.

The bitmap width field and the bitmap height field are each 2 bytes here, and the width and height of the bitmap are specified in pixels, respectively. The Display Window Width field uses 2 bytes and specifies the width of the display window, expressed as the number of pixels. The display window height field uses 2 bytes and specifies the height of the display window, expressed as the number of pixels.

The colormap size field uses 4 bytes and specifies the maximum number of table items that exist in the colormap table in the client. If the client cannot use the colormap format, this value is set equal to zero.

The colormap RGB width field uses 2 bytes and specifies the number of bits for each color component consisting of red, green, and blue displayed in the colormap (palette) display mode. Up to 8 bits can be used for each color component (red, green, and blue). Only the smallest digit bit of each color component defined in this field is used, even if 8 bits are sent to the colormap packet for each color component. If the display client cannot use this colormap (palette) format, this value will be zero.

The RGB function field (2 bytes) specifies the number of bits of resolution that can be displayed in RGB format. This value is zero if the display cannot use the RGB format. The RGB function word consists of three separate unsigned values. That is, bits 3 to 0 define the maximum number of blue bits for each pixel. Bits 7 to 4 define the maximum number of green bits for each pixel, and bits 11 to 8 define the maximum number of red bits for each pixel. Currently, bits 14-12 are reserved for future use and are generally set to zero. Bit 15 indicates that RGB pixel data can be accepted in either the packed format or the unpacked format when set to the logical 1st level. If bit 15 is set to the logical zero level, this indicates that the client can accept RGB pixel data in unpacked format only.

The black and white function field (1 byte) is used in one embodiment to specify the number of bits of resolution that can be displayed in the black and white format. If the display cannot use the black and white format, this value is set to zero. Bits 7-4 are reserved for future use and are therefore set as zero. Bits 3 to 0 define the maximum number of grayscale bits that can exist per pixel. These 4 bits allow you to specify a value from 1 to 15 per pixel. If the value is zero, the black and white format is not supported by the display.

The Y Cr Cb feature field (2 bytes) specifies the number of resolution bits that can be displayed in the Y Cr Cb format. If the display cannot use the Y Cr Cb format, this value is set equal to zero. The Y Cr Cb function word consists of three separate unsigned values, 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 From 8 defines the maximum number of bits in the Y sample, and bits 15 to 12 are reserved for future use and set to zero.

The Bayer feature field uses 1 byte to specify the resolution, pixel group, and number of pixels in pixel order that can be transferred in Bayer format. This value is zero if the client cannot use the Bayer format. The Bayer functional field consists of the following values: Bits 5 to 4 define the required pixel group pattern, bits 3 to 0 define the maximum number of bits of brightness present in each pixel, and bits 8 to 6 define the required pixel order. However, bits 14-19 are reserved for future use and are usually set to zero for the time being. Bit 15 indicates that the client can accept Bayer pixel data in either packed or unpacked format when set to logical 1 level. When bit 15 is set to zero, this indicates that the client can only accept Bayer pixel data in unpacked format.

In one embodiment, the client feature feature field uses 4 bytes containing a set of flags that indicate a particular feature on a supported client. Bits set to logical 1 level indicate that the feature is supported, and bits set to logical zero level indicate that the feature is not supported. In this embodiment, the value of bit 0 indicates whether a bitmap block forwarding packet (packet type 71) is supported. Whether the values of bits 1, 2 and 3 support a bitmap area fill packet (packet type 72), a bitmap pattern fill packet (packet type 73), or a communication link data channel packet (packet type 74), respectively. Show me how. The value of bit 4 indicates whether the client has the ability to make one color transparent using transparent color enable packets. Bit 5 and 6 values indicate whether the client can accept video or audio data in pack format, respectively, and bit 7 values indicate whether the client can send a reverse link video stream from the camera. Shown. The value of bit 8 indicates whether the client has the ability to receive a complete row of pixel data and ignore the display addressing specified by bit 5 of the pixel data attribute of the video stream packet, and the client has the pixel data attribute. The frame synchronization or end of the video frame data can also be detected using bit 15 of the field.

The value of bit 9 indicates whether the client has the ability to interpret the request-specific status packet and respond to the valid status response list packet. As mentioned above, the client can indicate that it has the ability to return the additional status in the valid parameter response list field of the valid status response list packet. The value of bit 10 indicates whether the client has the ability to support display power state 01. The display power state is set using bits [3: 2] in the power state field of the display power status packet described above. Display power state 01, if any, is a state in which the selected display is unlit and is consuming the lowest amount of power, during which the contents of the framebuffer are generally retained. Is guaranteed.

The values of bits 11 and 12 indicate when the client is communicating with the pointing device and can send and receive pointing device data packets, or can use the keyboard to send and receive keyboard data packets, respectively. The value of bit 13 indicates whether the client has the ability to set one or more of the audio or video parameters by supporting VCP feature packets. That is, a VCP feature request packet, a VCP feature response packet, a VCP setting feature packet, a valid parameter request packet, and a valid parameter response packet. The value of bit 14 indicates whether the client has the ability to write pixel data to the offline display framebuffer. This is shown in Figure 88A. When this bit is set to logical 1 level, the display update bits (bits 7 and 6 of the pixel data attribute of the video stream packet) may be set to the value "01".

The value of bit 15 indicates that the client has the ability to write pixel data only to the display framebuffer currently used to refresh the display image. This is shown in Figure 88B. If this bit is set to 1, the display update bits (6th and 7th bits of the pixel data attribute of the video stream packet) may be set to the value "00". The value of bit 16 indicates that the client has the ability to write pixel data from a single video stream packet to all display framebuffers. This is shown in Figure 88C. If this bit is set equal to logical 1 level, the display update bit (6th and 7th bits of the pixel data attribute of the video stream packet) may be set to the value "11".

In one embodiment, the value of bit 17 indicates that the client has the ability to respond to request-specific status packets, and the value of bit 18 indicates that the client has the ability to respond to round-trip delay measurement packets. The value of bit 19 indicates that the client has the ability for forward link distortion calibration packets. In one embodiment, the value of bit 20 indicates that the client has the ability to respond to display power status packets.

In one embodiment, block forwarding packets (packet type 71), bitmap area fill packets (packet type 72), and bitmap pattern fill packets (packet type 73) are populated by bits 0,1,2 or raster action fields. If supported by the identified client, the value of bit 21 is that this client has a block forwarding packet (packet type 71), a bitmap area fill packet (packet type 72), and a bitmap pattern fill packet (packet type). The time when the raster operation field of 73) can be used is shown. In one embodiment, if bit 21 has a logical zero level or a logical zero value and packets are supported, then the client is not capable of using raster action fields and the client is identified by these packets. Has only the ability to copy or write to pixel positions.

The value of bit 22 indicates whether the client has the ability to respond to register access packets. Bits 9-10, 20 and 23-31 are currently reserved for future use or alternative designations in effect for system designers and are usually set equal to zero.

The Display Video Frame Function field (1 byte) specifies the maximum video frame update function of the display in frames per second. The host may choose to update the image slower than the value specified in this field.

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

The voice channel function field, in this embodiment, uses 2 bytes and includes a group of flags indicating which voice channel is supported by the client or the device connected to the 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. Bit positions are assigned to various channels. For example, in one embodiment, bit positions 0, 1, 2, 3, 4, 5, 6, and 7 are left front channel, right front channel, left rear channel, right rear channel, front center channel, subwoofer channel, surround. It shows the left channel and the surround right channel. Bits 8-14 are currently reserved for future use and are usually set to zero. In one embodiment, bit 15 is used to indicate if the client supports forward voice channel enable packets. If supported, bit 15 is set to logical 1 level. However, if the client is unable to disable the voice channel as a result of a forward voice channel enable packet, or if the client does not support voice functionality, this bit is set to a logical zero level or value. To.

The 2-byte voice sample rate feature field for forward links contains a set of flags to indicate the voice sample rate feature of the client device. Bit positions are assigned according to different velocities, for example bits 0, 1, 2, 3, 4, 5, 6, 7 and 8 are 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, respectively. They are currently set to "0" because they are 22,050 and 44,100 samples per second (SPS), and bits 9 to 15 are reserved for future or alternative rate use. Setting the value of one of these bits to "1" indicates that a particular sample rate is supported, and setting the bit to "0" indicates that that sample rate is not supported. Shown.

The 2-byte audio sample resolution field specifies the number of bits per audio sample sent to the client in the audio stream packet for forward links.

The 2-byte microphone audio sample resolution field specifies the number of bits per audio sample sent by the microphone to the host in an audio stream packet for a reverse link.

The 2-byte microphone sample rate feature field contains a set of flags that indicate the voice sample rate feature of the microphone in the client device for reverse links. For MDDI, client device microphones are configured to support at least 8,000 sample rates per second. The bit positions in this field are, for example, 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, and 44,100 bit positions used to represent samples per second (SPS), respectively. Assigned to various speeds of 4, 5, 6, 7 and 8, bits 9 to 15 are currently set to "0" as they are reserved for future or alternative rate use as desired. Has been done. Setting the bit value of one of these bits to "1" indicates that a particular sample rate is supported, and setting a bit to "0" indicates that that sample rate is not supported. ing. If no microphone is connected, each of the microphone sample rate function bits is set equal to zero.

The keyboard data format field (1 byte here) identifies whether the keyboard is connected to the client system and the type of keyboard connected. In one embodiment, the value set by bits 6 to 0 is used to define the type of keyboard connected. If this value is zero (0), the keyboard type is considered unknown. For a value of 1, the keyboard data format is considered to be a standard PS-2 style. Values in the range 2 to 125 are not currently used and are specific to system designers, interface builders, or product developers for use with MDD interfaces and corresponding clients or hosts. Reserved to define a keyboard or input device. The value 126 is used to indicate that the keyboard data format is user-defined. On the other hand, the value 127 is used to indicate that the keyboard cannot connect to the client. In addition, bit 7 is used to indicate whether the keyboard can communicate with the client. The intentional use of this bit is to indicate when the keyboard can communicate with the client using a wireless link. Bit 7 is set to zero level if bits 6 to 0 indicate that the keyboard cannot be connected to the client. Therefore, in one embodiment, if the value of bit 7 is 0, the keyboard and the client cannot communicate, and if the value of bit 7 is 1, the keyboard and the client can communicate with each other. ..

The pointing device data format field (1 byte here) identifies whether the pointing device is connected to the client system and the type of pointing device to which it is connected. In one embodiment, the value set by bits 6 to 0 is used to define the type of pointing device connected. If the value is zero (0), then this pointing device is considered unknown. If the value is 1, this pointing device data format is considered to be a standard PS-2 style. Values in the range 2 to 125 are not currently used and are specific pointing by system designers, interface builders, or product developers for use with MDDI and corresponding clients or hosts. Reserved to define a device or input device. The value 126 is used to indicate that the pointing device data format is user-defined. On the other hand, the value 127 is used to indicate that the pointing device cannot connect to the client. In addition, bit 7 is used to indicate whether the pointing device can communicate with the client. The intentional use of this bit is to indicate when the keyboard can communicate with the client using a wireless link. Bit 7 is set to zero level if bits 6 to 0 indicate that the pointing device cannot be connected to the client. Therefore, in one embodiment, if the value of bit 7 is 0, the pointing device and the client cannot communicate, and if the value of bit 7 is 1, the pointing device and the client can communicate with each other. Admit.

The content protection type field (2 bytes) contains a set of flags that indicate the types of digital content protection supported by the display. Currently, bit position 0 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 desired. They are currently set to zero, as they are reserved for use in other protection schemes so that they can be used.

The Mfr name field (2 bytes here) contains the manufacturer's EISA 3 character ID and is packed into 3 5 bit characters in the same way as the VESA EDID specification. The character'A'is represented as 00001 binary and the character'Z' is represented as 11010 binary. And all the letters between'A'and'Z' are represented as sequential binary values corresponding to the alphabetical sequence between'A'and'Z'. The most significant bit of the Mfr name field is not used until it is used in future implementations and is generally set to logical zero for now. Example: The manufacturer represented by the string "XYZ" has an Mfr name value of 0x663a. If this field is not supported by the client, it is generally set to zero. The product code field uses 2 bytes and contains the product code assigned by the display manufacturer. If this field is not supported by the client, it is generally set to zero.

The Reserved 1 field, Reserved 2 field, and Reserved 3 field (here, 2 bytes each) are reserved for future use in the relevant information. All bits in this field are generally set to the logical zero level. The purpose of such fields is to have all subsequent 2-byte fields aligned with 16-bit word addresses and 4-byte fields aligned with 32-bit word addresses.

The filed serial number uses 4 bytes in this embodiment to identify the display serial number in numeric format. If this field is not supported by the client, it is generally set to zero. The manufacturing field week uses 1 byte to define the manufacturing week of the display. This value typically ranges from 1 to 53, if supported by the client. If this field is not supported by the client, it will be set to zero. The year of the manufacturing field is one byte that defines the year of manufacture of the display. This value is an offset from 1990. This field can represent the range from 1991 to 2245. Example: 2003 corresponds to a year of manufacture with a value of 13. Set to zero if this field is not supported by the client.

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

G. Client requests and status packets The reverse link request field (3 bytes) specifies the number of bytes that the client needs for the reverse link in the next subframe to send information to the host.

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 actual number of CRC errors exceeds 255, this value usually saturates at 255.

The feature change field uses 1 byte to indicate a change in client functionality. This will happen if the user connects a microphone, keyboard, or display, or peripherals for some other reason. When the bit "7: 0" is equal to 0, the functionality has not changed since the last client feature packet was sent. However, when bit [7: 0] equals 1 to 255, the functionality has changed. Client function packets are examined to determine new display characteristics.

The client busy flag field uses 2 bytes to indicate that the client is performing a particular function and is not ready to accept another packet for that function. Bits set to logical 1 level or logical 1 value indicate that a particular function is currently being performed by the client and that the associated function within the client is busy. If the relevant function in the client is ready, the bit is set to logical zero. The client should return a busy status (bits set to 1) for all features not supported within the client.

In one embodiment, these bytes are interpreted according to the following relationship: That is, if bit 0 is '1', the bitmap block transfer function is busy. On the other hand, if bit 1 is '1', the bitmap area fill function is busy. If bit 2 is '1', the bitmap pattern fill feature is busy. At the same time, if bit 3 is '1', the graphics subsystem is busy and performs operations that require the use of the framebuffer in the client. Other graphics features that require the use of framebuffers do not start until the bit is set to a logical 1 value.

For now, bits 4 to 15 are reserved for future use and are generally set to logical 1 level or state to indicate busy status when these bits are allocated in the future.

H. For bit block transfer packets The window upper left coordinate X value field and the Y value field use 2 bytes, respectively, to specify the X and Y values of the coordinates of the upper left corner of the moving window. The window width and window height fields use 2 bytes each to specify the width and height of the window to move. The window X and Y move fields use 2 bytes each to specify the number of pixels that the window will move horizontally and vertically, respectively. Positive values of Y move the window down and negative values move it up, but usually these coordinates move the window to the right with a positive value of X and to the left with a negative value. It is configured to do.

I. Bitmap area fill packet In one embodiment, a 2-byte pixel data attribute field has a value that identifies where the pixel data is updated. Here, bit 1 and bit 0 select the display whether the pixel data is updated. If the main display on the client does not support stereo images, the client can influence the pixel data in the main display with one of the bit combinations 01, 10, or 11. A value of 11 is recommended to be used to address the primary display on clients that do not support the stereo display feature. If bit [1: 0] has the value 11 (logical 1, logical 1), the pixel data is updated in the framebuffers of both the left and right eyes, and bit [1: 0] has the value 10 (logical 1, logical 1). If it has logic 0), the pixel data is updated in the framebuffer for the left eye only. If bit [1: 0] has the value 01 (logical 0, logical 1), the pixel data is updated in the framebuffer for the right eye only. If bit [1: 0] has the value 00 (both logical 0), the pixel data is updated in the framebuffer of the alternate display specified by bits 8-11.

In one embodiment, bit 4 of the pixel data attribute field identifies whether the source of the image of operation is the buffer of the left eye or the buffer of the right eye. Bit 4 is true if bit [1: 0] is not equal to 00. This is generally done to mean that source data from the main image buffer is not supported when the destination of the image is one of the alternate displays. Bit 4 is used to distinguish or identify between the left eye framebuffer and the right eye framebuffer as a data source. Bit 4 uses also allow the client to rasterize on the specified display as indicated by bit 21 of the client feature feature indicator field of the client feature packet, or bit 21 of the display feature feature indicator field of the alternate display feature packet. Limited to support. When applied, if bit 4 is equal to 0 (logical 0 level), then the left eye framebuffer is the data source, and if bit 4 is equal to 1 (logical 1 level), then the right eye framebuffer is the data source. Is.

Bit 5 of the pixel data attribute indicates whether the input for raster operation is the buffer used to refresh the display or the offline image buffer as the destination image for raster operation. Identify. Bit 5 also applies to alternative displays if they utilize offline image buffers. However, it does not support source data from the main image buffer if the image destination is an alternate display. Alternatively, the reverse is also possible. When applied, the image buffer used to refresh the display is the data source if bit 5 is equal to the value 0 or the logical zero level. If bit 5 is equal to the value 1 or logical 1 level, then the offline image buffer is the data source.

Bits 7 and 6 of the pixel data attribute field act as display update bits that specify the framebuffer in which the pixel data is updated or written. The effect of the frame update bit has already been detailed. If bit [7: 6] is '01' (logical zero, logical 1), pixel data is written to the offline image buffer. If bit [7: 6] is '00' (both logical zeros), pixel data is written to the image buffer used to refresh the display. If bit [7: 6] is '11' (both logical 1), pixel data is written to all image buffers. If bit [7: 6] is '10', it is treated as an invalid value. These bits are reserved for future use. In this situation, the entire command is ignored and the framebuffer is not updated.

Bits 11-8 of the pixel data attribute field specify the alternate client position or alternate display position where the pixel data is updated. Bits 0 and 1 are set equal to the value 00 (both logical zeros) so that the client interprets bits 11-8 as the number of alternate displays. If bit 1 and bit 0 are not equal to 00, then bits 8 to 11 are generally set equal to the logical zero value or level. Bits 2, 3, 12 to 15 are reserved for future use and are generally set to logical zero levels or values.

In one embodiment, the 2-byte raster operation field specifies how to combine each pixel at the source and destination positions to generate a new pixel value to be written to the destination image position. Raster behavior defines how two different rectangular areas of equal size in the framebuffer are combined. The destination image area is also one of the two images to be composited. The second of the two images is called the source image. If the client does not support the raster action field as specified in the client function packet, the host generally sends this packet with bits 3 to 0 equal to 3, and the client ignores bits 3 to 0. ..

In one embodiment, bits 3 to 0 identify the actual raster operation by using one of the values shown in Table XVI below or by setting them equal, and then after that value. The corresponding action shown is selected. That is, each bit [3: 0] listed in the first column has the behavior specified in the second column and defined in the third column for further clarification.<tables num="23"><img file="JP2010226725A_D0063.tif" /></tables>

Bits 9-8 are used to specify whether the destination pixel has been written to the destination location as related to the transparent color. Bit 4 of the client feature feature indicator field of the client feature packet indicates whether the transparent color and transparent mask features are supported by the client. Similarly, bit 4 of the display feature function indicator field of the alternate display feature packet indicates whether the transparent color and transparent mask features are supported by the specified alternate display. If transparent colors and transparent masks are not supported, raster behavior behaves as if bit [9: 8] was set to 00. The behavior specified by bit [9: 8] applies to whether raster behavior is supported by the client device. If the client does not support raster operation, the resulting destination pixel value considered for the operation defined by bit [9: 8] will only be equal to the source pixel value. This behavior is the same as setting bit [3: 0] to 3.

If the value of bit [9: 8] is equal to 00, the transparent color is not used. The resulting destination pixel is written to the destination pixel position without considering the value of the transparent color or transparent mask. The transparent color is defined by the transparent color and the mask setup packet. The value of bit [5: 4] equal to 01 is currently reserved for future use and is generally not used. If the value of bit [5: 4] is equal to 10, the result is that the destination pixel calculated by the raster operation and the transparent mask and the ANDed source pixel are equal to the transparent color. The resulting pixels are not written to the destination pixel position. If they are not equal, they are written to the destination pixel position. If the value of bit [9: 8] is equal to 11, the resulting pixel is written to the destination pixel position if the resulting destination pixel calculated by the raster operation is equal to the transparent color. If they are not equal, the resulting pixels are not written to the destination pixel position.

Bits 15-10 and 7-4 are reserved for future use and are generally set equal to a logical zero value or a logical zero level.

J. Bitmap pattern fill packet In one embodiment, the window upper left coordinate X and Y values fields of the bitmap pattern fill packet use 2 bytes, respectively, to specify the X and Y values of the coordinates of the upper left corner of the window to be filled. The window width and height fields (2 bytes each) specify the width and height of the window to be filled. The pattern width field and the pattern height field (2 bytes each) specify the width and height of the fill pattern, respectively. The horizontal pattern offset field (2 bytes) identifies the horizontal offset of the pixel data pattern from the left edge of the particular window to be filled. The value specified will be less than the value in the pattern width field. The vertical pattern offset field (2 bytes) identifies the vertical offset of the pixel data pattern from the top edge of a particular window when filled. The value specified will be less than the value in the pattern height field.

In one embodiment, a 2-byte pixel data attribute field has a value that identifies where the pixel data is updated. Here, bit 1 and bit 0 select the display whether the pixel data is updated. If the main display on the client does not support stereo images, the client can influence the pixel data in the main display with one of the bit combinations 01, 10, or 11. A value of 11 is recommended to be used to address the primary display on clients that do not support the stereo display feature. If bit [1: 0] has the value 11 (logical 1, logical 1), the pixel data is updated in the framebuffers of both the left and right eyes, and bit [1: 0] has the value 10 (logical 1, logical 1). If it has logic 0), the pixel data is updated in the framebuffer for the left eye only. If bit [1: 0] has the value 01 (logical 0, logical 1), the pixel data is updated in the framebuffer for the right eye only. If bit [1: 0] has the value 00 (both logical 0), the pixel data is updated in the framebuffer of the alternate display specified by bits 8-11.

Bits 3 and 2 shall be reserved for future use and set to zero.

Bit 4 identifies whether it is the left-eye buffer or the right-eye buffer that is input to the raster operation as the destination image for the operation. Bit 4 fits if bit [1: 0] is not equal to 00. This means that it does not support source data from the main image buffer if the destination of the image is one of the alternate displays. Bit 4 is when the client supports raster operation on the specified display as indicated by bit 21 of the client feature feature indicator field of the client feature packet, or bit 21 of the display feature feature indicator field of the alternate display feature packet. Only fits. If bit 4 is equal to 0, then the left eye framebuffer is the data source, and if bit 4 is equal to 1, then the right eye framebuffer is the data source.

Bit 5 specifies whether the buffer used to refresh the display, or the offline buffer, acts as a destination image for raster operation and as an input to raster operation. Bit 5 is also compatible with alternative displays if they utilize offline image buffers. If the image destination is one of the alternate displays, there is no support for the source data from the main image buffer. Alternatively, the reverse is also possible. If bit 5 is equal to the value 0, then the image buffer used to refresh the display is the data source. If bit 5 is equal to the value 1, the offline image buffer is the data source.

Bits 7 and 6 of the pixel data attribute field act as display update bits that specify the framebuffer in which the pixel data is updated or written. The effect of the frame update bit has already been detailed. If bit [7: 6] is '01' (logical zero, logical 1), pixel data is written to the offline image buffer. If bit [7: 6] is '00' (both logical zeros), pixel data is written to the image buffer used to refresh the display. If bit [7: 6] is '11' (both logical 1), pixel data is written to all image buffers. If bit [7: 6] is '10', it is treated as an invalid value. These bits are reserved for future use. In this situation, the entire command is ignored and the framebuffer is not updated.

Bits 11-8 of the pixel data attribute field specify the alternate client position or alternate display position where the pixel data is updated. Bits 0 and 1 are set equal to the value 00 (both logical zeros) so that the client interprets bits 11-8 as the number of alternate displays. If bit 1 and bit 0 are not equal to 00, then bits 8 to 11 are generally set equal to the logical zero value or level. Bits 2, 3, 12 to 15 are reserved for future use and are generally set to logical zero levels or values.

In one embodiment, the 2-byte raster operation field specifies how to combine each pixel at the source and destination positions to generate a new pixel value to be written to the destination image position. Raster behavior defines how two different rectangular areas of equal size in the framebuffer are combined. The destination image area is also one of the two images to be composited. The second of the two images is called the source image. If the client does not support the raster action field as specified in the client function packet, the host generally sends this packet with bits 3 to 0 equal to 3, and the client ignores bits 3 to 0. ..

In one embodiment, bits 3 to 0 identify the actual raster operation by using one of the values shown in Table XVII below or by setting them equal, and then after that value. The corresponding action shown is selected. That is, each bit [3: 0] listed in the first column has the behavior specified in the second column and defined in the third column for further clarification.<tables num="24"><img file="JP2010226725A_D0064.tif" /></tables>

Bits 9-8 are used to specify whether the destination pixel has been written to the destination location as related to the transparent color. Bit 4 of the client feature feature indicator field of the client feature packet indicates whether the transparent color and transparent mask features are supported by the client. Similarly, bit 4 of the display feature function indicator field of the alternate display feature packet indicates whether the transparent color and transparent mask features are supported by the specified alternate display. If transparent colors and transparent masks are not supported, raster behavior behaves as if bit [9: 8] was set to 00. The behavior specified by bit [9: 8] applies to whether raster behavior is supported by the client device. If the client does not support raster operation, the resulting destination pixel value considered for the operation defined by bit [9: 8] will only be equal to the source pixel value. This behavior is the same as setting bit [3: 0] to 3.

If the value of bit [9: 8] is equal to 00, the transparent color is not used. The resulting destination pixel is written to the destination pixel position without considering the value of the transparent color or transparent mask. The transparent color is defined by the transparent color and the mask setup packet. A value of bit [5: 4] equal to 01 is currently reserved for future use and is not commonly used, but is used by experts in the art to set related uses. It is possible to do. If the value of bit [5: 4] is equal to 10, the result is that the destination pixel calculated by the raster operation and the transparent mask and the ANDed source pixel are equal to the transparent color. The resulting pixels are not written to the destination pixel position. If they are not equal, they are written to the destination pixel position. If the value of bit [9: 8] is equal to 11, the resulting pixel is written to the destination pixel position if the resulting destination pixel calculated by the raster operation is equal to the transparent color. If they are not equal, the resulting pixels are not written to the destination pixel position.

Bits 15-10 and 7-4 are reserved for future use and are generally set equal to a logical zero value or a logical zero level.

In one embodiment, the 2-byte parameter CRC field in the bitmap pattern fill packet contains the CRC of all bytes from the packet length to the video format descriptor. If this CRC cannot be checked, the entire packet is dropped. The pattern pixel data field contains raw video information that specifies a fill pattern for the format specified by the video data format descriptor. The data is packed into bytes and the first pixel in each row is byte aligned. The fill pattern data is transmitted line by line at a time. The pattern pixel data CRC field for the bitmap pattern fill packet uses 2 bytes containing the CRC of the pattern pixel data only. If this CRC cannot be checked, the pattern pixel data is still available, but the CRC error content is incremented.

K. Communication link data channel packet The parameter CRC field (2 bytes) contains a 16-bit CRC of all bytes from packet length to packet type. If this CRC cannot be checked, the entire packet is dropped.

The communication link data field contains raw data from the communication channel. This data is simply passed to the computer device on the display.

The communication link data CRC field (2 bytes) contains a 16-bit CRC of communication link data only. If this CRC cannot be checked, the communication link data is still used or valid, but the CRC error count is incremented.

L. Forward voice channel enable packet The voice channel enable mask field (1 byte) contains a group of flags that indicate which voice channels must be enabled on the client. Bits set to 1 enable the corresponding channel and bits set to zero disable the corresponding channel. Bits 0 to 5 specify channels 0 to 5 that address the front left channel, front right channel, rear left channel, rear right channel, front center channel, and subwoofer channel, respectively. Bits 6 and 7 are reserved for future use and are usually set equal to zero for the time being.

M. Reverse Audio Sample Rate Package The audio sample rate field (1 byte) specifies the digital audio sample rate. The values in this field are assigned to various velocities, the values 0, 1, 2, 3, 4, 5, 6, 7, and 8 are 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, and Used to indicate 44,100 samples per second (SPS), values 9-254 are currently set to "0" as they are reserved for use with alternative speeds as desired. .. A value of 255 is used to disable the reverse link audio stream.

The sample format field (1 byte) specifies the format of the digital audio sample. When bits [1: 0] are equal to [0], the digital audio sample is in linear format, and when they are equal to 1, the digital audio sample is in μ-law format. Digital audio samples are in A-law format when they are equal to 2. Bit [7: 2] is reserved for alternative use in specifying the audio format, as desired, and is usually set equal to zero.

N. For Digital Content Protection Overhead Packets The content protection type field (1 byte) specifies the digital content protection method used. A value of 1 indicates a high bandwidth digital content protection system (HDCP), while a value of "0" indicates digital transmission content protection (DTCP). Values between 2 and 255 are not currently specified, but are reserved for use with alternative protection schemes as desired. The content protection overhead message field is a variable length field that contains content protection messages sent between the host and the client.

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

The video data format descriptor field (2 bytes) specifies the format of the pixel area fill value. Figure 11 shows how the video data format descriptor is coded. The format is usually the same as the same field in a video stream packet.

The pixel area fill value field uses 4 bytes allocated for the pixel value to be filled in the window specified above. The format of this pixel is specified in the video data format descriptor field.

P. Round-trip delay measurement packet The 2-byte packet length field specifies the total number of bytes in the packet that does not include the packet length field and is chosen to have a fixed length of 159 in one embodiment. The 2-byte packet type field that identifies this packet type with the value 82 identifies the packet as a round-trip delay measurement packet. The hClientID field is reserved for future use as a client ID, as described above, and is usually set to zero.

In one embodiment, the parameter CRC field (2 bytes) includes a 16-bit CRC of all bytes from packet length to packet type. If this CRC cannot be checked, the entire packet is dropped.

The guard time 1 field (64 bytes in this case) is used to allow the client MDDI_Data line driver to be enabled before the host line driver is disabled. The client enables the MDDI_Data line driver during bit 0 of guard time 1, and the host disables the line driver so that it is fully disabled before the last bit of guard time 1. The host and client both drive a logical zero level during guard time 1 when they are not disabled. Another purpose of this field is that all MDDI_Data signals have sufficient temporal logic zero level to allow the client to initiate clock or clock signal recovery using only MDDI_Stb before disabling the host line driver. To guarantee that it is in.

The measurement period field is a 64-byte window used to allow the client to respond to two bytes, 0xff, and 30 bytes, 0x00, at half the data rate used for the forward link. This data rate corresponds to a reverse link rate divisor of 1. The client returns this response as soon as it perceives it as the beginning of the measurement period. The response from this client is exactly the round-trip delay of the link plus the client's logical delay after the start of the first bit of the measurement period at the host, which is received by the host.

The full zero field (2 bytes) contains zeros to allow the MDDI_Data line drivers in the host and client to be duplicated so that MDDI_Data is always driven. The host enables the MDDI_Data line driver during bit 0 of one field of all zeros, and the client continues to drive the signal to the logical zero level as it did at the end of the measurement period.

The value of the guard time 2 field (64 bytes) allows for overlapping measurement periods driven by the client when the round trip delay is the maximum amount that can be measured in the measurement period. The client disables the line driver during bit 0 of guard time 2, and the host enables the line driver immediately after the last bit of guard time 2. Both the host and the client drive a logical zero level during guard time 2 when they are not disabled. Another purpose of this field is to ensure that all MDDI_Data signals have enough time logic zero level to allow the client to initiate clock signal recovery using both MDDI_Data0 and MDDI_Stb after enabling the host's line driver. It is to guarantee that you are.

Q. Forward link distortion calibration packet In one embodiment, the parameter CRC field (2 bytes) includes a 16-bit CRC of all bytes from packet length to packet type. If this CRC cannot be checked, the entire packet will be dropped.

One field with all zeros uses 8 bytes to ensure that there is a transition on MDDI_Stb at the beginning of the configuration data sequence field. In general, these bytes apply an 8-bit unsigned integer equal to zero. This also gives enough time to change the mode of the clock recovery circuit by simply using the MDDI_Stb or MDDI_Stb signal as the recovered clock, since the client core logic uses the XOR of MDDI_Stb and MDDI_0.

The calibration data sequence field contains a data sequence that toggles the MDDI_Data signal by data period. The length of the calibration data sequence field is determined by the interface used on the forward link. During the processing of the calibration data sequence, the MDDI host controller sets all MDDI_Data signals equally to the strobe signals. Although the calibration data sequence field is received by the client, the client clock recovery circuit should only use MDDI_Stb rather than MDDI_Stb XorMDDI_Data0 to recover the data clock. Depending on the exact phase of the MDDI_Stb signal at the beginning of the calibration data sequence field, the calibration data sequence will typically be one of the following, based on the interface type used when this packet is sent:

Type 1-(64-byte data sequence) 0xaa, 0xaa, ... or 0x55, 0x55 ... Type 2- (128-byte data sequence) 0xcc, 0xcc, ... or 0x33, 0x33 ... Type 3- (256-byte data sequence) 0xf0,0xf0, ... or 0x0f, 0x0f ... Type 4- (512-byte data sequence) 0xff, 0x00, 0xff, 0x00 ... or 0x00, 0xff, 0x00, 0xff ... The all-zero 2 field uses 8 bytes and XOR with MDDI_Stb and MDDI_0 because the client core logic uses the MDDI_Stb signal as the recovered clock to return the mode of the clock recovery circuit to its original state. Give enough time to change to use.

Examples of MDDI_Data and MDDI_Stb waveforms for both Type 1 and Type 2 interfaces are shown in Figures 62A and 62B, respectively.

XVII. Conclusion Although various embodiments of the present invention have been described above, it should be understood that they are presented only as illustrations and are not restrictions. Therefore, the breadth and scope of the invention should not be limited by any of the exemplary embodiments described above, but should be defined only in accordance with the appended claims and their equivalents.