High data rate interface

(Cross-reference of related applications) This patent application is entitled "Swithchable Threshold Differential Interface" filed on October 15, 2003, which is delegated to, referenced and expressly incorporated herein by the assignee. Claim priority over Patent Provisional Application No. 60 / 511,742.

I, field Embodiments of the invention in the present disclosure relate to digital signal protocols and processes for communicating or transferring signals at high data rates between a host device and a client device. 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 .

II. Background 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 typical video presentation scenarios that require electronic products, video data is transferred using current techniques at speeds, typically about 1 to 10 kilobits per second, at best 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, a bridge over a rotary or sliding hinge or hinge structure that attaches or connects a video screen or other element to the main enclosure, where the host and / or various other control and output components are present. May include built-in data bus and connection. 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. This presents an order of magnitude costly reliability challenge 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 are delegated to and incorporated herein by the transferees of the present invention, both of which are currently permitted, to create and implement communication protocols and interfaces for high-speed data rate signal transfer ( Generating And Implementing A Communication Protocol And Interface For High Data Rate Signal Transfer) proposed such a new transfer mechanism in US Patent Applications Nos. 10 / 020,520 and 10 / 236,657. It also states, "Generating And Implementing a Signal Protocol and Interface for Higher Data. Rates) , Application No. 10 / 860,116. The techniques described in those applications can significantly improve 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, efforts still need to be made for even faster transfer speeds, improved communication link efficiency, and stronger communication links. Therefore, there is an ongoing need to develop new or improved transfer mechanisms needed to increase the data throughput between host and client devices.

[Overview] 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. At least one controller residing in 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 types of data. It is configured to form digital presentation data in 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 an embodiment of the invention, at least one link controller, or client receiver, is located 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.

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 drawings, similar reference numbers generally indicate the same, functionally similar, and / or structurally similar elements or processing steps, and the drawing in which the element first appears is the number to the left of the reference number. Indicated by (there may be more than one).

<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="1C">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="1D">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="2">FIG. 5 illustrates the overall concept of a mobile digital data interface for host-client interconnection.</figref><figref num="3">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="4">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="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 2 interface, type 3 interface, and type 4 interface.</figref><figref num="6">It is a figure which shows the structure of a frame and a subframe used to realize an interface protocol.</figref><figref num="7">It is a figure which shows the general structure of the packet used to realize an interface protocol.</figref><figref num="8">It is a figure which shows the format of a subframe header packet.</figref><figref num="9">It is a figure which shows the format and content of a filler packet.</figref><figref num="10">It is a figure which shows the format of a video stream packet.</figref><figref num="11">It is a figure which shows the format and contents of the video data format descriptor used in FIG.</figref><figref num="12">It is a figure which shows the use of the pack format and the unpack format of data.</figref><figref num="13">It is a figure which shows the format of the voice stream packet.</figref><figref num="14">It is a diagram showing the use of byte-aligned PCM format and packed PCM format for data.</figref><figref num="15">It is a figure which shows the format of the stream packet defined by a user.</figref><figref num="16">It is a figure which shows the format of a color map packet.</figref><figref num="17">It is a figure which shows the format of the reverse link encapsulation packet.</figref><figref num="18">It is a figure which shows the format of a client function packet.</figref><figref num="19">It is a figure which shows the format of a keyboard data packet.</figref><figref num="20">It is a figure which shows the format of a pointing device data packet.</figref><figref num="21">It is a figure which shows the format of the link shutdown packet.</figref><figref num="22">It is a figure which shows the format of a client request status packet.</figref><figref num="23">It is a figure which shows the format of a bit block transfer packet.</figref><figref num="24">It is a figure which shows the format of a bitmap area fill packet.</figref><figref num="25">It is a figure which shows the format of a bitmap pattern fill packet.</figref><figref num="26">It is a figure which shows the format of a communication link data channel packet.</figref><figref num="27">It is a figure which shows the format of an interface type handoff request packet.</figref><figref num="28">It is a figure which shows the format of an interface type acknowledgment 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 enable 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="38">It is a figure which shows the processing step for a typical service request without a conflict.</figref><figref num="39">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="42">It is a figure which shows the driver and the termination register which are effective for realizing one Embodiment.</figref><figref num="43">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 relationship at the host receiver input between the timing of the transferred data and the front edge and the trailing edge of a strobe pulse.</figref><figref num="48">It is a figure which shows the corresponding client output delay caused by the switching characteristic and the reverse data timing.</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="52">It is a figure which shows the reverse link data rate change.</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">It is a figure which shows the interface pin assignment exemplary connector used with the I type / 2 type 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 an alpha cursor image function packet.</figref><figref num="76">It is a figure which shows the format of the alpha cursor transparent map packet.</figref><figref num="77">It is a figure which shows the format of the alpha cursor image offset packet.</figref><figref num="78">It is a figure which shows the format of the alpha cursor video stream packet.</figref><figref num="79">It is a figure which shows the format of the scaled video stream function packet.</figref><figref num="80">It is a figure which shows the format of the scaled video stream setup packet.</figref><figref num="81">It is a figure which shows the format of the scaled video stream acknowledgment packet.</figref><figref num="82">It is a figure which shows the format of the scaled video stream packet.</figref><figref num="83">It is a figure which shows the format of a special status request packet.</figref><figref num="84">It is a figure which shows the format of a valid status response list packet.</figref><figref num="85A">It is a figure which shows the format of a packet processing delay parameter packet.</figref><figref num="85B">It is a figure which shows the format of the delay parameter list item.</figref><figref num="86">It is a figure which shows the format of a personal display function packet.</figref><figref num="87A">It is a figure which shows the format of a client error report packet.</figref><figref num="87B">It is a figure which shows the format of an error report list item.</figref><figref num="88">It is a figure which shows the format of a client identification packet.</figref><figref num="89">It is a figure which shows the format of the alternative display function packet.</figref><figref num="90">It is a figure which shows the format of a register access packet.</figref><figref num="91A">It is a figure which shows the use of two display buffers to reduce a visible artifact.</figref><figref num="91B">It is a figure which shows the use of two display buffers to reduce a visible artifact.</figref><figref num="91C">It is a figure which shows the use of two display buffers to reduce a visible artifact.</figref><figref num="92">It is a figure which shows two buffers with display refresh faster than image transfer.</figref><figref num="93">It is a figure which shows two buffers with display refresh slower than image transfer.</figref><figref num="94">It is a diagram showing two buffers with display refresh that is much faster than image transfer.</figref><figref num="95">It is a figure which shows three buffers with display refresh faster than image transfer.</figref><figref num="96">It is a figure which shows three buffers with display refresh slower than image transfer.</figref><figref num="97">It is a figure which shows one buffer with display refresh faster than image transfer.</figref><figref num="98">It is a figure which shows the host-client connection through a daisy chain and a hub.</figref><figref num="99">It is a figure which shows the client device connected through the combination of a hub and a daisy chain.</figref><figref num="100">It is a figure which shows the color map.</figref><figref num="101">It is a figure which shows the leakage current analysis.</figref>

Detailed description of examples 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. In particular, the mechanism can use built-in display elements or input devices (for housings or support frames) as central controllers, or external display elements or devices such as wearable microdisplays (goggles or projectors) as portable computers, wireless communication devices or Useful for implementations with small connectors and thin flexible cables that are useful for connecting to entertainment equipment.

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. However, after considering the embodiments presented below, many non-mobility, non-display related applications benefit from the application of this protocol and the resulting interface structure, and the MDDI label is of the nature of the invention or It will be easily understood that it is not intended to imply effectiveness or limitations 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 Is generated or stored on the client display or presentation device at high speed. 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. 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), but also from the processor to the built-in screen or other presentation element. ..

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, for example, to adapt to the specificity of a particular client device, such as a unique display request for a particular device, or combined audio and video for some AV systems, or a joystick, touchpad, etc. Allows you to adjust the timing of data packets being forwarded to meet the requirements of your particular input device. 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, the very small projection element allows the user's eyes (s) to "see" the image on a much larger scale than is possible on a typical 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. 1C and 1D.

In Figures 1C and 1D, a small cut-out internal view of an overall electronic device or product makes them a video display element or corresponding client 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 even 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 2. In FIG. 2, 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 SVGA resolution at 30fps with 5.1-channel audio, using only a total of 3 wires, 2 for data transmission and 1 for power transmission in the smallest configuration. there is a possibility. 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 3 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 4 and 5. In FIGS. 4 and 5, 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. 5, 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 4 and 5. As can be seen in FIGS. 4 and 5, 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_Data11 +/-. 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="JP2010200332A_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, and include three twisted pair leads, each of which is also a multi-strand 30 AWG wire. .. Foil shield covering is wound or otherwise formed on top of the three twisted pairs as 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, it will be appreciated in the art that various conductors and cables are available for practicing the embodiments of the present invention based on a particular application. For example, in some applications an outer coating or even a metal layer can be used to protect the cable, while in other applications a thin, flat conductive ribbon type structure may fit well. I don't know.

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. The MDDI interface 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="JP2010200332A_D0002.tif" /></tables><tables num="3"><img file="JP2010200332A_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 interface 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 give a synchronous pulse to a simultaneous isochronous data stream. Client devices can use this common frame rate as a time reference. Low CF rates increase channel efficiency by reducing overhead for sending subframe headers. High CF rates, on the other hand, reduce latency and allow smaller, more flexible data buffers for voice samples. The CF rate 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="JP2010200332A_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 CF is achieved by transferring two frames of 27 bytes, one subframe of 26 bytes each following. Smaller CF rates 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 has 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 display. 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. It contains at most 768 bytes of graphic data (a quarter of the screen height) and less than about 200 bytes (several) bytes for other control and status commands.

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="JP2010200332A_D0005.tif" /></tables>

III. (Continued) High-speed digital data interface system architecture E. Link layer The data transferred using the MDD interface 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 4 and 5 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. 6, 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 the asynchronous or aperiodic mode in which the frame is used to provide bitmap data to the client 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 The format or structure of the packet used to perform the communication or signal protocol performed in this embodiment, or the method or means for data transmission, is presented below, the interface is extensible, and additional. It is noted that the packet structure can be added as desired. Packets are labeled with the terminology of their function at the interface, or divided into different "packet types", which are commands, information, values, or data that are transmitted or combined. 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="JP2010200332A_D0006.tif" /></tables><tables num="7"><img file="JP2010200332A_D0007.tif" /></tables><tables num="8"><img file="JP2010200332A_D0008.tif" /></tables><tables num="9"><img file="JP2010200332A_D0009.tif" /></tables>

Something that is clear from the other explanations in the text is that reverse encapsulation packets, client function packets and client request and status packets are each considered very important for external mode operation, or are also required for external mode operation. On the other hand, they can be considered optional for internal mode operation. This results in yet another type of MDDI interface 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 7, with a packet length field, a packet type field, a data byte field (s), and a CRC field. Has. As shown in Figure 7, 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 bitmap pixel locations 0,0. The width of the display window corresponds to the X-axis of the bitmap, and the width of the display window in this embodiment is less than or equal to the width of the corresponding bitmap. The height of the window shall correspond to the Y-axis of the bitmap, and the height of the display window shall be less than or equal to the height of the corresponding bitmap. 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. 8, 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 that the host can address multiple client devices. A value of zero 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.

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. 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 there is no information to send or exchange to the host or client. All hosts and clients need to be able to send and receive this packet in order to use the interface effectively.

