Generating and implementing a signal protocol and interface for higher data rates

Generate and implement a signal protocol and a higher data rate interface

The present invention relates to a digital signal protocol and method for transmitting or transmitting signals at a high data rate between a host device and a client audio/visual presentation device. More specifically, the present invention relates to a technology that uses a low-power, high-data-rate transmission mechanism to transmit multimedia and other types of digital signals from a wireless device to a microdisplay unit or other presentation device.

In the past few years, computer, electronic game related products and various video technologies (such as DVD and high-definition VCR) have been greatly improved, which can provide end users of such devices with higher and higher resolution still, video, and on-demand The presentation of video and graphic images can even include certain types of text. These advancements in turn require the use of higher-resolution electronic viewing devices, such as high-quality video monitors, HDTV monitors, or dedicated image projection components. Combining such visual images with high-quality or high-quality audio data (for example, when using CD-type audio reproduction, DVD, and other devices that also have associated audio signal output) is used to create more practical and rich content for end users Or a real multimedia experience. In addition, highly mobile, high-quality sound systems and music transmission mechanisms for presenting audio only to end users have been developed, such as MP3 players.

In a typical video presentation situation, the rate of transmitting video data using the current technology can usually only be called slow or medium speed, which is on the level of one to ten thousand bits per second. This data is then buffered or stored in a transient or long-term memory device for delayed (later) playback on the desired viewing device. For example, you can "pass through" or use the Internet to reside on a computer (with a modem or Internet The program on the network connection device transmits the image in order to receive or send data that can be used to present the image digitally. The same transmission can occur using a wireless device, such as a portable computer equipped with a wireless modem or a wireless Personal Data Assistant (PDA) or a wireless phone.

After receiving the data, the data is stored in the local memory components, circuits or devices, such as RAM or flash memory, including external storage devices for playback. Depending on the amount of data and the resolution of the image, playback can start sooner or be presented with a longer-term delay. That is, in some instances, the image is rendered as a very small or low-resolution image that does not require a lot of data or uses a certain type of buffer to provide a certain degree of real-time playback, so that after a small delay, some materials are presented while more materials are transmitted. If there is no interruption in the transmission link, once the presentation starts, the transmission is appropriately transparent to the end user of the viewing device.

The data used to create still images or motion video is usually compressed using one of several well-known technologies, such as Joint Photographic Experts Group (JPEG), Motion Picture Experts Group (MPEG) and media , Technology developed by other well-known standards organizations or companies in the computer and communications industries to accelerate data transmission on communications links. This makes it possible to use a smaller number of bits to transmit a given amount of information to transmit images or data faster.

Once the data is transmitted to the "regional (local)" device, such as a computer or other receiving device, it will be decompressed (or played by a special decoding player) and decoded (if necessary) according to the corresponding available presentation resolution and control components ) And prepare the final information for proper presentation. For example, the screen resolution of a typical computer video resolution represented by X by Y pixels usually ranges from as low as 480×640 pixels. Plain to 600×800, 1024×1024, although various other resolutions are usually possible according to expectations or needs.

The content of the image, the ability of a given video controller to process the image according to certain predetermined color levels or color depths (bits per pixel used to generate colors) and intensity, and any additional additional information bits used will also affect Image presentation. For example, normal computer rendering is expected to represent various colors (shadows and chroma) with approximately 8 to 32 or more bits per pixel, although other values may also be encountered.

It can be seen from the above values that in the range from the lowest to the highest typical resolution and depth, a given screen image will need to transmit 2.45 megabits (Mb) to approximately 33.55 Mb of data, respectively. When viewing video or action images at a rate of 30 frames per second, the amount of data required is approximately 73.7 to 1,006 megabits of data per second (Mbps), or approximately 9.21 to 125.75 megabytes per second (MBps). In addition, it may be necessary to present audio data combined with images, such as for multimedia presentation, or as separate high-resolution audio presentation, such as CD-quality music. Additional signals for processing interactive commands, controls or signals can also be used. Each of these options adds more data to be transmitted. In any case, when high-quality or high-resolution image data and high-quality audio information or data signals need to be transmitted to end users to create a rich experience, the presentation components and configuration are the source or host device that provides this type of data Requires high data transfer rate between time.

Modern serial interfaces can routinely process data rates of approximately 115 kilobytes (KBps) or 920 kilobits (Kbps) per second. Other interfaces (such as USB serial interface) can handle data transmission at a rate as high as 12 MBps, while dedicated high-speed transmission (e.g. If the Institute of Electrical and Electronics Engineers (IEEE) 1394 standard is used, data can be transmitted at a rate of 100 to 400 MBps. Unfortunately, these rates cannot solve the above-mentioned expected high data rates. It is expected that they will be used in future wireless data devices and provide high-resolution, rich content, and output signals for driving portable video displays or audio devices. service. In addition, these interfaces require the use of a large number of hosts or systems and client software to operate. Its software protocol stack also creates an undesirable amount of additional information, especially when using mobile wireless devices or phone applications. Such devices have strict limits on memory and power consumption, as well as reduced computing power. In addition, some of these interfaces use huge cables, which are too bulky and do not meet the needs of highly aesthetically oriented mobile applications, and complex connectors, which increase cost or simply consume too much power.

There are other known interfaces, such as an analog video graphics adapter (VGA), a digital video interactive (DVI) or a gigabit video interface (GVIF) interface. Before these interfaces, the two were side-by-side interfaces, which processed data at a higher transmission rate, but also used bulky cables and consumed a large amount of power in the order of several watts. These features are not suitable for use with portable consumer electronic devices. Even the third interface consumes too much power and uses expensive or bulky connectors.

For some of the above-mentioned interfaces, as well as other extremely high-speed data systems/protocols or transmission mechanisms associated with data transmission of fixedly installed computer equipment, there is another major disadvantage. Coping with the expected data transfer rate also requires a lot of Power and/or high current level operation. This greatly reduces the effectiveness of such technologies for highly mobile consumer-oriented products.

Usually, in order to use alternative solutions (such as optical fiber-type connections and transmission components) to cope with such data transmission rates, many additional converters and components are also required, which will increase complexity and cost, which is unsuitable for actual commercial consumer-oriented products. . In addition to the generally more expensive nature of optical systems, its power requirements and complexity also hinder the widespread use of lightweight, low-power, and portable applications.

What is lacking in the portable or mobile application industry is the technology that provides high-quality presentation experience for highly mobile end users, whether it is based on audio, video or multimedia. That is, when using portable computers, wireless phones, PDAs, or other highly mobile communication devices or equipment, the currently used video and audio presentation systems or devices cannot deliver output at the desired high-quality level. Generally, the lack of perceptual quality is the result of an unobtainable high data rate required to transmit high-quality presentation data. Therefore, a new transmission mechanism is needed to increase the amount of data output between a host device that provides data and a display device or component on the client side that presents output to end users.

The applicant has proposed such new transmission mechanisms in U.S. Patent Application Nos. 10/020,520 and 10/236,657, both of which are titled "Generate and implement a communication protocol and interface for higher data rate signal transmission." Assigned to the assignee of the present invention and incorporated herein by reference. The technologies described in these applications can greatly improve the transmission rate of large amounts of data in high-speed data signals. However, the demand for ever-increasing data rates (especially related to video presentation) continues to grow. Even if there are other continuous developments in data signal technology, we still need to strive for faster The transfer rate. Therefore, there is a continuous need to develop new or improved transmission mechanisms required to increase the data output between host and client devices.

The specific embodiments of the present invention solve the above-mentioned and other shortcomings in the present technology. Among them, new protocols and data transmission mechanisms have been developed to transmit data at a high data rate between the host device and the receiving client device.

The specific embodiment of the present invention is directed to a mobile data digital interface (MDDI) for transmitting digital data between a host device and a client device at a high rate via a communication path. The communication path uses a plurality of or a series of Linked together to form a packet structure used to communicate a set of pre-selected digital control and presentation data communication protocols between the host and the client device. The physical layer of the host or user-side link controller uses the signal communication protocol or the link layer. At least one link controller residing in the host device is coupled to the client device through a communication path or link, and configured to generate, send and receive packets forming a communication protocol and form one or more digital presentation data Type of data packet. This interface provides two-way information transmission between the host and the client.

In another aspect of the specific embodiment of the present invention, at least one client link controller or client receiver is placed in the client device and coupled to the host device through a communication path or link. The client link controller is also configured to generate, send, and receive packets forming a communication protocol and form digital presentation data into one or more types of data packets. Generally, the host or link controller uses a state machine to process data packets used for command or certain types of signal preparation and query processing, but a slower general-purpose processor can be used to process the data packets. Management data and some less complex packets used in the communication protocol. The host controller includes one or more differential line drivers, and the user-side receiver includes one or more differential line receivers coupled to the communication path.

Packets are grouped in a media frame (which is transmitted between the host and the client device and has a predefined fixed length of a predetermined number of packets, and the packets have different variable lengths). Each packet includes a packet length field, one or more packet data fields, and a cyclic redundancy check field. Transmit or locate the subframe header packet at the beginning of other packet transmissions from the host link controller. The communication protocol uses one or more video data stream type packets and audio data stream type packets to respectively transmit video type data and audio type data from the host to the client on the forward link for presentation to the user of the client device. The communication protocol uses one or more reverse link encapsulation type packets to transmit data from the client device to the host link controller.

The host link controller generates filler type packets to occupy the forward link transmission period without data. The communication protocol uses multiple other packets to transmit video information. Such packets include color mapping, bit block transmission, bit mapping area filling, bit mapping pattern filling, and transparent color actuation type packets. The communication protocol uses user-defined stream type packets to transmit interface-user-defined data. The communication protocol uses keyboard data and pointing device data type packets to transmit data arriving or coming from the user input device associated with the client device. The communication protocol uses link closed type packets to terminate data transmission in either direction of the communication path.

The communication path usually includes or uses a cable with a series of four or more conductors and a shield. In some specific embodiments, the link controller includes USB Data interface and cable use USB type interface together with other conductors. In addition, printed wires or flexible conductors can be used as needed.

The host link controller requests the client device to send display capability information so as to determine the data type and data rate that the client can handle through the interface. The client link controller uses at least one display capability type packet to convey the display or presentation capability to the host link controller. The communication protocol uses multiple transmission modes. Each mode allows a different maximum number of data bits to be transmitted in parallel in a given time period. Each mode can be selected by negotiation between the host and the client link controller. These transmission modes can be dynamically adjusted during data transmission, and the same modes need not be used on the reverse link as they are on the forward link.

In other aspects of some embodiments of the present invention, the host device includes a wireless communication device, such as a wireless phone, a wireless PDA, or a portable computer in which a wireless modem is placed. Typical client devices include portable video displays, such as micro display devices and/or portable audio presentation systems. In addition, the host can use storage components or components to store presentation data or multimedia data to be transmitted to the user of the client device for presentation.

I. Overview

The general purpose of the present invention is to provide a Mobile Display Digital Interface (MDDI), as described below, which generates or provides a low-cost, low-power consumption transmission mechanism that uses a "serial" type data link or The channel provides high or extremely high-speed data transmission on a short-range communication link between the host device and the display device. The mechanism itself can be combined to connect Display elements (or display devices) such as wearable microdisplays (goggles or projectors) can be implemented with miniature connectors and thin flexible cables that are particularly useful for portable computers, wireless communication devices, or entertainment devices.

One advantage of the specific embodiments of the present invention is that the technology provided for data transmission is low in complexity, low in cost, highly reliable, adaptable to the use environment, and very robust, while remaining very flexible.

The present invention can be used in various situations to transfer a large amount of data, which is usually used in audio, video or multimedia applications from a host or source device that generates or stores such data, and transmits or transmits to a client display or presentation device at a high rate. . A typical application (described below) is to transmit data from a portable computer or wireless phone or modem to a visual display device, such as a small video screen or a wearable micro-display appliance, such as goggles containing a small projection lens and a screen Or the form of a helmet, etc., or transfer from the host in this type of component to the client device. That is, it is transmitted from the processor to the internal screen or other presentation components.

The characteristics or attributes of MDDI make it independent of specific display technology. This is a highly flexible mechanism used to transmit data at a high rate without considering the internal structure of the data or the functional aspects implemented by the data or commands. This allows the timing of the transmitted data packet to be adjusted to suit the characteristics of a specific display device, or for the unique display needs of some devices, or to meet the combined audio and video requirements of some AV systems. This interface is extremely tolerant to display components or client devices, as long as the selected protocol is followed. In addition, the aggregate serial link data or data rate can vary in several quantitative levels, which allows the communication system or host device designer to optimize cost, power requirements, client device complexity, and display device update rate.

The data interface is mainly used to transmit large amounts of high-speed data over "wired" signal links or small cables. However, some applications can also use wireless links, including optical-based links, provided that they are configured to use the same packet and data structure developed for the interface protocol, and can maintain the desired level with sufficiently low power consumption or complexity Transmission level in order to maintain practicality.

II. Environment

A typical application can be seen in FIGS. 1A and 1B, where a portable or laptop computer 100 and a wireless phone or PDA device 102 communicate data with the display devices 104 and 106 and the audio reproduction system 108 and 112, respectively. In addition, FIG. 1A shows possible connections to a larger display or screen 114 or image projector 116, which are only shown in one drawing for clarity, but are also connected to the wireless device 102. The wireless device can receive data now or have previously stored a certain amount of multimedia type data in a memory element or device for later presentation, so that the end user of the wireless device can view and/or listen to it. Since a typical wireless device is used for voice and simple text communication most of the time, it has a small display screen and a simple audio system (speaker) for conveying information to the user of the device 102.

The computer 100 has a much larger screen, but the external sound system is still insufficient, and other multimedia presentation devices, such as a high-definition TV or movie screen, are still lacking. The computer 100 is used for illustrative purposes, and the present invention can also be used in conjunction with other types of processors, interactive video games or consumer electronic devices. The computer 100 may adopt (but is not limited or limited to) a wireless modem or other built-in devices for wireless communication, or may be connected to such devices using cables or wireless links as needed.

This reduces the usefulness or experience pleasure of the presentation of more complex or "rich" data. Therefore, the industry is developing other mechanisms and devices to present information to end users and provide a minimum level of desired pleasant or positive experience.

As mentioned above, several types of display devices for presenting information to end users of the device 100 have been or are currently being developed. For example, one or more companies have developed several sets of wearable goggles that project images in front of the eyes of the device user in order to present a visual display. When correctly positioned, this type of device effectively "projects" a visual image, which, as viewed by the user's eyes, is much larger than the component that provides visual output. In other words, the extremely small projection element allows the user's eyes to "see" an image that is much larger than the possible images such as a typical LCD screen. The use of larger visual screen images also allows the use of high resolution, which is much higher than the resolution possible with more limited LCD screen displays. Other display devices may include, but are not limited to, small LCD screens or various flat panel display elements, projection lenses, and display drivers for projecting images on the surface.

There may also be additional components connected to or associated with the wireless device 102 or computer 100 for presenting output to another user, or connected to another device, which transmits the signal elsewhere or stores it. For example, the data can be stored in a flash memory in an optical form, such as a writable CD medium, or stored on a magnetic medium, such as a tape recorder or similar device, for later use.

In addition, many wireless devices and computers now have built-in MP3 music decoding capabilities, as well as other advanced sound decoders and systems. Generally speaking, Portable computers use CD and DVD playback capabilities, and some of them have small dedicated flash memory readers to receive pre-recorded audio files. The problem caused by such capabilities is that the prospect of music files is highly increased and the experience of rich functions, but the decoding and playback procedures must be compatible. The same is true for digital video files.

To assist in sound reproduction, an external speaker 114 is shown in FIG. 1a, which may also be accompanied by additional components, such as a subwoofer or "surround sound" speakers for front and rear sound projection. At the same time, the figure indicates that the speaker or earphone 108 is built in the supporting frame or mechanism of the micro-display device 106 of FIG. 1b. As is well known, other audio or sound reproduction components can be used, including power amplification or sound shaping devices.

In any case, as described above, when high-quality or high-resolution image data and high-quality audio information or data signals need to be transmitted from the data source to the end user via one or more communication links 110, a high data rate is required. That is, the transmission link 110 is obviously a potential bottleneck in the data communication described earlier, and will limit the system performance, because the current transmission mechanism cannot achieve the generally expected high data rate. For example, as described above, for higher image resolution, such as 1024 by 1024 pixels, which has a color depth of 24 to 32 bits per pixel and a data rate of 30 fps, the data rate can approach a rate exceeding 755 Mbps or higher . In addition, such images can be presented as part of a multimedia presentation, which includes audio data and potentially additional signals for processing interactive games or communications, or various commands, controls, or signals, which further improve quality or data and data rates.

It's also obvious that almost no cables or interconnects are needed to establish a data link. Connected, which means that mobile devices associated with displays are easy to use and are likely to be adopted by a larger user base. This is especially true when multiple devices are used together to create a complete audio-video experience, especially when the quality levels of displays and audio output devices increase.

Unfortunately, the higher data rate exceeds the currently available data transmission technology. A technology that needs to transmit data at a higher rate used to present the data transmission link or communication path between the component and the data source, which provides always (lower) power, light weight, and a simple and economical cable structure as much as possible . Applicants have developed new technologies or methods and devices to achieve these and other purposes, enabling a large number of mobile, portable or even fixed-location devices to transmit data to desired displays, microdisplays or audio transmission components at extremely high data rates, and at the same time Keep the required low power consumption and complexity.

III. High-speed digital data interface system architecture

In order to establish and effectively utilize new device interfaces, signal protocols and system architectures have been developed that use low-power signals to provide extremely high data transmission rates. The agreement is based on the packet and common frame structure, or is linked together to form a structure used to convey a pre-selected set of data or data types and the command or operation structure applied to the interface.

A. Overview

The devices connected or communicating via the MDDI link are called the host and the client, and the client is usually a certain type of display device. According to the activation of the host, the data from the host to the display travels in the forward direction (referred to as forward flow or link), and the data from the display to the host travels in the reverse direction (reverse flow or link). This aspect is illustrated in the basic configuration shown in Figure 2. In Figure 2, a two-way communication channel is used 206 (shown in the figure as including a forward link 208 and a reverse link 210) connects the host 202 to the client 204. However, the channels are formed by a common set of conductors, and the data transmission is effectively switched between forward or reverse link operation.

As described elsewhere, the host includes one of several types of devices that can benefit from the use of the present invention. For example, the host 202 may be a handheld portable computer, a laptop computer or a similar mobile computing device, which may be a PDA, a paging device, or one of many wireless phones or modems. Alternatively, the host 202 may be a portable entertainment or presentation device, such as a portable DVD or CD player or game device. At the same time, the client 204 may include various devices for presenting information to end users. For example, micro-displays incorporating goggles or glasses, projection devices built in hats or helmets, small screens or even full-information components built in vehicles (such as in windows or windshields), or various speakers, earphones Or a sound system used to present high-quality sound or music. However, those skilled in the art will easily realize that the present invention is not limited to these devices. There are many other suggested devices on the market that aim to provide end users with high-quality images and sounds (in terms of storage and transmission or In terms of playback presentation). The present invention can be used to increase the data output between various devices in order to cope with the high data rate required to achieve the desired user experience.

B. Interface type

The MDD interface is used to handle five or more slightly different physical types of interfaces established in the communications and computer industries. Here it is simply labeled as Type I, Type II, Type III, Type IV and Type U.

The I-type interface is configured as a 6-wire (conductor) interface, which is suitable for mobile or wireless phones, PDAs, e-books, electronic games and portable media players. For example, CD players or MP3 players, and devices based on similar types of electronic consumer technology. The U-shaped interface is configured as an 8-wire (conductor) interface, which is more suitable for laptop computers, notebook computers, desktop personal computers and similar devices or applications. It does not need to update the display quickly and does not have a built-in MDDI Link controller. This interface type can also be distinguished by an additional dual-wire Universal Serial Bus (USB) interface, which is extremely useful for dealing with existing operating systems or software support on most personal computers. The U-shaped interface can also be used in USB-only mode, where the display simply has only a USB connector, which connects to a standard USB port on a computer or similar device, such as a consumer electronic device equipped with this port, such as a digital camera or video player Wait.

Type II, Type III, and Type IV interfaces are suitable for high-performance displays or devices, and use larger and more complex cables with additional twisted-pair conductors to provide proper shielding and low-loss transmission for data signals.

The signals transmitted by the I-type interface can include display, audio, control, and limited signaling information, which are usually used in devices that do not require high-resolution, full-rate video data. This type of interface is mainly used in devices such as mobile wireless devices, where there is usually no USB host available for connection and signal transmission in the device. In this configuration, the mobile device is an MDDI host device and acts as a "master device" to control the communication link from the host, which usually sends display data to the client (forward flow or link).

In this interface, the host sends special commands or packet types to the client (so that it can control the bus (link) within a specific duration and send data to the host as reverse packets) to activate the host to receive data from Client (anti Communication data to traffic or link). Figure 3 illustrates this situation, in which a type of packet called an encapsulated packet (described below) is used to cope with the transmission of reverse packets on the transmission link, thereby establishing a reverse link. The time interval allocated for the host to poll the display for data is predetermined by the host and is based on the requirements of each specified application. If the USB port cannot be used for the transmission of information or data from the client, this type of half-duplex two-way data transmission is particularly advantageous.

The U-shaped interface transmits signals, which is very suitable for laptop and desktop computer applications. A large number of motherboards or other hardware and operating system software generally support the USB interface. The use of the newly added USB interface allows the use of the "plug and play" function and easy application configuration. Including USB, it also provides universal two-way command flow, status, audio data, etc., and can use twisted pair cables to transmit video and audio data intended for client devices at low power and high speed. Other wires can be used to transmit power, as described below. The specific embodiment of the present invention using the USB interface enables high-speed transmission on a set of conductors, and at the same time mainly implements signaling and control through a USB connection (which can be turned off when not in use and consumes almost no power).

The USB interface is a standard widely used in modems and personal computer equipment. The details of the USB interface and its operation are well known in this technology and will not be explained here. For the USB interface, the communication between the host and the display complies with the Universal Serial Bus Specification Revision 2.0. In applications using a U-shaped interface, where USB is the main transmission channel and may be the voice return channel, the host can selectively poll the client through the MDDI serial data signal.

A high-performance display capable of reaching HDTV type or similar high-resolution requires a data stream at a rate of approximately 1.5 Gbps in order to support full-motion video. Type II The interface supports high data rates by sending 2 bits in parallel, the Type III interface sends 4 bits in parallel, and the Type IV interface sends 8 bits in parallel. The protocol used by MDDI allows each type I, type II, type III, or type IV host to communicate with any type I, type II, type III, or type IV client or display by negotiating the highest data rate available. The capabilities or available functions that can be referred to as the least capable devices are used to set link performance. Generally speaking, even for systems that can use Type II, Type III, or Type IV interfaces for both the host and the client, both of them start to operate as Type I interfaces. The host then determines the capabilities of the target client or display, and negotiates to hand over to the type II, type III or type IV mode or reconfiguration operation according to the specific application.

The host generally can use the appropriate link layer protocol (described further below), and can reduce or reconfigure the operation to a slower mode at any time to save power, or increase to a faster mode to support higher-speed transmission. For example, it is used for higher resolution display content. For example, when the display system is switched from a power source (such as a battery) to an AC power source, or when the display media source is switched to a lower or higher resolution format, the host can change the display mode, or a combination of these or other conditions or events may be visible It is the basis for changing the display or data transmission mode.

The system can also use one mode to convey data in one direction, and use another mode to convey data in the other direction. For example, the IV-type interface mode can be used to transmit data to display at a high rate, while the I-type or U-type mode is used when transmitting data from a peripheral device (such as a keyboard or pointing device) to the host device.

C. Physical interface structure

Figures 4 and 5 show the device used to establish communication between the host and the client device Or the general configuration of the link controller. In FIGS. 4 and 5, the MDDI link controllers 402 and 502 are shown installed in the host device 202, and the MDDI link controllers 404 and 504 are shown installed in the client device 204. As before, the host 202 is connected to the client 204 using a bidirectional communication channel 406 including a series of conductors. As described below, a single circuit design can be used to manufacture both the host and the client link controller as an integrated circuit, which can be set, adjusted or programmed to act as a host controller (driver) or a client controller (receiver) ) Response. Due to the large-scale manufacturing of a single circuit device, the manufacturing cost of this solution is lower.