An embodiment illustrating the format and content of the filler packet is shown in FIG. As shown in FIG. 9, 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. 10, in one embodiment, this type of packet has a packet length (2 bytes) field, a packet type field, and bClient. ID field, video data descriptor field, pixel display attribute field, X left edge field, Y top edge field, X right edge field, Y bottom edge field, X start field and Y start field, pixel count field, parameter CRC It is structured to have fields, pixel data fields and pixel data CRC fields. 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 bClient ID 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.

The common frame concept described above is an effective way to minimize audio buffer size and reduce latency. However, in the case of video data, it may be necessary to spread the pixels of one video frame across multiple video stream packets within a media frame. It is also likely that the pixels of a single video stream packet will not exactly match the perfectly rectangular window on the display. For an exemplary video frame rate of 30 frames per second, there are 300 subframes per second, resulting in 10 subframes per media frame. If each frame had 480 rows of pixels, each video stream packet within each subframe would contain 48 rows of pixels. In other situations, video stream packets may not contain integer pixel rows. This applies to other video frame sizes where the number of subframes per media frame is not evenly divided into the number of lines per video frame (also known as video lines). For efficient operation, each video stream packet should typically contain integer pixels, even if it may not contain integer rows of pixels. This is important if each pixel is multiple bytes, or if they are in a packed format as shown in Figure 12.

As mentioned above, the formats and contents used to implement the behavior of the exemplary video data descriptor fields are shown in FIGS. 11A-11E. In FIGS. 11A-11E, 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 11A through 11D 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 FIG. 11A, 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 11B, 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 11C, 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 11D, the video data is an array of 4: 2: 2 YCbCr format video data containing brightness and chrominance information. 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 11E. 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 in the figures, bit 12, shown as "P", Oh in the or, or byte-aligned pixel data pixel data samples are packed specify whether Ru. A value of "0" in this field indicates that each pixel in the pixel data field is byte-aligned with the MDD interface byte boundary. A value of "1" indicates that each pixel and each color within each pixel 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 12, 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.

The first pixel of the first video stream packet in the media frame of a particular display window is in the upper left corner of the stream window defined by the X left edge and the Y top edge, and the next pixel received is on the same line. It will be placed at the next pixel location, etc. In this first packet of a media frame, the X start value is usually equal to the X left edge and the Y start value is usually equal to the Y upper edge. For subsequent packets that correspond to the same screen window, the X and Y start values are usually the screens that would normally follow the last pixel transmitted in a video stream packet transmitted within a past subframe. Set to the pixel position in the window.

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 13.

As shown in FIG. 13, this type of packet is, in one embodiment, a packet length field, a packet type field, a bClient ID field, a voice channel ID field, a reserved 1 field, a voice sample count field, a bit per sample and a packing field. , Audio sample rate field, parameter CRC field, digital audio data field and audio data CRC field. In one embodiment, this type of packet is usually identified as a type 32 packet.

The bClient ID 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 14. A value of "0" indicates that each PCM audio sample in the digital audio data field is byte-aligned with the MDDI interface byte boundary, and a value of "1" indicates that each continuous PCM audio sample is past audio. Shown to be packed against the sample. 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 the MDD interface 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-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 Figure 15, this type of packet has a packet length (2 bytes) field, a packet type field, and bClient. It is structured to have an ID number field, a stream parameter field, a parameter CRC field, a stream data field and a stream data CRC field.

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 Figure 16, this type of packet has a packet length field, a packet type field, and hClient. It is structured to have an ID field, a colormap item count field, a colormap offset field, a parameter CRC field, a colormap data field, and a data CRC field. In one embodiment, this type of packet is typically identified as a 64-inch packet (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 Figure 17, this type of packet has a packet length field, a packet type field, and hCLient. ID field, reverse link flag field, reverse rate divisor field, turn 1 length field, turn turn 2 long field, parameter CRC field, all zero field, turn 1 field, reverse data packet field, turn 2 field , And are structured to have all zeros and two fields. In one embodiment, this type of packet is usually identified as a 65-inch packet. In external mode, every host must be able to generate this packet and receive data, and every client must be able to receive data and send it to the host. The implementation of this packet is optional for internal mode, but the reverse link-encapsulated packet is used as a host to receive data from the client.

The MDDI link controller operates specifically during the transmission of a reverse link encapsulated packet. The MDD interface 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 (this is the same behavior as if it were sending all zero data). It is.).

The host disables its MDDI data signal line driver during the period specified by Orientation 1, and the client reenables its line driver during the driver reenable field following the period specified by Orientation 2. To do. 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. ..

The host drives the MDDI_Data signal to the logical zero level during the all-zero-one field, and the client has the MDDI data line during at least one reverse link clock period before the start of the two-field diversion, that is, during the all-zero-two-field period. To the logical zero level. This keeps the data line in a deterministic state for one turn-around field period and two turn-around field periods. If the client has no more packets to send, the high vanition bias resistor (discussed elsewhere) is in the data line for the rest of the reverse data packet field, or for a period of about 16 forward link bytes or more. To keep them at the logical zero level, it may even disable the data lines after driving them to the logical zero level.

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. The functionality of the client, such as the display in this situation, must already be clear at the time of manufacture or incorporation into a single component or device of some type and must be known to the host, so this packet. Inplaymentation is optional for internal mode.

The format of the client function packet in one embodiment is depicted in FIG. As shown in FIG. 18 for this embodiment, this type of packet includes a packet length field, a packet type field, a cClientID field, a protocol version field, a minimum protocol version field, a data rate function field, an interface type function field, Alternate (Alt) number of displays field, reserved 1 field, bitmap width field, bitmap height field, display window width field, display window height field, color map size field, color map RGB width field, RGB function field, black and white Functional field, reserved 2 field, Y Cr Cb function field, Bayer function field, alpha-cursor image plane 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, voice sample resolution field, microphone voice 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 fields , Serial number field, manufacturing week field, manufacturing year field and CRC field. In an exemplary embodiment, this type of packet is usually recognized as a type 66 type.

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. 19 and contains a variable number of bytes of information from or for the keyboard. As shown in FIG. 19, this packet is structured to have a packet length field, a packet type field, a bClient ID field, a keyboard data format field, a keyboard data field, and a CRC field. Here, this type of packet is usually identified as a 67-type packet.

The bClient ID is a reserved field as described above and the 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 to transmit 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. 20 and includes a variable number of bytes of information from or for the pointing device. As shown in FIG. 20, this type of packet is structured to have a packet length field, a packet type field, a bClient ID 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 a type 68 packet in a 1-byte type field.

12. Link shutdown packet Link shutdown packets are sent from the host to the client as a method or means to indicate 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. The first packet sent after hibernation is the subframe header packet. The format of the client status packet is shown in Figure 21. As shown in FIG. 21, 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 a 69-inch packet in the 1-byte type field and uses a preselected fixed length of 3 bytes.

In the low power hibernation state, the MDDI_Data driver is disabled to the high impedance state and the MDDI_Data signal is pulled to the logical zero state using a high impedance bias network that the client can overdrive. The strobe signal used by the interface is set to the logical zero level in hibernation to minimize power consumption. 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. ..

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. The client needs to send this packet as the first packet in the 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. 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 interface protocol.

The format of client requests and status packets is shown in Figure 22. As shown in Figure 22, this type of packet has a packet length field, a packet type field, a cClient ID field, a reverse link request field, a feature change field, a graphics bug field, a CRC error count field, and a CRC field. It is structured to have. This type of packet is typically identified as a 70-type packet in a 1-byte type field, typically using a preselected fixed length of 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 Bitblock forwarding packets provide a means, structure or method for scrolling an area of the display in any direction. A display with this function reports the function with bit 0 of the display feature function indicator field of the client function packet. The format of the bit block transfer packet is shown in Figure 23. As shown in Figure 23, this type of packet has a packet length field, a packet type field, a hClientID field, an upper left X value field, an upper left Y value field, a window width field, a window height field, a window X move field, It is structured to have a window Y move field and a CRC field. This type of packet is usually identified as a type 71 packet and uses a preselected fixed length of 15 bytes in one embodiment.

The field must be moved vertically, the X and Y values of the coordinates of the upper left corner of the window to be moved, the width and height of the window to be moved, and the number of pixels the window must be moved horizontally. Used to specify the number of pixels that must not be. 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.

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. An embodiment for formatting a bitmap area fill packet is shown in FIG. As shown in Figure 24, this type of packet is a packet length field, a packet type field, a hClient field, an upper left X value field, an upper left Y value field, a window width field, a window height field, and a data format descriptor field. , Pixel area fill value field, and CRC field. This type of packet is usually identified as a 72-inch packet in a 1-byte field and uses a preselected fixed length of 17 bytes.

16. Bitmap pattern fill packet Bitmap pattern fill packets provide a means or structure to easily initialize the 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. Unless the horizontal or vertical pattern offset is non-zero, the upper left corner of the fill pattern is aligned with the upper left corner of the window to be filled. If the window to be filled is wider or taller than the 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, then the pixels between the left and left sides of the window plus the horizontal pattern offset are filled with the right-most pixels of the pattern. The horizontal pattern offset should be smaller than the pattern width. Similarly, if the vertical pattern offset is non-zero, then the pixels between the top of the window and the top of the side plus the vertical pattern offset are filled with the lower-most pixels of the pattern. The vertical pattern offset should be less than the height of the pattern.

An embodiment relating to the formatting of bitmap filled packets is shown in FIG. As shown in Figure 25, this type of packet has a packet length field, a packet type field, a hClient ID field, an upper left X value field, an upper left Y value field, a window width field, a window height field, and a pattern width field. , Pattern height field, data format descriptor field, parameter CRC field, pattern pixel data field and pixel data CRC field. In certain embodiments, this type of packet is usually identified as a 73-type packet in a 1-byte field.

17. Communication link data channel packet Communication link data channel packets provide a structure, means, or method for a client with a high level computing function such as a PDA to communicate with a mobile phone or a wireless transceiver such as a wireless data port device. In this situation, the MDDI link acts as a convenient high-speed interface between the communication device and a computer with a mobile display, and this packet transports data at the data link layer of the device's operating system. For example, this packet could be used if the web browser, email client, or entire PDA is built into the mobile display. A display having this function reports the function in bit 3 of the client feature function field of the client function packet.

The format of one embodiment for communication link data channel packets is shown in FIG. As shown in FIG. 26, this type of packet is structured to have a packet length field, a packet type field, a hClient ID field, a parameter CRC field, a communication link data field, and a communication data CRC field. There is. In one embodiment, this type of packet is usually identified as a type 74 packet in the type field.

18. Interface type handoff request packet The interface type handoff request packet is a type 1 (serial) mode, type 2 (2-bit parallel) mode, type 3 (4-bit parallel) mode, or type 4 from the existing mode or current mode of the client or display by the host. Provides means, methods, or structures that allow a shift to (8-bit parallel) mode to be required. Before a host requests a particular mode, it must ensure that the client can operate in the desired mode by examining bits 6 and 7 of the display feature function indicator field of the client function packet. An embodiment relating to the format of an interface type handoff request packet is shown in FIG. As shown in FIG. 27, this type of packet is structured to have a packet length field, a packet type field, an interface type field, a reserved 1 field, and a CRC field. This type of packet is usually identified as a 75-inch packet and uses a preselected fixed length of 4 bytes.