In FIG. 4, it is shown that the USB host device 408 and the USB client device 410 are also used to implement the U-shaped interface version of MDDI. The circuits and devices used to implement such functions are well known in the art, and will not be described in further detail herein.

In FIG. 5, the MDDI link controller 502 is shown installed in the host device 202', and the MDDI link controller 504 is shown installed in the client device 204'. As before, a two-way communication channel 506 including a series of conductors is used to connect the host 202' to the client 204'. As mentioned above, a single circuit design can be used to manufacture the host and client link controllers.

4 and 5 also illustrate the signals transmitted between the host and the user end (such as the display device) via the MDDI link or the physical conductor used. As shown in Figures 4 and 5, the main path or mechanism for transmitting data through MDDI uses data signals marked MDDI_Data0+/- and MDDI_Stb+/-. Each of these signals is a low-voltage data signal transmitted on the differential conductor pair of the cable. For each bit transmitted on the interface, there is only one transition on the MDDI_Data0 pair or the MDDI_Stb pair. This is a transmission mechanism based on voltage rather than current, so static The state current consumption is close to zero. The host drives the MDDI_Stb signal to the user-side display.

Although data can flow in the forward and reverse directions through the MDDI_Data pair, that is, it is a two-way transmission path, the host is the master control device or controller of the data link. Operate the MDDI_Data0 and MDDI_Stb signal paths in differential mode to maximize noise immunity. The clock rate transmitted by the host determines the data rate of the signals on these lines, which can vary from about 1 kbps to a maximum of 400 Mbps or higher.

Type II interface includes an additional data pair or conductor or path other than Type I, called MDDI_Data1+/-. The Type III interface includes two additional data pairs or signal paths in addition to the Type II interface, called MDDI_Data2+/- and MDDL_Data3+/-. The Type IV interface includes four more data pairs or signal paths other than the Type III interface, which are called MDDI_data4+/-, MDDI_Data5+/-, MDDI_Data6+/-, and MDDI_Data7+/-. In each of the above-mentioned interface configurations, the host can use wire pairs or signals designated as MDDI_Pwr and MDDI_Gnd to transmit power to the user terminal or the display.

Generally, the transmission type that can only be used for U-shaped configuration is MDDI USB connection or signal path. The MDDI USB link includes a secondary path for communication between the host and the client display. In some applications, it is more advantageous to transmit certain information between the host and the client at a relatively low data rate. Using the USB transmission link enables devices without an MDDI link controller (which has a USB host or limited host capabilities) to communicate with an MDDI compatible client or display equipped with a U-shaped interface. Examples of information that can be usefully transferred to the display via the USB interface are: static bit mapping, digital audio stream, pointing device data, keyboard Data and control and status information. The main MDDI high-speed serial data path can also be used to implement the functionality supported through the USB interface. Although the data defined above (see the packet below) can be transmitted via a USB-type interface, the requirements for linking data in a packet back-to-back manner cannot be applied to this USB interface, and packets that support MDDI-type delivery cannot be used.

Table I shows a summary of the signals transmitted between the host and the user end (display) via the MDDI link according to the interface type.

<tables><img file="TWI374635B_D0001.tif" /></tables>

Generally, the nominal length of the cable used to implement the above structure and operation is 1.5 meters, and it includes three twisted-pair conductors, and each conductor is a multi-wire 30 AWG wire. The foil shielding is wrapped around or otherwise formed over the three twisted pairs as an additional drain wire. The twisted pair and the shielded drain conductor terminate in the display connector, where the shield is connected to the shield for the display (user terminal), and an insulating layer covers the entire cable, which is well known in the art. The wire pairs are: MDDI_Gnd and MDDI_Pwr; MDDI_Stb+ and MDDI_Stb-; MDDI_Data0+ and MDDI_Data0-; MDDI_Data1+ and MDDI_Data1-; and so on. The nominal cable diameter is 3.0 mm, its nominal impedance is 85 ohms ± 10%, and the nominal DC resistance per 1000 feet is 110 ohms Hm. The nominal signal propagation speed should be 0.66c, and its maximum delay through the cable is less than about 8.0 nanoseconds.

D. Data type and rate

In order to achieve a useful interface for the entire user experience and applications, the Mobile Digital Data Interface (MDDI) and control information together provide various displays and display information, audio converters, keyboards, pointing devices and many other input devices (which can be combined with mobile Display device integration or cooperation) and its combination support. The MDD interface is designed to be able to use a minimum number of cables or conductors to cope with various possible types of data flows between the host and the user in the forward or reverse link direction. Support synchronous data stream and asynchronous data stream (update). There may be many combinations of data types, as long as the aggregate data rate is less than or equal to the maximum expected MDDI link rate. Such combinations may include (but are not limited to) the items listed in Tables II and III below.

<tables><img file="TWI374635B_D0002.tif" /></tables>

<tables><img file="TWI374635B_D0003.tif" /></tables>

The interface is not fixed, but extensible, so that it can support the transmission of various information "types", including user-defined data for future system flexibility. Examples of specific data to be dealt with are: full or partial screen bit-mapped fields or full-action video in the form of compressed video; low-rate static bit-mapped to save power and reduce implementation costs; PCM or compressed audio at various resolutions or rates Data; pointer device location and selection, and user-definable data for capabilities that need to be defined. Such data can also be transmitted with control or status information to detect device capabilities or set operating parameters.

The present invention advances technologies for data transmission, including (but not limited to): watching movies (video display and audio), using personal computers with limited personal viewing (graphics display, sometimes combined with video and audio), in PC , Console or personal device (motion graphics display or composite video and audio) playing video games, Internet "surfing", using video phone (two-way low-rate video and audio) form of device, camera for still digital photos , Or portable digital cameras for shooting digital video images, and productivity enhancement or entertainment use for mobile phones, smart phones or PDAs.

The following mobile data interface describes the provision of a large amount of AV type data via a communication or transmission link that is generally configured as a wired or cable type link. However, it can be easily understood that the signal structure, protocol, timing, or transmission mechanism can be adjusted to provide a link in the form of optical or wireless media, as long as it can maintain the desired data transmission level.

The MDD interface signal uses a concept known as Common Frame (CF) for basic signal protocol or structure. The idea of using a common frame It provides synchronization pulses for simultaneous synchronization of data streams. The display device can use this common frame rate as a time reference. The low CF rate increases the channel efficiency by reducing the additional information used to send the sub-frame header. On the other hand, a high CF rate reduces latency and provides a smaller flexible data buffer for audio samples. The CF rate of the interface of the present invention can be dynamically programmed, and can be set to one of many values suitable for the synchronous data stream used in a specific application. That is, select the CF value according to the needs to best suit a given display device and host configuration.

Table IV shows the number of bytes generally required for each common frame, which can be adjusted or programmable for the most likely synchronous data stream used by an application, such as a head-mounted micro-display.

<tables><img file="TWI374635B_D0004.tif" /></tables>

Using a simple programmable MIN counter structure, it is easy to obtain the count of the number of bit components in each common frame. For example, the counting of 26-2/3 bytes per CF is implemented by transmitting 27 bytes of 2 frames that each follow a frame of 26 bytes. A smaller CF rate can be selected to generate integer bytes per CF. However, generally speaking, the implementation of a simple M/N counter in hardware should require an integrated circuit chip or an integrated circuit chip or an integrated circuit chip that requires less area than a large audio sample FIFO buffer. The area within the electronic module (used to implement part or all of the present invention).

An exemplary application that illustrates the influence of different data transmission rates and data types is the Karaoke system. In Karaoke, system users sing along with music video programs. The lyrics of the song are displayed at the bottom of the screen so that the user knows the lyrics and probably knows the timing of the song. This application requires a video display with infrequent graphics updates, and a mix of user voice and stereo audio streams.

If the common frame rate is assumed to be 300 Hz, each CF consists of the following: 92,160-byte video content and 588-byte audio content (based on 147 16-bit Sample, stereo), and an average of 29.67 (26-2/3) bytes of voice are sent back from the microphone to the mobile Karaoke machine. Send asynchronous packets between the host and the display. This includes graphics data up to 768 bytes (a quarter of the screen height), and miscellaneous control and status commands less than about 200 bytes (several) bytes.

Table V shows how to distribute data in the common frame used in the Karaoke example. The total rate used is chosen to be approximately 225 Mbps. The slightly higher rate of 226 Mbps can transmit about 400 bytes of another data per sub-frame, which makes it possible to use occasional control and status messages.

<tables><img file="TWI374635B_D0005.tif" /></tables>

III. High-speed digital data interface system architecture

E. Link layer

The data transmitted by the high-speed serial data signal using the MDD interface is composed of successively linked time multiplexed packet streams. Even if the sending device has no data to transmit, the MDDI link controller will generally automatically transmit filler packets to maintain the packet flow. The use of a simple packet structure ensures reliable synchronization timing for video and audio signals or data streams.

The packet group is included in a signal element or structure called a sub-frame, and the sub-frame group is included in a signal element or structure called a media frame. The sub-frame includes one or more packets, depending on its individual size and data transmission usage, while the media frame includes one or more sub-frames. The largest sub-frame provided by the protocol used in the present invention is 2³²-1 or 4,294,967,295 byte level, so the maximum media frame size becomes 2¹⁶-1 or 65,535 frame level.

The special header packet includes a unique identifier, which appears at the beginning of each sub-frame, as described below. The identifier is also used to obtain the frame timing at the client device when the communication between the host and the client is initiated. The link timing acquisition will be described in detail below.

Generally, when a full-motion video is displayed, the display screen is updated once for each media frame. The display frame rate is the same as the media frame rate. The link protocol supports full-motion video on the entire display, or only full-motion video content in a small area surrounded by static images, depending on the desired application. In some low-power mobile applications, such as viewing web pages or emails, the display screen may only need to be updated occasionally. In these cases, it is advantageous to send a single Sub-frame, and then close or disable the link to minimize power consumption. The interface also supports effects such as stereo vision and handles graphics primitives.

The sub-frame is used to activate the transmission of high-priority packets on a periodic basis. This allows simultaneous simultaneous data streams to coexist with a minimum number of data buffers. This is an advantage provided by the present invention to the display program, which enables multiple data streams (high-speed communication of video, audio, control, status, pointing device data, etc.) to substantially share a common channel. It uses relatively few signals to transmit information. It also enables display-technology-specific actions, such as horizontal sync pulses and blank intervals for CRT monitors.

F. Link Controller

The MDDI link controller shown in Figures 4 and 5 is manufactured or combined into a fully digital implementation, except for the differential line receiver for receiving MDDI data and strobe signals. However, even the differential line driver and receiver can be implemented in the same digital integrated circuit with the link controller. No analog function or phase lock loop (PLL) is required to implement the hardware used in the link controller. The host and client link controllers include very similar functions, except for the display interface that includes the state machine for link synchronization. Therefore, the practical advantage provided by the present invention is that a single controller design or circuit that can be configured as a host or a client can be established, which can reduce the overall manufacturing cost for the link controller.

IV. Interface link protocol

A. Frame structure

FIG. 6 illustrates the signal protocol or frame structure used to implement packet transmission forward link communication. As shown in Figure 6, the composition of information or digital data is known as a packet Components. Multiple packets are then grouped together to form a so-called "sub-frame", and multiple sub-frames are then grouped together to form a "media" frame. In order to control the formation of the frame and the transmission of the sub-frames, each sub-frame starts with a special predefined packet called a Sub-frame Header Packet (SHP).

The host device selects the data rate needed for a given transmission. The host device can dynamically change this rate according to the maximum transmission capacity of the host or the data that the host extracts from the source, and the maximum capacity of the display or other devices to which the data is transmitted.

A receiving client device designed or capable of working with MDDI or the signal protocol of the present invention can be queried by the host to determine the maximum or current maximum data transmission rate that can be used, or can use a preset slower rate and available data Types and supported functions. This information can be transmitted using the Display Capability Packet (DCP) described further below. This client display device can use the pre-selected minimum data rate or an interface within the minimum data rate range to transmit data or communicate with other devices, and the host will use the data rate within this range to perform queries to determine the full capabilities of the client device .

Other status information that defines the nature of bit mapping and the rate capability of the display's video frame can be transmitted to the host in a status packet so that the host can configure the interface to be as efficient or optimal as possible, or to meet the needs within any system constraints.

When there are no (more) data packets to be transmitted in the current subframe, or when the host cannot transmit at a rate sufficient to match the data transmission rate selected for the forward link, the host transmits a filler packet. Since each sub-frame is sub-frame The frame header packet starts, so the end of the previous sub-frame includes the packet that just fills the previous sub-frame (most likely a filler packet). In the case that the data carrying packet itself lacks space, the filler packet is most likely to be the last packet in the subframe, or before the end of the next previous subframe and before the header packet of a subframe. The task of controlling operations in the host device is to ensure that for each packet to be sent in a sub-frame, there is enough free space in the sub-frame. At the same time, once the host device starts the transmission of the data packet, the host must be able to successfully complete the packet of that size in the frame without causing a data under-load condition.

In one aspect of the present invention, the sub-frame transmission has two modes. One mode is a periodic sub-frame mode for sending real-time video and audio streams. In this mode, the sub-frame length is defined as non-zero. The second mode is an asynchronous or aperiodic mode, in which the frame is only used when new information is available to provide bit-mapped data to the display device. This mode is defined by setting the sub-frame length to zero in the sub-frame header packet. When using periodic mode, sub-frame packet reception can start when the display is synchronized to the forward link frame structure. This corresponds to the "synchronizing" state defined according to the state diagram described below with reference to FIG. 49 or FIG. 63. In the asynchronous aperiodic sub-frame mode, the reception starts after receiving the first sub-frame header packet.

B. Overall packet structure

The following describes the packet format or structure used to formulate the sending protocol implemented by the present invention. Note that the interface can be expanded and additional packet structures can be added as needed. According to the function of the packet in the interface, that is, the command or data transmitted, the packet is marked or divided into different "packet types". Therefore, each packet type Represents the predefined packet structure used for a given packet (which is used to process transmitted packets and data). It can be easily understood that the packet can have a preselected length or a variable or dynamically changeable length depending on its individual function. Packets can also have different names, although they still perform the same function, as happens when the protocol is changed in the process of acceptance as a standard. The byte or byte value used in various packets is configured as a multi-bit (8 or 16-bit) unsigned integer. Table VI shows a summary of the packets used with its "type" name in order of type. It also indicates the direction in which the packet transmission is considered valid, and whether it is used in a U-shaped interface.

<tables><img file="TWI374635B_D0006.tif" /></tables>

The packets have a common basic structure or overall minimum field group, which includes a packet length field, a packet type field, a data byte field (or multiple), and a CRC field, which are illustrated in FIG. 7. As shown in FIG. 7, the packet length field includes information in the form of multiple bits or byte values, which specify the total number of bits in the packet or the length between the packet length field and the CRC field. A specific embodiment , The packet length field includes an unsigned integer with a width of 16 bits or 2 bytes, which specifies the packet length. The packet type field is another multi-bit field that specifies the type of information included in the packet. In an exemplary embodiment, this is an 8-bit or 1-byte wide value in the form of an 8-bit unsigned integer, which specifies such data type as display capability, handover, video or audio stream, status Wait.

The third field is a data byte field, which includes bits or data transmitted or transmitted as part of the packet between the host and the client device. The data format is clearly defined for each packet type according to the specific type of the transmitted data, which can be divided into a series of additional fields, each field having its own format requirements. That is, each packet type will have a format defined for this part or field. The last field is the CRC field, which includes the result of the 16-bit cyclic redundancy check calculated on the data byte, packet type, and packet length fields to confirm the integrity of the information in the packet. In other words, the calculation is performed on the entire packet except for the CRC field itself. The client generally keeps the total count of the CRC errors detected, and reports this count back to the host with a display request and status packet (see below).

In the packet transmission process, the field sent first starts with the least significant bit (Least Significant Bit; LSB) and ends with the most significant bit (Most Significant Bit; MSB) sent last. Parameters with a length greater than one byte are first sent using the least significant byte. The resulting bit transfer pattern and the bit transfer pattern used for the parameters longer than 8 bits and the shorter parameter of the LSB first are sent first. same. The data on the MDDI_Data0 signal path and the interface in any mode (Type I, Type II, Type III or Type IV) The bit "0" of the byte sent on the upper side is aligned.

When processing the data for the display, the data for the pixel array is first sent in columns and then in rows, as in the traditional implementation in electronic technology. In other words, all pixels appearing in the same column of the bitmap are sent in the order that the leftmost pixel is sent first and the rightmost pixel is sent last. After sending the rightmost pixel in the column, the next pixel in the sequence is the leftmost pixel in the next column. For most displays, the pixel columns are generally sent in order from top to bottom, although other configurations can be adapted as needed. In addition, in processing bit mapping, the traditional method (described below) defines the reference point by marking the upper left corner of the bit mapping as a position or offset "0,0". The X and Y coordinates used to define or determine the position in the bitmap increase in value as they approach the right and bottom of the bitmap, respectively. The first column and the first row start with a zero index value.

C. Packet definition

1. Sub-frame header packet

The sub-frame header packet is the first packet of each sub-frame, and has a basic structure as shown in FIG. 8. As shown in FIG. 8, this type of packet structure generally has fields in the following order: packet length, packet type, unique characters, sub frame length, protocol version, sub frame count, and media frame count fields. This type of packet is generally recognized as a type 255 (0xff hexadecimal) packet and uses a preselected fixed length of 17 bytes.

When the packet type field uses a 1-byte value, the unique character field uses a 3-byte value. The 4-byte groups of these two fields are combined to form a 32-bit unique character with good autocorrelation. In an exemplary embodiment, the actual unique character is 0x005a3bff, and the lower 8 bits are first used as the packet type Send, and then send the most significant 24 bits.

The sub-frame length field includes 4 bytes of information, which specifies the number of bytes of each sub-frame. The length of this field can be set equal to zero to indicate that the host will only send one sub-frame before closing the link to enter the idle state. The value in this field can be dynamically changed "on the fly" when changing from one sub-frame to the next. This capability can be used to make minor timing adjustments in the synchronization pulse used to cope with the synchronization data stream. If the CRC of the sub-frame header packet is invalid, the link controller should use the sub-frame length of the previously known good sub-frame header packet to estimate the length of the current sub-frame.

The protocol version field includes 2 bytes, which specifies the protocol version used by the host. Set the protocol version field to "0" to specify the first or current version of the protocol used. Over time, this value will change when a new version is created. The sub-frame count field includes 2 bytes, which specifies a serial number indicating the number of sub-frames that have been sent since the start of the media frame. The first subframe of the media frame has a zero subframe count. The last sub-frame of the media frame has a value of n-1, where n is the number of sub-frames of each media frame. It should be noted that if the length of the sub-frame is set equal to zero (indicating an aperiodic sub-frame), the sub-frame count must also be set equal to zero.

The media frame count field includes 3 bytes, which designates a serial number indicating the number of media frames that have been sent since the beginning of the media item or data currently being transmitted. The first media frame of the media item has a zero media frame count. The media frame count is only incremented before the first subframe of each media frame, and the maximum media frame count is used up (for example, the number of media frames 2²⁴-1=16,777,215) and then wrap around to zero. The count value of the media frame can generally be What time is reset by the host to meet the needs of terminal applications.

2. Filler packet

A filler packet is a packet that has no other information available for transmission to or from the client device when it is transmitted on the forward or reverse link. It is recommended that filler packets have a minimum length to provide maximum flexibility when other packets need to be transmitted. At the end of the subframe or reverse link encapsulated packet (see below), the link controller sets the size of the filler packet to fill the remaining space and maintain the integrity of the packet.

Figure 9 shows the format and content of the filler packet. As shown in Figure 9, this type of packet structure has packet length, packet type, filler byte and CRC fields. This type of packet is generally identified as type 0, which is indicated in the 1-byte type field. The bit or byte in the filler byte field includes a variable number of all-zero bit values, so that the filler packet is at a desired length. The minimum filler packet does not include bytes in this field. That is, the packet is only composed of packet length, packet type and CRC, and uses a preselected fixed length of 3 bytes.

3. Video stream packet

The video stream packet carries video data in order to update the area of the display device, which is usually rectangular. The size of this area can be as small as a single pixel or as large as the entire display. An almost unlimited number of data streams can be displayed at the same time, which is limited by system resources, because all the content needed to display the data stream is included in the video stream packet. Figure 10 shows the format of a video stream packet (video data format descriptor). As shown in Figure 10, this type of packet structure has packet length (2 bytes), packet type, video data descriptor, display attributes, X left edge, Y top Edge, X right edge, Y bottom edge, X and Y starting point, pixel count, parameter CRC, pixel data and CRC field. This type of packet is generally recognized as type 1, which is indicated in the 1-byte type field.

The above-mentioned common frame concept is an effective way to minimize the size of the audio buffer and reduce the latency. However, for video data, it may be necessary to extend the pixels of one video frame to multiple video stream packets in the media frame. It is also very likely that the pixels in a single video stream packet will not accurately correspond to the perfect rectangular window on the display. For an exemplary video frame rate of 30 frames per second, there are 300 subframes per second, which results in 10 subframes per media frame. If there are 480 columns of pixels in each frame, each video stream packet in each sub-frame will include 48 columns of pixels. In other cases, the video stream packet may not include an integer number of pixel rows. This is true for other video frame sizes, where the number of sub-frames of each media frame is not evenly divided into the number of rows of each video frame (also known as video lines). Each video stream packet generally must include an integer number of pixels, even though it may not include an integer number of pixel rows. This becomes important if each pixel has more than one byte, or if it is in the packaging format shown in Figure 12.

Figures 11a to 11d show the format and content used to implement the operation of the exemplary video data descriptor field. In FIGS. 11a to 11d, the video data format descriptor field includes 2 bytes in the form of a 16-bit unsigned integer, which specifies the format of each pixel in the pixel data of this data stream in this packet. Different video stream packets may use different pixel data formats, that is, different values are used in the video data format descriptor. Similarly, the data stream (display area) can change its data format during operation. The video data format descriptor definition is used in this packet Pixel format, but it does not mean that the constant format will continue to be used throughout the lifetime of a particular video stream.

Figures 11a to 11d illustrate how to encode video data format descriptors. As used in these drawings and this specific embodiment, when the bit [15:13] is equal to "000", as shown in Figure 11a, the video data consists of a monochrome pixel array, where the video data format descriptor Bits 3 to 0 of the character define the number of bits per pixel. In this case, bits 11 to 4 are set to zero. When the bit [15:13] is alternatively equal to "001", as shown in FIG. 11b, the video data is composed of an array of color pixels of each designated color through the color map. In this case, bits 5 to 0 of the video data format descriptor character define the number of bits per pixel, and bits 11 to 6 are set equal to zero. When bit [15:13] is alternatively equal to "010", as shown in Figure 11c, the video data consists of a color pixel array, where bits 11 to 8 define the number of bits for each red pixel. 7 to 4 define the number of bits for each green pixel, and bits 3 to 0 define the number of bits for each blue pixel. In this case, the total number of bits per pixel is used for the sum of the number of red, green, and blue bits.

However, when the bit [15:13] is alternatively equal to "011", as shown in Figure 11d, the video data consists of a 4:2:2 format video data array with luminance and chrominance information, and the middle position Elements 11 to 8 define the number of bits for each luminance (Y) pixel, bits 7 to 4 define the number of bits for each Cr component, and bits 3 to 0 define the number of bits for each Cb component. The total number of bits per pixel is the sum of the number of red, green, and blue bits. The Cr and Cb components are transmitted at half the rate of Y. In addition, the video sample in the pixel data part of this packet is organized as follows: Y_n, Cr_n, Cb_n, Y_n+1, Y_n+2, Cr_n+2, Cb_n+2, Y_n+3,..., of which Cr_nAnd Cb_nWith Y_nAnd Y_n+1Associated, and Cr_n+2And Cb_n+2With Y_n+2And Y_n+3Correlation, and so on. If there are an odd number of pixels in the column (X right edge to X left edge + 1) of this data stream, the Cb value corresponding to the last pixel in each column will be followed by the Y value of the first pixel in the next column.

For all four formats shown in the figure, bit 12 designated as "P" specifies whether to pack a sample or byte of pixel data to align the pixel data. The "0" value in this field indicates that each pixel in the pixel data field and each color in each pixel are aligned with the boundary of the MDD interface byte in bytes. The value of "1" indicates that each pixel in the pixel data and each color in each pixel are packed according to the previous pixels or colors in the pixels that have not left unused bits.

The first pixel in the first video stream packet of the media frame for a specific display window will enter the upper left corner of the data stream window defined by the X left edge and the Y top edge, and the next pixel received is placed in the same row The next pixel position, and so on. In this first packet of the media frame, the X start value is usually equal to the left edge of X, and the Y start value is usually equal to the top edge of Y. In subsequent packets corresponding to the same screen window, the X and Y start values are usually set at the pixel positions in the screen window, which usually follow the last pixel transmitted in the video stream packet sent in the previous subframe.

4. Audio stream packet

The audio stream packet carries audio data, which is played through the audio system of the display or used in an independent audio presentation device. Different audio data streams can be allocated to the separate channels in the sound system, such as: front left, front right, center, rear left, and rear right, depending on the type of audio system used. Provides a complete complement of sound channels for headphones that include enhanced spatial-sound signal processing. Figure 13 Description The format of the audio stream packet. As shown in Figure 13, this type of packet structure has the fields of packet length, packet type, audio channel ID, audio sample count, bits and packaging per sample, audio sample rate, parameter CRC, digital audio data, and audio data CRC fields . In a specific embodiment, this type of packet is generally identified as a type 2 packet.

The bit and packing field of each sample includes 1 byte in the form of an 8-bit unsigned integer, which specifies the packing format of the audio data. The generally used format is bits 4 to 0 to define the number of bits for each PCM audio sample. Bit 5 then specifies whether the digital audio data sample is packaged. Figure 14 illustrates the difference between packaging and byte alignment audio samples. The "0" value indicates that each PCM audio sample in the digital audio data field is aligned with the MDDI interface byte boundary, and the "1" value indicates that each consecutive PCM audio sample is packed according to the previous audio sample . This bit is only valid when the value defined by bits 4 to 0 (the number of bits per PCM audio sample) is not a multiple of eight. Bits 7 to 6 are reserved for future use and are generally set to a value of zero.

5. Keep data stream packets

In a specific embodiment, according to the needs of various applications encountered, packet types 3 to 55 are reserved for data stream packets used in future versions or changes of the packet protocol. Similarly, compared with other technologies, this part makes the MDD interface more flexible and more useful for constantly changing technologies and system designs.

6. User-defined data stream packet

The eight data stream types known as types 56 to 63 are reserved for dedicated applications, which can be defined by the equipment manufacturer for use in conjunction with the MDDI link. It is known as a user-defined data stream packet. Video stream packet delivery video Information in order to update (or not) the rectangular area of the display. The definition of data stream parameters and the data used for these packet types are left to the specific equipment manufacturers seeking their use. Figure 15 illustrates the format of a user-defined data stream packet. As shown in Figure 15, this type of packet structure has a packet length (2 bytes), packet type, data stream ID number, data stream parameters, parameter CRC, data stream data, and data stream data CRC fields.

7. Color mapping packet

The color mapping packet specifies the content of the color mapping lookup table used to provide colors for the display. Some applications may require color mapping that is larger than the amount of data that can be sent in a single packet. In these cases, multiple color-mapped packets can be transmitted, and each packet has a different color-mapped subset by using the following offset and length fields. Figure 16 illustrates the format of a color-mapped packet. As shown in Figure 16, this type of packet structure has packet length, packet type, color mapping data size, color mapping offset, parameter CRC, color mapping data, and data CRC fields. This type of packet is generally recognized as a type 64 packet.

8. Reverse link encapsulation packet

In an exemplary embodiment, a reverse link encapsulation packet is used to transmit data in the reverse direction. Transmit the forward link packet and change or turn to MDDI link operation (transmission direction) in the middle of the packet, so that the packet can be transmitted in the reverse direction. Figure 17 illustrates the format of the reverse link encapsulation packet. As shown in Figure 17, this type of packet structure has two fields: Packet Length, Packet Type, Reverse Link Flag, Turn Length, Reference CRC, Turn-Around 1, Reverse Data Packet, and Turn Around. This type of packet is generally recognized as a type 65 packet.

MDDI link controller uses a special method when transmitting reverse link encapsulation packets action. The MDD interface has a strobe signal that is always driven by the host. For each bit of the reverse link encapsulation packet and the reverse data packet portion, the host behaves as if it is sending zeros. During the two-turn time and the time allocated for the reverse data packet, the host toggles the MDDI_Strobe signal on each bit boundary (this is the same behavior as if sending all zero data). The host disables its MDDI data signal line driver during the time period specified by the turn 1, and the user terminal reactivates its line driver in the drive re-activation field after the time period specified by the turn 2 field. The display reads the turning length parameter and immediately drives the data signal to the host after turning to the last bit in the 1 field. The display uses the packet length and turn-around length parameters to know the length of time it can use to transmit the packet to the host. When the client has no data to send to the host, it can send a filler packet or drive the data line to a zero state. If the data line is driven to zero, the host interprets this as a packet with zero length (invalid length), and the host no longer accepts packets from the client during the current reverse link encapsulation packet duration.

The user-side display drives the MDDI data line to the zero level during at least one reverse link clock cycle before the start of the turn 2 field. This keeps the data line in a certain state during the turnaround 2 time period. If the client has no more packets to send, the client can even disable the data line after driving it to the zero level, because the sleep bias resistor (specified separately) switches the data line during the remaining time in the reverse data packet field Keep it at zero level.

The display request and the reverse link request field of the status packet can be used to notify the host of the number of bytes required for the display in the reverse link encapsulation packet to send data back to the host. The host tries to encapsulate the packet in the reverse link Allocate at least this number of bytes to grant the request. The host can transmit multiple reverse link encapsulated packets in the sub-frame. The display can transmit display request and status packets at almost any time, and the host interprets the reverse link request parameter as the total number of bytes requested in a sub-frame.

9. Display Capability Packet

The host needs to know the capabilities of the display (client) with which it is communicating in order to configure the host-to-display link in a generally best or desired way. It is recommended that the display send the display capability packet to the host after obtaining the forward link synchronization. When the host uses the reverse link to encapsulate the reverse link flag request in the packet, the transmission of this packet is deemed necessary. Figure 18 illustrates the format of the Display Capability Packet. As shown in Figure 18, this type of packet structure has packet length, packet type, protocol version, minimum protocol version, bit mapping width, bit mapping height, monochrome capability, color mapping capability, RGB capability, Y Cr Cb capability , Display function capability, data rate capability, frame rate capability, audio buffer depth, audio stream capability, audio rate capability, minimum sub-frame rate and CRC field. In an exemplary embodiment, this type of packet is generally identified as a 66 type packet.

10. Keyboard data packet

The keyboard data packet is used to send keyboard data from the client device to the host. The wireless (or wired) keyboard can be used in combination with various displays or audio devices, including (but not limited to) head-mounted video displays/audio presentation devices. The keyboard data packet forwards the keyboard data received from several known keyboard devices to the host. This packet can also be used to send data to the keyboard on the forward link. Figure 19 shows the format of the keyboard data packet, which includes the variable from or for the keyboard Information about the number of bytes. As shown in Figure 19, this type of packet structure has packet length, packet type, keyboard data and CRC fields. Here, this type of packet is generally identified as a type 67 packet.

11. Pointer device data packet

The pointing device data packet is used to send position information from the wireless mouse or other pointing devices from the display to the host. You can also use this packet to send data to the pointing device on the forward link. Figure 20 shows an exemplary format of a pointing device data packet, which includes a variable number of bytes of information from or for the pointing device. As shown in Figure 20, this type of packet structure has packet length, packet type, indicator device data and CRC fields. In an exemplary embodiment, this type of packet is generally recognized as a type 68 packet in the 1-byte type field.

12. Link closed packet

The link close packet is sent from the host to the client display to indicate that the MDDI data and strobe will be closed and enter a low power consumption "sleep" state. After the static bitmap is transmitted from the mobile communication device to the display, or when there is temporarily no additional information to be transmitted from the host to the client, this packet can be used to close the link and save power. When the host transmits the packet again, normal operation resumes. The first packet sent after sleep is the sub-frame header packet. Figure 21 illustrates the format of the Display Status Packet. As shown in Figure 21, this type of packet structure has packet length, packet type and CRC fields. In a specific embodiment, this type of packet is generally recognized as a type 69 packet in the 1-byte type field, and uses a preselected fixed length of 3 bytes.

In the low-power sleep state, disable the MDDI_Data driver to high impedance In the state, a high impedance bias network (which can be overdriven by the display) is used to pull the MDDI_Data signal to a logic zero state. The strobe signal used by the interface is set to a logic zero level in the sleep state to minimize power consumption. Both the host and the client can make the MDDI link "wake up" from the dormant state. As explained elsewhere in this document, this is a key advancement and advantage of the present invention.

13. Display request and status packet

The host needs a small amount of information from the display so that the host-to-display link can be configured in a generally optimal way. It is recommended that each sub-frame display send a display status packet to the host. The display should transmit this packet as the first packet in the reverse link encapsulation packet to ensure that it is reliably delivered to the host. Figure 22 illustrates the format of the Display Status Packet. As shown in Figure 22, this type of packet structure has packet length, packet type, reverse link request, CRC error count, and CRC fields. This type of packet is generally recognized as a type 70 packet in the 1-byte type field, and uses a pre-selected fixed length of 8 bytes.

The reverse link request field can be used to notify the host of the number of bytes required for the display to send data back to the host in the reverse link encapsulation packet. The host should attempt to grant the request by allocating at least this number of bytes in the reverse link encapsulation packet. The host can transmit multiple reverse link encapsulation packets in the sub-frame to accommodate data. The client can send display request and status packets at any time, and the host interprets the reverse link request parameter as the total number of bytes requested in a subframe. The following will show additional detailed instructions and specific examples of how reverse link data is sent back to the host.

14. Bit block transmission packet

The bit block transmission packet provides a way to scroll the display area in any direction. Displays with this capability will report the capability in bit 0 of the display capability indicator of the display capability packet. Figure 23 shows the format of a bit block transmission packet. As shown in Figure 23, this type of packet structure has packet length, packet type, upper left X value, upper left Y value, window width, window height, window X movement, window Y movement and CRC fields. This type of packet is generally recognized as a 71-type packet and uses a preselected fixed length of 15 bytes.

These fields are used to specify the coordinate X and Y values of the upper left corner of the window to be moved, the width and height of the window to be moved, and the number of pixels that the window needs to move in the horizontal and vertical directions, respectively. The positive values used for the last two fields move the window to the right and down, and negative values cause it to move to the left and up, respectively.

15. Fill the packet with bit map area

The bitmap area fill packet provides a way to easily initialize the display area to a single color. Displays with this capability will report the capability in bit 1 of the display capability indicator field of the display capability package. Figure 24 shows the format of the bitmap area padding packet. As shown in Figure 24, this type of packet structure has packet length, packet type, upper left X value, upper left Y value, window width, window height, data format descriptor, pixel area filling value and CRC field. This type of packet is generally recognized as a type 72 packet in the 1-byte type field, and uses a preselected fixed length of 17 bytes.

16. Bit-mapped pattern fill packet

The bit-mapped pattern fill packet provides a way to easily initialize the display area to a pre-selected pattern. Displays with this capability will report the capability in bit 2 of the display capability indicator of the display capability packet. Fill map The upper left corner of the case is aligned with the upper left corner of the window to be filled. If the window to be filled is wider or higher than the filling pattern, the pattern can be repeated many times horizontally or vertically to fill the window. If necessary, cut off the right or bottom of the last repeated pattern. If the window is smaller than the filling pattern, the right or bottom of the filling pattern can be cut off to fit the window.

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

17. Communication link data channel packet

The communication link data channel packet provides a method for a display (such as a PDA) with high-end computing capabilities to communicate with a wireless transceiver (such as a mobile phone or a wireless data port device). In this case, the MDDI link is used as a traditional high-speed interface between a communication device and a computing device with a mobile display, where the packet transmits data at the data link layer of the operating system of the device. For example, if a web browser, email client or the entire PDA is built in a mobile display, this packet can be used. Displays with this capability will report the capability in bit 3 of the display capability indicator of the display capability packet.