19. Interface type acknowledgment packet Interface type acknowledgment packets are sent by the client and provide the means, method, or structure that allows the client to confirm receipt of the interface type handoff packet. The required modes, namely type 1 (serial) mode, type 2 (2-bit parallel) mode, type 3 (4-bit parallel) mode or type 4 (8-bit parallel) mode, echo back to the host as parameters in this packet. Will be done. The format of the interface type acknowledgment packet is shown in Figure 28n. As shown in FIG. 28, this type of packet is structured to have a packet length field, a packet type field, a cClientID field, an interface type field, a reserved 1 field, and a CRC field. This type of packet is usually identified as a Type 76 packet and uses a preselected fixed length of 4 bytes.

20. Execution handoff packet An executable handoff packet is a means, structure, or method for a host to instruct a client to handoff to the mode specified in this packet. This must be in the same mode that was previously requested and acknowledged by the interface type handoff request packet and the interface type acknowledgment packet. The host and client must switch to the agreed mode after this packet is sent. The client may lose link synchronization and reacquire during mode changes. The format of one embodiment for an executable handoff packet is shown in FIG. As shown in FIG. 29, this type of packet is structured to have a packet length field, a packet type field, a packet type field, a reserved 1 field, and a CRC field. This type of packet is usually identified as a 77-type packet in a 1-byte type field and uses a preselected fixed length of 4 bytes.

21. Forward voice channel enable packet This packet provides a structural method or means that allows the host to enable or disable the client's voice channel. This feature is useful because the client (eg, the display) can power off the audio amplifier or similar circuit elements to save power when there is no audio 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 the forward voice channel enable packet in one embodiment is shown in FIG. As shown in Figure 30, this type of packet has a packet length field, a packet type field, and hClient. It is structured to have an ID field, a voice channel enable mask field, and a CRC field. This type of packet is typically identified as a 78-inch packet in a 1-byte field and uses a preselected fixed length of 4 bytes.

22. Reverse voice sample rate 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 for a reverse voice sample rate packet is shown in FIG. As shown in Figure 31, this type of packet has a packet length field, a packet type field, and hClient. It is structured to have an ID field, a voice sample rate field, a reserved 1 field, and a CRC field. This type of packet is usually identified as a Type 79 packet and uses a preselected fixed byte of 4 bytes.

23. 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 for digital content protection overhead packets 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 a type 80 packet.

24. 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. A display with this function reports its function in 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, this type of packet in one embodiment is a packet length field, a packet type field, a hClient ID field, a transparent color enable field, a reserved 1 field, an alpha-cursor identifier field, a data format descriptor. It is structured to have fields, transparent pixel value fields, and CRC fields. This type of packet is typically identified as an 81-type packet in a 1-byte field and uses a fixed length of 10 bytes, which is preselected.

25. Round trip delay measurement packet Round-trip delay measurement packets provide the structure, method, or means used to measure the propagation delay from host to client (display), plus the 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. 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 is a packet length field, a packet type field, a hClient ID field, a parameter CRC field, a guard time 1 field, a measurement period field, a total zero field, and It is configured to have two guard time fields. This type of packet is usually identified as a type 82 packet and uses a preselected fixed length of 159 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. Therefore, about half of this amount is due to the delay caused by the one-way passage of the signal to the client.

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 enable and disable times during which both the host and client guard times elapse are the times at which the MDDI_data signal is at the appropriate low level, at any appropriate round-trip delay time.

26. Forward link distortion calibration packet 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.

An embodiment of the format of the forward link distortion calibration packet is shown in FIG. As shown in Figure 56, this type of packet should have a packet length (2 bytes) field, a packet type field, a client ID field, a parameter CRC field, an all zero field, a calibration data sequence field and a CRC field. It is structured in. This type of packet is typically identified as a type 83 type in the type field and has a preselected length of 515 in one embodiment.

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. ..

27. 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 20 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 hClient ID field, an MCCS VCP code field and a CRC field. 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 8 bits for this type of packet.

The hClient ID field is reserved for use as a client ID in future runs, and is generally set to zero. The MCCS VCP code field contains two bytes of information that specify the MCCS VCP control code parameters. Values in the range 0-255 return VCP feature response packets with a single item in the VCP feature response list that corresponds to the specified MCCS code. The MCCS VCP code 65535 (0xfff) requests a VCP feature response packet with a VCP feature response list containing feature response list items for each control supported by the client. Values from 256 to 65534 for this field are reserved for future use and are no longer in use.

28. 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 a VCP feature response packet using bit 20 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 is structured to have a packet length field, a packet type field, a cClient ID field, an MCCS version field, a response sequence number field, a VCP feature response list field, and a CRC field. ing. Usually in one embodiment, this type of packet is identified as type 129 as shown in the 2-byte field.

The cClient ID field contains information reserved for the client ID. This field is reserved for future use and is usually set to zero. 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 the feature response list on multiple VCP feature response packets. In this case, the client assigns a sequence number to each contiguous packet, and the sequence number of the VCP feature response packet sent in response to a single VCP feature request packet starts at zero and increments by one minute. The VCP feature list item in the last VCP feature response packet must contain an MCCS VCP control code value equal to 0xffff to identify that the packet is the last packet, and is the best sequence of groups of returned packets. Includes number. If only one VCP feature response packet is sent in response to a VCP feature request packet, the sequence number response in that single packet is zero and the VCP feature response list is a record with an MCCS VCP control code equal to 0xffff. including.

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 list item in the VCP feature response list in this packet. Contains 2 bytes to specify the number. 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 defined in 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 contains a 32-bit unsigned integer that specifies the maximum possible value for 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 length of the returned value is less than 32 bits (4 bytes) according to the VESA MCCS specification, the value is placed inside a 32-bit integer and the most significant (unused) byte remains set to zero. To.

29. 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 20 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 is structured to have a packet length field, a packet type field, a hClient ID field, an MCCS VCP code field, a number of values field in the list, a control value list field, and a CRC field. Has been done. This type of packet is typically identified as type 130, as indicated by the 2-byte field, and is 20 bytes long, excluding the packet length field.

The hClient ID field uses a double-byte value to specify it as the Client ID again or to act as the Client ID. This field has been reserved for future specifications and is currently set to zero. The MCCS VCP code field 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 the specified MCCS Specified by the parameter description of the 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.

30. Valid parameter request packet A valid parameter request packet is a means or preferred mechanism for requesting a client to return a valid parameter response packet containing a list of parameters supported by the specified discontinuous (NC) or table (T) control. used. 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 20 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 hClient ID 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 hClient ID specifies the client ID again, but is currently reserved for future use and is set to zero as will be apparent to those skilled in the art. The 2-byte MCCS VCP code field contains a value that specifies the non-contiguous MCCS VCP control code parameters to be queried. The value of this field corresponds to the discontinuous control implemented on the client. Values 256 to 65535 (0xffff) are usually reserved or considered valid and are considered the controls implemented in the error response.

31. 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 20 of the client feature feature of the client function packet.

The host may request the contents of the table as follows: The host sends VCP featured packet settings that include necessary or desired parameters such as read / write parameters, LUT offsets, 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 cClient ID 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 response list field. And structured to have CRC fields. This type of packet is typically identified for an embodiment as type 132, as shown in the 2-byte field.

The 3-byte MCCS VCP code packet contains values that specify the discontinuous MCCS VCP control code parameters described by this packet, but the cClient ID field is known for future client IDs, as is known from the above description. It is reserved. If an invalid MCCS VCP control code is specified by a valid parameter request packet, the same invalid parameter value is specified 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 contains two bytes of information or a value that specifies the nature of the response associated with the request for the information regarding the specified MCCS 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.

Alpha-cursor image The associated protocols and mechanisms for communicating data over MDD interfaces and communication links provide support for multiple image planes that overlap each other and may have varying transparency. Hardware cursors can be implemented using overlapping images with variable XY offsets. An overview of alpha-cursor functionality and related protocol support is given below. The ability to support alpha-cursor image packets is defined in alpha-cursor image feature packets sent in response to special status request packets.

32. Alpha-Cursor Image Function Packet Alpha-cursor image function packets are used to define the characteristics of the alpha cursor image and the associated transparency map on the client. In one embodiment, the client demonstrates the ability to support alpha-cursor image function packets with a parameter value of 133 in the valid parameter response list of the valid status response list packet. The packet length specified in the packet length field is set to a fixed value of 20 in the case of one embodiment without including the packet length field.

The format of the alpha-cursor image function packet of one embodiment is shown in FIG. As can be seen in Figure 75, this type of packet has a packet length field, a packet type field, a cClient ID field, an alpha-cursor identifier field, an alpha-cursor bitmap width field, an alpha-cursor bitmap height field, and an RGB functional field. , Black and white functional field, reserved 1 field, Y Cr Cb functional field, transparency map Res. Field, functional bit field, and CRC field. The cClient ID field is usually reserved for future use of the client ID and is currently set to zero.

The alpha-cursor identifier field (2 bytes) contains a value that identifies a special alpha-cursor plane. If the client supports n alpha-cursor image planes, the alpha-cursor identifier has a valid range of 0 to n-1. In one embodiment, the value n is specified by the alpha cursor image plane field of the display function packet. The client returns a unique alpha cursor image function packet for each alpha cursor image plane.

The 2-byte Alpha-Cursor Bitmap Height field value is expressed as the number of pixels Alpha-Cursor Bitmap Specifies the height of the image, while the 2-byte Alpha-Cursor Bitmap Width field value is the number of pixels Alpha-Cursor Specifies the width of the bitmap image, represented as.

The RGB function field uses 2 bytes to specify the number of bits of resolution that can be displayed in RGB format. This value is zero if the client cannot use the RGB format. The RGB function word is composed of three separate values, and in one embodiment, it is realized as follows. Bits 3 to 0 define the maximum number of blue bits (blue brightness) for each pixel. Bits 7 to 4 define the maximum number of green bits (green brightness) for each pixel, and bits 11 to 8 define the maximum number of red (red brightness) bits for each pixel. Bits 15-12 are reserved for future use in presenting RGB functional information so that they are usually zero for the time being.

The 1-byte black and white function field is used to specify the number of bits of resolution that can be displayed in black and white format. This value is set to zero if the client cannot use the black and white format. Bits 7-4 are reserved for future use and are therefore 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.

1 Byte Reserved 1 field contains a value that is normally reserved for future use, thus setting all bits of this field to zero. As a result, the subsequent 2-byte fields are aligned with the 16-bit word address, and the 4-byte fields are aligned with the 32-bit word address.

The 2-byte Y Cb Cr functional field contains a value or information that 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 Cr Cb format. In general, in one embodiment, the Y Cb Cr functional word consists of three separate 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, bits 11 to 8 that define the maximum number of bits that specify the Y sample, And Y Cb Cr Bits 15 to 12, which are reserved for future use in presenting functional information or values, but are currently set to zero.

The 1-byte transparency map resolution field contains a value or information that specifies the number of bits (depth) for each pixel location in the alpha-cursor image transparency map. This value can be in the range 1-8. If the value is zero, the transparency map is not supported for this alpha-cursor image buffer (buffer specified by the alpha-cursor identifier field).

A 1-byte function bit field provides a value or information containing a set of flags that specify the function associated with the alpha-cursor image buffer. In one embodiment, the flag is defined as: Bit 0 serves to select the pixel data of the alpha-cursor video stream packet in pack format. Bit 1 serves to indicate that the transparency map data for the alpha-cursor transparency packet is in packet format. An example of byte-aligned and packed transparency map data is shown in Figure 76. Bit 2 works to indicate that the alpha-cursor image plane uses the alpha cursor image offset packet to support the image offset feature. Bit 3 serves to indicate that the alpha-cursor image plane can support the colormap data format. The same colormap table is used for the alpha cursor image plane as it is used for the main image buffer and the scaled video stream. Colormaps are constructed using colormap packets described elsewhere.