Figure 26 shows the format of a communication link data channel packet. As shown in Figure 26, this type of packet structure has fields for packet length, packet type, parameter CRC, communication link data, and communication data CRC. This type of packet is generally recognized as a type 74 packet in the type field.

18. Interface type handover request packet

The interface type handover request packet allows the host to request the client or display to transfer from the current or current mode to Type I (serial), Type II (2-bit parallel), Type III (4-bit parallel) or Type IV (8-bit Yuan juxtaposition) mode. Before the host requests a specific mode, it should check bits 6 and 7 of the display capability indicator field of the display capability packet to confirm that the display can operate in the desired mode. Figure 27 shows the format of the interface type handover request packet. As shown in Figure 27, this type of packet structure has packet length, packet type, interface type, and CRC fields. This type of packet is generally recognized as a 75-type packet and uses a preselected fixed length of 4 bytes.

19. Interface type confirmation packet

The display sends the interface type confirmation packet to confirm the receipt of the interface type handover packet. The requested mode, namely Type I (serial), Type II (2-bit parallel), Type III (4-bit parallel), or Type IV (8-bit parallel) mode, is sent back as a parameter in this packet Host. Figure 28 shows the format of the interface type confirmation packet. As shown in Figure 28, this type of packet structure has packet length, packet type, interface type and CRC fields. This type of packet is generally recognized as a 76-type packet, and uses a preselected fixed length of 4 bytes.

20. Execution type handover packet

The execution type handover packet is a method used by the host to instruct the display to hand over to the mode specified by the packet. This is the same mode as the request and confirmer of the previous interface type handover request packet and interface type confirmation packet. After sending this packet, the host and display should switch to a consensus mode. The display may lose and regain link synchronization during the mode change. Figure 29 shows Shows the format of the execution type handover packet. As shown in Figure 29, this type of packet structure has packet length, packet type, packet type and CRC fields. This type of packet is generally recognized as a 77-type packet in the 1-byte type field, and uses a pre-selected fixed length of 4 bytes.

21. Forward audio channel activation packet

This packet allows the host to activate or deactivate the audio channel in the display. This ability is very useful. It enables the display (user terminal) to turn off the audio amplifier or similar circuit components when the host is silent, in order to save power. This is obviously more difficult to implement if it only implies the presence or absence of the use of audio data streams as an indicator. The default state when the display system is turned on is that all audio channels are activated. Figure 30 shows the format of the forward audio channel activation packet. As shown in Figure 30, this type of packet structure has packet length, packet type, audio channel activation mask, and CRC fields. This type of packet is generally recognized as a type 78 packet in the 1-byte type field, and uses a preselected fixed length of 4 bytes.

22. Reverse audio sample rate packet

This packet enables the host to activate or deactivate the reverse link audio channel and set the audio data sample rate of this data stream. The host selects the effective sample rate defined in the display capability packet. If the host selects an invalid sample rate, the display will not send an audio data stream to the host. The host can disable the reverse link audio stream by setting the sample rate to 255. The default state taken when the system is initially powered on or connected is that the reverse link audio stream is disabled. Figure 31 shows the format of the reverse audio sample rate packet. As shown in Figure 31, this type of packet structure has packet length, packet type, audio sample rate and CRC fields. This type of packet is generally recognized as a 79 type packet, and uses a 4-byte pre-selection fixed length.

23. Digital content protection additional information package

This packet allows the host and display to exchange messages related to the digital content protection method used. Currently, two types of content protection are considered, namely Digital Transmission Content Protection (DTCP) or High-bandwidth Digital Content Protection System (HDCP), and there are specific reservations for future alternative protection schemes. space. The method used is specified by the content protection type parameter in this packet. Figure 32 shows the format of the digital content protection additional information packet. As shown in Figure 32, this type of packet structure has packet length, packet type, content protection type, content protection additional information message and CRC fields. This type of packet is generally recognized as a type 80 packet.

24. Transparent color actuation packet

The transparent color activation package is used to specify which colors in the display are transparent and activate or deactivate the use of transparent colors for displaying images. Displays with this capability will report the capability in bit 4 of the display capability indicator field of the display capability package. When a pixel with a value for a transparent color is written into the bitmap, the color will not change from the previous value. Figure 33 shows the format of a transparent color activation packet. As shown in Figure 33, this type of packet structure has packet length, packet type, transparent color activation, data format descriptor, transparent pixel value, and CRC fields. This type of packet is generally recognized as a type 81 packet in the 1-byte type field, and uses a preselected fixed length of 10 bytes.

25. Round trip delay measurement packet

The round-trip delay measurement packet is used to measure the distance from the host to the user (display) The propagation delay plus the delay from the client (display) to the host. This measurement inherently includes the delay and interconnect subsystems that exist within the line driver and receiver. This measurement is used to set the steering delay and reverse link rate divisor parameters in the reverse link encapsulated packet outlined above. This packet is most useful when the MDDI link is running at the maximum speed expected by the specific application. The MDDI_Stb signal behaves like transmitting all zero data during the following fields: all zeros, two guard time and measurement period. This causes MDDI_Stb to toggle at half the data rate so that it can be used as a periodic clock in the display during the measurement period.

Figure 34 shows the format of a round-trip delay measurement packet. As shown in Figure 34, this type of packet structure has packet length, packet type, parameter CRC, all zeros, guard time 1, measurement period, guard time 2 and driver reactivation fields. This type of packet is generally recognized as a type 82 packet, and uses a preselected fixed length of 533 bits.

Figure 35 illustrates the timing of events that occur during the round-trip delay measurement packet. In Figure 35, the host transmits a round-trip delay measurement packet, which is displayed by the presence of the parameter CRC and the strobe alignment field and the following all zeros and guard time 1 fields. The delay 3502 occurs before the packet reaches the display device or processing circuit on the user side. When the display receives the packet, it sends the 0xff, 0xff, and 0x0 patterns as accurately as possible at the beginning of the measurement period determined by the display. From the perspective of the host, the actual time at which the display starts to send this sequence is delayed from the beginning of the measurement period. This amount of delay is essentially the time it takes for the packet to propagate through the line driver and receiver and interconnect subsystem. The propagation of the pattern from the display back to the host causes the same amount of delay 3504.

In order to accurately determine the round-trip delay time of the signal passing through the user terminal, the main The machine counts the number of bit time periods that occurred after the start of the measurement period until the start of the sequence of 0xff, 0xff, and 0x0 is detected when it arrives. This information is used to determine the amount of time for the round-trip signal to pass from the host to the client and back again. Therefore, about half of this delay is due to the delay established by a path of the signal arriving at the user end.

After the display transmits the last bit of the 0xff, 0xff, and 0x0 patterns, it immediately disables its line driver. Guard time 2 allows the display line driver to have time to fully reach the high impedance state before the host sends the packet length of the next packet. The sleep pull-up and pull-down resistors (see Figure 42) ensure that the MDDI_Data signal remains at a valid low level during the interval when the host and display both disable the line driver.

26. Forward link skew calibration packet

The forward link skew calibration packet allows the user terminal or the display itself to calibrate the difference in the propagation delay of the MDDI_Data signal with respect to the MDDI_Stb signal. Without delayed skew compensation, the maximum data rate is generally limited to solving the worst-case scenario of such delays. Generally speaking, this packet is only sent when the forward link data rate is configured to be about 50 Mbps or lower. After sending this packet to calibrate the display, the data rate can gradually rise to above 50 Mbps. If the data rate is set too high in the skew calibration procedure, the display may be synchronized with the bit cycle replacement command, which can turn off the delayed skew compensation setting in multiple bit times, resulting in incorrect data clocks. The interface of the highest data rate type or the largest possible interface type is selected before sending the forward link skew calibration packet to calibrate all existing data bits.

Figure 56 shows the format of the forward link skew calibration packet. As shown in Figure 56, this type of packet structure has packet length (2 bytes), packet type, and parameters. Count CRC, calibration data sequence and CRC field. This type of packet is generally recognized as a Type 83 packet in the type field, and uses 515 to pre-select a fixed length.

D. Packet CRC

The CRC field appears at the end of the packet, sometimes after some of the more critical parameters in the packet with extremely large data fields (and therefore an increased possibility of errors in transmission). In a packet with two CRC fields, when only one is used, the CRC generator is reinitialized after the first CRC, so that the CRC calculation after the long data field is not affected by the parameters at the beginning of the packet.

In an exemplary embodiment, the polynomial used for CRC calibration is known as CRC-16 or X¹⁶+X¹⁵+X²+X⁰. Figure 36 shows a sample implementation of the CRC generator and checker 3600 that can be used to implement the present invention. In FIG. 36, the CRC register 3602 is initialized to a value of 0x0001 before transmitting the first bit of the packet input to the Tx_MDDI_Data_Before_CRC line, and then the packet byte is transferred to the register starting with the first LSB. It should be noted that the number of register bits in this figure corresponds to the order of the polynomial used, not the bit positions used by MDDI. It is more effective to transfer the CRC register in a single direction, which results in CRC bit 15 appearing in bit position 0 of the MDDI CRC field, and CRC register bit 14 appearing in bit position 1 of the MDDI CRC field, and so on. , Until it reaches MDDI bit position 14.

For example, if the packet content used for the display request and status packet is: 0x07, 0x46, 0x000400, 0x00 (or expressed as a byte sequence: 0x07, 0x00, 0x46, 0x00, 0x04, 0x00, 0x00), and use multiplexing The input of the device 3604 and 3606 and the NAND gate 3608 are submitted, then the final CRC output on the Tx_MDDI_Data_With_CRC line is 0x0ea1 (or represented as 0xa1, 0x0e sequence).

When the CRC generator and checker 3600 is configured as a CRC checker, the CRC received on the Rx_MDDI_Data line is input to the multiplexer 3604 and NAND gate 3608, and uses NOR gate 3610 and exclusive OR (XOR) gate 3612. And the AND gate 3614 compares it bit by bit with the value found in the CRC register. If there is any error in the output of the AND gate 3614, for each packet including the CRC error, the CRC is incremented once by connecting the output of the gate 3614 and the input of the register 3602. It should be noted that the exemplary circuit shown in FIG. 36 can output multiple CRC error signals within a given CHECK_CRC_NOW window (see FIG. 37B). Therefore, the CRC error counter generally only counts the first CRC error instance in each interval under the effect of CHECK_CRC_NOW. If configured as a CRC generator, the CRC will be clocked outside the CRC register at the same time as the end of the packet.

Figures 37A and 37B graphically illustrate the timing and actuation signals for input and output signals. Figure 37A shows the generation of CRC and the transmission of data packets with the status (0 or 1) of the Gen_Reset, Check_CRC_Now, Generate_CRC_Now, and Sending_MDDI_Data signals, and the Tx_MDDI_Data_Before_CRC and Tx_MDDI_Data_With_CRC signals. Figure 37B shows the reception of the data packet and the checking of the CRC value with the status of the Gen_Reset, Check_CRC_Now, Generate_CRC_Now, and Sending_MDDI_Data signals, as well as the Rx_MDDI_Data and CRC error signals.

E. Additional information about error codes used for packet CRC

As long as the data packet and CRC are only transmitted between the host and the client, the error code is not included. The only error was the loss of synchronization. In addition, you must wait for the link to fail If there is no good data transmission path or timeout in the pipeline, then reset the link and continue. Unfortunately, this is time consuming and inefficient.

For use in a specific embodiment, a new technology has been developed in which the CRC part of the packet is used to transmit error code information. This is shown roughly in Figure 65. That is, the processor or device processing the data transmission generates one or more error codes, which indicate specific predefined errors or defects that may occur in the communication process or the link. When an error is encountered, the bit used for the CRC of the packet is used to generate and transmit an appropriate error code. That is, the CRC value is overloaded or overwritten with the expected error code, which can be detected by the error monitor or checker that monitors the value of the CRC field at the receiving end. In the case where the error code matches the CRC value for some reason, the complement of the error is transmitted to prevent confusion.

In a specific embodiment, in order to provide a robust error warning and detection system, the error code can be transmitted several times, which uses a series of packets, generally all packets transmitted or transmitted after the error has been detected. This happens until the point where the system clears the condition of the establishment error, which transmits the regular CRC bits, but will not be overloaded by another value.

This technology of overloading the CRC value provides a faster response to system errors while using a minimum number of extra bits or fields.

V. Link restarts from hibernation

When the host restarts the forward link from the dormant state, it drives MDDI_Data to a logic one state for about 150 μsec, then starts MDDI_Stb, and drives MDDI_Data to a logic zero state for 50 μsec, and then restarts by sending a subframe header packet Start forward link traffic. This generally allows bus competition to transmit sub-frame headers by providing sufficient settling time between signals Resolve before packet.

When the client (here, the display) needs data or communication from the host, it drives the MDDI_Data0 line to a logic one state for about 70 μsec, although other cycles can be used as needed, and then it is placed in a high impedance state. Deactivate the drive. This action enables the host to start or restart the data flow on the forward link (208), and poll the status of the client. The host must detect the existence of the request pulse within 50 μsec, and then start to drive MDDI_Data0 to a logic one 150 μsec and a logic zero 50 μsec start sequence. If MDDI_Data0 is longer than 50 μsec in the logic one state, the display should not transmit service request pulses. The following describes the time selection properties and time interval tolerances related to the sleep processing and the startup sequence.

FIG. 38 illustrates an example of processing steps for a typical service request event 3800 without competition, in which the letters A, B, C, D, E, F, and G are used to mark the events for the convenience of explanation. At point A, the process starts when the host sends a link close packet to the client device to notify it that the link will transition to a low-power sleep state. In the next step, the host enters the low-power sleep state by disabling the MDDI_Data0 driver and setting the MDDI_Stb driver to logic zero, as shown in point B. Drive MDDI_Data0 to the zero level by the high impedance bias network. After a period of time, the client sends a service request to the host by driving MDDI_Data0 to the logic level shown in point C. The host still uses a high-impedance bias network to determine the zero level, but the driver in the user terminal forces the line to a logical level. Within 50 μsec, the host reorganizes the service request pulse, and determines the logical level on MDDI_Data0 by activating its driver, as shown in point D. Then the client stops trying to determine the service request pulse, and the user The terminal puts its driver in a high impedance state, as shown at point E. The host drives MDDI_Data0 to the logic zero level for 50 μsec, as shown by point F, and also starts to generate MDD_Stb in a manner consistent with the logic zero level on MDDI_Data0. After judging MDDI_Data0 to the zero level and driving MDDI_Stb for 50 μsec, the host starts to send data on the forward link by sending a subframe header packet, as shown by point G.

Figure 39 illustrates a similar example, where the service request is determined after the link restart sequence is started, and the events are marked with the letters A, B, C, D, E, F, and G again. This represents the worst case, where the request pulse or signal from the client is most likely to damage the sub-frame header packet. At point A, the process starts when the host sends a link-off packet to the user-end device again to inform it that the link will transition to a low-power sleep state. In the next step, the host enters the low-power sleep state by disabling the MDDI_Data0 driver and setting the MDDI_Stb driver to logic zero, as shown in point B. As before, MDDI_Data0 is driven to the zero level by the high-impedance bias network. After a period of time, the host starts the link restart sequence by driving MDDI_Data0 to the logic level shown at point C for 150 μsec. Before 50 μsec after the start of the link restart sequence, the display also judges MDDI_Data0 in the duration of 70 μsec, as shown in point D. This happens because the display needs to request service from the host but does not recognize that the host has started the link restart sequence. Then the client stops trying to determine the service request pulse, and the client puts its driver in a high impedance state, as shown in point E. The host continues to drive MDDI_Data0 to a logical level. The host drives MDDI_Data0 to logic zero level 50 μsec, as shown by point F, at the same time it starts to be the same as the logic zero level on MDDI_Data0 MDD_Stb is generated in a consistent manner. After judging MDDI_Data0 to the zero level and driving MDDI_Stb for 50 μsec, the host starts to send data on the forward link by sending a subframe header packet, as shown by point G.

From the above description, it can be seen that the previous solution included passing the host through two states as part of the wake-up sequence. For the first state, the host drives the MDDI_Data0 signal high for 150μs, then drives the MDDI_Data0 signal low for 50μs, and at the same time activates the MDDI_Stb line, and then starts sending MDDI packets. This procedure can effectively advance the technology based on the data rate achievable using MDDI devices and methods. However, as mentioned earlier, the higher speed in terms of reducing the response time to the situation or being able to select the next step or procedure more quickly simplifies the processing or component capabilities, and there is always a need.

The applicant has discovered a new creative method of wake-up processing and timing, in which the host uses a timing based on the clock cycle for signal switching. In this configuration, after the host drives the MDDI_Data0 signal high at the beginning of the wake-up sequence, the host starts to switch MDDI_Stb from 0 to 10 μsec, and does not wait until the signal is driven low. During the wake-up sequence, the host toggles MDDI_Stb, as if the MDDI_Data0 signal is always at the same logic zero level. This effectively removes the concept of time on the client side, and the host changes from the 150 μs and 50 μs cycles previously used for the first two states to the 150 clock cycles and 50 clock cycles used for these cycles.

Now the host is responsible for driving the data line high and starting to send strobe signals within 10 clock cycles, treating the data line as zero. After the host has driven the data line higher by 150 clock cycles, the host drives the data line lower by 50 clock cycles while continuing to send strobe signals. After completing these two procedures, the host can start sending the first A subframe header packet.

On the user side, the user side implementation can now use the generated clock to calculate the number of clock cycles of the data line from high to low. The number of clock cycles that need to occur in the second drive high state data line is 150, and the drive low state data line is 50. This means that for the correct wake-up sequence, the client should be able to count at least 150 continuous clock cycles of the high data line, followed by at least 50 continuous clock cycles of the low data line. Once these two conditions are met, the client can start searching for the unique character of the first subframe. The interrupt in this pattern is used as the basis for returning the counter to the initial state, where the user end again looks for 150 consecutive clock cycles of the high data line.

The client implementation of the present invention for host-based sleep wakeup is very similar to the initial startup situation, except that the clock rate does not have to start at 1 Mbps, as described above. Conversely, the clock rate can be set to resume when the communication link goes to sleep, regardless of the previous rate used. If the host starts the transmission of the above strobe signal, the client should be able to count again at least 150 continuous clock cycles of the high data line, followed by at least 50 continuous clock cycles of the low data line. Once these two conditions are met, the client can start searching for unique characters.

The client implementation of the present invention for client-based sleep wakeup is similar to host-based wakeup, except that it is activated by enabling the client to drive the data line. The client can asynchronously drive the clockless data line to wake up the host device. Once the host recognizes that the data line is driven high by the client, it can start the wake-up sequence. The client can count the number of clock cycles generated by the host that is starting the wake-up procedure or is in the process of the wake-up procedure. Once the client counts 70 high data continuous clock cycles, it can stop driving the high data line. this At that time, the host should also have driven the data line high. The user terminal can then count another 80 high data line continuous clock cycles in order to reach 150 high data line clock cycles, and then can search for 50 low data line clock cycles. Once these three conditions are met, the client can start looking for unique characters.

The advantage of this new wake-up processing implementation is that it does not require time measurement devices. Regardless of whether it is an oscillator or a capacitor discharge circuit or other such well-known devices, the user terminal no longer needs such external devices to determine the starting conditions. When the controller, counter, etc. are implemented on the user-end device board, this can save cost and circuit area. Although this is not equally beneficial to the client, for the host, this technology should also potentially simplify the host according to the very high density logic (VHDL) used in the core circuit. The power consumption of using data and strobe lines as wake-up notification and measurement sources is also lower, because the core components wait for host-based wake-up without running external circuits.

VI. Interface electrical specifications

In an exemplary embodiment, a data strobe signal or DATA-STB format is used to encode data in a non-return-to-zero (NRZ) format, which makes it possible to embed clock information in the data and strobe signals middle. The clock can be restored without a complicated phase-locked loop circuit. The data is carried on a two-way differential link, which is generally implemented using wired cables, but it can also be implemented using other conductors, printed wires, or transmission components, as previously explained. The strobe signal (STB) is carried on a unidirectional link driven only by the host. Whenever there is a back-to-back state 0 or 1, which remains the same on the data line or signal, the strobe signal will toggle the value (0 or 1).

Figure 40 shows in graphical form how to use DATA-STB encoding to send data An example of a data sequence such as the bit "1110001011". In FIG. 40, the DATA (data) signal 4002 is displayed on the top line of the signal timing diagram, and the STB (strobe) signal 4004 is displayed on the second line, and each timing sequence is properly aligned (common starting point). As time goes by, when the state of the DATA line 4002 (signal) changes, the STB line 4004 (signal) maintains the previous state. Therefore, the first "1" state of the DATA signal and the first "0" state of the STB signal (its Start value) related. However, if or when the state and level of the DATA signal have not changed, the STB signal toggles to the opposite state ("1" in this example), as in the situation in Figure 40, where DATA provides another " 1" value. That is, there is one and only one transition per bit period between DATA and STB. Therefore, the STB signal changes again, this time to "0", because the DATA signal is still at "1", and when the DATA signal changes its level to "0", the STB signal maintains this level or value. When the DATA signal is still at "1", the STB signal toggles to the opposite state ("1" in this example), and so on, as the DATA signal changes or maintains the level or value.

After receiving these signals, a mutually exclusive OR (XOR) operation is performed on the DATA and STB signals to generate a clock signal 4006, which is shown at the bottom of the timing diagram for comparison with ideal data and strobe signals. FIG. 41 shows an example of a circuit for generating DATA and STB output OR signals from the input data at the host, and then recovering or retrieving the data from the DATA and STB signals at the user end.

In FIG. 41, the transmitting part 4100 is used to generate and send the original DATA and STB signals on the intermediate signal path 4102, and the receiving part 4120 is used to receive these signals and recover the data. As shown in Figure 41, in order to transfer the data from the main The DATA signal is combined with the clock signal used to trigger the circuit to input two D-type flip-flop circuit elements 4104 and 4106. Then two differential line drivers 4108 and 4110 (voltage mode) are used to separate the outputs (Q) of the two flip-flop circuits into differential signal pairs MDDI_Data0+, MDDI_Data0- and MDDI_Stb+, MDDI_Stb-, respectively. Connect a three-input exclusive NOR (XNOR) gate, circuit or logic element 4112 to receive the DATA and output of the two flip-flops, and generate an output that provides data input for the second flip-flop, The second flip-flop in turn generates MDDI_Stb+ and MDDI_Stb- signals. For convenience, a reversing magnetic bubble is placed on the XNOR gate to indicate that it is effectively reversing the Q output of the flip-flop that generates the strobe signal.

In the receiving part 4120 of FIG. 41, two differential line receivers 4122 and 4124 each receive MDDI_Data0+, MDDI_Data0-, MDDI_Stb+, MDDI_Stb-, and generate signal outputs from these differential signals. The output of these amplifiers is then input to each input of a two-input mutually exclusive OR (XOR) gate, circuit or logic element 4126, and the XOR gate 4126 generates a clock signal. The clock signal is used to trigger each of the two D-type flip-flop circuits 4128 and 4130, which receive a delayed DATA signal through the delay element 4132, and a flip-flop circuit (4128) generates data "0" values , And another flip-flop circuit (4130) generates the data "1" value. The clock also has an independent output from the XOR logic. Since the clock information is distributed between the DATA and STB lines, the state transition of any signal will not be faster than half of the clock rate. Since the clock is reproduced by processing the DATA and STB signals using mutually exclusive OR, it is the same as transmitting the clock signal directly through a single dedicated data line. Compared with the case of sending, the system can effectively tolerate twice the amount of skew between the input signal and the clock.

The MDDI_Data pair, MDDI_Stb+ and MDDI_Stb- signals are operated in a differential mode to minimize the negative effects of noise. Each part of the differential signal path is terminated at the source, and half of the characteristic impedance of the cable or conductor is used to transmit the signal. The MDDI_Data pair ends at the source and ends at both the host and the client. Since only one of the two drivers is active at a given time, the terminal continues to exist at the source of the transmission link. The MDDI_Stb+ and MDDI_Stb- signals are only driven by the host.

Figure 42 shows an exemplary component configuration, which can be used to transmit signal drivers, receivers and terminals as part of the creative MDD interface, and the corresponding MDDI_Data and MDDI_Stb DC electrical specifications are shown in Table VII middle. This exemplary interface uses low voltage sensing, here 200 mV, where the power swing is less than 1 volt and the power consumption is very low.

<tables><img file="TWI374635B_D0007.tif" /></tables>

Table VIII illustrates the electrical parameters and characteristics of the differential line driver and line receiver. In terms of function, the driver transfers the logic level on the input directly to a positive output, and transfers the inverse of the input to a negative output. The delay from input to output just matches the differential line of the differential drive. In most implementations, the voltage swing on the output is smaller than the voltage swing on the input, thereby minimizing power consumption and electromagnetic emissions. Table VIII shows that the minimum voltage swing is about 0.5V. However, those skilled in the art should understand that other values can be used, and the inventor considers smaller values in some specific embodiments, which depend on design constraints.

The differential line receiver has the same characteristics as the high-speed voltage comparator. In Figure 41, the input without magnetic bubbles is a positive input, and the input with magnetic bubbles is a negative input. If (V_input+)-(V_input-) Is greater than zero, the output is logic one. Another description method is that a differential amplifier has a very large (almost infinite) gain, and its output is clamped between logic 0 and 1 voltage levels.

The delay skew between the different pairs should be minimized so that the highest potential speed Operate the differential transmission system.

In FIG. 42, the host controller 4202 and the client or display controller 4204 are shown as transmitting packets via the communication link 4206. The host controller uses three drivers 4210, 4212, and 4214 in series to receive host DATA and STB signals to be transmitted, and to receive client data signals to be transmitted. The driver responsible for the path of the host DATA uses an actuation signal input to allow the communication link to be initiated only when transmission from the host to the user terminal is generally required. Since the STB signal is formed as part of the data transmission, no additional actuation signal is required for the driver (4212). The output of each DATA and STB driver is connected to terminal impedance or resistors 4216a, 4216b, 4216c, and 4216d, respectively.

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

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

The above drivers and impedances can be formed as discrete components or as part of circuit modules, or application specific integrated circuits (application specific integrated circuits). integrated circuit; ASIC), which acts as a more cost-effective encoder or decoder solution.

It can be easily seen that the power supply uses signals marked MDDI_Pwr and MDDI_Gnd to be transmitted from the host device to the client device or display via a pair of conductors. The MDDI_Gnd part of the signal serves as a reference ground and power supply return path or a signal for the display device. The MDDI_Pwr signal serves as the power supply for the display device, which is driven by the host device in an exemplary configuration; for low-power applications, the display device is allowed to draw up to 500 mA. The MDDI_Pwr signal can be provided from a portable power source, such as (but not limited to) a lithium-ion battery or battery pack residing in the host device, and the MDDI_Pwr signal can range from 3.2 to 4.3 volts relative to MDDI_Gnd.

VII. Timing characteristics

A. Overview

Figure 43 shows the steps and signal levels used by the client to ensure the services obtained from the host and the host to provide these services. In Figure 43, the first part of the illustrated signal shows the link closed packet transmitted from the host, and then a high impedance bias circuit is used to drive the data line to a logic zero state. The client display or host whose drive has been disabled is not sending any data. A series of strobe pulses for the MDDI_Stb signal line can be seen at the bottom, because MDDI_Stb is active during the link closure packet. Once the packet is over and the logic level becomes zero as the host drives the bias circuit and the logic goes to zero, the MDDI_Stb signal line also becomes zero. This represents the last signal transmission from the host or the termination of the service, and may have occurred at any time in the past, including it to show the previous stop of the service, and the previous stop of the service before the start of the service The state of the signal. If necessary, such a signal can be sent to only reset the communication link to the correct state, without the need to "know" the previous communication that this host service has undertaken.

As shown in Figure 43, the signal output from the user terminal is initially set at the logic zero level. In other words, the user terminal output is at high impedance, and the driver is disabled. When requesting service, the client activates its driver and sends a service request to the host. The service request is a period of time, using t_serviceIndicates that the line is driven to a logical level during this time period. Then a certain amount of time has elapsed, or it may take a certain amount of time before the host can detect the request. This amount of time is called t_host-detectAfter the amount of time has elapsed, the host responds with a link activation sequence by driving the signals to a logical level. At this time, the user terminal resolves the request, and disables the service request driver, so that the output line from the user terminal enters the logic zero level again. During this time, the MDDI_Stb signal is at a logic zero level.

The host is called t_restart-highDrive the host's data output to be at the "1" level during the cycle, and then the host drives the logic level to zero and is called t_restart-lowStart MDDI_Stb within the period of, then the first forward flow starts with the sub-frame header packet, and then these forward flow packets are transmitted. MDDI_Stb signal at t_restart-lowIt is active during the period and the subsequent sub-frame header packet period.

Table VIII shows the representative time for the length of the various periods mentioned above, and the relationship between the exemplary minimum and maximum data rates, where:<maths><img file="TWI374635B_D0008.tif" /></maths>

<tables><img file="TWI374635B_D0009.tif" /></tables>

Those skilled in the art can easily understand that the functions of the individual components shown in FIGS. 41 and 42 are already well known, and the functions of the components in FIG. 42 have been verified by the timing diagram in FIG. 43. The detailed information about the serial terminal and the sleep resistor shown in FIG. 42 is omitted in FIG. 41, because this information is not necessary for explaining how to perform data-strobe coding and recover the clock from it.

B. Data-strobe timing forward link

Table IX shows the cut of the data on the forward link from the host driver output and transmission Change characteristics. Table IX shows in tabular form the minimum and maximum time required for certain signal transitions versus the typical time. For example, the typical length of time for the transition (Data0 to Data0 transition) to occur from the beginning to the end of a data value (output of "0" or "1") is called t_{tdd-(host-output)}, Department t_tbit, And the minimum time is about t_tbit-0.5 nanoseconds, the maximum time is about t_tbit+0.5 nanoseconds. Figure 44 illustrates the relative interval between the transitions on Data0, other data lines (DataX), and strobe lines (Stb), which shows Data0 to strobe, strobe to strobe, strobe to Data0, Data0 to non-Data0, The transitions from non-Data0 to non-Data0, non-Data0 to gated and gated to non-Data0 are called t_{tds-(host-output)}, T_{tss-(host-output)}, T_{tsd-(host-output)}, T_{tddx-(host-output)}, T_{tdxdx-(host-output)}, T_{tdxs-(host-output)}And t_{tsdx-(host-output)}。

<tables><img file="TWI374635B_D0010.tif" /></tables>

For the same signal that transmits data on the forward link, the typical MDDI timing requirements input by the client receiver are shown in Table X. Since the signals discussed are the same but with a delay in time, there is no need for new schemes to illustrate the signal characteristics or meaning of individual tags. Those familiar with the technology should understand its meaning.

<tables><img file="TWI374635B_D0011.tif" /></tables>

Figures 45 and 46 show the delay in response, which can occur when the host disables or activates the host driver, respectively. In the case that the host transmits certain packets (such as reverse link encapsulation packets or round-trip delay measurement packets, etc.), the host is transmitting the required packets (such as the transmitted parameters CRC, strobe alignment, and all zeros shown in Figure 45). After the packet, etc.), the line driver is disabled. However, as shown in Figure 45, the line state does not need to be switched from "0" to a higher value in real time. Although this real-time switching can be achieved by using some control or existing circuit components, the cost is called host driver deactivation. Delay (Driver Disable Delay) period of time to respond. Although it can actually happen immediately, so that the length of the time period is 0 nanoseconds, it can be easily extended to a longer period, where 10 nanoseconds is the ideal maximum period length, which occurs in guard time 1 or turning 1 During the packet cycle.

Referring to Figure 46, when the host driver is activated to transmit packets such as reverse link encapsulation packets or round-trip delay measurement packets, the signal level undergoes a change. Here, after guard time 2 or turn to 2 packet cycles, the host driver is activated and starts to drive one level (here "0"), which is called the Host Driver Enable Delay (Host Driver Enable Delay) period Time period When the value is approached or reached, the time period occurs during the driver re-enable period before the driver transmitting the first packet.

A similar process occurs in the driver and signal transmission of the client device (here, the display). Table XI below shows the general guidelines for the length of these periods and their individual relationships.

<tables><img file="TWI374635B_D0012.tif" /></tables>

C. Data-strobe timing reverse link

Figures 47 and 48 show the switching characteristics and timing relationships of the data and strobe signals used to output and transmit data on the reverse link from the client driver. The typical time for some signal transitions is discussed below. Figure 47 illustrates the relationship between the timing of the transmitted data and the front and back edges of the strobe pulse at the input of the host receiver. It is called t of the rising or leading edge of the strobe signal_su-srAnd the set time t called the falling or trailing edge of the strobe signal_su-sf. The typical time length of the set period is about 8 nanoseconds minimum.

Figure 48 illustrates the corresponding user-side output delay formed by the switching characteristics and reverse data timing. As can be seen in Figure 48, the relationship between the timing of the transmitted data and the front and back edges of the strobe explains the delay caused. It is called the t_pd-srAnd t_pd-sf. The typical maximum length of the propagation delay period is At the level of about 8 nanoseconds.

VIII. Link control implementation plan (link controller operation)

A. State machine packet processor

Packets transmitted via the MDDI link are dispatched very quickly, usually at a rate of about 300 Mbps or higher, such as 400 Mbps, but it can of course cope with lower rates as needed. For current commercial (economical) general-purpose microprocessors or the like, the speed of this type of bus or transmission link is too large to be controlled. Therefore, an actual implementation of this type of signal transmission is to use a programmable state machine to analyze the input packet stream to generate packets, and then transmit or redirect them to the desired appropriate audio-video subsystem. Such devices are well known and use circuits generally dedicated to a limited number of operations, functions, or states to achieve the desired high-speed or extremely high-speed operation.

General-purpose controllers, processors, or processing elements can be used to more appropriately act on or manipulate certain information, such as control or status packets, which have lower speed requirements. After receiving these packets (control, status, or other predefined packets), the state machine should pass them to the general-purpose processor through a data buffer or similar processing element, so that they can act on these packets to provide the desired results ( Effect), and audio and video packets are transmitted to their corresponding destinations. If microprocessors or other general-purpose controllers, processors, or processing components manufactured in the future can achieve higher data rate processing capabilities, software control of such devices is usually used as a program stored on storage components or media. Implement the state or state machine discussed below.

In some embodiments, by using the processing power or available excess cycles of the microprocessor (CPU) in the computer application, or the controller, processor, ASICs used in digital signal processors (DSP), dedicated circuits, or wireless devices can implement general-purpose processor functions, and some modems or graphics processors use the processing power of the CPU used in computers to execute certain These functions and reduce hardware complexity and cost are very similar. However, this period sharing or use can negatively affect the processing speed, timing, or the overall operation of such components. Therefore, in many applications, it is better to use dedicated circuits or components for this general processing.

In order to view the image data on the display (microdisplay), or to reliably receive all the packets sent by the host device, the display signal processing is synchronized with the timing of the forward link channel. That is, in order to perform correct signal processing, the signals arriving at the display and the display circuit need to be substantially synchronized in time. Figure 49 presents a high-level state diagram that can be achieved by a signal processing step or method that can implement such synchronization. Figure 49 shows that the possible forward link synchronization "states" of the state machine 4900 are classified as an asynchronous frame state (ASYNC FRAMES STATE) 4904, two ACQUIRING SYNC STATEs (ACQUIRING SYNC STATE) 4902 and 4906, and three synchronizations IN-SYNC STATE 4908, 4910 and 4912.

As shown in the start step or state 4902, the display or client (such as a presentation device, etc.) starts in the preselected "out of sync" state, and searches for a unique character in the first sub-frame header packet detected . It should be noted that this unsynchronized state represents the lowest communication setting or "back drop" setting, in which the I-type interface is selected. If the unique character is found during the search, the display will save the subframe length field. For the processing on this first frame, no CRC bit check is performed or until synchronization is obtained. If the length of this subframe is zero, the same The step state processing accordingly proceeds to a state 4904, where it is marked as the "asynchronous frame" state, indicating that synchronization has not been achieved. In Figure 49, this step in the process is marked as encountering cond 3 or condition 3. Otherwise, if the frame length is greater than zero, the synchronization state processing proceeds to state 4906, where the interface state is set to "a synchronization frame found". In Figure 49, this step in the process is marked as cond 5 or condition 5 encountered. In addition, for a frame length greater than zero, if the state machine finds a frame header packet and a good CRC decision, the processing proceeds to the "a synchronization frame found" state. In Figure 49, this line is marked as cond 6 or condition 6 encountered.

In each case where the system is in a state other than "out of sync", if the unique character is detected and a good CRC result is determined for the sub-frame header packet, and the sub-frame length is greater than zero, the The interface status becomes "Syncing" status 4908. In Figure 49, this step in the process is marked as cond 1 or condition 1 encountered. On the other hand, if the unique character or the CRC in the sub-frame header packet is incorrect, the synchronization state processing advances or returns to the interface state 4902 "No synchronization frame" state. In the state diagram of Figure 49, this part of the process is marked as cond 2 or condition 2 encountered.

B. Acquisition time for synchronization

The interface can be configured to tolerate a certain number of "synchronization errors" before deciding that the synchronization has been lost and returning to the "no synchronization frame" state. In Figure 49, once the state machine has reached the "synchronizing state" and no errors are found, it will continue to encounter the cond 1 result and remain in the "synchronizing" state. However, once a cond 2 result is detected, the process will change the state to the "a sync error" state 4910. At this time, if the processing results in another cond 1 knot being detected If the result, the state machine returns to the "synchronizing" state, otherwise it will encounter another cond 2 result and move to the "second synchronization error" state 4912. Similarly, if cond 1 occurs, the process returns the state machine to the "synchronizing" state. Otherwise, if another cond 2 is encountered, the state machine will return to the "out of sync" state. It can also be understood that if the interface encounters a "link closed packet", this will cause the link to terminate data transmission and return to the "unsynchronized frame" state, because there is no frame synchronized with it; the state in Figure 49 In the machine, this situation is called cond 4 or condition 4 encountered.

It should be understood that there may be repeated "miscopy" of the unique character, which may appear in a fixed position in the sub-frame. In this case, the state machine is unlikely to be synchronized with the sub-frame, because in order to advance the MDD interface processing to the "synchronizing" state, the CRC on the header packet of the sub-frame must also be valid during processing.

The length of the sub-frame in the sub-frame header packet can be set to zero to instruct the host to send only one sub-frame before closing the link, and the MDD interface is placed or configured in an idle sleep state. In this case, the display must receive the packet via the forward link immediately after detecting the sub-frame header packet, because only a single sub-frame is transmitted before the link transitions to an idle state. In a normal or typical operation, the sub-frame length is non-zero and the display only processes forward link packets, and the interface system is in the states shown in FIG. 49 as the "synchronizing" state.

The time required for the display to synchronize with the forward link signal varies according to the size of the sub-frame and the forward link data rate. When the size of the sub-frame is large, the unique word that is part of the randomized (or more randomized) data is detected in the forward link Yuan Zhi's "wrong copy" is also more likely. At the same time, the ability to recover from error detection is low, and if the forward link data rate is slow, it will take longer to recover.

C. Initialization

As mentioned earlier, at the time of "startup", the host configures the forward link to operate at the required or ideal minimum data rate of 1 Mbps or less, and appropriately configures the sub-frame length and media frame rate for a given data rate. Set application. That is, both the forward link and the reverse link use the I-type interface to start operation. Generally, these parameters are only used temporarily, and the host determines the capabilities or desired configuration used by the client display (or other types of client devices). The host first sends or transmits a sub-frame header packet via the forward link, and then sends a reverse link encapsulation packet. The request flag bit "0" is set to the value one (1), thereby requesting the display or The client responds with a display capability packet. Once the display is synchronized on the forward link (or using the forward link), it transmits display capability packets and display request and status packets via the reverse link or channel.

The host detects the contents of the display capability packet, thereby deciding how to reconfigure the link to achieve the best or desired level of performance. The host detects the protocol version and minimum protocol version fields to confirm that the protocol versions used by the host and the display are compatible with each other. The protocol version is generally maintained as the first two parameters of the display capability packet, so that even when other elements of the protocol may be incompatible or cannot be fully understood as compatible, the compatibility can still be determined.

D. CRC processing