Bits 7-4 are reserved for future use and are usually set to zero or logical level.

33. Alpha-Cursor Transparency Map Packet The alpha-cursor transparency map packet defines the content of the image transparency map for the specified alpha-cursor image plane. Some applications may require a transparency map that exceeds the amount of data that can be sent in a single packet. In these cases, multiple alpha-cursor transparency map packets may be sent, each with a different subset of the transparency map by using the transparency map X and Y start fields described below. These fields behave like the X and Y start fields of a video stream packet. The client uses the alpha-cursor image feature packet transparency map resolution field on each particular alpha-cursor plane specified by the alpha-cursor identifier field of the alpha-cursor image feature packet to alpha-cursor in one embodiment. Demonstrates the ability to support transparency map packets. The packet length and client ID fields behave as described above for the other packets described above. In one embodiment, the value 134 in the packet type field is used to identify the packet as an alpha-cursor transparency map packet.

The format of the alpha-cursor transparency map packet of one embodiment is shown in FIG. As can be seen in Figure 76, this type of packet has a packet length field, a packet type field, a hClientID field, an alpha-cursor identifier field, a transparency map X start field, a transparency map Y start field, a transparency map resolution field, a reserved 1 field, It is structured to have a parameter CRC field, a transparency map medium field, and a transparency map data CRC field.

The 2-byte alpha-cursor identifier field has a value that identifies a particular alpha-cursor plane. If the client supports n alpha-cursor image planes, the alpha-cursor identifier has a valid range from 0 to n-1.

The 2-byte transparency map X start field and Y start field specify absolute X and Y coordinates, respectively, and the point (transparency map X start, transparency map Y start) is the first pixel in the following transparency map data fields. ..

The transparency map resolution field (1 byte) contains the resolution of the transparency map and a value that specifies whether the data is packed. In one embodiment of this field, bits 3 to 0 determine the number of resolution bits present in all transparency map table items. Specify the width so that the valid value is 1 bit to 8 bits. Values 0 and 9 to 15 are considered invalid. This value must match the value returned by the client in the transparency map resolution field of the alpha-cursor image feature packet. Bits 6-4 are reserved for future use and are therefore usually set to logical zero this time. Bit 7 of this byte specifies whether the transparency map data is in the packet or is in byte-aligned format. If bit 7 is equal to "1", the transparency map data is in packed format, and if bit 7 is "0", the data is byte aligned. Examples of packed and byte-aligned transparency map data are shown elsewhere. The value of this bit must match the value of bit 1 of the function bit field of the alpha-cursor image function packet.

1 Byte Reserved One field is reserved for future use, so all bits in this field are usually set equal to the logical zero level. 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 parameter CRC field contains a 16-bit CRC of all bytes from the packet length to the reserved 1 field. If this CRC cannot be checked, the entire packet must be dropped.

For transparency map data fields, each transparency map location is 1 to 8 bits wide. If a single transparency map cannot fit into one alpha-cursor transparency map packet, the entire transparency map will have different transparency map data and transparency map X and Y start values in each packet. It may be specified by sending a packet.

The 2-byte transmission map data CRC field contains only 16-bit CRC of transparency map data. If the CRC cannot be checked, the transparency map data is still available, but the CRC error count shall be incremented.

34. Alpha-Cursor Image Offset Packet The alpha-cursor image offset packet specifies the X and Y offsets of the cursor from the upper left corner of the main display image. The alpha-cursor image offset packet is shown in Figure 77. As shown in FIG. 77, in one embodiment, the alpha-cursor image offset packet is the packet length field, packet type field, hClient. It is structured with an ID field, an alpha-cursor X offset field, an alpha-cursor Y offset field, and a CRC field. In one embodiment, the client uses bit 2 of the function bit field of the alpha-cursor image function packet on each special alpha-cursor plane specified by the alpha-cursor identifier field of the alpha-cursor image function packet. Alpha-Shows the ability to support cursor image offset packets. In one embodiment, the packet length is fixed at 10 as shown in the 2-byte packet length field. In one embodiment, the packet type 135 identifies the packet as an alpha-cursor image offset packet.

2-Byte Alpha-Cursor X and Y offset fields specify the horizontal and vertical offsets of the leftmost column and top row of pixels in the cursor image from the left and top of the main image, respectively. Includes a value. hClient ID-2 bytes containing a 16-bit unsigned integer reserved for the client ID. This field shall be reserved for the future and set to zero.

35. Alpha Cursor Video Stream Packet Alpha-cursor video stream packets carry video data to update the rectangular area of the alpha-cursor image plane. The size of this area may be as small as a single pixel or as large as the entire display. The format of the alpha-cursor video stream packet is shown in Figure 78. As shown in FIG. 78, in one embodiment, the alpha-cursor video stream packet is a packet length field, a packet type field, a bClientID field, a video data format attribute field, an X left edge field, and a Y top edge field. , X right edge field, Y bottom edge field, X start field, Y start field, pixel count field, parameter Crc pixel data field, and pixel data CRC field. In one embodiment, the client uses an alpha-cursor image function packet for each special alpha-cursor plane specified by the alpha cursor identifier field of the alpha-cursor image function packet to play an alpha cursor video stream. Indicates the ability to support a packet and its associated parameters, a value of 17 in the packet type field indicates or identifies the packet as an alpha-cursor video stream packet. The hClient ID field (2 bytes) is reserved for future use as a client ID and is generally set to zero for the time being to be well understood by the technology.

The 2-byte video data format descriptor field contains information or values that specify the format of each pixel in the pixel data in this stream of this packet. The pixel data format must conform to at least one of the valid formats of the alpha-cursor image plane as defined in the alpha-cursor image function packet. The video data format descriptor field contains a value that defines the 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. 11 above shows how the video data format descriptor is encoded. The format is as follows.

In one embodiment, when bit [15:13] is "000", the video data consists of an array of black and white pixels whose number of bits per pixel is defined by bits 3 to 0 of the video data format descriptor word. .. Bits 11-4 are then set to zero. When bit [15:13] is "001", the video data consists of an array of color pixels, each specifying a color through a color map (palette). Bits 5 to 0 of the video data format descriptor word define the number of bits per pixel, and bits 11 to 6 are set to zero. When bit [15:13] is "010", the video data has the number of red bits defined by bits 11-8, the number of bits per green pixel defined by bits 7-4, and the number of bits per blue pixel. It consists of an array of color pixels in unprocessed RGB format, the number of bits 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.

When bit [15:13] is "011", the video data consists of an array of 4: 2: 2 Y Cb Cr format video data with luminance and chrominance information. 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 Cb and Cr components are transmitted at half the speed of Y. The video sample in the pixel data part of this packet is organized as Cbn, Yn, Crn, Yn + 1, Cbn + 2, Yn + 2, Crn + 2, Yn + 3 ... Yn and Yn + 1 are associated, Cbn + 2 and Crn + 2 are associated with Yn + 2 and Yn + 3, and so on. Y, Yn + 1, Yn + 2, and Yn + 3 are the brightness values of four consecutive pixels in a single row from left to right. Color component ordering is Microsoft's UYVY Same as FOURCC format. If the rows in the window referenced by the video stream packet (X right edge-X left edge +1) have an odd number of pixels, the next line after the Cb value corresponding to the last pixel in each line. Followed by the Y value of the first pixel of.

Windows using the Y Cb Cr format are recommended to have a width that is even pixels. The pixel data in the packet contains an even number of pixels. It is odd or odd when the last pixel of the pixel data corresponds to the last pixel of the row of 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 Y. It may contain an even number of pixels.

For all five formats, bit 12 (indicated as "P" in the figure) specifies whether the pixel data sample is packed. When the value of bit 12 is "0", each pixel in the pixel data field and each color within each pixel is byte-aligned with the MDDI interface byte boundary. When the value of bit 12 is "1", each pixel in the pixel data and each color within each pixel is packed relative to a past pixel or color within the pixel, leaving no unprocessed bits.

In one embodiment, the pixel data attribute field (2 bytes) has a set of bit values that are interpreted as shown below. Bits 1 and 0 select how the display pixel data is sent. For a bit value of "11" the data is displayed for both eyes or for both eyes, for a bit value "10" the data is sent only to the left eye and for a bit value "01" the data is only for the right eye Will be sent to.

Bit 2 of the pixel data attribute field indicates whether the pixel data is presented in an interlaced format, and a value of "0" indicates that the pixel data is in a standard gradual format and has a row number (pixel Y coordinate). It means that it is incremented by 1 when going from one row to the next. This bit increments the line number by 2 as you move 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 enabled by bit 2, but the interlace is vertical instead of horizontal. When bit 3 is "0", the pixel data takes a standard gradual format and the column number (pixel X coordinate) is incremented by 1 for each successive pixel received. When bit 3 is "1", the pixel data takes an alternative pixel format and the column number is incremented by 2 as each pixel is received.

Bit 4 of the pixel data attribute field allows the data to be sent to the internal display, or from the internal display, for wireless phones or similar devices or for portable computers, or for such other devices as described above. Indicates whether the pixel data is relevant to the display or camera if it is being transferred, or if the data is being transferred to or from a camera that is built into or directly coupled to the device. .. When bit 4 is "0", the pixel data is being transferred to or from the display framebuffer. When bit 4 is "1", pixel data is being transferred to or from a camera or some kind of video device, and such devices are well known in the art.

Bit 5 of the pixel data attribute field is usually set to a zero value or "0" because it is reserved for future use or application of the MDD interface.

Bits 7 and 6 of the pixel data attribute field are display update bits that specify the framebuffer in which the pixel data is written. Further specific effects are 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 have applications for future applications of the interface. Bits 8 to 15 are reserved for future use and are usually set to zero.

In one embodiment, the 2-byte X and Y start fields specify the absolute X and Y coordinates of the points (X start, Y start) for the first pixel of the pixel data field. Alpha where the X right edge field and the Y bottom edge field are being updated-Specify the X coordinate of the right edge and the Y coordinate of the bottom edge of the cursor image window, but the 2-byte X left edge field and the Y top edge field The field specifies the X coordinate of the left edge and the Y coordinate of the top edge of the alpha-cursor image window filled by the pixel data field.

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

The 2-byte parameter CRC field 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 contains raw video information that must be displayed and formatted as described by the video data format descriptor field. Data is transmitted one "row" at a time, as described elsewhere. The pixel data CRC field (2 bytes) contains a 16-bit CRC with pixel data only. If CRC validation of this value fails, the pixel data is still available, but the CRC error count is incremented.

Scaling video stream image The MDD interface or protocol mechanism 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, and the scaled image is placed in the main image buffer. It will be copied. 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.

36. 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 has a packet length field, a packet type field, a cClient ID field, a maximum number of streams field, a source maximum X size field, a source maximum Y size field, and an RGB function field. , Black and white functional field, reserved 1 field, Y Cr Cb functional field, reserved 2 field and CRC field. In one embodiment, the packet length is a 2-byte cClient that is reserved for use with the client ID and otherwise set to zero, as shown in the length field. It is selected to be a fixed 20 bytes including the ID field and CRC field. 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 shall be reserved for future use and set to zero. Bit 2 shall be 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.

37. Scaling video stream setup packet Scaling video stream setup packets are used to define the parameters of the scaling video stream, and the client uses the information to allocate internal storage for image buffering and scaling. 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 hClient ID 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. , Generally all bits are set to logical-zero values.

The stream ID field uses 2 bytes to specify a unique identifier for the stream ID. This value is assigned by the host and is distributed from zero to the value of the maximum stream ID value specified in the display 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 must conform to at least one of the valid formats for the alpha-cursor image plane as defined in the alpha cursor image function packet. 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. 11 shows how the video data format descriptor is encoded, an embodiment as described above for other packets.