For all packet types, the packet processor state machine will ensure that the CRC checker is properly or correctly controlled. When the CRC comparison results in the detection of one or When there are multiple errors, it will also increment the CRC error counter, and it will reset the CRC counter when each sub-frame starts processing.

E. Alternative synchronization loss check

Although the above steps or state series can produce a higher data rate or throughput speed, the applicant has found that an alternative configuration or condition change used by the client to announce that there is a loss of synchronization with the host can be used to effectively achieve a higher data rate Or flux. This new inventive specific embodiment has the same basic structure, but the conditions for changing the state have changed. A new counter is additionally implemented to help check the synchronization of the sub-frames. The steps and conditions are based on the procedure shown in Figure 63, which illustrates a series of states and conditions used to establish the operation of the method or state machine. For clarity, only the "Get Sync Status" and "Syncing Status" sections are shown. In addition, since the result state (that is, the state machine itself) is substantially the same, the same numbers are used for these states. However, the conditions used to change the state (and state machine operation) are slightly changed, so for the sake of clarity between the two figures, the conditions are renumbered (1, 2, 3, 4, 5 and 6 to 61, 62, 63, 64 and 65) to facilitate the identification of differences. Since asynchronous frames are not considered in this discussion, a state (4904) and condition (6) are no longer used in this figure.

In FIG. 63, the system or client (displayed or presented by the user) starts the state machine 5000 with a preselected "out of sync" state 4902, as shown in FIG. 49. The first state change to change state from the out-of-sync state 4902 is in condition 64, which is the discovery of a sync pattern. Assuming that the CRC of the sub-frame header is also transmitted on this packet (condition 61 is encountered), the state of the packet processor state machine can be changed to the synchronization state 4908. A synchronization error, condition 62, will cause the state machine to become state 4910, and if a second synchronization error occurs, the state machine will change to state 4912. However, it has been found that any CRC failure of the MDDI packet will cause the state machine to leave the synchronization state 4908 and enter a synchronization error state 4910. Another CRC failure of any MDDI packet will cause the state machine to move to the second synchronization failure state 4912. A packet decoded with the correct CRC value will cause the state machine to return to the in-sync state 4908.

The changed system uses the CRC value or decision for "each" packet. That is, for each packet, let the state machine check the CRC value to determine the synchronization loss, instead of just observing the sub-frame header packet. In this configuration or processing, the synchronization loss is not determined by using unique characters and only the sub-frame header CRC value.

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

To make this system more robust, the client should also increase or use the sub-frame counter. Then when the unique character is expected to arrive or appear in the signal, the user terminal checks whether the unique character exists. If the unique character does not appear at the correct time, the client can recognize that a synchronization failure has occurred more quickly, without waiting for several (here, three) packet times or cycles that are greater than the length of the subframe. If the test of the unique character indicates that it does not exist, in other words, the timing is incorrect, the user terminal can immediately declare the link synchronization loss and move to the asynchronous state. The process of checking whether the correct unique character exists or not adds a condition 65 (cond 5) to the state machine, saying that the unique character is incorrect. If a sub-frame packet is expected to be received on the user end and the packet does not match, the user end can immediately enter the asynchronous state 4902, thereby saving waiting for multiple synchronization errors (condition 62; generally encountered when crossing states 4910 and 4912) To) the extra time.

This change uses an additional counter or the counting function in the client core to count the length of the sub-frame. In a specific embodiment, the countdown function is used, and if the counter has expired, the transmission of any packet currently being processed is interrupted to check the unique character of the subframe. Alternatively, the counter can be counted up, and the count is compared with the required maximum value or a specific required value, and the current packet is checked at that point. This process protects the client from using abnormally long packet lengths to decode incorrectly received packets on the client. If the sub-frame length counter needs to interrupt some other packet being decoded, a synchronization loss can be determined, because any packet should not cross the sub-frame boundary.

IX. Packet processing

For each type of packet received by the state machine, it performs specific processing steps or series of steps to implement the interface operation. Generally, forward link packets are processed according to the exemplary processing listed in Table XII below.

<tables><img file="TWI374635B_D0013.tif" /></tables><tables><img file="TWI374635B_D0014.tif" /></tables>

X. Reduce reverse link data rate

The inventor has observed that certain parameters for the host link controller can be adjusted or configured in a certain way to achieve the maximum or better (proportional) reverse link The data rate of the road is very suitable for the needs. For example, during the time period used to transmit the reverse data packet field of the reverse link encapsulated packet, the MDDI_Stb signal pair toggles to establish a periodic data clock, the clock rate being lower than the forward link data rate half. This happens because the MDDI_Stb signal generated by the host link controller corresponds to the MDDI_Data0 signal, which seems to be transmitting all zeros. The MDDI_Stb signal is transmitted from the host to the client, and the MDDI_Stb signal at the client is used to generate a clock signal for transmitting reverse link data from the display, and the reverse data combined with the clock signal is sent back to the host. Figure 50 shows a diagram of typical delays encountered in signal transmission and processing on the forward and reverse paths in a system using MDDI. In Figure 50, a series of delay values are displayed near the processing part of Stb+/- generation, cable transmission to display, display receiver, clock generation, signal timing, Data0+/- generation, cable transmission to host and host receiver level. 1.5 nanoseconds, 8.0 nanoseconds, 2.5 nanoseconds, 2.0 nanoseconds, 1.0 nanoseconds, 1.5 nanoseconds, 8.0 nanoseconds and 2.5 nanoseconds.

Depending on the forward link data rate and signal processing delay encountered, the completion of this "back and forth" effect or this set of events may require multiple cycles on the MDDI_Stb signal, which results in consuming an undesirable amount of time or cycles. To overcome this problem, a reverse rate divisor (Reverse Rate Divisor) can enable the bit time on the reverse link to span multiple periods of the MDDI_Stb signal. This means that the reverse link data rate is less than the forward link data rate.

It should be noted that the actual length of the signal delay through the interface may be different depending on each specific host-client system or hardware used. Although it is not necessary, by using the round-trip delay measurement packet to measure the actual delay in the system, the reverse rate divisor can be set to an optimal value. The performance of the system is better.

By letting the host send a round-trip delay measurement packet to the display, the round-trip delay can be measured. In response to this packet, the display sends back a sequence of one to the host within or during a preselected measurement window (called the measurement period field) in the packet. The detailed timing of this measurement has been explained previously. The round-trip delay is used to determine the sampling rate at which reverse link data can be safely sampled.

Round-trip delay measurement includes determining, detecting, or counting forward link data between the start of the measurement period (Measurement Period) field and the start of the time period when the host receives the 0xff, 0xff, and 0x00 response sequence from the client. The number of clock intervals. Please note that the measurement count may only start to increment after a small segment of the forward link clock cycle has passed since the response was received from the user end. If this unmodified value is used to calculate the reverse rate divisor, it may cause bit errors on the reverse link due to unreliable data sampling. Figure 51 illustrates an example of this situation, where MDDI_Data at the host, MDDI_Stb at the host, forward link data clock inside the host, and Delay Count signals are illustrated in graphical form. In FIG. 51, the delay count starts to increase from 6 to 7 after a segment of the forward link clock cycle after receiving the response sequence from the display. If the delay is assumed to be 6, the host will start sampling the reverse data after the bit transition or possibly during the bit transition. This may cause incorrect sampling at the host. For this reason, the measurement delay should usually be incremented by one before it is used to calculate the reverse rate divisor.

The reverse rate divisor is the number of MDDI_Stb cycles that the host should wait before sampling reverse link data. Because the cycle rate of MDDI_Stb is the forward link speed Therefore, the corrected round-trip delay measurement needs to be divided by 2, and then rounded to the next integer. Express this relationship as a system of equations:<maths><img file="TWI374635B_D0015.tif" /></maths>

For the given example, this becomes:<maths><img file="TWI374635B_D0016.tif" /></maths>

If the round-trip delay used in this example is measured as 7 instead of 6, the reverse rate divisor will also be equal to 4.

The host samples the reverse link data on the rising edge of the reverse link clock (Reverse Link Clock). Both the host and the client (display) have counters or similar well-known circuits or devices to generate the reverse link clock. The counters are initialized so that the first rising edge of the reverse link clock appears at the beginning of the first bit in the reverse link packet field of the reverse link encapsulated packet. Figure 52 illustrates this situation with the example given below. The counters are incremented at each rising edge of the MDDI_Stb signal, and the number of counts that occur until the count wraps around is set by the reverse rate divisor parameter in the reverse link encapsulation packet. Since the MDDI_Stb signal toggles at half of the forward link rate, the reverse link rate is half of 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 rate is expressed as:<maths><img file="TWI374635B_D0017.tif" /></maths>

Figure 52 shows an example showing the timing of the MDDI_Data0 and MDDI_Stb signal lines in the reverse link encapsulation packet, where the packet parameters used for illustration have the following values: packet length=1024 (0x0400) turn to 1 length=1 packet type=65 (0x41) Turn to 2 Length = 1 Reverse Link Flag = 0 Reverse Rate Divisor = 2 Parameters CRC = 0xdb43 All zeros are 0x00

The packet data between the packet length and the parameter CRC field is: 0x00, 0x04, 0x41, 0x00, 0x02, 0x01, 0x01, 0x43, 0xdb, 0x00,...

The first reverse link packet returned from the display is a display request and status packet, which has a packet length of 7 and a packet type of 70. This packet starts with the byte value 0x07, 0x00, 0x46,... etc. However, only the first byte (0x07) is visible in Figure 52. In the figure, the first reverse link packet is offset in time close to a reverse link clock cycle to illustrate the actual reverse link delay. The dashed trace shows an ideal waveform in which the round-trip delay from the host to the display is zero.

The MS byte of the transmission parameter CRC field, the front of which is the packet type, and the back is the all zero field. When the data from the host changes the level, the strobe from the host switches from one to zero, and then back to one, thereby forming a wider pulse. When the data enters zero, the strobe switches at a higher rate, and only data changes on the data line cause changes near the end of the alignment field. For the rest of the figure, since the data signal is at a fixed 0 or 1 level for an extended period of time, the strobe switches at the higher rate, and the transitions fall On this pulse pattern (edge).

When the reverse link clock for the host starts to adapt to the reverse link packet, the clock stays at zero until the end of the turnaround cycle. The arrow in the lower part of the figure indicates when the data was sampled, as will be understood from the rest of this manual. The figure shows that the first byte of the transmitted packet field (here, 11000000) starts after turning 1, and the line level has stabilized since the disabled host driver. The delay in the path of the first bit can be seen in the dashed line of the data signal, as seen in bit three.

In Figure 53, you can observe the typical value of the reverse rate divisor based on the forward link data rate. The actual reverse rate divisor is determined as the result of the round-trip link measurement to ensure correct reverse link operation. The first area 5302 corresponds to a safe operation area, the second area 5304 corresponds to the marginal performance area, and the third area 5306 indicates settings that are unlikely to operate correctly.

Use any interface type setting operation on the forward or reverse link, the round-trip delay measurement is the same as the reverse rate divisor setting, because it is expressed in the actual clock cycle rather than the number of bits sent or received. And operation.

XI. Steering and protection time

As mentioned earlier, the turn 1 field in the reverse link encapsulation packet and the guard time 1 field in the round-trip delay measurement packet specify the time length value, which allows the host interface driver to be disabled before the display interface driver is activated. The Steering 2 and Guard Time 2 fields provide time values that allow the display driver to be deactivated before the host driver is activated. The guard time 1 and guard time 2 fields are generally filled with preset or pre-selected length values, and it is not desired to adjust these values. Depends on In the interface hardware used, empirical data can be used to form these values, and in some cases, these values can be adjusted to improve operation.

Several factors jointly determine the length of the turn to 1. These factors are the forward link data rate and the maximum deactivation time of the MDDI_Data driver in the host. The maximum host driver deactivation time is specified in Table XI, which shows that the drivers take a maximum of approximately 10 nanoseconds to deactivate and approximately 2 nanoseconds to activate. The maximum number of forward link clocks required to disable the host driver is expressed according to the following relationship:<maths><img file="TWI374635B_D0018.tif" /></maths>

The allowable value range of turn 1 is expressed according to the following relationship:<maths><img file="TWI374635B_D0019.tif" /></maths>

The interface type factor is 1 for type I, 2 for type II, 4 for type III, and 8 for type IV.

Combining the above two equations, it can be seen that the interface type factor term disappears, and the transition to the 1 system is defined as:<maths><img file="TWI374635B_D0020.tif" /></maths>

For example, the 1500 Mbps Type III forward link will use the turnaround 1 delay as:<maths><img file="TWI374635B_D0021.tif" /></maths>

As the round-trip delay increases, from the time the host is disabled to the display activation The time sequence marginal improvement.

The factors that determine the length of time generally used for turn 2 are the forward link data rate, the maximum deactivation time of the MDDI_Data driver in the display, and the round-trip delay of the communication link. The calculation of the time required to disable the display driver is essentially the same as the calculation for the host driver described above, and is defined according to the following relationship:<maths><img file="TWI374635B_D0022.tif" /></maths>

And the allowable value range for turn 2 is expressed as:<maths><img file="TWI374635B_D0023.tif" /></maths>

For example, a 1500 Mbps Type III forward link with a round-trip delay of 10 forward link clocks usually uses turn 2 delays at the following levels:<maths><img file="TWI374635B_D0024.tif" /></maths>

XII. Alternative reverse link timing

Although the use of the above timing and guard bands can achieve a high data transmission rate interface, the inventor has discovered a technique by changing the reverse timing to find that the technique allows the reverse rate length to be shorter than the round-trip time.

As explained above, the previous method for reverse link timing is configured to count the number of clock cycles from the last bit of the guard time 1 of the reverse timing packet until it is sampled on the rising edge of an IO clock. Until the first digit. It is a clock signal used to time the input and output of the MDD interface. Therefore, the calculation system used for the reverse rate divisor is given as:<maths><img file="TWI374635B_D0025.tif" /></maths>

This provides a bit width equal to the round-trip delay and can result in a very reliable reverse link. However, it has been shown that the reverse link can run faster, or run at a higher data transmission rate, and the inventor hopes to take advantage of this. New creative technology allows the use of additional capabilities of the interface to achieve higher speeds.

This is achieved by allowing the host to count the number of clock cycles until one is sampled, and the host samples the data lines on the rising and falling edges during the reverse timing packet. This allows the host to select the most useful or even the best sampling point in the reverse bit to ensure bit stability. That is, for reverse flow and reverse encapsulation of the packet, find the most useful or best rising edge of the sampled data on it. The best sampling point depends on the reverse link divisor and whether the first one is detected on the rising or falling edge. The new timing method allows the host to only look for the first edge of the 0xFF 0xFF 0x00 pattern sent by the user to determine where in the reverse encapsulation packet to sample.

Figure 64 illustrates an example of the arrival of the reverse bit and how various reverse rate divisors are found for that bit. It also illustrates the number of clock cycles that have occurred since the last bit of guard time 1. As can be seen from Figure 64, if the first edge appears Between a rising and falling edge (marked as rising/falling), for the best sampling point where the reverse rate divisor is one, the best sample point is the edge of the clock cycle marked "b" because it is The only rising edge that occurs in the reverse bit period. For the reverse rate divisor of two, the best sampling point may still be the front edge "b" of the clock cycle, because the cycle edge "c" is closer to the bit edge than "b". For the reverse rate divisor of four, the best sampling point may be the front edge "d" of the clock cycle because it is closer to the back edge of the reverse bit whose value may have stabilized.

Referring again to Figure 64, if the first edge occurs between a falling and rising edge (marked as falling/rising), then the best sampling point for the reverse rate divisor is one is the sampling point clock period edge "a ", because it is the only rising edge that appears in the reverse bit time period. For the reverse rate divisor of two, the best sampling point is the edge "b", and for the reverse rate divisor of four, the best sampling point is the edge "c".

It can be seen that as the reverse rate divisor becomes larger and larger, the determination or selection of the best sampling point becomes easier because it should be the rising edge closest to the middle.

The host can use this technique to find the number of rising clock edges before the rising data edge of the timing packet data is observed on the data line. Then according to whether the edge occurs between a rising and falling edge or a falling and rising edge, and what the reverse rate divisor is, it can be determined how many extra clock cycles need to be added to a number counter, so as to reasonably Make sure to sample the bit at the edge as close as possible to the middle.

Once the host has selected or determined the number of clock cycles, it can communicate with the client "Explore" various reverse rate divisors to determine whether a specific reverse rate divisor can work. The host (and the client) can check the CRC of the reverse state packet received from the client at the beginning of the divisor to determine whether the reverse rate can operate properly to transmit data. If the CRC is corrupted, there may be a sampling error, and the host can increase the reverse rate divisor and try to request the status packet again. If the packet of the second request is destroyed, the divisor can be increased again and the request can be made again. If the packet is correctly decoded, the reverse rate divisor can be used for all future reverse packets.

This method is effective and useful because the reverse timing should not deviate from the initial round-trip timing estimate. If the forward link is stable, the user end should continue to decode forward link packets, even if there is a reverse link failure. Of course, the host is still responsible for setting the reverse link divisor for the link, because this method does not guarantee a perfect reverse link. In addition, the divisor will mainly depend on the quality of the clock used to generate the IO clock. If the clock has a significant amount of jitter, there is a greater probability of sampling errors. This error probability increases as the amount of clock cycles in the round-trip delay increases.

This implementation is best for type I reverse data, but it may cause problems for type II to type IV reverse data, because the skew between the data lines may be very large, and the link cannot be used for only one The data pair runs for the best data rate. However, even with Type II to Type IV operation, the data rate may not need to be reduced to the level of the previous method. If this method is used on each data line to select the ideal or optimal clock sample position, this method can also work best. If it is at the same sample time for each data line, this method will continue to operate. If it is in a different sample period, Two different methods can be used. The first method is to select an ideal or better sample location for each data point, even if it is different for each data pair. Then, after sampling all the bits from the set of data pairs: type II two bits, type III four bits, and type IV eight bits, the host can reconstruct the data stream. Another option is to let the host increase the reverse rate divisor so that the data bits of each data pair can be sampled at the same clock edge.

XIII. The influence of link delay and skew

The delay skew between the MDDI_Data pair and MDDI_Stb on the forward link can limit the maximum possible data rate, unless delay skew compensation is used. The delay differences that cause timing skew are due to the controller logic, line drivers and receivers, and the cables and connectors described below.

A. Link timing analysis of skew limitation (Type I MDDI)

1. Delay and skew examples of Type I link

Figure 57 shows a typical interface circuit similar to that shown in Figure 41, which is used to cope with Type I interface links. Fig. 57 shows exemplary or typical values of propagation delay and skew at several processing or interface levels of the I-type MDDI forward link. The delay skew between MDDI_Stb and MDDI_Data0 causes distortion of the duty cycle of the output clock. The data at the D input of the receiver flip-flop (RXFF) stage using flip-flops 5728, 5732 must be slightly changed after the clock edge in order to be reliably sampled. The figure shows two-stage delay lines 5732a and 5732b, which are used to solve two different problems related to establishing this timing relationship. In actual implementation, the delay lines can be incorporated into a single delay element.

Figure 58 illustrates the data, strobe and clock recovery timing for exemplary signal processing through the interface on the Type I link.

Significant total delay skew generally originates from or comes from the sum of the skew of the following stages: transmitter flip-flop (TXFF) with flip-flops 5704 and 5706; transmitter driver (TXDRVR) with drivers 5708 and 5710; cable 5702; Receiver line receiver (RXRCVR) with receiver 5722, 5724; and Receiver XOR logic (RXXOR). The delay 1 5732a should match or exceed the delay of the XOR gate 5736 in the RXXOR level, which is determined by the following relationship:<maths><img file="TWI374635B_D0026.tif" /></maths>

This requirement needs to be met so that the D input of the receiver flip-flops 5728 and 5732 will not change before the clock input. If the hold time of RXFF is zero, this is valid.

The purpose or function of delay 2 is to compensate the holding time of the RXFF flip-flop according to the following relationship: t_{PD-min(Delay2)}=t_H(RXFF)

In many systems, this will be zero because the hold time is zero. Of course, in this case, the maximum delay of delay 2 can also be zero.

The worst case that causes skew in the receiver XOR stage is the data-late/strobe-early case, where the delay 1 is at the maximum, and the clock output from the XOR gate is as early as possible according to the following relationship: t_{SKEW-max(RXXOR)}=t_{PD-max(Delay1)}-t_PD-min(XOR)