The 2-byte pixel data attribute field has values that are interpreted as follows:

Bits 1 and 0 select the display on which pixel data is to be sent.

Bit [1: 0] = 11 or 00-Data is displayed in both eyes.

Bits [1: 0] = 10-Data is sent only to the left eye.

Bits [1: 0] = 01-Data is sent only to the right eye.

Bit 2 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) shall be 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) shall be incremented by 2 from one line to the next.

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, the pixel data is in standard gradual format. The column number (pixel X coordinate) shall be incremented by 1 when each successive pixel is received. When bit 3 is 1, the pixel data takes an alternative pixel format. The column number (pixel X coordinate) shall be incremented by 2 upon receipt of each pixel.

Bit 4 indicates whether the pixel data is related to the display or the camera. When bit 4 is 0, the pixel data is to or from the display framebuffer. When bit 4 is 1, the pixel data is to or from the camera. Bit 5 is usually set to zero because it is reserved for future use.

Bits 7 and 6 are display update bits that specify the framebuffer in which the pixel data is to be written. The effect of the frame update bit is explained in more detail elsewhere. When bit [7: 6] is "01", pixel data is written to the offline image buffer. When bit [7: 6] is "00", pixel data is written to the image buffer used to refresh the display. When bit [7] 6] is "11", pixel data is written to all image buffers. When bit [7: 6] is "10", this is treated as an invalid value. These bits are currently reserved for future use. In this situation, the pixel data will be ignored and will not be written to any of the image buffers.

Bits 8 to 15 are reserved for future use and are generally set to the level or value of logical zero.

The 2-byte X left edge field, Y upper edge field, X right edge field, and Y lower edge field are the X coordinate of the left edge, the Y coordinate of the upper edge, the X coordinate of the right edge, and the bottom of the destination image. Specify each edge. The 2-byte X and Y image size fields specify the width and height of the source image, respectively. The CRC field again contains the CRC of all bytes in the packet, including the packet length.

38. Scaling video stream acknowledgment packet 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. It shall indicate the 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 cClient ID 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 stream ID already 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.

39. 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 shall demonstrate its ability to support video stream packets.

The format of one embodiment of the scaling video stream packet is generally shown in FIG. As can be seen in Figure 82, the scaling video stream packet now has a packet length field, a packet type field, a hClient ID field, a stream ID field, a parameter CRC field, a pixel count field, a pixel data field, and a pixel data CRC field. It is structured. The 2-byte packet type field uses the value 18 to identify the packet as a scaling video stream packet. The hClient ID 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.

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.

40. 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 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. The client can use bit 21 of the client feature feature field of the client feature packet to demonstrate its ability to support special status request packets.

The format of one embodiment of the special status request packet is generally shown in FIG. As can be seen in FIG. 83, 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 hClient ID field (2 bytes) is reserved for future use for the client ID and is set to zero for the time being, while the 2-byte status packet ID field is sent by the client to the host as follows: Specifies the type of function or status packet. Typical packet types are:

66-Client Function Packets shall be sent by the client.

133-Alpha-Cursor Image Function Packets shall be 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.

140-Packet processing delay parameter A packet is sent by the client.

141-Personal Display Function Packets are sent by the client.

142-Error report display packets are 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.

41. 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 respond 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 Figure 84, the valid status response list packet is structured to have a packet length field, a packet type field, a cClient ID field, a number of values field in the list, a valid parameter response list field, and a CRC field. There is. 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 cClient ID 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 140-Packet processing delay parameter packet 141-Personal Display Function Packet 142-Client error report packet 143-Scaled video stream feature packets 144-Client identification packet Packet types 56-63 can be used as manufacturer's special features and status identifiers.

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

42. Packet processing delay parameter packet Packet Processing Delay Parameters Packets provide a set of parameters that allow a host to calculate the time it takes to complete the processing associated with receiving a particular packet type. Some commands sent by the host cannot be completed by the client in zero time. The host may poll the status bits in the client request and status packets to determine if a particular function has been completed by the client, or the host may use the parameters returned by the client in the packet processing delay parameter packet. The completion time may be calculated. Valid Status Response List Packet Enabled Parameter The response list can be used with a parameter value of 140 to indicate its ability to support packet processing delay parameter packets.

Packet Processing Delay Parameter The format of one embodiment of the packet is generally shown in Figure 85A. As can be seen in FIG. 85A, the packet processing delay parameter packet is structured to have a packet length field, a packet type field, a cClient ID field, a list item count field, a delay parameter 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 140 identifies the packet as a packet processing delay parameter packet. The cClient ID field is reserved for future use as a client ID and is usually set to zero. The 2-byte list item count field specifies the number of items in the subsequent valid parameter response list.

A delay parameter list field is a list containing one or more delay parameter list items. The format for one embodiment of a single delay parameter list item is shown in Figure 85B, a packet type field for delay, a pixel delay field, a horizontal pixel delay field, a vertical pixel delay field, and a fixed delay field. It is shown.

Each delay parameter list item is typically limited to exactly 6 bytes in length and is further defined as shown below. The packet type field for a 2-byte delay specifies the packet type to which the following delay parameters apply. The pixel delay field (1 byte) has an index on the delay value. The value read from the table is multiplied by the total number of pixels in the destination field of the packet. The total number of pixels is the width x height of the destination area of the bitmap referenced by the packet. The 1-byte horizontal pixel delay field contains values that are indexes to the delay value table (the same table as DPVL). The value read from the table is multiplied by the width (in pixels) of the packet's destination field. The 1-byte vertical pixel delay field contains values that are indexes to the delay value table (the same table as DPVL). The value read from the table is multiplied by the height (in pixels) of the packet's destination field.

The fixed delay field uses 1 byte as an index for the delay value table (the same table as DPVL). The value read from the table is a fixed delay parameter that represents the time it takes to process a packet that is irrelevant to any parameter value specified for the packet. The total delay, that is, the packet processing completion time delay is obtained according to the following relationship.

Delay = (PacketProcessingDelay (PixelDelay) / TotalPixels) + (PacketProcessingDelay (HorizontalPixelDelay) Width) + (PacketProcessingDelay (VerticalPixelDelay) / Height) + PacketProcessingDelay (FixedDelay) For some packets, the pixel sum, width or height does not apply because those parameters are not referenced in the corresponding packet. In those cases the corresponding pixel delay parameter is usually set to zero.

43. 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. 86, the personal display function packet includes a packet length field, a packet type field, a cClient ID field, a subpixel layout field, a pixel shape field, a horizontal field of view field, a vertical field of view field, an axis crossing field, and a left and right image field. , See-through field, maximum brightness field, optical function field, minimum IPD field, maximum IPD field, IFeld point field of curvature list and 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 cClient ID field is reserved for future use and is usually set to zero for the time being.

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.

The pixel shape field specifies the shape of each pixel, which consists of specially configured subpixels, using the following values: 0 indicates no subpixel shape, 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 are future in indicating the desired chapes, as can be understood by those skilled in the art. Reserved for use.

The A1 byte horizontal field of view (HFOV) field specifies the horizontal field of view in increments of 0.5 degrees (for example, if HFOV is 30 degrees, this value is 60). No HFOV is specified if this value is zero.