In this case, the data can change between two-bit periods (n and n+1), which is very close to the time when the bit n+1 is clocked to the receiver flip-flop.

The maximum data rate (minimum bit period) of the Type I MDDI link is the maximum skew encountered by all drivers, cables and receivers in the MDDI link plus The function of the overall data set in the RXFF level. The total delay skew in the link up to the output of the RXRCVR stage can be expressed as: t_{SKEW-max(LINK)}=t_{SKEW-max(TXFF)}+t_{SKEW-max(TXDRVR)}+t_{SKEW-max(CABLE)}+t_{SKEW-max(RXRCVR)}

And the minimum bit period system is given as: t_BIT-min=t_{SKEW-max(LINK)}+t_{SKEW-max(RXXOR)}+t_{PD-max(Delay)}+t_SU(RXFF)

In the example shown in Figure 57, t_{SKEW-max(LINK)}=1.4 nanoseconds, and the minimum bit period can be expressed as: t_BIT-min=1.4+0.3+0.2+0.5=2.4 nanoseconds, or expressed as about 416 Mbps.

B. Link timing analysis for Type II, Type III and Type IV MDDI

Figure 59 shows a typical interface circuit similar to that shown in Figures 41 and 57, which is used to cope with Type II, Type III, and Type IV interface links. TXFF (5904), TXDRVR (5908), RXRCVCR (5922) and RXFF (5932, 5928, 5930) levels use additional components to cope with additional signal processing. Fig. 59 shows exemplary or typical values of the propagation delay and skew of several processing or interface levels of the Type II MDDI forward link. In addition to the delay skew between MDDI_Stb and MDDI_Data0 that affects the duty cycle of the output clock, there is also a skew between these two signals and other MDDI_Data signals. The data at the D input of the receiver flip-flop B (RXFFB) stage composed of flip-flops 5928 and 5930 is slightly changed after the clock edge, so that reliable sampling can be obtained. If MDDI_Data1 arrives earlier than MDDI_Stb or MDDI_Data0, the sampling of MDDI_Data1 should be delayed, and the delay amount should be at least equal to the delay skew amount. To achieve For this purpose, the delay 3 delay line is used to delay the data. If MDDI_Data1 arrives later than MDDI_Stb and MDDI_Data0, the delay 3 should also delay MDDI_Data1, so that the change point of MDDI_Data1 is closer to the next clock edge. This process determines the upper limit of the data rate of Type II, Type III, or Type IV MDDI links. FIGS. 60A, 60B, and 60C illustrate some exemplary different possibilities of the timing or skew relationship between the two data signals and MDDI_Stb.

In order to reliably sample the data in RXFFB when MDDI_DataX arrives as early as possible, the delay 3 is set according to the following relationship:<maths><img file="TWI374635B_D0027.tif" /></maths>

The minimum allowable bit period determines the maximum link speed. This is most affected when MDDI_DataX arrives as late as possible. In this case, the minimum allowable cycle time is given as: t_BIT-min=t_{SKEW-max(LINK)}+t_{PD-max(Delay3)}+t_SU(RXFFB)-t_PD-min(XOR)

The upper limit of the link speed is: t_{PD-max(Delay3)}=t_{PD-min(Delay3)}

And suppose: t_{BIT-min(lower-bound)}=2. t_{SKEW-max(LINK)}+t_PD-max(XOR)+t_SU(RXFFB)-t_H(RXFFB)

In the example given above, the lower limit of the minimum bit period is given by the following relationship: t_{BIT-min(lower-level)}= 2.1.4+1.5+0.5+0.1=4.8 nanoseconds, which is approximately 208 Mbps.

This is far below the maximum data rate that can be used for Type I links. MDDI's automatic delay skew compensation capability significantly reduces the impact of delay skew on the maximum link rate ring.

XIV. Physical layer interconnection description

Use commercial parts, for example, the host uses the part numbered 3260-8S2(01) manufactured by Hirose Electric Co., Ltd., and the display device uses the part numbered 3240-8P-C manufactured by Hirose Electric Co., Ltd., which can be used for implementation. According to the physical connection of the interface of the present invention. Table XIII lists and Figure 61 illustrates exemplary interface pin assignments or "pin layouts" for this type of connector for Type I/Type II interfaces.

<tables><img file="TWI374635B_D0028.tif" /></tables>

The shield is connected to the MDDI_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 display.

Choosing or designing interconnection elements or devices so that they are small enough to be used in mobile communication and computing devices, such as PDAs and wireless phones, or portable gaming devices, so as not to appear prominent or unsightly compared to the size of related devices. Any connector and cable should be durable enough to be suitable for use in normal consumer environments, and allow small size (especially for cables) and relatively low cost. The transmission component should be able to handle the data and strobe signals of the differential NRZ data type. Its transmission rate for Type I and Type II is as high as about 450 Mbps, and for 8-bit parallel The Type IV version is up to 3.6 Gbps.

XV. Operation

54A and 54B show a summary of the general steps taken to process data and packets during an interface operation using a specific embodiment of the present invention, and FIG. 55 schematically shows the interface device for processing these packets. In this diagram, the process starts with step 5402 to determine whether the user terminal and the host are connected using a communication path (here, a cable). This can be done by the host using periodic polling. The host uses software or hardware that detects the presence of a signal at the connector or cable or input of the host (as seen from the USB interface), or other well-known technologies . If no client is connected to the host, it can simply enter a waiting state of a predetermined length (depending on the application), enter sleep mode, or deactivate for future use (this may require the user to take action to restart the host ). For example, when the host resides on a computer-type device, the user may need to click on a screen icon or request a program that initiates host processing to find the client. Similarly, simply plugging in a USB type connection, such as for a U-shaped interface, can start host processing, depending on the capabilities and configuration of the host or host software that resides.

Once the client is connected to the host or vice versa, or the presence of the client is detected, the client or host will send appropriate packets in steps 5404 and 5406 to request services. In step 5404, the user terminal can transmit a display service request or status packet. It should be noted that, as described above, the link may have been previously closed or in a sleep mode, so the initialization may not be the complete initialization of the communication link described below. Once the communication link is synchronized and the host attempts to communicate with the client, the client will also provide a display capability packet to the host, as in step 5408 in. The host can now determine the type of support that the client can handle, including the transfer rate.

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

As mentioned earlier, all transmissions start with a subframe header packet, as shown in step 5412, followed by data type (here, video and audio stream packets) and filler packets, as shown in step 5414Of Transmission. Audio and video data are previously prepared or mapped in packets, and filler packets are inserted as needed to fill the required number of bits in the media frame. The host can send a packet such as a forward audio channel activation packet to activate the audio device. In addition, the host can use the above-mentioned other packet types to transmit commands and information. Here, in step 5416, it is displayed as transmission color mapping, bit block transmission, or other packets. In addition, the host and the client can use appropriate packets to exchange data about the keyboard or pointing device.

During operation, one of several different events may occur, which causes the host or client to require a different data rate or interface mode type. For example, computers or other data-transmitting devices may encounter loading conditions when processing data, causing the preparation or presentation of packets to slow down. The display receiving the data may be switched from a dedicated AC power supply to a more limited battery power supply, the display may not be able to transmit data, process commands as quickly as possible, or use the same resolution or color depth under a more limited power setting. Or, restrictive clause Files may be eased or disappear, allowing any device to transmit data at a higher rate. This is more in line with needs, and a request can be made to switch to a higher transmission rate mode.

If these or other types of well-known conditions occur or change, the host or client can detect these conditions and try to renegotiate the interface mode. This is shown in step 5420, where the host sends the interface type handover request packet to the client, requesting handover to another mode, and the client sends the interface type confirmation packet to confirm the request for change, and then the host sends the execution type handover packet To switch to the specified mode.

Although no specific processing sequence is required, the client and the host can also exchange packets related to data sent to or received from pointing devices, keyboards or other user-type input devices mainly associated with the client. Of course, such components are also available. May exist on the host side. Generally, general-purpose processor-type components are used instead of a state machine (5502) to process these packets. In addition, general-purpose processors (5504, 5508) can also process some of the above commands.

After data and commands are exchanged between the host and the client, a decision is made at some point as to whether additional data needs to be transmitted or whether the host or the client will stop serving the transmission. This system is shown in step 5422. If the link enters the dormant state or shuts down completely, the host will send the link closed packet to the user end, and then both ends will terminate the data transmission.

The packets transmitted in the above operation process will be transmitted using the drivers and receivers previously discussed about the host and the client controller. The line drivers and other logic elements are connected to the above-mentioned state machine and general-purpose processor, as outlined in FIG. 55. In Figure 55, the state machine 5502 can be further connected to the communication Use processors 5504 and 5508 to connect to other components not shown in the figure, such as dedicated USB interfaces, memory components, or other components that reside outside the link controller and interact with it, including (but not limited to) data sources, And the video control chip used to view the display device.

The processor and the state machine provide the control to activate and deactivate the driver, as discussed above on the guard time, etc., to ensure the effective establishment or termination of the communication link and the transmission of the packet.

XVI. Appendix

In addition to the above-mentioned format, structure, and content of the architectures and protocols used for various packets to implement specific embodiments of the present invention, the following will describe the field content or operations of some packet types in more detail. This description is used to further clarify its individual use or operation, so that those skilled in the art can more easily understand the present invention and use the present invention in various applications. Only a few fields that have not been discussed are further discussed here. In addition, exemplary definitions and values will be used to illustrate these fields with respect to the above-mentioned specific embodiments. However, such values should not be considered as limitations to the present invention, but represent one or more specific embodiments for implementing interfaces and protocols, and it is not necessary to implement all specific embodiments together or at the same time. In other specific embodiments, other values can be used to achieve the desired presentation of the data or data rate transmission results, and those skilled in the art should understand this.

A. Video stream packet

In a specific embodiment, the display attribute field (1 byte) has a series of bit values, and the explanation is as follows. Bits 1 and 0 select how to route display pixel data. For the bit value "00" or "11", the data is displayed for both eyes; for the bit value "10", the data is only routed to the left eye; for the bit value "01", the data is only routed to the right eye. Bit 2 indicates whether to present the pixel data in an interlaced format, where the value "0" indicates that the pixel data is in the standard progressive format, and when it advances from one row to the next, the row number (pixel Y coordinate) is incremented by 1. If this bit has the value "1", the pixel data is in the interlaced format, and when advancing from one row to the next, the row number is incremented by 2. Bit 3 indicates that the pixel data is in alternate pixel format. This is similar to the standard interlace mode activated by bit 2, but the interlace is vertical rather than horizontal. If bit 3 is 0, the pixel data is in the standard progressive format, and each time a continuous pixel is received, the row number (pixel X coordinate) is incremented by 1. If bit 3 is 1, the pixel data is in alternate pixel format, and each time a pixel is received, the row number is incremented by 2. Bits 7 to 4 are reserved for future use and are generally set to zero.

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

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

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

The pixel data field includes the original video information to be displayed, and it is formatted in the manner described in the video data format descriptor field. As described elsewhere, the data is sent one "row" at a time.

Pixel data CRC field (2 bytes) only includes 16 bits of pixel data CRC. If the CRC verification of this value fails, the pixel data can still be used, but the CRC error count will increase.

B. Audio stream packet

In a specific embodiment, the audio channel ID field (1 byte) identifies the specific channel to which the client device sends audio data. The physical audio channel is specified in this field or mapped by this field. The value is 0, 1, 2, 3, 4, 5, 6 or 7, indicating the left front, right front, left rear, right rear, front center, Sub-bass, left surround, right surround channels. The audio channel ID value 254 indicates that a single digital audio sample stream is sent to the front left and front right channels. This can simplify applications that use stereo headsets for voice communication, productivity enhancement applications used on PDAs, or other applications that generate warning sounds through a simple user interface. ID field values ranging from 8 to 253 and 255 are currently reserved for new designs that require additional designation.

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

The bit and packing field of each sample includes 1 byte, which specifies the stride format of the audio data. The generally used format is bits 4 to 0 to define the number of bits per PCM audio sample. Then bit 5 specifies whether the digital audio data sample is packaged. As mentioned above, FIG. 12 illustrates the difference between the packed audio sample and the byte-aligned audio sample. The value "0" of bit 5 indicates that each PCM audio sample in the digital audio data field is aligned with the interface byte boundary system byte, and the value "1" indicates that each successive PCM audio sample is aligned with the previous The audio samples are packed. This bit is only valid when the value defined in bits 4 to 0 (the number of bits per PCM audio sample) is not a multiple of eight. Bits 7 to 6 are reserved It is used for systems that require additional designation, and is generally set to a value of zero.

The audio sample rate field (1 byte) specifies the audio PCM sample rate. The format used is that a value of 0 indicates a sampling rate of 8,000 samples per second (samples per second; sps), a value of 1 indicates 16,000 sps, a value of 2 indicates 24,000 sps, a value of 3 indicates 32,000 sps, a value of 4 indicates 40,000 sps, and a value of 5 It indicates 48,000 sps, a value of 6 indicates 11,025 sps, a value of 7 indicates 22,050 sps, and a value of 8 indicates 44,100 sps, values 9 to 15 are reserved for future use, so the current system is set to zero.

The parameter CRC field (2 bytes) includes the 16-bit CRC of all bytes from the packet length to the audio sample rate. If the CRC check is incorrect, the entire packet is discarded. The digital audio data field includes the original audio samples to be played, and is usually in the form of an unsigned integer linear format. The audio data CRC field (2 bytes) only includes the 16-bit CRC of the audio data. If the CRC check is incorrect, the audio data can still be used, but the CRC error count will increase.

C. User-defined stream packets

In a specific embodiment, the 2-byte stream ID number field is used to identify a specific user-defined stream. The contents of the stream parameters and stream data fields are usually defined by the MDDI equipment manufacturer. The 2-byte stream parameter CRC field includes the 16-bit CRC of all bytes from the packet length to the stream parameter of the audio coding byte. If the CRC check is incorrect, the entire packet is discarded. The 2-byte stream data CRC field only includes the CRC of the stream data. If this CRC is not properly checked, the use of stream data is optional and depends on the needs of the application. The use of stream data depending on whether the CRC is good or not generally requires buffering the stream data until it is confirmed that the CRC is good. If the CRC is not checked, then increment the CRC Error count.

D. Color mapping packet

The color mapping data size field (2 bytes) specifies the total number of color mapping table entries in the color mapping data in this packet. In this specific embodiment, the number of bytes in the color map data is 3 times the size of the color map. The color map size is set to be equal to zero, so that color map data is not transmitted. If the color mapping size is zero, the color mapping offset will generally be transmitted, but the display will ignore the color mapping offset. The color mapping offset field (2 bytes) specifies the offset between the color mapping data in this packet and the start of the color mapping table in the display device.

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

For the color mapping data field, each color mapping position is a 3-byte value, where the first byte specifies the amplitude of blue, the second byte specifies the amplitude of green, and the third byte specifies the amplitude of red . The color mapping size field specifies the number of 3-byte color mapping table items existing in the color mapping data field. If a single color map cannot be put into a video data format and color map packet, the entire color map can be specified by transmitting multiple packets, each of which has different color map data and color map offsets.

The 2-byte color mapping data CRC field only includes the CRC of the color mapping data. If the CRC check is incorrect, the color mapping data can still be used, but the CRC error count will increase.

E. Reverse link encapsulation packet

In a specific embodiment, the reverse link flag field (1 byte) includes A set of flags to request information from the display. If a bit (for example, bit 0) is set to one, the host will use the display capability packet to request the specified information from the display. If the bit is zero, the host does not need information from the display. The remaining bits (bits 1 to 7) are reserved for future use and are set to zero. However, more bits can be used as needed to set the flag for the reverse link.

The reverse rate divisor field (1 byte) specifies the number of MDDI_Stb cycles that occur with respect to the reverse link data clock. The reverse link data period is equal to the forward link data clock divided by two times the reverse rate divisor. The reverse link data rate is related to the reverse reverse link data clock and the interface type on the reverse link. For Type I interface, the reverse data rate is equal to the reverse link data clock; for Type II, Type III, and Type IV interfaces, the reverse data rate is equal to twice, four times, and eight times the reverse link data time. pulse.

The Turn 1 Length field (1 byte) specifies the total number of bytes allocated to Turn 1. The recommended length of turn 1 is the number of bytes required by the MDDI_Data driver in the host to disable the output. This is based on the aforementioned output disable time, forward link data rate, and the type of forward link interface used. A more complete description of the steering 1 setting will be given below.

The Turn 2 Length field (1 byte) specifies the total number of bytes allocated to the turn. The recommended length of Turn 2 is the number of bytes required by the MDDI_Data driver in the display to disable its output plus the round-trip delay. The description of the steering 2 setting will be given below.

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

The all-zero field (1 byte) is set equal to zero, and is used to ensure that all MDDI_Data signals are in the zero state before the line driver is disabled during the first protection time period.

The turn 1 field is used to establish the first turn cycle. This field allocates the number of bytes specified by the steering length parameter to allow the MDDI_Data line driver in the host to be disabled before the line driver in the user terminal is activated. The host disables its MDDI_Data line driver during the turn to bit 0 of 1, and the user terminal (display) activates its line driver immediately after turning to the last bit of 1. The MDDI_Stb signal behaves as if the steering cycle is all zero.

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

The turn 2 field is used to establish the second turn cycle. This field allocates the number of bytes specified by the steering length parameter.

The driver reactivation field uses 1 byte, which is equal to zero, to ensure that all MDDI_Data signals are reactivated before the packet length field of the next packet.

F. Display Capability Packet

In a specific embodiment, the protocol version field uses 2 bytes to specify the protocol version used by the client. The initial version is set to be equal to zero, and the minimum protocol version field uses 2 bytes to specify the minimum protocol version that can be adopted or interpreted by the client. The Display Data Rate Capability field (2 bytes) specifies the maximum data rate that the monitor can receive on the forward link of the interface, and is specified in the form of megabits per second (Mbps). Interface type capability field (1 bit Group) Specify the interface types supported on the forward and reverse links. The current indication of this field is: select bit 0, bit 1, or bit 2 to select type II, type III, or type IV mode on the forward link respectively, select bit 3, bit 4, or bit 5 and above The type II, type III, or type IV mode on the reverse link is selected respectively, and bits 6 and 7 are reserved and set to zero. The bitmap width and height fields (2 bytes) specify the width and height of the bitmap in the pixel.

The monochrome capability field (1 byte) is used to specify the number of bits of the resolution that can be displayed in the monochrome format. If the monitor cannot use the monochrome format, set this value to zero. Bits 7 to 4 are reserved for future use, so they are set to zero. Bits 3 to 0 define the maximum number of grayscale bits that can exist for each pixel. These four bits make it possible to specify a value between 1 and 15 for each pixel. If the value is zero, the monitor does not support the monochrome format.

The color mapping capability field (3 bytes) specifies the maximum number of table items in the color mapping table in the display. If the monitor cannot use the color mapping format, this value is zero.

The RGB capability field (2 bytes) specifies the number of bits of the resolution that can be displayed in the RGB format. If the monitor cannot use the RGB format, this value is equal to zero. The RGB capability character consists of three separate unsigned values. In each pixel: 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 the maximum number of red bits. Currently, bits 15 to 12 are reserved for future use, and are generally set to zero.

The Y Cr Cb capability field (2 bytes) specifies the number of bits of resolution that can be displayed in the Y Cr Cb format. If the display cannot use the Y Cr Cb format, then this The value system is set equal to zero. The Y Cr Cb capability character consists of three separate unsigned values, where bits 3 to 0 define the maximum number of bits in the Cb sample, and bits 7 to 4 define the maximum number of bits in the Cr sample. Bits 11 to 8 define the maximum number of bits in the Y sample, and bits 15 to 12 are currently reserved for future use and are set to zero.

The display feature capability indicator field uses 4 bytes, which includes a set of flags to indicate specific features supported in the display. One bit is set to one indicator to support the ability, and one bit is set to zero to indicate that the ability is not supported. The value of bit 0 indicates whether bit-mapped block transmission packets are supported (packet type 71). The values of bits 1, 2, and 3 respectively indicate whether to support bit-mapped area filling packets (packet type 72), bit-mapped pattern filling packets (packet type 73), or communication link data channel packets (packet type 74). The value of bit 4 indicates whether the display is capable of making a color transparent, while the values of bits 5 and 6 respectively indicate whether the display can accept video data or audio data in the packaging format, and the value of bit 7 indicates whether the display can read from the camera Transmit reverse link video stream. The values of bits 11 and 12 respectively indicate when the client communicates with the pointing device and can send and receive data packets of the pointing device or when it communicates with the keyboard and can send and receive keyboard data packets. Bits 13 to 31 are currently reserved for future use or as an alternative designation by the system designer, and are generally set to zero.