The A1 byte Vertical Field (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.

The A1-byte visual crossing field specifies the visual crossing in 0.01 diopter (1 / m) increments (for example, if the visual crossing is 2.22 meters, this value is 45). If this value is zero, no axial crossing is specified (Note: is this parameter specified in the desired range for most applications?).

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

The A1 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 shall not be 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.

The 2-byte optics flag field contains 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 usually set to zero.

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. It shall indicate 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.

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 below. 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<tables num="10"><img file="JP2010200332A_D0010.tif" /></tables>

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

44. 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 Figure 87A. As can be seen in FIG. 87A, the client error report packet is structured to have a packet length field, a packet type field, a cClient ID 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 cClient ID 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 87B.

In one embodiment, each error report list item is exactly 4 bytes in length, as shown in FIG. 87B, 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.

45. 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 display 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. 88. As can be seen in FIG. 88, the client identification packet includes a packet length field, a packet type field, a cClient ID 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. It is structured to have a string 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 display identification packet. This value is chosen to be 144 in one embodiment. The cClient ID 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.

46. Alternate display function packet Alternate display feature packets indicate the capabilities of the alternate display attached to the 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. 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. 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. 89, the alternative display function packet includes a packet length field, a packet type field, a cClient ID field, an alternative display number field, a reserved 1 field, a bitmap width field, a bitmap height field, and a display window width field. Structured to have display window height field, color map RGB width field, RGB functional field, black and white functional field, reserved 2 field, Y Cb Cr functional field, display feature functional field, reserved 3 field, and CRC field There is. A packet type value of 145 identifies the packet as an alternate display function packet. The cClient ID field is reserved for client IDs for future use and is usually set to zero.

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 usually designed as number 0, and the other alternative displays shall be 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 is a replacement for display function packets. The number of displays field has a value of 1.

Reserved 1 field (1 byte) is reserved for future use. All bits in this field are set to zero. 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 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 1-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 2-byte CRC field contains the 16-bit CRC of all bytes in the packet, including the packet length.

47. 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 format of one embodiment of the register access packet is generally shown in FIG. As can be seen in FIG. 90, a register access packet may have a packet length field, a packet type field, a bClient ID field, a read / write flag field, a register address field, a parameter CRC field, a register data list field and a register data CRC field. It is structured in. A packet type value of 146 identifies the packet as a register access packet. The bClient ID field is reserved for future use and is usually set to zero for the time being.

The 2-byte read / write flag field specifies 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", it is treated as an invalid value and this value is reserved for future use and will not be used.

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.

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 for a client request and status packet is 0x000c, 0x0046, 0x000, 0x0400, 0x00, 0x00, 0x000 (or 0x0c, 0x00, 0x46, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, When submitted using the inputs of the multiplexers 3604 and 3606 and the NAND gate 3608 (represented as a sequence of bytes such as 0x00, 0x00, 0x00), the resulting CRC output on the Tx_MDDI_Data_With_CRC line is 0xd9aa (or 0xaa). , Represented as a sequence such as 0xd9).

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 NAND gate 3608, NOR gate 3610, exclusive OR (XOR) gate 3612 and AND. It is compared bit by bit with the value found in the CRC register using 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.

<u style="single"> V. Link hibernation</u> MDDI links can quickly enter hibernation and wake up quickly from hibernation. This responsiveness allows the communication system or device power to force the MDDI link to hibernation frequency in order to reduce consumption. Because it is possible to wake up again very quickly for use. In one embodiment, the external mode client wakes up early from hibernation, so it should run at a data rate of 1 Mbps and at strobe pulse timing, i.e. the MDDI_Stb pair should toggle at a 500 kHz rate. Once the client features are discovered by the host or in communication, the host can then wake up the link at any rate, generally from 1 Mbps to the maximum rate at which the client can operate. Internal mode clients can wake up at any rate that both the host and the client can run. This is also generally applicable for fast time internal mode wakeups.

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 slow line receiver that consumes only a small portion of the current as the differential receiver required to receive the signal at maximum link operating speed. Either the host or the client can wake up the link, in which case the wakeup protocol is designed to handle the contention that can occur if both the host and the client attempt to wake up at the same time.

The MDDI_Data and MDDI_Stb differential drivers are disabled for the duration of the hibernation state, and the differential voltage across all differential pairs is zero volt. The differential receiver used to detect the sequence of pulses during the period of wake up from hibernation has an intentional voltage offset. In one embodiment, the threshold between logic 1 and logic zero levels in these receivers is about 12.5 mV. This causes the non-driven differential pair to be considered at the logical zero level during the period when the link wakes up.

To enter the Hibernation State, the host sends a 64MDDI_Stb cycle after the CRC of the Link Shutdown Packet. The host disables the output of MDDI_Data0 of the host in the range of 16 to 56 MDDI_Stb cycles after CRC (including invalid propagation delay output). The host terminates sending the 64MDDI_Stb cycle after the CRC of the link termination packet and before it initiates the wakeup sequence. In one embodiment, the wake-up initiated host is defined as the host that must wait at least 100 nsec after MDDI_Data0 reaches the proper logical 1 level before driving the pulse over MDDI_Stb. In one embodiment, the client waits at least 60 MDDI_Stb cycles after the CRC of the end-of-link packet before it drives MDDI_Data0 to the logical 1 level to attempt to wake up the host.

Several processes or steps are undertaken to "wake up" from the hibernation state. If the client, here the display, needs data or communication, services from the host, it drives the MDDI_Data0 line into a logical 1 state for around 70-1000 μsec, where MDDI_Stb is inactive, and Keep MDDI_Data0 driven to logical 1 level for about 70 MDDI_Stb cycles (ranging from 60-80) after MDDI_Stb is active, even if other periods are available if desired. The client then disables the functionality of the MDDI_Data0 driver by putting it in a high impedance state.

If MDDI_Stb is in a viable state for the duration of the hibernation, then the client then puts only MDDI_Data0 into a logical 1 state for about 70 MDDI_Stb cycles (range 60-80), even if it is unlikely. Will drive. This behavior causes the host to start or restart data traffic on the forward link (208) and to investigate the state of the client.

The host must detect the presence of the request pulse and drive MDDI_Data0 to one logical level for about 150 MDDI_Stb cycles (range 140-160), and logic for about 50 MDDI_Stb cycles (range 40-60). Start a start-up sequence that drives to zero level. The display should not send a service request pulse if it detects MDDI_Data0 during more than 70 MDDI_Stb cycles in the logical 1 state. After the host drives MDDI_Data0 to the logical zero level for a period of 50 MDDI_Stb cycles, the host begins sending packets on the link. The first packet sent is a sub-frame header packet. The characteristics of time interval time and tolerance selection for pause processing and start sequences are further discussed below (see Figures 68A-C).

The host can first activate MDDI_Stb and at the same time initiate a wakeup by driving it at a logical zero level. MDDI_Stb should not be driven to logic 1 level until the pulse is output as described below. After MDDI_Stb reaches the logical zero level, the host makes MDDI_Data0 operational and at the same time drives it to the logical 1 level. MDDI_Data0 should not be driven to a logical zero level until a period of 50 MDDI_Stb pulses as described below while it is driven to a logical zero level. The host should wait at least 100 nsec after MDDI_Data0 reaches the proper logic 1 level before driving the pulse to MDDI_Stb. This timing relationship arises when considering the worst case output enable delay. This effectively compensates for the client having enough time to fully operational its MDDI_Stb receiver after being invoked by the logical 1 level for a host-driven MDDI_Data0.

An example of the processing steps for a typical client service request event 3800 with no race condition is that the event is named for convenience of illustration using the letters A, B, C, D, E, F and G Figure 38. 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. After asserting MDDI_Data0 to the logical zero level and driving MDDI_Stb for 50 μsec, the host initiates data transmission on the forward link by transmitting a subframe header packet 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 client puts its fast receiver for MDDI_Data0 and MDDI_Stb in hibernation at any time after the CRC of the link shutdown packet and after the 48th rising edge of the MDDI_Stb cycle. Clients are advised to hibernate fast receivers for MDDI_Data0 and MDDI_Stb after CRC of the link shutdown packet and before the 64th rising edge of the MDDI_Stb cycle.

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 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.

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.

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. 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.

In Figure 41, the receiving part 4120 is used to receive the signal and recover the data, while the transmitting part 4100 produces the original DATA and STB signals on the intermediate signal path 4102. And used to send. As shown in Figure 41, to transfer data from the host to the client, a DATA signal is input to two D-type flip-flop circuit elements 4104 and 4106, along with a clock signal to trigger the circuit. Will be done. The two flip-flop circuit outputs (Q) are then combined into a differential set of signals MDDI_Data0, MDDI_Data0-, and MDDI_Stb +, MDDI_Stb-, respectively, using two differential line drivers 4108 and 4110 (voltage mode). It is divided. A second 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 the MDDI_Stb + and MDDI_Stb- signals. Produces an output that provides a data input to the flip-flop. 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 is used to trigger each of the two D-type flip-flop circuits 4128 and 4130 that receive a delayed version of the DATA signal through the delay element 4132, one of which (4128) is the data " The other (4130) yields the data "1" value, which yields the "0" 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 MDDI data set, ie MDDI_Stb + and MDDI_Stb- signals, are operated in differential mode to maximize immunity from the negative effects of noise. Each differential pair is a parallel transmission terminal with the characteristic impedance of the cable or conductor used to transmit the signal. Generally, all parallel transmission terminals are present in the client device. This is close to a differential receiver for forward traffic (data sent from the host to the client), but this is cable or other conductor or reverse traffic (data sent from the client to the host). At the driving end of the transmission element with respect to. Due to reverse traffic, the signal is driven by the client, reflected by the high impedance receiver at the host, and terminated at the client. This eliminates the need for double termination, which increases current consumption. It also operates at a higher data rate than the mutual reciprocating delay in the cable. MDDI_Stb + and MDDI_Stb-conductors or signals are driven only by the host.

An exemplary configuration of drivers, receivers and effective elements to achieve termination for transferring signals as part of the MDD interface of the present invention is shown in FIG. This exemplary interface uses low voltage sensing, here 200 mV, which is smaller than the 1 V power swing and has a low power drain. The driver for each signal pair has a differential current output. While receiving MDDI packets, the MDDI_Data and MDDI_Stb pairs use a regular differential receiver with a voltage threshold of 0V. In hibernation, the driver's output is disabled, and a resistor terminating in parallel attracts the voltage of each signal pair to 0V. During the pause period, certain receivers on the MDDI_Data0 pair have a positive 125 mV offset input threshold, which causes the pause line receiver to perform a non-drive signal pair as a logical-zero level.

Sometimes the host or client is a differential pair to logical 1 level or logical zero level to ensure an appropriate logical level for the pair when the direction of data flow changes (host to client or client to host). Are driven at the same time. The output voltage range and output reference will be met by outputs driven simultaneously to the same logic level. In some systems, it may be necessary to drive a small current to the terminated differential pair to generate a small offset voltage at certain times of duration of hibernation and when the link wakes up from hibernation. .. In these conditions, the operational offset-current bias circuit must drive the following leakage:

I_ESD-and-RX-Internal ESD diode and differential receiver input I_ESD-and-RX1 μA I_Tx-Hi-Z-Differential driver output in high impedance condition I_Tx-Hi-Z1 μA Iexternal-ESD-Leakage through an external ESD protection diode Iexternal-ESD 3 μA.

These leakage currents are shown in Figure 101. The pull-up and pull-down circuits must reach the minimum differential voltage in the worst case leakage situation when all of the above occur at the same time. The total leakage 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 diode.

The electrical parameters and characteristics of the differential line driver and line receiver are listed in Table VIII. 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. Table VIII presents a minimum voltage amplitude of 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.

FIG. 42 shows a host controller 4202 and a client or display controller 4204 that are forwarding packets over communication link 4206. While the client employs three drivers 4230, 4232, and 4234, the host controller receives the host DATA and the transmitted STB signal in the same way that it receives the transmitted client Data signal. Adopt a series of drivers 4210, 4212, and 4214. The driver responsible for passing through host DATA (4212) employs a workable signal input that generally allows the activation of communication links only when transmission from the host to the client is desired. No additional operable signal is adopted for this driver (4212) as the STB signal is formed as part of the data transmission. The inputs of the client DATA and STB receivers (4132, 4230) each have a termination impedance or resistors 4218 and 4220, respectively, arranged across them. The client control driver 4234 is used to prepare the data signal to be transmitted from the client to the host, where the input driver 4214 processes the data.

Special receivers (drivers) 4216 and 4236 are coupled or connected to the DATA line and generate or use the 125 mV voltage offset discussed earlier as part of the abort control discussed elsewhere. The offset causes the dormant line receiver to interpret the non-drive signal 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 serves as a reference ground and a signal for the power return path or client device. 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 The steps and signal levels used by the client to secure service from the host and used by the host to provide such service are shown in FIG. In FIG. 43, the first part of the signal depicted is the link shutdown packet being forwarded from the host, and the data line is then driven to a logical zero state using a high impedance bias circuit. The data is not sent by the client display, that is, 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 ends and the host drives the bias and logic circuits to zero and the logic level changes to zero, the MDDI_Stb signal line also changes to the logic zero level. 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 FIG. 43, the signal output from the client is initially set at a logical level of zero. In other words, the client output is in high impedance and the driver is disabled. When service is requested, the client enables the driver and the period during which the line is driven to the logical 1st level, that is, the specified t_serviceSend a service request to the host. Then the host is t_host-detectA certain amount of time may elapse or be required before the request is detected, after which the host responds to the link activation sequence by driving the signal to the logical 1st level. At this point, the client stops asserting the request and disables the service request driver so that the output line from the client is again at zero logic level. During this time, the MDDI_Stb signal is at the logical zero level.

The host drives the host data output at the "1" level for a period called trestart-high, after which the host drives the logical level to zero, t_restart-lowMDDI_Stb is activated for a period called, after which the first forward traffic begins with a subframe header packet and the forward traffic packet is forwarded. MDDI_Stb signal is t_restart-lowActive during the period and subsequent subframe header packets.

Tables VII and VIII show typical times of the various period lengths mentioned above, and the relationships between exemplary minimum and maximum data rates.<maths num="1"><img file="JP2010200332A_D0011.tif" /></maths>

Where Link_Data_Rate is the bit rate of a single data pair.<tables num="11"><img file="JP2010200332A_D0012.tif" /></tables><tables num="12"><img file="JP2010200332A_D0013.tif" /></tables>

Those skilled in the art will readily appreciate that the function of the individual elements shown in FIGS. 41 and 42 is well known and that the function of the element of FIG. 42 is confirmed in the timing diagram of FIG. Details about the series termination and hibernation resistors shown are omitted from Figure 41 as that information is unnecessary to explain how to perform data-strobe coding and recover the clock from it. ..

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 IX. Table IX 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"), Data0 to Data0 called ttdd- (host-output) The transition 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)}It is depicted in Figure 44, which shows the transitions from Data0 to strobe, from strobe to strobe, from strobe to Data0, from Data0 to non-Data0, from non-Data0 to non-Data0, from non-Data0 to strobe, and from strobe to non-Data0. There is.<tables num="13"><img file="JP2010200332A_D0014.tif" /></tables>

Typical MDDI timing requirements for client receiver input of the same signal transferring data over a forward link are shown in Table X. 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="14"><img file="JP2010200332A_D0015.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 XI below.<tables num="15"><img file="JP2010200332A_D0016.tif" /></tables>

C. Data-Strobe Timing Reverse Link The switching characteristics and timing relationship between the data signal and the strobe signal used to transfer data from the client driver output via the reverse link are shown in FIGS. 47 and 48. The appropriate time for a particular signal transition will be described later. FIG. 47 shows the relationship between the timing of the transferred data and the host receiver input between the leading and trailing edges of the strobe pulse. That is, the setup time for the rising or leading edge of the strobe signal, tsu-sr, and the setup time for the falling or trailing edge of the strobe signal, called tsu-sf. The typical length of time for these setup periods is a minimum of about 8 nanoseconds.

FIG. 48 shows the switching characteristics and the corresponding client output delays deployed by the reverse data timing. In FIG. 48, we can see the relationship between the timing of the data being transferred and the anterior and posterior edges of the strobe pulse that explain the induced delay. That is, the propagation delay between the rising edge or the leading edge of the strobe signal and the data (valid), tpd-sr, and the propagation delay between the data and the trailing edge or the falling edge, called tpd-sf. The typical maximum time length of these propagation delay periods is about 8 nanoseconds.

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. Cycles, CPUs found in computers 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 of. 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. A high-level diagram of the condition achieved by the signal of one embodiment is presented in the diagram of 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 "no synchronization", the interface state is changed to the "in synchronization" state 4908 if a packet with good CRC results is detected. This step in the process is named as having encountered cond1 or condition1 in FIG. On the other hand, if the CRC of any of the packets 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 encountered cond2 or condition2 in the phase diagram of FIG.

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 zero to indicate that the host sends only one subframe before the link is shut down and the MDD interface is put into hibernation or configured. May be set. In this case, after the display detects the subframe header packet, only one subframe is sent before the link transitions to the idle state, so the packet must be received immediately on the forward link. 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 can be attached to the host if the host is already transmitting a forward link data sequence. The time it takes for the display to synchronize with the forward link signal is variable depending on the subframe size and the 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.

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 display or client response display Capability Packet in order to request to answer, forward link followed by the Reverse Link Encapsulation Packet to set the bit "0" of the request flag to a value of one (1) Send or forward the subframe header packet above. 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 client 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 client use mutually compatible protocol versions. The protocol version usually remains as the first two parameters of the client feature packet so that compatibility can be determined even when elements of other protocols are incompatible or not fully understood to be compatible.

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 XII below.<tables num="16-1"><img file="JP2010200332A_D0017.tif" /></tables><tables num="16-2"><img file="JP2010200332A_D0018.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 client, client receiver, clock creation, signal time, respectively. Shown near the processing part for recording, Data0 +/- generation, cable transfer to host, and host 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 can support either basic data sampling, which is simple but operates at low speed, or advanced data sampling, which supports more complex but higher inverse data rates. Clients that support both methods are considered to have the same functionality.

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 shown graphically in FIG. 51 with signals representing MDDI_Data on the host, MDDI_Stb on the host, the forward link data clock inside the host, and the delay count. 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="JP2010200332A_D0019.tif" /></maths>

For the example shown, this would be:<maths num="3"><img file="JP2010200332A_D0020.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 FIG. 52 for an example 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="JP2010200332A_D0021.tif" /></maths>

An example showing the timing of the MDDI_Data0 and MDDI_Stb signal lines in a reverse link-encapsulated packet is shown in FIG. 52, 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 FIG. 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 with a zero host to display the round trip delay 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.

XI. Direction change and guard time As mentioned above, the turnaround 1 field in the reverse link encapsulation packet and the guard time 1 field in the round trip delay measurement packet can disable the host interface driver before the client interface driver is enabled. Specify a value for the length of time. The Turn 2 field and Guard Time 2 field provide a time value that allows the client driver to be disabled before the host driver is enabled. The guard time 1 field and guard time 2 field are usually filled with preset or preselected values of lengths that are not intended to be adjusted. Depending on the interface hardware used, these values are created using empirical data and may be adjusted to improve behavior in some examples.

Multiple factors contributed to the determination of the length of turnaround 1, which are the forward link data rate and the maximum disable time of the MDDI_Data driver in the host. The maximum host driver disable time is specified in Table XI, which shows that it takes up to about 10 seconds for the driver to disable and about 2 nsec to enable it. The minimum number of forward link clocks required for a host driver to be disabled is expressed according to the following relationships:<maths num="5"><img file="JP2010200332A_D0022.tif" /></maths>

The allowed value range for turn 1 is expressed according to the following relationships:<maths num="6"><img file="JP2010200332A_D0023.tif" /></maths>

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

Combining the two equations from the above, the term of the interface type factor cancels out, and the direction change 1 is defined as follows.<maths num="7"><img file="JP2010200332A_D0024.tif" /></maths>

For example, a 1500 Mbps Type 3 forward link would use the following turnaround 1 delay:<maths num="8"><img file="JP2010200332A_D0025.tif" /></maths>

As the round trip delay increases, the timing margin improves from the time the host is disabled to the point where the client is enabled.

Factors that determine the length of time normally used for turnaround 2 are the forward link data rate, the maximum disable time of the MDDI_Data driver in the client, and the round-trip delay of the communication link. The calculation of the time required to disable the client driver is essentially the same as the host driver described above, and is determined according to the following relationships:<maths num="9"><img file="JP2010200332A_D0026.tif" /></maths>

The permissible value range for directional change 2 is expressed as follows.<maths num="10"><img file="JP2010200332A_D0027.tif" /></maths>

For example, a 1500MB ps3 type forward link with a round trip delay of 10 forward link clocks typically uses approximately the following diversion 2 delays:<maths num="11"><img file="JP2010200332A_D0028.tif" /></maths><maths num="12"><img file="JP2010200332A_D0029.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 inputs and outputs of the MDD interface. Therefore, the calculation for the reverse rate divisor is shown below.<maths num="13"><img file="JP2010200332A_D0030.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. Delay distortion between MDDI_Stb and MDDI_Data0 deforms the duty cycle of the output clock. Data at the D input of the receiver flip-flop (RXFF) stage using flip-flops 5728, 5732 must change 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 arises 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 at the RXXOR stage, which is determined by the following relationships.<maths num="14"><img file="JP2010200332A_D0031.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="15"><img file="JP2010200332A_D0032.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 that delay 1 is the maximum and the clock output from the XOR gate occurs as early as possible according to the following relationship: Data-Delay / Strobe-Early Case It is in.<maths num="16"><img file="JP2010200332A_D0033.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="17"><img file="JP2010200332A_D0034.tif" /></maths>

The minimum bit period is<maths num="18"><img file="JP2010200332A_D0035.tif" /></maths>

Specified by.

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

t_BIT-minIt is stated as = 1.4 + 0.3 + 0.2 + 0.5 = 2.4nsec, that is, about 416Mbps.

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 slightly 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="19"><img file="JP2010200332A_D0036.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="20"><img file="JP2010200332A_D0037.tif" /></maths>

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

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

In the example shown above, the lower limit of the minimum bit period is indicated by the following relationship.

t_{BIT-min (lower-level)}= 2.1.4 + 1.5 + 0.5 + 0.1 = 4.8nsec, that is, about 208Mbps.

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.

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.). Illustrative interface pin assignments, or "pinouts," for such connectors used with Type 1 / Type 2 interfaces are listed in Table XIII and illustrated in Figure 61.<tables num="17"><img file="JP2010200332A_D0040.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 display 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.

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 color map transfer, bit block transfer, or other packet 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. Clients that receive data change from dedicated AC power to more restricted battery power, unable to transfer data quickly, cannot easily process commands, or have similar resolution or color under more limited power settings. 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 91A 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 91B.