The display video frame rate capability field (1 byte) specifies the maximum video frame update capability of the display, in units of frames per second. The host can select an update rate lower than the value specified in this field to update the image.

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

The audio channel capability field (2 bytes) includes a set of flags, which indicate which audio channels the display (client) supports. One bit is set to indicate that the channel is supported, and one bit is set to zero to indicate that the channel is not supported. Bit positions are assigned to different channels. For example, bit positions 0, 1, 2, 3, 4, 5, 6, and 7 indicate front left, front right, back left, back right, center front, subwoofer, surround left, and Right surround channel. Bits 8 to 15 are currently reserved for future use, and are generally set to zero.

The 2-byte audio sample rate capability field for the forward link includes a set of flags indicating the audio sample rate capability of the client device. Bit positions are assigned to different sample rates accordingly, for example, bits 0, 1, 2, 3, 4, 5, 6, 7, and 8 are assigned to 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, respectively , 22,050 and 44,100 samples per second (SPS), and bits 9 to 15 are reserved for future use or as an alternative sample rate as needed, so they are currently set to "0". Setting the bit value of one of these bits to "1" indicates that the specific sample rate is supported, and setting the bit to "0" indicates that the sample rate is not supported.

The minimum sub-frame rate field (2 bytes) specifies the minimum sub-frame rate in units of frames per second. The minimum sub-frame rate keeps the display status update rate sufficient to read some sensors or pointing devices in the display.

The 2-byte microphone sample rate capability field for the reverse link includes a set of flags that indicate the audio sample rate capability of the microphone in the client device. For the purpose of MDDI, the client device microphone is configured to support at least a sample rate of at least 8,000 samples per second. The bit positions of this field are assigned to different sample rates, among which bit positions are 0, 1, 2, 3, 4, 5, 6, 7, and 8. They are used to represent (for example) 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, and 44,100 samples per second (SPS), respectively, and bits 9 to 15 are reserved for future use or as alternative samples as needed Therefore, it is currently set to "0". Setting the bit value of one of these bits to "1" indicates that the specific sample rate is supported, and setting the bit to "0" indicates that the sample rate is not supported. If the microphone is not connected, the sample rate capability bits of each microphone are set to be equal to zero.

The content protection type field (2 bytes) includes a set of flags that indicate the type 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 reserved for other protection schemes that are needed or available. Therefore, these bits The element system is currently set to zero.

G. Display request and status packet

The reverse link request field (3 bytes) specifies the number of bytes required for the display to send information to the host in the reverse link in the next sub-frame.

The CRC error count field (1 byte) indicates how many CRC errors have occurred since the start of the media frame. When sending a sub-frame header packet with a sub-frame count of zero, reset the CRC count. If the actual number of CRC errors exceeds 255, this value is generally saturated to 255.

The ability change field uses 1 byte to indicate the ability of the display to change. This may happen if the user connects a peripheral device, such as a microphone, keyboard, or display, or for some other reasons. If the bit [7:0] is equal to 0, the display capability has not changed since the last display capability packet was transmitted. However, if the bit [7:0] is equal to 1 to 255, the display capability has been changed. Check the display capability packet to determine new display characteristics.

H. Bit block transmission packet

The X value and Y value fields of the upper left coordinate of the window use 2 bytes, each of which is used to specify the X and Y values of the upper left coordinate of the window to be moved. The window width and height fields use 2 bytes, each of which is used to specify the width and height of the window to be moved. The window X movement and Y movement fields use 2 bytes to specify the number of pixels to move the window in the horizontal and vertical directions, respectively. Generally speaking, the coordinate systems are configured such that when X is a positive value, it causes the window to move to the right, when it is a negative value, it causes the window to move to the left, and when Y is a positive value, it causes the window to move downward, and when it is a negative value, it causes the window to move upward. .

I. Fill the packet with bit map area

The X value and Y value fields of the upper left coordinate of the window use 2 bytes, and each is used to specify the X and Y values of the upper left coordinate 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 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 filling value field (4 bytes) includes the pixel value to be filled in the window specified by the above field. The format of this pixel is specified in the video data format descriptor field.

J. Bit-mapped pattern fill packet

The X value and Y value fields of the upper left coordinate of the window use 2 bytes, and each is used to specify the X and Y values of the upper left coordinate 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 and pattern height fields (2 bytes each) specify the width and height of the filling pattern respectively Spend. The 2-byte video data format descriptor field specifies the format of the pixel area padding value. Figure 11 illustrates how to encode the video data format descriptor. The format is the same as the same field in the video stream packet.

The parameter CRC field (2 bytes) includes the CRC of all the bytes from the packet length to the video format descriptor. If the CRC check is incorrect, the entire packet is discarded. The pattern pixel data field includes original video information, which specifies the filling pattern of the format specified by the video data format descriptor. The data is packed into bytes, and the first pixel of each row must be aligned with the byte. The fill pattern data is sent one row at a time. The pattern pixel data CRC field (2 bytes) only includes the pattern pixel data CRC. If the CRC check is incorrect, the pattern pixel data can still be used, but the CRC error count will increase.

K. Communication link data channel packet

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

The communication link data field includes the original data from the communication channel. This data is simply passed to the computing device in the display.

The communication link data CRC field (2 bytes) only includes the 16-bit CRC of the communication link data. If this CRC check is incorrect, the communication link data can still be used or it is still useful, but the CRC error count will be incremented.

L. Interface type handover request packet

The interface type field (1 byte) specifies the new interface type to be used. The value in this field specifies the interface type in the following way. If the value of bit 7 is equal to "0", the type handover request is used for the forward link; if the value is equal to "1", Then the type handover request is used for the reverse link. Bits 6 to 3 are reserved for future use and are generally set to zero. Bits 2 to 0 are used to define the type of interface to be used. The value 1 means handover to type I mode, the value 2 means handover to type II mode, the value 3 means handover to type III mode, and the value 4 means Handed over to Type IV mode. The values "0" and 5 to 7 are reserved for future alternative mode designation or combination mode designation.

M. Interface type confirmation packet

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

N. Execution type handover packet

The 1-byte interface type field indicates the new interface type to be used. The value in this field specifies the interface type. First, the value of bit 7 is used to determine whether the type handover is used for the forward link or the reverse link. The value "0" indicates that the type handover request is for the forward link, and the value "1" indicates that it is for the reverse link. Bits 6 to 3 are reserved for future use, so they are generally set to the value zero. However, bits 2 to 0 are used to define the type of interface to be used, where the value is 1, 2, 3, and 4 are designated to be delivered to Type I, Type II, Type III, and Type IV modes respectively. The values 0 and 5 to 7 of these bits are reserved for future use.

O. Forward audio channel activation packet

The audio channel activation mask field (1 byte) includes a set of flags that indicate which audio channel should be activated in the client. A bit set to one activates the corresponding channel, and a bit set to zero deactivates the corresponding channel. Bits 0 to 5 specify channels 0 to 5, which are for the front left, front right, back left, back right, and subwoofer channels, respectively. Bits 6 to 7 are reserved for future use, and at the same time are generally set equal to zero.

P. Reverse audio sample rate packet

The audio sample rate field (1 byte) specifies the digital audio sample rate. The value of this field is assigned to different sample rates, where bit positions 0, 1, 2, 3, 4, 5, 6, 7 and 8 are used to specify 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, respectively , 11,025, 22,050 and 44,100 samples per second (SPS), and bits 9 to 254 are reserved for the required alternative sample rate, so they are currently set to "0". The value 255 is used to disable the reverse link audio stream.

The sample format field (1 byte) specifies the format of the digital audio sample. When the bit [1:0] is equal to "0", the digital audio sample is in linear format; when it is equal to 1, the digital audio sample is in μ-Law format; and when it is equal to 2, the digital audio sample is in A-Law format. Bits [7:2] are reserved for alternatively specifying the required audio format, and are generally set equal to zero.

Q. Digital content protection additional information package

The content protection type field (1 byte) specifies the digital content protection method used. The value "0" indicates digital transmission content protection (DTCP), and the value 1 indicates Shows the high-bandwidth digital content protection system (HDCP). The value range of 2 to 255 has not yet been specified and is reserved for the required alternative protection schemes. The content protection additional information message field is a variable length field, which includes the content protection message sent between the host and the client.

R. Transparent color actuation packet

The transparent color activation field (1 byte) specifies when to activate or deactivate the transparent color mode. If bit 0 is equal to 0, the transparent color mode is disabled; if it is equal to 1, the transparent color mode is activated, and the transparent color is specified by the following two parameters. Bits 1 to 7 of this byte are reserved for future use, and are usually set equal to zero.

The video data format descriptor field (2 bytes) specifies the format of the pixel area fill value. Figure 11 illustrates how to encode the video data format descriptor. This format is generally the same as the same field in the video stream packet.

The pixel area filling value field uses 4 bytes, which are allocated for the pixel value to be filled in the above-mentioned window. The format of this pixel is specified in the video data format descriptor field.

S. Round trip delay measurement packet

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

The all-zero field (1 byte) includes zeros to ensure that all MDDI_Data signals are in the zero state before the line driver is disabled during the first guard time period.

The guard time 1 field (8 bytes) is used to allow The MDDI_Data line driver is disabled before the line driver in the user terminal (display) is activated. The host disables its MDDI_Data line driver during bit 0 of guard time 1, and the display activates its line driver immediately after the last bit of guard time 1.

The measurement period field is a 512-byte window to allow the display to respond with 0xff, 0xff, and 0x0 at half of the data rate used on the forward link. This rate corresponds to the reverse link rate divisor 1. The display returns this response immediately at the beginning of the measurement cycle. A host will receive this response exactly when the round-trip delay of the link after the start of the first bit of the measurement period at the host is delayed. The MDDI_Data line driver in the display is disabled immediately before and after the 0xff, 0xff, and 0x00 responses from the display.

The value in the guard time 2 field (8 bytes) allows the MDDI_Data line driver at the client to be disabled before the line driver in the host is activated. Guard time 2 always exists, but it is only needed when the round-trip delay is at the maximum measurable amount in the measurement period. The user terminal disables its line driver during bit 0 of guard time 2, and the host activates its line driver immediately after the last bit of guard time 2.

The driver reactivation field (1 byte) is set equal to zero to ensure that all MDDI_Data signals are reactivated before the packet length field of the next packet.

T. Forward link skew calibration packet

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

The calibration data sequence field contains a 512-byte sequence, which causes the MDDI_Data signal to toggle in every data cycle. During the processing of the calibration data sequence, the MDDI host controller sets all MDDI_Data signals equal to the strobe signal. When the user-side display receives the calibration data sequence field, the display clock recovery circuit should only use MDDI_Stb instead of MDDI_Stb Xor MDDI_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 generally be one of the following according to the type of interface used when sending this packet: Type I-0xaa,0xaa...or 0x55,0x55 ...Type II-0xcc,0xcc...or 0x33,0x33...Type III-0xf0,0xf0...or 0x0f,0x0f...Type IV-0xff,0x00,0xff,0x00...or 0x00 ,0xff,0x00,0xff...

62A and 62B show examples of possible MDDI_Data and MDDI_Stb waveforms for Type I and Type II interfaces, respectively.

XVII. Conclusion

When different specific embodiments of the present invention have been described above, it must be understood that they are presented only by examples and are not limiting. Therefore, the breadth and scope of the present invention are not limited to any of the above-mentioned exemplary embodiments, but should be defined only according to the following patent application scope and its equivalent content.

<p>100laptop</p><p>102PDA device</p><p>108Audio Copy System</p><p>112Audio Copy System</p><p>104Display device</p><p>106Display device</p><p>114Screen</p><p>116Image Projector</p><p>110Transmission link</p><p>202Host</p><p>204Client</p><p>206Two-way communication channel</p><p>208forward link</p><p>210Reverse link</p><p>402MDDI Link Controller</p><p>502MDDI Link Controller</p><p>404MDDI Link Controller</p><p>404MDDI Link Controller</p><p>406Two-way communication channel</p><p>202'Host device</p><p>204'Client device</p><p>3502Delay</p><p>3504Delay</p><p>3600Checker</p><p>3602CRC register</p><p>3604Multiplexer</p><p>3606Multiplexer</p><p>3608NAND gate</p><p>3610NOR gate</p><p>3612mutual exclusion OR gate</p><p>3614AND gate</p><p>4002Data signal</p><p>4004Strobe signal</p><p>4006Clock signal</p><p>4100Transmission part</p><p>4102Signal path</p><p>4104Flip-Flop Circuit Components</p><p>4106Flip-Flop Circuit Components</p><p>4108Differential Line Driver</p><p>4110Differential line driver</p><p>4112mutual exclusion NOR gate</p><p>4120Receiving part</p><p>4122Differential line receiver</p><p>4124Differential line receiver</p><p>4126XOR gate</p><p>4128Flip-Flop Circuit</p><p>4130Flip-Flop Circuit</p><p>4132Delay element</p><p>4202Host Controller</p><p>4204Client Controller</p><p>4206Communication link</p><p>4210Drive</p><p>4212Drive</p><p>4214Drive</p><p>4216a, 4216b, 4216c, 4216dTerminal impedance</p><p>4218a, 4218bResistor</p><p>4220Voltage source</p><p>4230Client side receiver</p><p>4232Client Data Processing Receiver</p><p>4900State Machine</p><p>4902Get synchronization status</p><p>4904Asynchronous frame status</p><p>4906Get synchronization status</p><p>4908Synchronizing status</p><p>4910Synchronizing status</p><p>4912Synchronizing status</p><p>5502State Machine</p><p>5504,5508General Purpose Processor</p><p>5702Cable</p><p>5704,5706Flip-Flop</p><p>5708,5710Drive</p><p>5722,5724Receiver</p><p>5728,5732Reverser</p><p>5732a,5732bDelay line</p><p>5736XOR gate</p><p>5904Transmitter Flip-Flop</p><p>5908Transmitter Driver</p><p>5922Receiver line receiver</p><p>5932,5928,5930receiver flip</p>

Further characteristics and advantages of the present invention, as well as the structure and operation of various specific embodiments of the present invention, will be described in detail below with reference to the accompanying drawings. instruction. In the drawings, the same reference number usually indicates the same, functionally similar, and/or structurally similar element or processing step, and the first appearance of the element is represented by the leftmost digit in the reference number.

Figure 1A illustrates the basic environment in which a specific embodiment of the present invention can operate, including the use of a microdisplay device used in conjunction with a portable computer.

FIG. 1B illustrates the basic environment in which a specific embodiment of the present invention can operate, including the use of a micro-display device and an audio presentation element used in conjunction with a wireless transceiver.

Figure 2 illustrates the overall concept of a mobile digital data interface with host and client interconnection.

Figure 3 illustrates the packet structure used to implement data transmission from the client device to the host device.

Figure 4 illustrates the use of the MDDI link controller and the types of signals transmitted between the host and the client on the physical data link conductors used for I-type and U-type interfaces.

Figure 5 illustrates the use of the MDDI link controller and the types of signals transmitted between the host and the client on the physical data link conductors used for Type II, II, and IV interfaces.

Figure 6 illustrates the structure of the frame and sub-frames used to implement the interface protocol.

Figure 7 illustrates the general packet structure used to implement the interface protocol.

Figure 8 illustrates the format of the subframe header packet.

Figure 9 illustrates the format and content of the filler packet.

Figure 10 illustrates the format of a video stream packet.

Figure 11 illustrates the format and content of the video data format descriptor used in Figure 10 Allow.

Figure 12 illustrates the use of packaged and unpackaged data formats.

Figure 13 illustrates the format of the audio stream packet.

Figure 14 illustrates the use of byte alignment and packaging PCM data format.

Figure 15 illustrates the format of a user-defined data stream packet.

Figure 16 illustrates the format of a color mapping packet.

Figure 17 illustrates the format of the reverse link encapsulation packet.

Figure 18 illustrates the format of the Display Capability Packet.

Figure 19 illustrates the format of the keyboard data packet.

Figure 20 illustrates the format of the pointer device data packet.

Figure 21 illustrates the format of a link close packet.

Figure 22 illustrates the format of the Display Request and Status Packet.

Figure 23 illustrates the format of a bit block transmission packet.

Figure 24 illustrates the format of the bitmap area padding packet.

Figure 25 illustrates the format of a bitmapped pattern fill packet.

Figure 26 illustrates the format of a communication link data channel packet.

Figure 27 illustrates the format of the interface type handover request packet.

Figure 28 illustrates the format of the interface type confirmation packet.

Figure 29 illustrates the format of an execution type handover packet.

Figure 30 illustrates the format of a forward audio channel activation packet.

Figure 31 illustrates the format of a reverse audio sample rate packet.

Figure 32 illustrates the format of a digital content protection additional information packet.

Figure 33 illustrates the format of a transparent color activation packet.

Figure 34 illustrates the format of a round-trip delay measurement packet.

Figure 35 illustrates the timing of events in the round-trip delay measurement packet.

Figure 36 illustrates a sample implementation of the CRC generator and checker that can be used to implement the present invention.

FIG. 37A illustrates the timing of the CRC signal used in the device of FIG. 36 when transmitting data packets.

FIG. 37B illustrates the timing of the CRC signal used in the device of FIG. 36 when receiving a data packet.

Figure 38 illustrates the processing steps for a typical contention-free service request.

Fig. 39 illustrates the processing steps of a typical service request that is used to determine after the link restart sequence has started that is in competition with the link start.

Figure 40 illustrates how DATA-STB encoding can be used to send a data sequence.

Figure 41 illustrates a circuit that can be used to generate DATA and STB signals from input data at the host and then restore the data on the user side.

Figure 42 illustrates drivers and terminating resistors that can be used to implement a specific embodiment.

Figure 43 illustrates the steps and signal levels used by the client to ensure services from the host and the host to provide such services.

Figure 44 illustrates the relative interval between the transitions of data 0, other data lines (data X), and strobe lines (Stb).

FIG. 45 illustrates the presentation of response delay that can occur when the host disables the host driver after transmitting the packet.

Figure 46 illustrates the response delay that can occur after the host activates the host driver to transmit the packet.

Figure 47 illustrates the host computer between the data transmission timing and the strobe before and after the edge Receiver input relationship.

Figure 48 illustrates the switching characteristics and the corresponding client output delay developed from the reverse data timing.

Figure 49 illustrates a high-level diagram of the signal processing steps and conditions that can be synchronized using a state machine.

Figure 50 illustrates the typical amount of delay encountered in signal processing on the forward and reverse paths in a system using MDDI.

Figure 51 illustrates the marginal round-trip delay measurement.

Figure 52 illustrates the reverse link data rate change.

Figure 53 illustrates a graph of the reverse rate divisor value versus the forward link data rate.

Figures 54A and 54B illustrate the steps taken in the interface operation.

Figure 55 illustrates a schematic diagram of the interface device processing packets.

Figure 56 illustrates the format of a forward link packet.

Figure 57 illustrates the typical values of propagation delay and skew used in the I-type link interface.

Figure 58 illustrates the data, Stb and clock recovery timing on the Type I link for exemplary signal processing through the interface.

Figure 59 illustrates the typical values of propagation delay and skew in the interface for Type II, Type III, or Type IV links.

Figures 60A, 60B, and 60C respectively illustrate different possibilities for the timing of two data signals and MDDI_Stb, which are ideal, earlier and later, relative to each other.

Figure 61 illustrates an exemplary connector for interface pin assignment for use with a Type I/Type II interface.

Figures 62A and 62B illustrate the possibilities for both Type I and Type II interfaces, respectively MDDI_Data and MDDI_Stb waveforms.

Figure 63 illustrates a high-level diagram of alternative signal processing steps and conditions that can be synchronized using a state machine.

Figure 64 illustrates an exemplary relative timing between a series of clock cycles and various reverse link packet bit and divisor value timings.

Fig. 65 illustrates an exemplary error code transmission process.