In an application with a fixed image with a small video window, write the fixed image to both buffers (display update bit equal to "11") as shown in Figure 91C, 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.

The video stream packet contains a set of display update bits that specify the framebuffer in which the pixel data will be 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 92 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 92 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. 93 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. 94, 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 95.

However, as shown in Figure 96, 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 97. 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. Delay value table Packet Processing Delay Parameter Packets use the table lookup feature to calculate the expected delay to process a particular command within the client. The values in the table increase logarithmically to provide a very wide dynamic range of delay values. An exemplary table of delay values effective for implementing embodiments of the present invention is set forth in Table XX below, along with the corresponding exponential vs. delay values.<tables num="18"><img file="JP2010200332A_D0041.tif" /></tables>

The delay is calculated by performing a table lookup using the specified parameters as the table index. That is, the delay is equal to the Packet Processing Table (index). For example, if one of the parameters from the delay parameter list item is an 8-bit value equal to 134, then the delay is equal to PacketProcessingTable (134), which is 16 μsec. A value of 255 indicates that the command completion time cannot be calculated and the host will check the graphics busy flag in client requests and status packets, or the MCCS VCP control parameter B7h.

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

XVIII. 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 98, or using a hub, or using a combination of these techniques as shown in Figure 99. Is useful to be connected to the host.

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 (2 bytes) has a set of bit values interpreted as: Bits 1 and 0 select how the display pixel data is sent. If the bit value is "11", the data is displayed for both eyes or for both eyes, if the bit value is "10", the data is sent only to the left eye, and if the bit value is "01", the data is sent only to the right eye. For a bit value of "00" sent, the data is sent to the alternate display as specified by bits 8-11 as described below.

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 form a 4-bit unsigned integer that specifies the alternate display or display location to which the pixel data is sent. Bits 0 and 1 are set equal to "00" for the display client to interpret bits 8 to 11 as alternative display numbers. If bits 0 and 1 are not equal to "00", bits 8-11 are set to the logical zero level.

Bits 12-14 are reserved for future use and are 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. If bit 5 of the pixel data attribute field is set to logical level 1, the pixel data field will have the first transmitted pixel corresponding to the leftmost pixel and the last transmitted pixel corresponding to the rightmost pixel. Yes, contains exactly one row of pixels.

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 the stream parameter field and the stream parameter CRC field may be discarded if they are not required by the end use of the MDDI interface, 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 shall be packed, and each color map item (least significant bit of the blue component) must be byte-aligned. Figure 100 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 display 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. If a bit (eg bit 0) is set to 1, the host requests the information specified by the display using the client function packet. If the bit is set to logical zero level, the host does not need any information from the client. 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. For type 1 interfaces, the reverse data rate is equal to the reverse link data clock, and for type 2, 3 and 4 interfaces, the reverse data rates are twice, 4 times and 8 times the reverse link data clock, respectively. Equal to double.

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 number of bytes specified by the redirect 1 length parameter is allocated to allow the MDDI_Data line driver in the client to be enabled before the line driver in the host is disabled. 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 timing of enabling the client driver and disabling the host driver process is such that one or both of the MDDI_Data signals are driven to the logical zero level throughout the turnaround 1 as seen by the line receiver at the host. 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 zero state or level when there is no data to send to the host. When the MDDI_Data line is driven to zero in this embodiment, 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 number of bytes specified by the turn length parameter is allocated to enable the host MDDI_Data line driver before the client line driver is disabled. The host enables its MDDI_Data line driver during bit 0 of the first byte of diversion 2 and the client outputs its output so that they are fully disabled before the last bit of diversion 2. Disable. The timing to disable the client driver and enable the host driver process is to send the MDDI_Data signal to one or both logical zero levels through or during turn 2 as seen by the host's line receiver. Is enough to drive. The MDDI_Stb signal behaves 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 uses 2 bytes to specify 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 the initial version is now set equal to 1 and as is well known if a new version is generated. , Will change over that time. In this case, the 0 value is also a valid value. The data rate feature field (2 bytes) specifies the maximum data rate that a client can receive on each data pair on the forward link of the interface, in the form of megabytes per second (Mbps). The Interface Type feature field (1 byte) specifies the interface types supported by forward and reverse links. Setting the bit to '1' indicates that the specified interface type is supported, and setting the bit to '0' indicates that the specified interface type is not supported. Hosts and clients will support at least Type 1 on forward and reverse lines. It is not necessary to support the interface type connection range. For example, it is perfectly valid to support only type 1 and type 3 in an interface, not type 3 and type 4. It is not necessary to operate the forward and reverse links with the same interface type. However, if the link exits hibernation, both forward and reverse links will be typed until both the host and client agree, select, or otherwise approve the use of the other mode. It should start working in one mode.

The supported interfaces are, in one embodiment, bits 0, bits to select either type 2 (2 bits), type 3 (4 bits) or type 4 (8 bits) mode for the forward link, respectively. Directed by selecting 1 or bit 2 and by selecting bit 3, bit 4 or bit 5 to select either type 2, type 3 or type 4 mode in the reverse link, respectively, bits 6 and bit 7 are reserved and are usually set to 0 at this point. The Bitmap Width Height fields are each 2 bytes here, specifying the width and height of the bitmap within a pixel, respectively.

The black and white function field (1 byte) is used to specify the number of bits of resolution that can be displayed in 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 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 1. When bit 15 is set to zero, this indicates that the client can only accept Bayer pixel data in unpacked format.

The colormap function field (3 bytes) specifies the maximum number of table items present in the display's colormap table. If the display cannot use the colormap format, this value is set to zero.

The RGB function field (2 bytes) specifies the number of bits of resolution that can be displayed in RGB format. This value is equal to zero if the display 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, bits 7 to 4 define the maximum number of green bits, and bits 11 to 8 define each pixel. Defines the maximum number of red bits in. Currently, bits 14-12 are reserved for future use and are usually set to zero. Bits 14-12 are reserved for future use and are usually set to zero. Bit 15, when set to 1, indicates that the client can accept RGB pixel data in either packed or unpacked format. If bit 15 is set to the logical zero level, this indicates that the client can only accept RGB pixel data in unpacked format.

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 Client Features feature field uses 4 bytes containing a set of flags that indicate a particular feature on a supported client. A bit set to 1 indicates that the feature is supported, and a bit set to zero indicates that the feature is not supported. In one 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. 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. Bit 15 of the field can also be used to detect frame synchronization or end of video frame data.

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. 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 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 update the display image. If this bit is set to 1, then the Diplay Update Bit (bits 7 and 6 in the pixel data attribute field of the video stream packet) can be set to the value '00'. The value associated with bit 16 indicates when the client has the ability to write pixel data from a single video stream packet to all display framebuffers. If this bit is set to 1, it can be set to the Diplay Update Bit (bits 7 and 6 of the pixel data attribute field of the video stream packet) value '11'.

The value of bit 17 indicates when the client is capable of responding to the Request Specific Status Packet, the value of bit 18 indicates when the client is capable of responding to the Round Trip Delay Measurement Packet, and the value of bit 19 indicates when. It indicates when the client is capable of responding to Forward Link Skew Calibration Packets, and the value of bit 19 indicates when the client is capable of responding to VESA MCCS Virtual Control Panel (VCP) packets.

The value for bit 21 indicates when the client has the ability to interpret the Request Specific Status Packet and responds to the Valid Status Reply Packet. The client demonstrates the ability to return to an additional state in the Valid Parameter Reply List field of the Valid Status Reply List Packet as described elsewhere.

The value for bit 22 indicates whether the client has the ability to respond to Register Access Packets. Bits 9-10 and 23-31 are currently reserved for future use or other support in effect for the system designer, and are usually set equal to 0.

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 (2 bytes) contains a group of flags that indicate 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, bit positions 0, 1, 2, 3, 4, 5, 6, and 7 in one embodiment are left front channel, right front channel, left rear channel, right rear channel, front center channel, subwoofer channel, surround left. The channel and surround right channel are shown. Bits 8-14 are currently reserved for future use and are usually set to zero. In one embodiment, bit 15 is used to indicate whether the client provides support for Forward Audio Channnel Enable Packet. If this is the case, bit 15 is set to logical 1 level. However, the client has Forward Audio Channel Enable This bit is set to a logical 0 level or 0 value if the Packet does not have the ability to disable the audio channel as a result, or if the client does not support any audio function.

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 minimum subframe rate field (2 bytes) specifies the minimum subframe rate in frames per second. The minimum subframe rate keeps the client status update rate sufficient to read a particular sensor or pointing device in the client.

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.

Keyboard data format The field (1 byte here) specifies whether the keyboard is connected to the client system and the type of keyboard connected. In one embodiment, the values set by bits 6-0 are used to specify the type of keyboard connected. If the value is zero (0), the keyboard model is probably unknown. For a value of 1, the keyboard data format is considered a standard PS-2 style. Values in the range 2 to 125 are not used at this time and are used by system designers and interface founders or product developers to specify specific keyboards or input devices for the use of MDD interfaces and corresponding clients or hosts. Reserved for use by the person. A value of 126 is used to indicate that the keyboard data format is defined by the user, while a value of 127 is used to indicate that the keyboard cannot connect to this client. In addition, bit 7 can be used to indicate whether the keyboard can communicate with the client. The intended use of this bit is to indicate when the keyboard can communicate with clients using wireless links. If bits 6-0 indicate that the keyboard cannot connect to the client, bit 7 will be set to level 0. Therefore, in one embodiment, when the value of bit 7 is 0, the keyboard and the client cannot communicate, while when the value of bit 7 is 1, the keyboard and the client confirm that they can communicate with each other.

The pointing device data format field (1 byte here) specifies whether the pointing device is connected to the client system and the type of pointing device to be connected. In one embodiment, the value set by bit 6 is used to specify the type of pointing device to be connected. If the value is zero (0), the model of the pointing device is probably unknown. For a value of 1, the pointing device data format is considered to be the standard PS-2 style. Values in the range 2 to 125 are not used at this time and are intended for system designers and interface founders or products to specify specific pointing devices or input devices for use with MDD interfaces and corresponding clients or hosts. Reserved for developer use. A value of 126 is used to indicate. Pointing device Used to indicate that the data format is defined by the user, while a value of 127 is pointing. The device is used to indicate that it cannot connect to this client. In addition, bit 7 can be used to indicate whether the pointing device can communicate with the client. The intended use of this bit is to indicate when the keyboard can communicate with the client using a wireless link. If bits 6-0 indicate that the pointing device cannot connect to the client, bit 7 will be set to zero level. Therefore, in one embodiment, if the value of bit 7 is 0, the pointing device and the client cannot communicate, while if the value of bit 7 is 1, the pointing device and the client can communicate with each other. Confirm.

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-2 bytes that form the 16-bit value contain the product's EISA 3-character ID packed into three 5-bit characters in a manner similar to the VESA EDID specification. The character'A' is represented as a 00001 binary. The character'Z'is represented as a 11010 binary. And all letters between'A'and'Z' are represented as consecutive binary values corresponding to the sequence of alphabets between'A' and'Z'. The most significant bit of the Mfr Name field is unused and should always be 0. Example; The manufacturer represented by the string "XYZ" would have an Mfr Name value of 0x633a. If this field is not supported by the client, it will be set to zero.

Product Code-2 bytes This contains the product code assigned by the display manufacturer. If this field is not supported by the client, it will be set to zero.

Reserved 4-2 bytes This contains 16-bit unsigned integers reserved for future use. All bits in this field should be set to zero. The purpose of this field is to align all subsequent 2-byte fields to 16-bit word addresses, and to align 4-byte fields to 32-bit word addresses.

Serial Number-4 Bytes This identifies the serial number of the display in the form of numbers. If this field is not supported by the client, it will be set to zero.

Week of Manufacture-1 Byte This identifies the week of manufacture of the display. If this is supported by the client, this value will be in the range 1-53. If this is not supported by the client, this value is set to zero.

Year of Manufacture-1 Byte This defines the year of manufacture of the display. This value is an offset from 1990. Years in the range 1991 to 2245 can be represented by this field. Example: 2003 corresponds to a production value of 13 years. If this field is not supported by the client, it will be set to zero.

CRC-2 bytes This contains the 16-bit CRC 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 the change in display 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.

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 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 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 video data format descriptor field (2 bytes) specifies the format of the pixel area fill value. The format is the same as the same field in the video stream packet. The pixel area fill value field (4 bytes) contains the pixel values that are filled into the window specified by the fields described above. The format of this pixel is specified in the video data format descriptor field.

J. Bitmap pattern fill packet 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 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 from the left edge of the identified window to be filled for the pixel data pattern. The value to be specified is less than the value in the pattern width field. The vertical pattern offset field (2 bytes) identifies the vertical offset from the top edge of the identified window to be filled for the pixel data pattern. The value specified is less than the value in the pattern height field.

The 2-byte video data format descriptor field specifies the format of the Pixel Area Fill Value. Figure 11 shows how the video data format descriptor is encoded.

The parameter CRC field (2 bytes) 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 must be byte aligned. The fill pattern data is transmitted line by line at a time. The pattern pixel data CRC field (2 bytes) contains 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. For interface handoff request packets The interface type field (1 byte) specifies the new interface type to use. The value of this field specifies the interface type as follows: If the value of bit 7 is equal to "0", the type handoff request is for forward links, and if it is equal to "1", the type handoff request is for reverse links. Bits 6 to 3 are reserved for future use and are usually set to zero. Bits 2 to 0 are used to define the interface type used, a value of 1 is a handoff to type 1 mode, a value of 2 is a handoff to type 2 mode, and a value of 3 is to type 3 mode. Handoff, and a value of 4 means handoff to type 4 mode. Values "0" and 5 to 7 are reserved for future designation of alternative modes or combinations of modes.

M. Interface type acknowledgment packet The interface type field (1 byte) has a value that confirms the new interface type to use. The value of this field specifies the interface type as follows: If bit 7 is equal to "0", the type handoff request is for forward links, and instead if it is equal to "1", the type handoff request is for reverse links. Bit positions 6 to 3 are currently reserved for use in designating other handoff types as desired and are usually set to zero. However, bit positions 2 to 0 are used to define an interface type for use with a negative acknowledgment or a value of "0" to indicate that the requested handoff cannot be performed, "1", " The values 2 , 3 and 4 indicate handoffs to type 1 mode, type 2 mode, type 3 mode and type 4 mode, respectively. Values 5 to 7 are reserved for use with alternative designations of modes as desired.

N. Execution type handoff packet The 1-byte interface type field indicates the new interface type to use. The value present in this field specifies the interface type by first using the value bit 7 to determine if the type handoff is for forward or reverse links. A value of "0" indicates that the type handoff request is for a forward link, and a value of "1" indicates a reverse link. Bits 6 to 3 are reserved for future use and are usually set to a value of zero. However, bits 2 to 0 are used to define the interface type used, and the values 1, 2, 3 and 4 are handoffs to type 1 mode, type 2 mode, type 3 mode, and type 4 mode, respectively. Specifies the use of. Use of values 0 and 5 to 7 for these bits is reserved for future use.

O. 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.

P. 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.

Q. 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.

R. 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.

S. 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 hClient ID 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, 0x0, 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 guard time 2, and the client also drives 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.

T. 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.

The calibration data sequence field contains a 512-byte data sequence that toggles the MDDI_Data signal for each data period. 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 display, the display 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 I-0xaa, oxaa ... or 0x55, 0x55 ... Type II-0xcc, 0xcc ... or 0x33,0x33 ... Type III-0xf0,0xf0 ... or 0x0f, 0xf0 ... Type IV-0xff, 0x00,0xff, 0x00 ... 0r0x00,0xff, 0x00,0xff 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.