KR20030061001A - Generating and implementing a communication protocol and interface for high data rate signal transfer - Google Patents

Abstract

A data interface for transmitting digital data between a host and a client over a communication path using a packet structure linked to each other to form a communication protocol for communicating a preselected set of digital controls and presentation data. Signaling protocols are digital in the form of one or more data packets, using at least one data packet present in the host device and connected to a client via a communication path to form, transmit and receive packets forming the communication protocol. Used by link controllers configured to form data. The interface provides a cost-effective, low-power, bidirectional, high-speed data transfer mechanism over a short distance "serial" form of data link, so it is particularly used for connecting display elements such as microdisplays and wireless communication devices that can be mounted on portable computers. The smallest possible connector and thin, flexible cable can be implemented.

Description

Formation and Implementation of Communication Protocols and Interfaces for High Data Rate Signaling {GENERATING AND IMPLEMENTING A COMMUNICATION PROTOCOL AND INTERFACE FOR HIGH DATA RATE SIGNAL TRANSFER}

Computers, electronic games-related merchandise, and many video technologies (such as DVDs and high-definition VCRs) have even made presentations of increasingly high resolution stills, videos, video-on-demand video, and graphic images containing some types of characters. Significant developments have been made in the last few years to provide end users of the equipment. This development has again driven the use of high resolution electronic visual devices such as high definition video monitors, HDTV monitors or special image projection elements. Combining these visual images with high-definition or high-quality audio data, such as when using CD-like sound playback, DVDs, and other devices with associated audio signal output, is more realistic, rich in content, or a true multimedia experience for end users. Used to form. In addition, high mobility high quality sound systems and music transmission mechanisms such as MP3 players have been developed for audio-only presentations to end users.

In a typical video presentation scenario, video data is typically delivered using current technology at a rate that is best represented as slow or medium, on the order of 1 to 10 kilobits per second. Such data is buffered or stored in a temporary or long term memory device for delayed (after) play at the desired viewing device. For example, an image may be delivered "through" or using the Internet using a program residing on a computer with a modem or internet connection to receive or transmit data usable for digitally representing the image. Similar delivery is accomplished using a wireless device such as a wireless modem or a wireless personal digital assistant (PDA) or a portable computer with a wireless telephone.

Once received, the data is stored locally in a memory element, circuit or device such as RAM or flash memory including external storage for playback. Depending on the amount of data and the image resolution, playback starts relatively quickly or has a long delay. That is, in some examples, the image presentation may require some real-time playback for very small or low resolution images that do not require much data, or use some form of buffering, so that a lot of material is delivered after some delay. Some materials are retained. Assuming there is no interference on the transmission link, the transmission becomes transparent to the end user of the visual device when the presentation begins.

The data used to generate still images or motion video is often used in the media, computer and communications industries to accelerate data transfer over communication links, JPEG, MPEG and other well-known standards bodies or companies. Compressed using one of several known techniques as defined by. This allows the delivery of images or data to deliver a given amount of information faster by using fewer bits.

When data is transferred to a "local" device, such as a computer or other device, the resulting information is not compressed (or played using a special decoding player) and is appropriately presented based on the available presentation resolutions and control elements. Is prepared for presentation. For example, although different resolutions are generally possible as desired, typical computer video resolutions typically range as low as 480 × 640, 600 × 800, and 1024 × 1024, in terms of screen resolution of X × Y pixels. .

Image presentation is also influenced by the image content and ability of a given video controller to manipulate the image in terms of some color level or color depth (bits per pixel used to generate color) and intensity. For example, a typical computer may expect 8 to 32 or more bits per pixel to represent different colors (shading and colour), although other values are possible.

From the above values, it would require that a given screen image be delivered anywhere from 2.45 Mb to 33.55 Mb of data at the lowest to highest typical resolution, depth range. When the visual video or motion image is 30 frames per second, the amount of data required is 73.7 to 1,006 megabits per second (Mbps) or 9.21 to 125.75 megabytes per second (MBps). In addition, you may want to provide audio data with images, such as multimedia presentations or individual high resolution audio presentations such as CD-like music. Additional signals that handle interactive commands, controls or signals may be used. Each of these choices allows more data to be conveyed. In any case, between a presentation element and a source or host device configured to provide this type of data when it is desired to deliver high quality or high resolution image data and high quality audio information or data signals to end users to create a content rich environment. High data rate links are required.

Data rates of 115 KBps or 920 Kbps are routinely processed by the current serial interface. Other interfaces, such as the USB serial interface, accept data transfers at high rates, such as 12 MBps, and special high-speed transfers such as those configured using the Institute of Battery Electronics Engineers (IEEE) 1394 standard can occur at speeds of 50-100 MBps. Unfortunately, these speeds fall short of the desired high data rates described above considering the use of future wireless data devices to provide high resolution, content rich, portable video displays or output signals for driving audio devices. In addition, these interfaces require the use of client software for operation with a significant amount of host or system. These software protocol stacks are formed when an undesirable amount of expense is taken into account, particularly when a mobile wireless device or telephone application is considered. Moreover, some of these interfaces use bulk cables and complex connectors that are too heavy and unsatisfactory for mobile applications that only care about too aesthetic, or consume too much power.

There are other known interfaces, such as analog video graphics array (VGA), digital video interactive (DVI) or gigabit video interface (GVIF) interfaces. The first two of them process data at high transfer rates but consume large amounts of power, such as several watts, and use heavy cables. None of these features can be modified for use with a portable consumer electronic device. Even the third interface consumes too much power and uses expensive or bulky connectors.

For other high speed data systems / protocols or delivery mechanisms related to the interfaces and data delivery for fixed installation computer equipment, there are other significant disadvantages. It requires a significant amount of power and / or operation at high current levels to accommodate the desired data rate. This greatly reduces the availability of this technology for mobile consumer oriented products.

In general, to accommodate such transmission data rates using alternatives such as fiber optic connection and delivery elements, many additional converters and elements are required that are much more complex and expensive than those required entirely for commercial consumer-oriented products. Shall be. Apart from the high cost of optical systems, their power requirements and complexity prevent typical use for heavy, low power portable applications.

What is required in the portable or mobile application industry is the technology to provide a high quality presentation environment for highly mobile end users depending on whether they are audio, video or multimedia based. That is, when using too mobile communication devices or equipment such as portable computers, wireless telephones, PDAs, or the like, video and audio presentation systems or devices that are currently simply used can deliver output at the desired high quality level. Often, poor and perceived quality is the result of unobtainable high data rates needed to deliver high quality presentation data. Therefore, there is a need to increase data throughput between a host device providing data and a client display device or element providing output to an end user.

The present invention relates to a digital signal protocol and process for communicating signals between a host communication device and a client audio / video presentation device at a high data rate. In particular, the present invention relates to a technique for transferring digital signals using a low power, high data rate transfer mechanism from a multimedia and other forms of wireless device to a micro-display unit or other presentation device.

1A illustrates the basic environment of the present invention, including the use of a micro-display for use with a portable computer.

1B illustrates the basic environment of the present invention, including the use of a micro-display device and an audio presentation element used with a wireless receiver.

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

3 shows the structure of a packet used to implement data transfer from a client device to a host device.

4 illustrates the use of MDDI link controllers and the form of signals passed between a host and a client over physical data link conductors for type I and type U interfaces.

FIG. 5 illustrates the use of MDDI link controllers and the form of signals passed between a host and a client over physical data link conductors for type II, II, and IV interfaces.

6 shows the structure of a frame and sub-frames used to implement the interface protocol.

7 shows the general structure of a packet used to implement an interface protocol.

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

9 shows the format and content of a filler packet.

10 shows the format of a video stream packet.

FIG. 11 illustrates the format and content for the video data format descriptor of FIG. 10.

12 illustrates the use of packing and unpacking formats of data.

13 shows the format of an audio stream packet.

14 illustrates the use of a byte-aligned packetized PCM format for data.

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

16 shows the format of a color map packet.

17 illustrates the format of a reverse link encapsulation packet.

18 illustrates the format of a Display Capability Packet.

19 shows the format of a keyboard data packet.

20 illustrates the format of a pointing device data packet.

21 shows the format of a link shutdown packet.

22 shows the format of the display request and status packet.

23 shows the format of a bit block delivery packet.

24 shows the format of a bitmap area fill packet.

25 illustrates the format of a bitmap pattern fill packet.

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

27 shows the format of an interface type handoff request packet.

28 shows the format of an interface type acknowledgment packet.

29 illustrates the format of an performed handoff packet.

30 illustrates the format of a forward audio channel enable packet.

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

32 illustrates the format of a digital content protection overhead packet.

33 illustrates the format of a transparent color enable packet.

34 shows the format of a one-week delay specific packet.

35 illustrates event timing during a one week delay specific packet.

36 illustrates a sample implementation of a CRC generator and checker used in the present invention.

FIG. 37A illustrates the timing of a CRC signal for the apparatus of FIG. 36 when transmitting a data packet.

FIG. 37B illustrates the timing of a CRC signal for the apparatus of FIG. 36 upon receiving a data packet.

38 shows the processing steps for a typical service request without any conflict.

FIG. 39 illustrates the processing steps for a typical service request that appeared after the link restart sequence that was in conflict at the start of the link began.

40 shows how a data sequence can be transmitted using DATA-STB encoding.

FIG. 41 shows circuitry used to generate DATA and STB signals from input data at a host to receive data at a client.

42 illustrates a driver and termination register used to implement an embodiment of the present invention.

Figure 43 shows the steps and signal levels used by the client to secure the service from the host by the hose to provide such a device.

44 shows the relative spacing between transitions between Data0, another data line DataX, and the strobe line Stb.

45 illustrates the presence of a delay in response that may occur when the host disables the host driver after forwarding the packet.

46 illustrates the presence of delays in the response that may occur when the host enables the host driver for delivery of packets.

47 shows the relationship at the host receiver input between the time of the data to be transferred and the leading and trailing edges of the strobe pulses.

48 shows the corresponding client output delay and switching characteristics produced by reverse data timing.

FIG. 49 shows a high level diagram of a signal processing step by synchronization which may implement the present invention using a state machine.

50 illustrates a typical amount of delay incurred in signal processing for the forward and reverse paths in a system using MDDI.

51 shows margin one week delay specification.

52 shows the reverse link data rate change.

53 shows a graph for the value of reverse speed divider vs. forward link data rate.

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

55 overall illustrates a driver, receiver, processor, and state machine for implementing an embodiment of the present invention.

The above and other problems are solved by embodiments of the present invention in which new protocols and data transfer mechanisms have been developed for data transfer between the host device and the receiving client device at high data rates.

An advantage of the present invention is that a technology is provided for data transmission that is very flexible, not complicated, low cost, very reliable, very suitable for the environment of use and very robust.

Embodiments of the present invention provide a host device via a communication path using multiple or serial packet structures linked together to form a communication protocol for communicating a set of digital control and presentation data between a host and a client device. And a mobile digital data interface (MDDI) for transferring digital data at high speed between a client device and a client device. Signaling communication protocols or links are used by the physical layer of the host or client link controller. At least one controller residing within the host device is coupled to the client device via a communication path or link, and is configured to generate, transmit, and receive packets forming a communication protocol, and transmit the digital presentation data into one or more types of data packets. Configured to form. An interface is provided for bidirectional transfer of information between a host and a client.

In a further feature of an embodiment of the present invention, at least one client link controller or client receiver is located within the client device and connected to the host device via a communication path or link. The client link controller is also configured to generate, send and receive packets forming the communication protocol and to form digital presentation data into one or more types of data packets. Generally, a host or link controller uses a state machine to understand the data packet processing and query processing used in command or some form of signal preparation, but is a slow general purpose processor to manipulate data and some complex packets used within a communication protocol. Can be used. The host controller includes one or more differential line drivers; The client receiver includes one or more differential line receivers coupled to the communication path.

Packets are grouped together in a media frame that is communicated between a host and a client device having a predetermined fixed length having a predetermined number of packets of different variable lengths. Each packet includes a packet length field, one or more packet data fields, and a periodic redundancy check field. The sub-frame header packet is forwarded or positioned when starting forwarding another packet from the host link controller. One or more video streamed packets and audio streamed packets are used by communication protocols for delivering video and audio data, respectively, to a client device user via a forward link for presentation. One or more reverse link encapsulated packets are used by the communication protocol to transfer data from the client device to the host link controller.

Filler-type packets are generated by a host link controller which occupies a period of forward link transmission without data. Many other packets are used by communication protocols to convey video information. Such packets include color maps, bit block transfers, bitmap region fills, bitmap pattern fills, and transparent color enabled packets. User-defined streamed packets are used by communication protocols to interface-user data. Keyboard data and pointing device data type packets are used by the communication protocol to transfer data to or from a user input device associated with the client device. Link shutdown packets are used by communication protocols that terminate data transfer in any direction through the communication path.

The communication path generally includes or uses a cable having four or more conductors and shields in series. In some embodiments, the link controller includes a USB data interface, and the cable uses a USB type interface with other conductors. In addition, printed wires or flexible conductors can be used if desired.

The host link controller needs display capability information from the client device to determine what type of data and data rate can be accepted by the client through the interface. The client link controller communicates the display or presentation capability to the host link controller using at least one display capable packet. Multiple delivery modes are used by communication protocols that allow the delivery of several maximum numbers of data bits in parallel over a given time period, each mode being selectable by negotiation between the host and client link controllers. These transfer modes are dynamically adjustable during data transfer and are not used in the reverse direction as the same modes are used on the forward link.

In another aspect of some embodiments of the present invention, the host device includes a wireless communication device, such as a wireless telephone, a wireless PDA, or a portable computer with a wireless modem located therein. Typical client devices include portable video displays and / or portable audio presentation systems such as micro-display devices. Moreover, the host uses storage means and elements for storing presentation or multimedia data to be provided and delivered to the client device user.

Further features and advantages of the present invention and the structure and operation of various embodiments of the present invention are described in detail below with reference to the accompanying drawings. In the figures, like reference numerals generally refer to similar, functionally similar and / or structurally similar elements or processing steps, with the first element shown being represented by the leftmost digit in the reference.

I. summary

According to the general principles of the present invention, a cost-effective and low power consumption that enables high or high speed data transfer over a short range of communication links between a host device and a display device using a " serial " data link or channel. A mobile display digital interface (MDDI) is provided that provides a delivery mechanism. Such mechanisms may include small connectors and thin flexible cables that are particularly usable in display elements or devices such as wearable micro-displays (goggles or projectors) as portable computers, wireless communication devices, or entertainment devices.

The present invention is used in many situations to communicate large amounts of data, typically audio, video or multimedia application data at high speed from a host or source device from which data is generated or stored to a client display or presentation. Typical applications described below transfer data from a cordless phone or modem or portable computer to a wearable micro-display application such as a virtual display device such as a small video screen or a goggle or helmet comprising a small projection lens and screen. will be.

The nature or propensity of MDDI is independent of the particular display technology. This is a very flexible mechanism for delivering data at high speed regardless of its internal structure, and furthermore, the functional features or commands of the data implement it. This allows the timing of the data packets to be delivered to be adjustable to adapt to the characteristics of a particular display device or display conditions unique to a particular device or to meet the requirements of audio and video combined for some A-V systems. The interface is a display element or client device as long as the selected protocol is satisfied. In addition, the combined serial link data or data rate allows the communication system or host device to optimize cost, power requirements, client device complexity, and display device update rate.

Data interfaces are primarily provided for use in carrying large amounts of speed data over "wired" signal links or small cables. However, if in some applications a radio link including an optical based link is configured to use the same packet and data structure developed for the interface protocol and maintain the desired level of delivery with sufficiently low power consumption or complexity in the remaining practical use, Will be advantageous.

II. Environment

Typical applications where a portable or laptop computer 100 and a wireless telephone or PDA device 102 are in communication with a display device 104 <106 with audio playback systems 108 and 110 in FIGS. 1A and 1B, respectively. This is shown. The wireless device may be currently received data or may have previously stored a certain amount of multimedia data in the memory element or device for later presentation for viewing and / or listening by the end user of the wireless device. Since typical wireless devices are used for video and simple text communications for most of the time, the device 102 has a rather small display screen and simple audio system (speakers) to communicate information to the user.

Computer 100 has a much larger screen, which is still an inappropriate external sound system and unsuitable for other multimedia devices such as high definition televisions or movie screens. Computer 100 may be used for illustrations and other forms of processor, interactive video games, or consumer electronics may be used in the present invention. Computer 100 uses, but is not limited to, a wireless modem or other modem embedded within the device for wireless communication, and if desired, is connected to such device using a cable or wireless link.

This allows for presentations with complex or "rich" data to be less than available or enjoyable environments. Therefore, industries have been developed for other mechanisms and devices to provide information to end users and to provide the minimum level of enjoyment or positive environment desired.

As previously described, various types of display devices are currently under development to provide information to end users of the device 100. For example, more than one company has developed a set of wearable goggles that project an image in front of the device user's eyes to provide a virtual display. When correctly positioned such a device effectively “projects” a virtual image that is much larger than the element providing the virtual output, as perceived by the user's eye. That is, very small projection elements allow the user's eyes to see the image at a much larger size than would be possible with a typical LCD screen. The use of large virtual screen images allows the use of much higher resolution images possible on more limited LCD screen displays. Other display devices include, but are not limited to, small LCD screens or display drivers for projecting images onto various flat panel display elements, projection lenses, and surfaces.

There may also be additional elements connected to or associated with the wireless device 102 or the computer 100 to provide output to other users or other devices that transmit or store signals anywhere. For example, data is stored in flash memory in optical form using recordable CD media or magnetic media such as magnetic tape recorders or similar devices to be used later.

In addition, many wireless devices and computers have built-in MP3 music decoding capabilities and other advanced acoustic decoders and systems. Later computers typically use CD and DVD playback capabilities, and some have small dedicated flash memory readers for receiving prerecorded audio files. They have the ability to ensure a highly increased feature rich environment only when digital music file decoding and playback processing is in line with trends. The same applies to digital video files.

To assist in sound reproduction, an external speaker 108 is shown in FIG. 1A, which may be accompanied by additional elements such as sub-woofers or “surround-sound” speakers for front and rear acoustic projection. At the same time, the speaker or earphone 110 is marked as embedded to support the frame or mechanism of the micro-display device 106 of FIG. 1B. As is known, other audio or sound reproduction elements are used, including power amplification or sound shaping devices.

In any case, as described above, high data rates are needed if one wants to deliver high quality or high resolution image data and high quality audio information or data signals from one or more communication links 112 to the end user. That is, forward link 112 is a potential bottleneck and marginal system performance in the communication of data as described above, because current delivery mechanisms typically do not achieve the high data rates required. For example, as described above, for high image resolutions such as 1024 x 1024 pixels with a color width of 24-32 pixels per pixel and a data rate of 30 bps, the data rate may be close to speeds above 336 Mbps. . In addition, these images are provided as part of a multimedia presentation that includes audio data and potentially processes additional signals with interactive games or communications, various commands, controls or signals, and further improves the quality and data rate of the data. Increase.

Also, the less cable or interconnect required to establish a data link means a mobile device associated with a previously used display, and moreover will be adopted by many user bases. This is used to set up the entire audio-virtual environment and increase the quality level of the display and audio output device.

Unfortunately, high data rates exceed the current available for transmission data. What is needed is a technique for delivering data at high speed over a data transfer link or communication path between the presentation element and the data source, which allows for simple and economical cabling as low power and light weight as possible. Applications are new to accomplish these and other purposes, allowing mobile, portable or even fixed position devices to deliver data at very high data rates to the desired display, micro-display or audio delivery elements while maintaining the desired low power consumption and complexity. Techniques or methods and apparatus have been developed.

III. High Speed Digital Data Interface System Architecture

In order to form and efficiently use new device interfaces, signal protocols and system architectures have been created that use low power signals to provide high speed transfer rates. Such protocols are based on packet and command frame structures linked together to form a protocol for communicating a predetermined selected data set or data type with the commands or operational structures imposed on the interface.

A. Overview

Devices that connect or communicate over an MDDI link are called posts and clients, and clients are typically some form of display device. As enabled by the host, data from the host to the display moves in the forward direction (called forward traffic or link) and data from the display to the host moves in the reverse direction (reverse traffic or link). This is shown in the basic configuration as shown in FIG. In FIG. 2, host 202 is connected to client 204 using a bidirectional communication channel 206, which is shown to include forward link 208 and reverse link 210. However, these channels are formed by a common set of conductors with data transfer that is efficiently switched between forward or reverse link operation.

As will be described, a host is one of several types of devices that have the benefits of using the present invention. For example, host 202 may be a portable computer such as a portable, laptop or similar mobile computing device, which may be a PDA, pager or one of many wireless telephones or modems. At the same time, client 204 may include several devices used to provide information to end users. For example, a micro-display combined with goggles or glasses, a projection device built into a hat or helmet, a small screen or even a hologram element built into a window or windshield of a car, or several speakers, mobile phones or high quality sound or music. Sound system to provide. However, it will be readily apparent to one skilled in the art that the present invention is not limited to these devices, and for the purpose of providing end users with high quality images and sound in terms of storage and delivery or in terms of presentation in playback. Many other devices on the market are possible. The present invention is used to increase data throughput between multiple devices to accommodate the high data rates needed to realize the desired user environment.

MDD interfaces are contemplated for addressing at least five more physically spaced forms of interfaces found in the communications and computer industries. These are simply called Type I, Type II, Type III, Type IV, and Type U.

Type I interface is a six-wire (conductor) that makes it suitable for devices in portable media players such as mobile or portable telephones, PDAs, e-books, electronic games and CD players or similar forms of MP3 players and electronic consumer technologies It is configured as an interface. The U-type interface is implemented as an 8-wire (conductor) interface suitable for laptops, notebooks, or desktop personal computers and similar devices or applications, which does not require the display to be updated quickly and has no embedded MDDI link controller. This type of interface is distinguished by the use of an additional two-wire universal serial bus (USB) interface, which is used to accommodate software support found in currently operating systems or most personal computers. The U-type interface can be used in a USB-only mode where the display has a USB connector, for example, connected to a standard USB port on a computer or similar device.

Type II, III and IV interfaces are suitable for high performance displays and use more complex cabling with additional twisted pair conductors to provide adequate shielding and low loss transfer of data signals.

Type I interfaces may include display, audio, control, and limited signaling information and typically carry signals used in devices that do not require high resolution full speed video data. This type of interface is primarily designed for devices such as mobile wireless devices, where a USB host is typically unavailable within the device for connection and transmission of signals. In this configuration, the mobile device is an MDDI host device and acts as a "master" to control the communication link from the host, which generally sends display data to the client (forward traffic or link).

In this interface, the host receives the communication data from the client (reverse traffic or link) at the host by sending a specific command or packet form to the client that carries the bus for a particular period of time and sends the data to the host as a reverse packet. Enable. This is illustrated in Figure 3, where the packet type referred to as the encapsulation packet (discussed below) is suitably used for creating reverse links and transmitting reverse packets on the transmission link. The time interval assigned to the host to poll the display for data is predetermined by the host and is based on the needs of each particular application. This type of bidirectional half-duplex data transfer is particularly desirable where the USB port cannot be used to transfer information or data from the client.

The Type-U interface transmits signals that can be suitably used for laptop and desktop applications, which are widely supported by a wide range of motherboards or other hardware and by operating system software. The use of the added USB interface allows it to be used with "plug and play" characteristics and easy application configuration. The inclusion of USB also enables the flow of general purpose bidirectional commands, status, audio, data and the like, and video and audio data for the client device can be transmitted using the twisted pair at low power and high speed. . Embodiments of the present invention that use a USB interface allow transmission at high speed on one set of conductors, and implement control of the USB connection that is blocked when not used and when power is rarely used.

The USB interface is used in a wide range of specifications for personal computer devices, and details of the USB interface and its operation are known in the art and will not be described below. For the USB interface, the communication between the host and the display corresponds to Universal Serial Bus Specification Version 2.0. In applications where the Type-U interface is used where USB is the basic signaling channel and possibly a voice return channel, it is optional for the host to poll the client via the MDDI serial data signals.

High-performance displays with HDTV type or similar high-performance resolutions require 1.5Gbps data streams to support full motion video. The Type-II interface supports high data rates by transmitting 2 bits in parallel, the Type-3 supports 4 bits in parallel, and the Type-4 interface supports high data rates by transmitting 8 bits in parallel. do. The protocol used for the MDDI can negotiate what is the highest data rate that can be used to allow each of type 1, 2, 3, 4 hosts to communicate with any given type 1, 2, 3, 4 client or display. Make sure The performance and possible features of the device, which may be referred to as the minimum possible device, may be used to set the performance of the link. In general, even in systems where both the host and client can use Type 2, 3 or 4 interfaces, both begin to operate as Type 1 interfaces. The host then determines the performance of the target client or display and negotiates a reconfiguration to operate in the type-2, 3, 4 mode appropriate for hand-off or specific application.

In general, the host uses appropriate link-layer protocols, reconfigures or steps down to operate in slower mode to conserve power at regular times, or steps in fast mode to support high-speed transfers such as ultrafast resolution display content. Can be up. For example, when the display system is switched to AC power from a power source such as a battery, or when the source of the display media is switched to a lower or higher resolution format, or combinations or other conditions or events thereof The host may change the display mode if considered a basis for changing the display or data transfer mode.

In addition, the system can communicate in one direction using one mode and in another direction using another mode. For example, tie 4 interface mode is used to transfer data for display at high speed, and type 1 or type U mode is used to transfer data from a peripheral device such as a keyboard or printing device to a host device.

C. Physical Interface Structure

The arrangement of a generic device or link for establishing communication between a host and a client device is shown in FIGS. 4 and 5. 4 and 5, MDDI link controller 402 is shown mounted to host device 202, and MDDI link controller 404 is shown mounted to client device 204. In FIG. Previously, host 202 is connected to client 204 using a bidirectional communication channel 406 that includes a serial conductor. As discussed below, both host and client link controllers can be fabricated into an integrated circuit using a single circuit design that can be programmed, adjusted or configured to respond to a host controller (driver) or client controller (receiver). have. This can be provided at lower cost due to the large fabrication of a single circuit design.

In Figure 4, USB host device 401 and USB client device 410 are shown for use in the implementation of the Type U interface version of the MDDI. Circuits and devices that implement these functions are well known in the art and therefore will not be described in detail below.

In FIG. 5, MDDI link controller 502 is shown mounted to host device 202 ', and MDDI link controller 504 is shown mounted to client device 204'. As before, the host device 202 'is connected to the client 204' using a bidirectional communication channel 506 that includes serial conductors. As discussed previously, both the host and client link controllers can be fabricated using a single circuit design.

Signals transmitted between a host and a client, such as a display device, over an MDDI link or physical conductors are shown in FIGS. 4 and 5. As shown in Figures 4 and 5, the primary path or mechanism for transmitting data via the MDDI uses data signals labeled MDDI DataO +/- and MDDI Stb +/-. Each of these data signals are low voltage data signals transmitted over wires of a differential pair of cables. Each bit transmitted over the interface has only one translation in the MDDI Data 0 +/− pair and the MDDI Stb pair. It is a voltage based on the transmission mechanism, not based on the current, so the static current consumption is almost zero. The host drives the MDDI Stb signals to the client display.

Data is either forward or reverse in the MDDI Data pair, ie a bidirectional transmission path, but the host is a master or controller of the data link. The MDDI DataO and MDDI Stb signal paths operate in differential mode to maximize noise rejection. The data rate for the signal on the line is determined by the clock rate transmitted by the host and can vary from 1 kbps to 400 Mbps or more.

The type-2 interface includes one additional data pair or conductor or path beyond the range of type-1 referred to as MDDI Data1 +/-. The type-3 interface includes two additional data pairs or signal paths beyond the range of type-2 interfaces referred to as MDDI_Data2 +/- and MDDI_Data3 +/-. The type-4 interface includes four additional data pairs or signal paths beyond the range of type-3 interfaces referred to as MDDI_Data4 +/-, MDDI_Data5 +/-, MDDI_Data6 +/- and MDDI_Data7 +/-, respectively. In each of the above interface structures, the host transmits power to the client or display using twisted pairs or signals referred to as MDDI_Pwr and MDDI_Gnd.

The transport type available for the type U structure only is the MDDI USB connection or signal path. The MDDI USB connection includes a second path for communication between a host and a client display. In certain applications, it is desirable to transfer certain information between the host and the client at relatively low data rates. Using the USB transport link enables the device without a limited host capable of communicating with a USB host or MDDI compatible client or with an MDDI link controller having a display equipped with the U type interface. Information that can be usefully transferred to the display over the USB interface is static bitmaps, digital audio streams, pointing device data, keyboard data and control and context information. All functions supported via the USB interface can be implemented using the main MDDI high speed serial data path. The defined data can be transmitted on a USB type interface, but requiring a series of data in the form of back-to-back packets does not apply to the USB interface and does not use packets that support MDDI type handoff.

A summary of the signals transmitted over the MDDI link between the host and client (display) is shown in Table 1 corresponding to the interface type.

Table 1

Type-1 MDDI_Pwr / GndMDDI_Stb +/- MDDI_Data0 +/- Type-UMDDI_Pwr / GndMDDI_Stb +/- MDDI_Data0 +/- MDDI_USB +/- Type-2 MDDI_Pwr / GndMDDI_Stb +/- MDDI_Data0 +/- MDDI_Data1 +/- Type-3MDDI_Pwr / GndMDDI_Stb +/- MDDI_Data0 +/- MDDI_Data1 +/- MDDI_Data2 +/- MDDI_Data3 +/- Type-4MDDI_Pwr / GndMDDI_Stb +/- MDDI_Data0 +/- MDDI_Data1 +/- MDDI_Data2 +/- MDDI_Data3 +/- MDDI_Data4 +/- MDDI_Data5 +/- MDDI_Data6 +/- MDDI_Data7 +/-

A typical cabling used to implement the structure and operation is nominally a multiple of 1.5 meters and contains three stranded pairs of conductors, each of which is in turn a multi-strand 30AWG wire. A thin membrane protective covering is covered or formed on the three pairs of stranded wires as additional drain wires. The stranded pair and the protective drain conductor terminate at a display connector having a shield connected to the shield for the display (client), and there is an insulating layer covering the entire cable as is known in the art. . The wires are paired as follows: MDDI-Gnd and MDDI_Pwr; MDDI Stb + and MDDI Stb-; MDDI_Data0 + and MDDI_Data0-; MDDI_Data1 + and MDDI_Data1- etc. The diameter of the nominal cable is a multiple of 3.0 mm with a nominal impedance of 85 ohm ± 10% and a nominal 110 ohm DC resistance per 1000 feet. The signal propagation rate is nominally 0.66c and the maximum delay on the cable should be 8.0 nsec or less.

D. Data Types and Rates

To achieve a useful cable for all ranges of user use and applications, the mobile digital data interface (MDDI) can be integrated with multiple displays or display information, audio translating to work in concert with the mobile display by control information. Provides support for producers, keyboards, pointing devices, and other input devices and combinations thereof. The MDDI interface is designed to use several potential types of data streams transmitted between the host and the client in the forward or reverse direction using a minimum of cable or conductors. Both isochronous and non-isochronous streams are supported. Many combinations of data types may be used until the aggregate data rate is less than or equal to the maximum desired MDDI link rate. These include, but are not limited to, the items set forth in Tables 2 and 3 below.

Table 2

Send from host to client Isochronous video data 720x480, 12 bit, 30f / s ~ 124.5 Mbps Isochronous stereo audio data 44.1 kHz, 16 bit, stereo ~ 1.4 Mbps Isochronous graphic data 800x600, 12-bit, 10f / s, stereo ~ 115.2 Mbps Isochronous Control at least << 10 Mbps

Table 3

Send from client to host Isochronous voice data 8 kHz, 8 bits << 1.0 Mbps Isochronous video data 640x480, 12 bit, 24f / s To 88.5 Mbps Isochronous state, user input, etc. at least << 1.0 Mbps

The interface is not fixed and can be extended to support the transmission of various " type " information including user defined data for future system activity. Specific examples of data that can be used are full motion video, either in the form of full or partial screen bitmap fields or compressed video, low-speed static bitmaps to reduce power and implementation costs, PCM or multiple resolution and speed compression. Audio data; Pointing device location and user defined data that can be selected and defined. Such data may also be sent with control context information to retrieve device performance or to set operating parameters.

The present invention uses a personal computer to watch a movie (video display and audio), a personal computer with a limited personal field of view (often a graphic display associated with video and audio), or a PC, console or personal device (motion graphic display or synthesis). Camcorders and cellular for playing video games, surfing the Internet, using the device in the form of video phones (two-way low-speed video and audio), or capturing camera or digital video images for still digital photography It is an advanced technology used for data transmission, including but not limited to entertainment and performance enhancements with phones, smartphones or PDAs.

The mobile data interface discussed below is for providing large amounts of A-V type data on a communication or transmission link consisting of a wire or cable type link. However, it is obvious that the signal structure, protocol, timing or transmission mechanism can be adjusted to provide for a link in the form of optical or wireless media, provided that the desired level of transmission is maintained.

The MDD interface signals use a concept known as a common frame (CF) for the basic signal protocol or structure. The idea of using a common frame is to provide synchronization pulses for simultaneous isochronous data streams. The display device may use the common frame rate as a time reference. Low CF rates increase channel efficiency by reducing the overhead of transmitting the sub-frame headers. High CF rates, on the other hand, reduce latency and allow smaller, resilient data buffers for audio samples. The CF speed of the interface of the present invention is actively programmable and can be set to one of many values suitable for isochronous streams used in a particular application. That is, the CF value is selected to best suit the given display device and host structure.

The number of bytes typically required per adjustable and programmable common frame for an isochronous data stream that can be used with applications such as a head mounted micro display is shown in Table 4.

Table 4

Common Frame Rate (CFR) = 1200 Hz X Y beat Frame rate channel Speed (Mbps) Byte / CFR DVD Movie 720 480 12 30 One 124.4 12960 Stereographic 800 600 12 10 2 115.2 12000 camcorder 640 480 12 24 One 88.5 9216 CD audio One One 16 44100 2 1.4 147 voice One One 8 8000 One 0.1 6.7

Fraction counts of bits per common frame can be easily obtained using a simple programmable M / N counter structure. For example, a count of 26-2 / 3 bytes per CF is implemented by sending two frames of 27 bytes, with each frame following one frame of 26 bytes. Smaller CF rates may be chosen to produce integer bytes per CF. However, implementing a simple M / N counter in hardware requires that the area within the integer circuit chip used to implement all or part of the invention be smaller than the area required for a simpler larger audio FIFO buffer.

An example application and data type that illustrates the effects of different data rates is a karaoke system. For karaoke systems, the system user sings like a music video program. The lyrics of the song are displayed at the bottom of the screen so that the user can know the lyrics of the song to sing and the timing of the song. The application requires mixing the video display and stereo audio stream with the user's voice with graphics that are occasionally updated.

Assuming a common frame rate of 300 Hz, each CF consists of 92,160 bytes of video content and 588 bytes of audio content (Stereo 147 16-bit samples) on the forward link to 29.67 (26-2). / 3) bytes of voice are returned from the microphone to the mobile karaoke machine for transmission. Isochronous packets are sent between the host and the display. It contains at least 768 bytes of graphics data (a quarter-high screen) and less than 2001 bytes for miscellaneous control and status commands.

Table 5 shows how data is allocated in a common frame for the karaoke example. The overall speed used is selected at 225 Mbps. The slightly faster 226Mbps speed allows 400 bytes of data to be transmitted per subframe, which allows for the use of preliminary control and status messages.

Table 5

Component Speed Bytes / CF 640x480 pixels and 30 fps music video 92160 640x120 pixels and 1 fps song text 768 44,100sps, stereo, 16-bit CD audio 588 8000sps, mono, 8-bit voice 26.67 Subframe header 19 Reverse link overhead 26.67 + 2 * 9 + 20 Total bytes / CF 93626.33 Full speed (Mbps) 224.7032

E. Link Layer

The data transmitted using the MDD interface high speed serial data signals consists of a stream of time multiple packets which are in turn linked. When the transmission of the device does not have any data to be transmitted, the MDDI link controller automatically sends a filler packet, thus maintaining a stream of packets. The use of a simple packet structure ensures reliable isochronous timing of video and audio signals or data streams.

Groups of packets are included in signal components or structures referred to as subframes, and groups of subframes are included in signal components or structure referred to as media frames. The subframe includes one or more packets based on the size of the packets and the data transmission usage, and the media frame must include one or more subframes. The largest subframe braked by the protocol used by the present invention is 2 ²³ -1 times or 4,294,967,295 bytes and the size of the largest media frame is 2 ¹⁶ -1 or 65,535 subframes.

As discussed below, certain header packets contain a unique identifier at the beginning of each subframe. The identifier is also used to obtain frame timing at the client device when communication is initiated between the host and client. Link timing acquisition is discussed in more detail below.

Typically, when full motion video is displayed, the display screen is updated once per media-frame. The display frame rate is equal to the media frame rate. The link protocol supports full motion video on the entire display or on a small portion of full motion video content surrounded by static images, depending on the desired application. In mobile applications that use low power, such as web pages or e-mail, the display screen often needs to be updated. In such a situation, it is desirable to block the link to transmit a single sub-frame and reduce power consumption. The interface also supports effects such as stereo versions and controls primitive graphics.

Subframes exist to enable the transmission of packets with high priority in a periodic manner. This simultaneously allows the isochronous stream to be present with minimal data buffering. It is an advantage of the present inventors to provide a display process that allows multiple data streams (high speed communications of video, voice, control, context, pointing devices, etc.) to essentially share a common channel. It transmits information using relatively small signals. It also allows display technology specific activities such as horizontal sync pulses and blanking periods for CRT monitors.

F. Link Controller

The MDDI controllers shown in Figures 4 and 5 are fabricated or assembled to be fully digital implemented with the exception of the differential line receivers used to receive MDDI data and strobe signals. No analog functions or phase locked loops (PLLs) are required for the implementation of the hardware beyond the link controller. The host and display link controllers include nearly similar functionality except for the display interface, which includes a state machine for link synchronization. Thus, the present invention has the advantage of generating a single controller design or circuit that can be configured as a host or a client, and can reduce the overall manufacturing cost of the link controllers.

Ⅳ. Interface link protocol

A. Frame Structure

The single protocol or frame structure used to implement forward link communication for packet transmission is shown in FIG. As shown in FIG. 6, information or digital data is grouped into components known as packets. Multiple subframes are alternately grouped to form a media frame. To control the formation of frames and the transmission of subframes, each subframe begins with a predetermined packet called a subframe header packet (SHP).

The host device selects a data rate used for a given transmission. The rate may be actively changed by the host based on the host's maximum transmission capability or data retrieved by the host from a source and the display maximum capability or other device to which the data is transmitted.

The receiving client device capable of and working with the MDDI or inventive signaling protocol may be used as well as the data type or supported characteristics that may be used by the host, as well as the maximum or current maximum data transfer rate that may be used or Can be waited to determine the slower default minimum speed. The information may be transmitted using a Display Capability Packet (DCP) as described in more detail below. The client display device may transmit data or communicate with another device using the interface within a predetermined minimum data rate or minimum data range, and the host may transmit data within the range to determine the full performance of the client device. You can use the speed to queue up.

The host transmits filler packets when there are no data packets transmitted in the current subframe or when the host cannot transmit at a sufficient rate corresponding to the selected data transmission rate of the forward link. Since each subframe begins with a subframe header, the end of the previous subframe includes packets (mostly filler packets) that fill the previous subframe. If there is not enough space for the packets with data itself, the filler packet will be at the end of the immediately preceding subframe or before the subframe header packet in the subframe. It is a control operation in the host device to ensure sufficient space that each packet transmitted in the subframe exists in the subframe. At the same time, when the host device starts to transmit the data packet, the host can successfully complete the packet of the size in the frame without the pre-operation state of the data occurring.

In one aspect of one embodiment of the present invention, subframe transmission has two modes. One mode is the periodic subframe mode used to transmit video and audio streams in real time. In this mode, the sub frame length is defined as non-zero. The second mode is an asynchronous or aperiodic mode in which frames are used to provide bitmap data to the display device only when new information is available. When the periodic mode is used, subframe reception may begin when the display is synchronized with the forward link frame structure. This corresponds to the "synchronous" state defined in correspondence with the state diagram described below with reference to FIG. In the asynchronous aperiodic subframe mode, reception begins after the first subframe header packet is received.

B. Overall Packet Structure

Note that the format or structure of the packets used to form the signaling protocol implemented by the present invention is described below, wherein the interface can be extended and additional packet structures can be preferably added. The packets are labeled or split into different " packet types " in their functions at the interface, i.e. the data or commands they transmit. Thus, each packet type defines a predetermined packet structure for a given packet used to regulate the packets and the data transmitted. It is apparent that the packets may have a predetermined length or a length that can vary variably or actively, depending on their respective function. The byte value used for the byte or packets consists of a number of bits (8 bits or 16 bits) which are unencoded integers. A summary of the packets used with the type definition of the packets, presented in type order, is shown in FIG. The direction in which packet transmission is considered valid is also defined by whether it is used for a Type U interface.

Table 6

Packet name Packet type Effective direction Forward Reverse Type-U Subframe header packet 255 x x Filler packet 0 x x Video stream packet One x x x Audio stream packet 2 x x x Preallocated Stream Packet 3-55 User-defined stream packet 56-63 x x x Color map packet 64 x x x Reverse Link Encapsulation Packet 65 x Display capability packet 66 x x Keyboard data packet 67 x x x Pointing device data packet 68 x x x Link blocking packets 69 x Display request and status packet 70 x x Bit block transport packet 71 x x Bitmap Area Fill Packets 72 x x Bitmap Pattern Fill Packets 73 x x Communication link data channel packets 74 x x x Interface Type Handoff Request Packet 75 x Interface type acknowledgment packet 76 x Type Handoff Execution Packet 77 x Forward Audio Channel Enable Packet 78 x x Reverse audio sample rate packet 79 x x Digital Content Protection Overhead Packets 80 x x x Transform color enable packet 81 x x Round Trip Delay Packet 82 x

The packets have a full set of minimal fields, including the general basic structure or packet length field, packet type field, data byte field, and CRC field, as shown in FIG. As shown in Fig. 7, the packet length field includes information in the form of multiple bits or byte values or the length between the packet length field and the CRC field, which defines the total number of bits in the packet. In a preferred embodiment, the packet length field contains an unencoded integer of 16 bits or 2 bytes in length that defines the packet length. The packet type field is another multiple bit field that defines the type of information contained in the packet. In a preferred embodiment of the present invention, this defines the display capability, handoff, video or audio stream, status, etc. in a range of 8 bits or 1 byte in the form of an 8 bit unencoded integer.

The third field contains, as part of the packet, data or bits transmitted or transmitted between the host and the client device. The format of the data is defined for each packet type corresponding to the prescribed data type to be transmitted and can be separated into a series of additional fields by its format request. In other words, each packet type may have a defined format or field for its portion. The last field is a CRC field that contains the results of a 16-bit periodic redundancy check calculated on the data byte, packet type, and packet length fields, and is used to confirm the completeness of the information in the packet. In other words, it is calculated on the entire packet except the CRC field. The client generally maintains a total count of detected CRC errors and returns the count result to the host in the display request and status packet.

During the transmission of the packet, the fields are transmitted starting with the least significant bit (LSB) and ending with the last transmitted most significant bit (MSB). Parameters having more than one byte length are transmitted using the least significant byte, which is the same bit transmission pattern used for parameters longer than 8 bits, such as the LSB is used for shorter parameters that are initially transmitted. The data on the MDDI_data0 signal path is aligned with bit 0 of the bytes transmitted on the interface in Type 1, Type 2, Type 3 or Type 4, certain constant modes.

When adjusting data for display, as is done in the electronics industry, data for pixel arrays is first sent in rows and columns. In other words, all pixels visible in the same row of the bitmap are sent in the order in which the leftmost pixels are sent and then the rightmost pixels are sent. After the rightmost pixels of the row are transmitted, the next pixel of the sequence is sent the leftmost pixel of the next row. Other structures may be applied as needed, but rows of pixels are generally transmitted in upper to lower order in most displays. In addition, when adjusting the bitmap, the conventional scheme described below defines the criteria by labeling the upper left corner of the bitmap with the offset "0,0". The X and Y axes, which are used to determine or define positions in the bitmap, increase as they approach the bottom right of the bitmap. Line 1 column 1 starts with an index value of zero.

C. Packet Definition

1. Subframe Header Packet

The subframe header packet is the first packet of all subframes and has a basic structure as shown in FIG. As shown in Fig. 8, the packet of the type is configured to have a packet length, a packet type, a unique word, a sub frame length, a protocol version, a sub frame count, and a media frame count field. In order. Packets of this type are generally identified as type 255 packets and use a fixed length of 17 bytes.

The packet type field uses a one byte value, while the unique word field uses a three byte value. The combination of the two fields has a 32-bit unique word with good autocorrelation. The unique word is 0x005a3bff, where the lower 8 bits are sent first in packet type and the most significant 24 bits later.

The subframe length field has 4 bytes of information defining the number of bytes per subframe. The length of the field may be set to zero to indicate that only one subframe will be sent by the host before the link is blocked in an idle state. The value in the field can be actively changed as it is converted from one subframe to the next. This capability can be used to make minor timing adjustments of synchronization pulses for applying isochronous data streams. If the CRC of the subframe header packet is invalid, the link controller will use the subframe length of the header packet of the good subframe previously known to evaluate the length of the current subframe.

The protocol version field contains two bytes that specify the protocol version used by the host. The protocol version field is set to '0' to specify the first or current protocol version used. The value will change in time when new versions are created. The subframe count field includes two bytes that define the number of sequences indicating the number of subframes transmitted after the media frame starts. The first subframe of the media frame has a subframe count of zero. The last subframe of the media frame has a value of n-1, where n is the number of subframes per media frame. Note that if the length of the subframe is set to zero, the count of the subframe should also be set to zero.

The media frame count field includes three bytes that define the number of sequences indicating the number of media frames transmitted after the current media item or the transmitted data. The first media frame of a media item has a media frame count of zero. The media frame count is incremented before the first subframe of each media frame and returns to zero after the maximum media frame count (media frames number 2 ²⁴ -1 = 16,777,215) is used. The media frame count value may be generally reset at a certain time by the host to suit the needs of the terminal application.

2. Filler Packet

A filler packet is a packet sent from or to a client device when no information can be sent on the reverse or forward link. Filler packets are required to have a minimum length to allow maximum flexibility in transmitting other required packets. In the last or reverse link encapsulation packet of a subframe (see below), the link jagger sets the size of the filler packet to fill the remaining space to maintain packet integrity.

The format and contents of the filler packet are shown in FIG. As shown in Fig. 9, the type of packet is configured to have a packet length, a packet type, a filler byte, and a CRC field. Packets of this type are generally identified as type 0, indicated in the 1 byte type field. The bits or bytes of the filler byte field contain a variable number of bits, all zero values, to ensure that the filler packet can have a desired length. That is, the packet consists of a packet length, a packet type, and a CRC, and uses a predetermined fixed length of 3 bytes.

3. Video stream packet

Video stream packets transmit video data to irregularly update the rectangular region of the display device. The size of the region may be as small as the size of the pixel or as large as the entire display. Since all content that must display a stream is contained in the video stream packet, there are a number of displayed streams that are limited by system resources and at the same time are almost unlimited. The format of the video stream packet (video data pocket descriptor) is shown in FIG. As shown in Fig. 10, the packet of this type has a packet length, packet type, video data descriptor, display attributes, X-axis left corner, Y-axis upper corner, X-axis right corner, Y-axis lower corner, X and It is configured to have a starting point of the Y axis, a pixel count, a parameter CRC, pixel data, and a CRC field. Packets of this type are generally identified as type 1 and indicated in the 1 byte type field.

The common frame concept described above is an effective way to minimize the audio buffer site and reduce latency. However, for video data, it is necessary to extend the pixels of one video frame across multiple video stream packets within a media frame. In addition, the pixels of a single video stream packet do not exactly correspond to the complete orthogonal window of the display. In the example of a video frame rate of 30 frames per second, there are 300 subframes per second, so there are 10 subframes per media frame. If there are 480 rows of pixels in each frame, then 48 pixels of each video stream packet of each subframe will be included. In other cases, the video stream packet may not contain integer pixel rows. The same is true for other video frames in which the number of subframes per media frame is not divided by the even number of rows per video frame. Although the Gaga video stream packet does not contain integer rows of pixels, each video stream packet must contain integer pixels. This is important if the pixels are one or more bytes, or if they are in packed format as shown in FIG.

The formats and contents used to realize the operation of the video data descriptor field described above are shown in Figs. 11A-11D. 11A-11D, the Video Data Format Descriptor field contains two bytes in the form of a 16-bit unencoded integer that specifies the format of each pixel of the pixel data in the current stream of the current packet. Different streams may use different pixel data formats. That is, different values of the video data format descriptor may be used, and similarly, a certain stream may change its data format on-the-fly. The video data format descriptor defines the pixel format for the current packet, which does not mean a constant format to be used over the lifetime of a particular video stream.

11A to 11D illustrate how the video data format descriptor is coded. As used in the figure, when the bits [15:13] are '000', as shown in Fig. 11A, the video data consists of an array of monochrome pixels, with the number of bits per pixel being three. It is defined by the video data format descriptor word of zero bits. In this case, bits 11 to 4 are set to zero. When bits [15:13] are '001', the video data consists of an array of color pixels, each pixel defining a color in a color map, as shown in FIG. In this case, bits 5 through 0 of the video data format descriptor word define the number of bits per pixel, and bits 11 through 6 are set to zero. If bits [15:13] are '010', as shown in Fig. 11C, the video data is defined as the number of bits per pixel of red is from 11 to 8, and the number of bits per pixel of green is from 7 to 4; It is defined as an array of color pixels in which the number of bits per pixel of blue is defined as three to zero. In this case, the total number of bits in each pexel is the sum of the number of bits used for red, green and blue.

However, bits [15; 13] are '001', as shown in Fig. 11D, and the video data is composed of a 4: 2: 2 format video data array having luminance and chrominance information. The number of data bits of luminance Y per pixel is determined by 11 to 8 bits, the number of bits of the Cr component is determined by 7 to 4 bits, and the number of data bits of the Cb component is 3 to 0. It is decided. The total number of bits in each pixel is the sum of the number of bits used for red, green and blue. The Cr and Cb components are transmitted at half the rate of Y. In addition, the video samples in the pixel data portion of the packet are constructed as follows: Yn, Crn, Cbn, Yn + 1, Yn + 2, Crn + 2, Cbn + 2, Yn + 3, ..., Where Crn and Cbn are related to Yn and Yn + 1 and Crn + 2 and Cbn + 2 are related to Yn + 2 and Yn + 3. If odd pixels are present in the row of the current stream (X right edge-X left corner + 1), the C value corresponding to the last pixel of each row is followed by the Y value of the first pixel of the next row.

For all four formats shown in the figure, bit 12, designated "P", specifies whether the pixel data samples or byte aligned pixel data are packed. A value of '0' in this field indicates that each color at each pixel and each pixel in the pixel data field is aligned by the MDDI interface byte boundary. A value of " 1 " is packed against each color in each pixel and in each pixel of the pixel data against the color in the pixel leaving the previous pixel or unused bits.

The first pixel of the first video stream for a particular display window goes down to the upper left corner of the stream window defined by the X offset and the Y offset, and the next pixel received is placed at the next pixel position of the same row. To facilitate the operation, the display maintains a "next pixel row and column" counter associated with each active video stream ID.

4. Audio stream packet

The audio stream packets transmit audio data that is played through the display audio system or for a standalone audio presentation device. Different audio data streams can be allocated for separate audio channels of the sound system: for example, left front, right front, center, right back, left back, depending on the type of audio system used. A full complement of audio channels is provided for the head set that includes enhanced spatial acoustic signal processing. The format of the audio stream packets is shown in FIG. As shown in Fig. 13, the type of packet includes a packet length, packet type, audio channel ID, audio sample count, bits per sample and packing, audio sample rate, parameter CRC, digital audio data and audio data CRC fields. It is configured to include. Packets of this type are generally identified as type-2 packets.

The bits per sample and packing field contain one byte in the form of an 8-bit unencoded integer that specifies the packing format of the audio data. The format generally used is bit 0 to bit 4 which defines the number of bits per PCM audio sample. Bit 5 specifies whether the digital audio data samples have been packed. The difference between the packed sample and byte aligned audio samples is shown in FIG. A value of '0' indicates whether each PCM audio sample in the digital audio data field is aligned with the MDDI interface byte boundary, and a value of '1' indicates whether consecutive PCM audio samples have been packed against previous audio samples. . The bit is effective only when the value (number of bits per PCM audio sample) defined in bit 4 in bit 4 is not a multiple of eight. In bit 7 bit 6 is reserved for future use and is generally set to a value of zero.

5 Preallocated Stream Packets

The packet types 3 to 55 are reserved for later versions or stream packets which are defined for use in a variety of anticipated applications or changes in the packet protocol. In addition, in an environment where the system design changes compared to technology and other technologies, this makes it more flexible and useful for fabricating MDD interfaces.

6. User Defined Stream Packets

Eight data streams, known from type 56 to type 63, are pre-assigned for use in proprietary applications that can be defined by device manufacturers for use with MDDI links. These are known as user defined stream packets. The video stream packets transmit video data to update the orthogonal area of the display. The definition of the stream parameters and the data for the packet type is left up to the particular device manufacturer wishing to use. The format of the user defined stream packets is shown in FIG. As shown in Fig. 15, the packet of the type is configured to include a packet length, packet type, stream ID number, stream parameters, parameter CRC, stream data and stream data CRC fields.

7. Color Map Packets

The color map packets define the content of the color map lookup table used to represent the color for display. Certain applications may require more color maps than the amount of data that can be transmitted in a single packet. In that case, multiple color map packets may be sent, each having a different subset of the color map by using the offset and length fields described below. The format of the color map packet is shown in FIG. As shown in Fig. 16, the packet of the type is configured to include a packet length, packet type, color map data size, color map offset, parameter CRC, stream data and stream data CRC fields. Packets of this type are generally identified as type64 packets.

8. Reverse Link Encapsulation Packets

Data is transmitted in the reverse direction using reverse link encapsulation packets. The forward link packet is transmitted and the MDDI link operation (transmission direction) is changed or exchanged in the middle of the packet, so the packets can be transmitted in the reverse direction. The format of the reverse link encapsulation packet is shown in FIG. As shown in Fig. 17, the packet of the type includes packet length, packet type, reverse link plugs, exchange-round length, parameter CRC, exchange-round 1, reverse data packets, and exchange-round 2. Consists of. Packets of this type are generally identified as type 65 packets.

The MDDI link controller operates in a special way while transmitting reverse link encapsulation packets. The MDD interface has a strobe signal that is always driven by the host. The host acts as sending zeros for each bit of the data packet portion of the exchange round and reverse reverse link encapsulation packets. The host toggles the MDDI-strobe signal at each bit boundary during the two exchange round times and during the time allotted for the reverse data packet (which is all the same as acting to transmit zero data). The host disables its MDDI data signal line driver during the time period defined by the exchange round 1, and the client follows its time period defined by the exchange round 2 field. Re-enable during the drive re-enable field. The display reads the exchange-round length parameter and drives the data signal to the host after the last bit of the exchange-round1 field. The display uses the packet length and exchange-round length parameters to know the length of time that packets can be sent to the host. When no data is sent to the host, the client can send filler packets or drive the data lines to zero. If the data lines are driven to zero, the host interprets this as a packet of zero length, and the host does not receive any other packets from the client during the current reverse link encapsulation packet period.

The display drives the MDDI data lines to zero level for at least one reverse link clock period before the start of the exchange round 2 field. This maintains data lines in a determined state during the exchange round 2 time period. If the client no longer has a packet to transmit, after driving the data lines to zero level, the hibernation bias resistor keeps the data lines zero for the redundancy of the reverse data packet field. Can be disabled.

The reverse link request field and status packet of the display request are used to teach the host the number of bytes required for the display to return data to the host in the reverse link encapsulation packet. The host attempts to grant the request by allocating at least the number of bytes of the reverse link encapsulation packet. The host may transmit one or more reverse link encapsulation packets in a subframe. The display can send display requests and status packets at almost any time, and the host interprets the reverse link request parameter as the total number of bytes required in one subframe.

9. Display Capability Packets

The host needs to know the ability of the display to communicate to configure the host to display link in a preferred or optimal manner. The display recommends sending a Display Capability Packet to the host after forward link synchronization has taken place. The transmission of such a packet is considered to be required when requested by the host using the reverse link plug of the reverse link encapsulation packet. The format of the display capability packet is shown in FIG. As shown in Fig. 18, the packet of the type is packet length, packet type, protocol version, protocol protocol version, bitmap width, bitmap height, packet type, capability, color map capability, GBG capability, Y Cr Cb. It is configured to include a capability, a display characteristic capability, a data rate capability, a frame rate capability, an audio buffer depth, an audio stream capability, an audio rate capability, a sub subframe rate, and a CRC field. Packets of this type are generally identified as packets of type 66.

10. Keyboard Data Packets

Keyboard data packets are used to send keyboard data from the client device to the host. Wireless (or wired) keyboards may be used in combination with various display or audio devices, including but not limited to head mounted video display / audio presentation devices. The keyboard data packet relays keyboard data received from one of several devices, such as several known keyboards, to the host. The packet is also used to send data to the keyboard on the forward link. The format of the keyboard data packet is shown in FIG. 19 and contains several bytes of information from or to the keyboard. As shown in Figure 19, this packet type is configured to have a packet length, packet type, keyboard data, and CRC fields. This packet type is generally identified as a type 67 packet.

11. Pointing device data packets

The pointing device data packet is used to send location information from the wireless mouse or other pointing device from the display to the host. Data can also be sent to the pointing device on the forward link using this packet. The format of the pointing device data packet is shown in FIG. 20 and includes variable information bytes from or for the pointing device. As shown in Figure 20, this packet type is configured to have a packet length, packet type, pointing device data, and a CRC field. This packet type is generally identified as a type 68 packet in the 1-byte type field.

12. Link Blocking Packets

The link blocking packet is sent from the host to the client display to indicate that the MDDI data and strobe will shut down and proceed to a low-power consumption "hibernate" state. These packets are used to disconnect the link and conserve power after static bitmaps are sent from the mobile device to the display or when there is no information to be sent from the host to the client for the time being. Normal operation is initiated when the host sends a packet again. The first packet transmitted after hibernation is a sub-frame header packet. The format of the display status packet is shown in FIG. As shown in Figure 21, this packet type is configured to have a packet length, packet type, and CRC fields. This packet type generally uses a fixed length of 3 bytes that is identified as a type 69 packet in the 1-byte type field and is pre-selected.

In the low-power hibernation state, the MDDI data driver is disabled in a high impedance state, and the MDDI data signals are driven to a logic zero state using a high impedance bias network that can be overdriven by the display. The strobe signal used by the interface is set to a logic zero level to minimize power consumption in the dormant state. Either the host or the display can cause the MDDI link to be in a "wake up" state from hibernation, which is an advantage and an advanced feature of the present invention.

13. Display Request and Status Packets

In order to configure the host-to-display link in an optimal manner, the host needs a small amount of information from the display. It is desirable for the display to send one display status packet in each sub-frame of the host. The display must send these packets from the reverse link seal packet to the first packet to ensure reliable transmission to the host. The format of the display status packet is shown in FIG. As shown in Figure 22, this packet type is configured to have a packet length, packet type, reverse link request, CRC error count, and CRC field. This packet type is generally identified as a type 70 packet in the 1-byte type field and uses a pre-selected 7 byte fixed length.

The reverse link request field can be used to inform the host of the number of bytes the display needs in the reverse link seal packet to send data back to the host. The host should attempt to grant the request by allocating at least these bytes in at least the reverse link seal packet. The host may send one or more reverse link seal packets in the sub-frame to accommodate the data. The display may send a display request and status packet at any time and the host will interpret the reverse link request parameter as the total number of bytes requested in one sub-frame. Additional details and examples of how reverse link data is sent back to the host will be described below.

14. Bit Block Forwarding Packets

The bit block transfer packet provides a means for scrolling the areas of the display in any direction. Displays with this capability will report the capability in bit 0 of the display characteristic capability indicators for the display capability packet. The format of the bit block forwarding packet is shown in FIG. As shown in Figure 23, this packet type is configured to have a packet length, packet type, upper left X value, upper left Y value, window width, window height, window X move, window Y move, and CRC fields. This packet type is generally identified as a type 71 packet and uses a pre-selected fixed length of 15 bytes. These fields are used to define the X and Y values for the coordinates of the upper left corner of the window to move, the width and height of the window to move, and the number of pixels of the window to move horizontally and vertically, respectively. Positive values for the latter two fields cause the window to move to the right and downwards, and negative values to the left and to the top.

15. Bitmap Area Fill Packets

The bitmap area fill packet provides a means to easily initialize the display area for one color. Displays with this capability report this capability in bit 1 of the Display Capability Indicators field of the Display Capability Packet. The format of the bitmap region fill packet is shown in FIG. As shown in Figure 24, this packet type is configured to have a packet length, packet type, upper left X value, upper left Y value, window width, window height, data format descriptor, pixel area fill value, and CRC fields. This packet type is generally identified as a type 72 packet in the 1-byte field and uses a pre-selected fixed length of 17 bytes.

16. Bitmap Pattern Fill Packet

The bitmap pattern fill packet provides a means to easily initialize the area of the display for the pre-selected pattern. Displays with this capability report this capability in bit 2 of the Display Feature Capability Indicators field of the Display Capability Packet. The upper left corner of the fill pattern is aligned with the upper left corner of the window to be filled. If the window to be filled is wider or larger than the fill pattern, this pattern repeats several times horizontally or vertically to fill the window. The right side or bottom of the final repeated pattern is cut as needed. If the window is smaller than the fill pattern, the right or bottom of the fill pattern is cut to fit the window.

The format of the bitmap pattern fill packet is shown in FIG. As shown in Fig. 25, these packet types include 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 pixel. Configured to have data CRC fields. This packet type is generally identified as a type 73 packet in the 1-byte type field.

17. Communication Link Data Channel Packets

The communication link data channel packet provides a means for display with high-level computing capability, such as a PDA, to communicate with a wireless transceiver, such as a cellular phone or a wireless data port device. In this situation, the MDDI link behaves like an existing high speed interface between the communication device and the computing device via a mobile display, where these packets carry data at the data link layer of the operating system for the device. For example, such a packet can be used when a web browser, email client, or complete PDA is built on the mobile display. Displays with this capability report this capability in bit 3 of the Display Feature Capability Indicators field in the Display Capability Packet.

The format of the communication link data channel packet is shown in FIG. As shown in Fig. 26, this packet type is configured to have packet length, packet type, parameter CRC, communication link data, and communication data CRC fields. This packet type is generally identified as a type 74 packet in this field.

18. Interface Type Handoff Request Packets

The interface type handoff request packet can be type-I (serial), type-II (2-bit parallel), type-III (4-bit parallel), or type-IV (8-bit parallel) mode from the existing or current mode. This allows the host to request that the client or display move. Before the host requests a particular mode, it should check the bits 6 and 7 of the Display Feature Capability Indicator field in the Display Capability Packet to see if the display can operate in the required mode. The format of the interface type handoff request packet is shown in FIG. As shown in Figure 27, this packet type is configured to have a packet length, packet type, interface type, and CRC fields. This packet type is generally identified as a type 75 packet and uses a fixed length of 4 bytes pre-selected.

19. Interface type confirmation packets

Interface type acknowledgment packets are sent by the display to confirm receipt of interface type handoff packets. The requested mode, Type-I (serial), Type-II (2-bit parallel), Type-III (4-bit parallel), or Type-IV (8-bit parallel) mode, can be hosted as a parameter within these packets. Is echoed back to. The format of the interface type confirmation packet is shown in FIG. As shown in Figure 28, this packet type is configured to have a packet length, packet type, interface type, and CRC fields. This packet type is generally identified as a type 76 packet and uses a fixed length of 4 bytes pre-selected.

20. Perform Type Handoff Packet

A performance type handoff packet is a means by which the host instructs the display to handoff to the mode specified in this packet. This is the same mode as requested and confirmed by the Interface Handoff Request Packet and the Interface Type Confirmation Packet. The host and display must switch to the agreed mode after these packets are sent. The display may lose and regain link synchronization during this mode change. The format of the performance type handoff packet is shown in FIG. As shown in Figure 29, this packet type is configured to have a packet length, packet type, and CRC fields. This packet type is generally identified as a Type 77 packet in the 1-Byte Type field and uses a fixed length of pre-selected 4 bytes.

21. Forward Audio Channel Enable Packets

This packet allows the host to enable or disable audio channels in the display. This capability is useful for enabling a display (client) to power off an audio amplifier or similar circuit elements when there is no audio output by the host. This is more difficult to implement simply using the presence or absence of audio streams as an indicator. The default state when the display system is powered up is that all audio channels are enabled. The format of the forward audio channel enable packet is shown in FIG. As shown in FIG. 30, this packet type is configured to have a packet length, packet type, audio channel enable mask, and CRC fields. This packet type is identified as a type 78 packet in the 1-byte type field and uses a fixed length of 4 bytes pre-selected.

22. Reverse Audio Sample Rate Packets

This packet allows the host to enable or disable reverse link audio channels and to set the data sample rate of this stream. The host selects a sample rate defined as valid in the display capability packet. If the host selects an invalid sample rate, the display will not send an audio stream to the host. The default state assumed when the display system is initially powered up or connected is to disable the reverse link audio stream. The format of the reverse audio sample rate packet is shown in FIG. As shown in Figure 31, this packet type is configured to have a packet length, packet type, audio sample rate, and CRC fields. This packet type generally identifies a type 79 packet and uses a fixed length of 4 bytes pre-selected.

23. Digital Content Protection Overhead Packets

These packets allow the host and display to exchange messages related to the digital content protection method used. Currently, high-bandwidth digital content protection system (HDCP) or digital transmission content protection (DTCP) with two types of content protection, a reserved room for future alternative protection scheme designations, is contemplated. The method used is defined by the content protection type parameter in this packet. The format of this content protection overhead packet is shown in FIG. As shown in Figure 32, this packet type is configured to have a packet length, packet type, content protection type, content protection overhead messages, and CRC fields. This packet type is generally identified as a type 80 packet.

24. Transparent Color Enable Packets

The transparent color enable packet is used to specify which color is transparent in the display and to enable or disable the use of the transparent color to display images. Displays with this capability will report this capability in 4 bits of the Display Feature Capability Indicators of the Display Capability Packet. When a pixel having a value for the transparent color is written to the bitmap, this color does not change from the previous value. The format of the transparent color enable packet is shown in FIG. As shown in Figure 33, this packet type is configured to have a packet length, packet type, transparent color enable, data format descriptor, transparent pixel value, and CRC fields. This packet type is generally identified as a type 81 packet in the 1-byte type fields and uses a pre-selected fixed length of 10 bytes.

25. Round trip delay measurement packets

The round trip delay measurement packet is used to measure the propagation delay value plus the delay from the host to the client (display) and the delay from the client (display) to the host. This measurement essentially includes delays present in the line drivers, receivers, and interconnect sub-system. This measure is used to set the reverse link rate divisor parameters and turn around delay in the reverse link seal packet as described generally above. These packets are most useful when the MDDI link is operating at the maximum speed intended for a particular application. The MDDI Stb signal acts as if all zero data is transmitted during the following fields: all zeros, guard times, and measurement period. This allows the 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.

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

The timing of events occurring during the round trip delay measurement packet is shown in FIG. In FIG. 35, the host transmits a round trip delay measurement packet presented by the presence of the parameter CRC and strobe alignment preceding all zero and guard time 1 fields. Delay 3502 occurs before the packet reaches the client display device or processing circuitry. When the display receives the packet, it transmits the pattern Oxff, 0xff, 0xf exactly as it really is at the beginning of the measurement period determined by the display. The actual time at which the display starts transmitting this sequence is delayed from the start of the measurement period from the host's point of view. This amount of delay is the time it takes for a packet to propagate through the line driver, receiver, and interconnect system. A similar amount of delay in delay 3504 is caused by the pattern propagating back from the display to the host.

In order to accurately determine the round trip delay time for signal traversal to and from the client, the host must determine which bits occur after the start of the measurement cycle until the start of the Oxff, 0xff, 0xf sequence is detected on arrival. Count the number of time periods. This information is used to determine the amount of time it takes for the round trip signal from the host to the client and then back from the client to the host. Then, about half of this amount is considered the delay incurred for one-way signaling to the client.

The display disables the line drivers immediately after sending the last bits of the 0xff, 0xff, and 0xf patterns. Guard time 2 allows time for the line drivers of the display to go to a completely high-impedance state before the host sends the packet length of the next packet. Hibernate pull-up and pull-down resistors (see Figure 42) allow the MDDI data signals to remain at a valid low level at the interval at which the line drivers are disabled on both the host and the display.

D. Packet CRC

CRC fields appear at the end of packets and often with very large data fields and after any more important parameters in a packet that are prone to error during delivery. In packets with two CRC fields, if only one is used, the CRC generator is reinitialized after the first CRC so that CRC calculations following the long data field are not affected by the parameters at the beginning of the packet.

In an embodiment of the invention, the polynomial used for the CRC calculation is known as CRC-16, or X ¹⁶ + X ¹⁵ + X ² + X ⁰ . An exemplary implementation of a CRC generator and tester 3600 useful for implementing the present invention is shown in FIG. 36. In Fig. 36, the CRC register 3602 is initialized to a value of 0x0001 just before the transfer of the first bit of the packet input on Tx_MDDI_Data_Before_CRC, and then the bytes of the packet are shifted into a register starting with the first LSB. It should be noted that the register bit numbers in this figure correspond to the order of the polynomial used and are not the bit positions used by MDDI. Moving the CRC register in a single direction is more efficient, when MDDI bit position 14 is reached in such a way that CRC bit 15 appears in bit position 0 of the MDDI CRC field and CRC register bit 14 appears in MDDI CRC bit position 1. To be performed.

For example, packet contents for display request and status packets may be 0x07, 0x46, 0x000400, 0x00 (or 0x07, 0x00,0x46, 0x00, 0x04). , Represented as a byte sequence such as 0 × 00, 0 × 00), and transmitted using multiplexers 3604, 3606, and NAND gate 3608, the resulting CRC output on the Tx_MDDI_Data_With_CRC line is 0 × 0ea1 ( Or 0xa1, 0x0e sequence).

When the CRC generator and checker 3600 is configured as a CRC checker, the CRC received at the Rx_MDDI_Data line is input to the multiplexer 3604 and the NAND gate 3608, and the NOR gate 3610, exclusive-OR (NOR) gate ( 3612, and AND gate 3614 is used to compare bitwise to the value found in the CRC register. When output by AND gate 3614, if any error occurs, the CRC is incremented once for every packet containing a CRC error by connecting the output of gate 3614 to the input of register 3602. Note that the example circuit shown in FIG. 36 may output one or more CRC error signals within a given CHECK_CRC_NOW window (see FIG. 37B). Thus, the CRC error counter will only count the first CRC error instance within each interval for which CHECK_CRC_NOW is active. If implemented as a CRC generator, the CRC is clocked from the CRC register at a time consistent with the end of the packet.

The timing for the input and output signals, and the enabling signals, are shown in Figures 37A and 37B. CRC generation and transmission of data packets are shown in FIG. 37A and have states (0, 1) for Gen_Reset, Check_CRC_NOW, Generate_CRC_NOW, Sending_MDDI_Data signals, Tx_MDDI_Data_Before_CRC, and Tx_MDDI_Data_With_CRC signals. A check for the reception and CRC value of the data packet is shown in FIG. 37 and has states for Gen_Reset, Check_CRC_Now, Generate_CRC_Now, Sending_MDDI_Data signal, Rx_MDDI_Data and CRC error signals.

Ⅴ. Restart link from hibernation

When the host resumes from hibernation to the forward link, it drives MDDI_Data to the logical 1 state for approximately 150μsec and then activates MDDI_Stb and simultaneously drives MDDI_Data to logical zero for 50μsec, and then transmits the sub-frame header packet. Thereby initiating forward link traffic. This generally provides sufficient settling time between signals so that bus connections are resolved before the sub-frame header packet is transmitted.

Client, where the display requires data or communication from the host, the client drives the MDDI_Data0 line to a logic 1 state for approximately 70 μsec, then other drivers may be used as required, then the driver to a high impedance state. Disable the driver. This operation allows the host to start or restart data traffic on the forward link 208 and poll the client for its status. The host must detect the presence of the request pulse within 50 μsec, then initiate a startup sequence that drives MDDI_Data0 to logic 1 for 150 μsec and logic 0 for 50 μsec. If the display does not detect MDDI_Data0 in Logic 1 state for more than 50μsec, it shall not send a service request. The selection of these times and the tolerance of the intervals associated with hibernation and startup sequences will be described below.

An example of processing steps for a generic service request event 3800 with no contention is shown in FIG. 38, where the events are labeled for convenience using the letters A, B, C, D, E, F, and G. . This process is initiated at point A when the host sends a link blocking packet to the client to indicate that the link will transition to a low-power hibernation state. In the next step, the host enters a low power hibernation state by disabling the MDDI Data0 driver and setting the MDDI Stb driver to logic 0, as shown at point B. MDDI DataO is driven to zero level by a high-impedance bias network. After some time period, the client sends a service request pulse by driving MDDI_Data0 to a logical one level as indicated at point C. The host still exhibits a zero level using a high-impedance bias network, but the driver of the client forces this line to a logical one level. Within 50 μsec, the host acknowledges the service request pulse and asserts a logical one level on MDDI DataO by enabling the driver as shown at point D. The client then ceases attempting to assert the service request pulse and the client puts the driver in high-impedance state as indicated at point E. The host starts driving MDDI DataO at a logic zero level for 50 μsec, as shown at point F, and also starts generating MDDI Stb in a manner consistent with the logic zero level on MDDI DataO. After asserting MDDI Data0 to zero level and driving MDDI Stb for 50 μsec, the host starts transmitting data on the forward link by sending a sub-frame header packet as indicated at point G.

A similar example is shown in Figure 39, where the service request is asserted after the link restart sequence is initiated and the events are again labeled using the letters A, B, C, D, E, F, G. This represents the worst case where the request pulse from the client is closest to destroying the sub-frame header packet. This process begins at point A when the host sends a link blocking packet back to the client device to indicate that the link will transition to a low power hibernation state. In the next step, the host enters a low-power hibernation state by disabling the MDDI Data0 driver and setting the MDDI Stb driver to logic zero as shown in point B. As before, MDDI DataO is driven to zero level by a high-impedance bias network. After a period of time, the host initiates the link restart sequence by driving MDDI_Data0 to a logical 1 level for 150 μsec, as shown at point C. Before 50 μsec elapses after the link restart sequence begins, the display also asserts MDDI DataO for 70 μsec, as shown at point D. This occurs because the display needs to request service from the host and does not realize that the host has already started the link restart sequence. The client then ceases attempting to assert a service request pulse and the client puts the driver in high-impedance state as indicated at point E. The host drives MDDI DataO at a logic zero level for 50 μsec, as shown at point F, and also starts generating MDDI Stb in a manner consistent with the logic zero level at MDDI DataO. After asserting MDDI Data0 to zero level and driving MDDI Stb for 50 microseconds, the host starts transmitting data on the forward link by sending a sub-frame header packet as shown at point G.

Ⅵ. Interface electrical details

In an embodiment of the present invention, data in non-zero return (NRZ) format is encoded using a data-strobe signal or a DATA-STB format, which allows clock information to be embedded within the data and storobe signals. The clock can be recovered without complex phase clock loop circuitry. Data is transferred on a bi-directional differential link, which is generally implemented using wire-line cables as mentioned above, although other conductors, printed wires, or transfer elements may be used. The strobe signal STB is carried on a unidirectional link driven only by the host. The strobe signal toggles the value (0 or 1) whenever there is a black to black state, 0 or 1, that remains the same on the data line or signal.

An example of how a data sequence such as bit "1110001011" can be transmitted using DATA-STB encoding is shown in FIG. In FIG. 40, the DATA signal 4002 is presented on the top line of the signal timing chart, and the STB signal 4004 is presented on the second line, and is properly aligned each time (common starting point). Over time, if a state change occurs on the DATA line 4003 (signal), the STB line 4004 (signal) remains in its previous state, so that the first "1" state of the DATA signal is its starting value. Correlated with the first "0" state for the STB signal. However, if the state, level of the DATA signal does not change, the STB signal toggles to the opposite state, or "1" in the current example, and as in the example of Figure 40, DATA provides another '1' value. That is, there is always one and only one transition per bit cycle between DATA and STB. Therefore, when the DATA signal stays at '1', the STB signal transitions to '0' this time and holds this level or value when the DATA signal changes to '0' level. If the DATA signal stays at '1', the STB signal toggles to '1' in the opposite state or current example, and the DATA signal changes or holds the level or values.

Upon receiving these signals, an exclusive-OR (XOR) operation is performed on the DATA and STB signals to generate a clock signal 4006, which is used in the timing chart for relative comparison with the required data and storobe signals. Presented at the bottom. An example of circuitry useful for generating DATA and STB outputs or signals from input data at a host and then recovering and extracting data from DATA and STB signals at a client is shown in FIG.

In FIG. 41, the transmitting portion 4100 is used to generate and transmit original DATA and STB signals on the intermediate signal path 4102, and the receiving portion 4120 is used to receive the signal and recover the data. As shown in Figure 41, to transfer data from the host to the client, the data signal is input into two D-type flip-flop circuit elements 4104 and 4106 with a clock signal that triggers the circuit. The two flip-flop circuit outputs Q are then divided into differential pairs MDDI_Data0 +, MDDI_Data0- and MDDI_Stb +, MDDI_Stb- of signals using two differential line drivers 4108 and 4110 (voltage mode). A 3-input exclusive-NOR (XNOR) gate, circuit or logic element 4112 receives the outputs and DATA of both flip-flops and provides a data input for a second flip-flop that generates MDDI_Stb +, MDDI_Stb− signals. Connected to generate an output. For convenience, the XNOR gate has an inversion bubble located to indicate that it is effectively inverting the Q output of the flip-flop that generates the strobe.

In receive portion 4120 of FIG. 41, MDDI DataO +, MDDI DataO and MDDI_Stb +, MDDI Stb- signals are received by each of two differential line receivers 4122 and 4124 generating one outputs from the differential signals. The outputs of the amplifiers are then input to each of the inputs of a two-input exclusive-OR (XOR) gate, circuit, logic element 4126 that generates a clock signal. The clock signal is used to trigger each of the two D-type flip-flop circuits 4128 and 4130 to receive a delayed version of the DATA signal via the delay element 4132, one of which 4128 is a data '0' value. And the other 4130 generates a data '1' value. The clock also has an output independent from the XOR logic. Since clock information is distributed between the DATA and STB lines, no signal transitions between states more than half the clock rate. Because clock information is regenerated using exclusive-OR processing of DATA and STB signals, the system effectively allows twice the amount of skew between the input data and the clock compared to when the clock signal is transmitted directly on one dedicated data line. .

MDDI_Data +, MDDI_Data- and MDDI_Stb +, MDDI_Stb- signals are operated in differential mode to maximize immunity from negative effects of noise. Each part of the differential signal path is a source terminated with half the characteristic impedance of the cable or conductor used to carry the signals. MDDI_Data +, MDDI_Data- are the source terminated at both ends of the host and client. Since only one of these drivers operates at a given time, there is always a termination at the source for the transport link. MDDI Stb +, MDDI Stb- signals are driven by the host.

An exemplary configuration of elements useful for achieving drivers, receivers, and terminations for conveying signals as part of the original MDD interface is shown in FIG. 42, and the corresponding DC electrical details of MDDI Data and MDDI Stb are listed. Is presented in This exemplary interface uses 200 mV of low power sensing and low power drain, which is less than 1 volt power swing.

Table 7

parameter Contents Min Typ Max unit R _term Serial termination 41.3 42.2 43.0 0hms R _hibernate Hibernation Bias Termination 8 10 12 K-Ohms V _hibernate Hibernating state open-circuit voltage 1.5 3.3 V _{Voutput-range} Allowable Driver Output Range for GND 0 2.8 V V _{OD +} Driver Differential Output High Voltage 0.8 V V _OD- Driver Differential Output Undervoltage -0.8 V V _{IT +} Receiver Differential Input High Threshold Voltage 100 mV V _IT- Receiver Differential Input Low Threshold Voltage -100 mV V _Input-Range Allowable Receiver Input Voltage Range for GND 0 2.8 V I _in Input Leakage Current (No Hibernate Bias) -25 25 ㎂

The electrical parameters and characteristics of the differential line drivers and line receivers are presented in Table VII. Functionally, the driver passes the logic level on the input directly to the positive output and the inverse of the input to the negative output. The delay from the input to the outputs matches well with the differentially driven differential line. In most implementations, the voltage swing on the outputs is smaller than the swing on the input to minimize power consumption and electromagnetic emissions. Table 7 shows the minimum voltage swing of approximately 0.8V. However, other values may be used and are well understood by those skilled in the art, and the present invention contemplates small values of 0.5 or 0.6 V in some embodiments depending on design limitations.

Differential line receivers have the same characteristics as fast voltage comparators. In Figure 41, the input without bubbles is a positive input and the input with bubbles is a negative input. The output is logical 1 if (V _{input +} )-(V _input- ) is greater than zero. Another way of describing this is a differential amplifier with a very large (actually infinite) gain with a clipped output at logic 0 and 1 voltage levels.

Delay skew between different pairs should be minimized to operate the differential transmission system at the highest potential speed.

In FIG. 42, a host controller 4202 and a client or display controller 4204 are presented to forward packets on the communication link 4206. The host controller uses a series of three drivers 4210, 4212, 4214 to receive host DATA and STB signals to be forwarded and also client data signals to be forwarded. The driver responsible for passing the host DATA uses the enable signal input to allow the communication link to be active only when a transfer from the host to the client is required. Since the STB signal is formed as part of the data transfer, no additional enable signal is used for that driver 4212. Respective outputs of the DATA and STB drivers are connected to termination impedances or resistors 4216a, 4216b, 4216c and 4216d, respectively.

Termination resistors 4216a and 4216b also operate as impedances to the input of client-side receiver 4220 for STB signal processing, and additional termination resistors 4216e and 4216f are in series with resistors 4216c and 4216d. Disposed on an input of a processing receiver 4222. The sixth driver 4262 of the client controller is used to prepare the data signals to be delivered from the client to the host, where the driver 4214 is for delivery to the host to be processed at the input side via termination resistors 4216c and 4216d. Process the data.

Two additional resistors 4218a and 4218b are located between terminating resistors and ground and voltage source 4220 as part of hibernate control. The voltage source is used to drive the delivery lines at the high or low level previously discussed to manage the data flow.

The drivers and impedances may be formed as part of an application specific integrated circuit (ASIC) that operates with discrete components or a more cost effective encoder or decoder solution.

Signals labeled MDDI_Pwr and MDDI_Gnd on a pair of conductors can be used to easily identify the power transfer from the host device to the client device or display. The MDDI Gnd portion of the signal acts as a signal for the reference ground and power supply return path or display device. In an example implementation, for low power applications, the display device is allowed up to 5OOmA. The MDDI Pwr signal may be provided from portable power sources such as a lithium-ion type battery or a battery pack located in a host device and has a range of 3.2 to 4.3 volts for MDDI Gnd.

Iii. Timing characteristics

A. Overview

The steps and signal levels used by the client to protect the service from the host and used by the host to provide such a service are shown in FIG. In Figure 43, the first portion of the signals presented shows a link blocking packet from the host and the data line is driven to logic zero using a high-impedance bias circuit. No data is sent by the client display or host whose driver is disabled. Since MDDI Stb operates during the link blocking packet, a series of strobe pulses for the MDDI Stb signal line can be seen at the bottom. If such a packet ends and the logic level changes to zero as the host drives the bias circuit and logic to zero, the MDDI Stb signal line also changes to zero level. This may indicate the last signaling or termination of a service from the host and may occur at any time in the past, and is included to show the status of signals prior to service pre-suspension and service initiation. If necessary, a signal can be sent to reset the communication link to an appropriate state without the 'known' previous communication taken by this host device.

As shown in Figure 43, the signal output from the client is initially set to zero logic level. That is, the client output is high impedance and the driver is disabled. When a service is requested, the client enables the driver and sends a service request to the host, the time period specified by t _service , during which the line is driven to a logical one level. Then any time has elapsed or some time is required before the host named t _host-detect is able to detect the request, after which the host responds through the link startup sequence by driving the signal to a logical one level. . At this point, the client de-asserts the request and disables the service request driver so that the output line from the client goes back to zero logic level. During this time, the MDDI Stb signal is at logic zero level.

The host drives the host data output at the '1' level for a time called t _restart-high , after which the host drives the logic level to zero and activates _{MDDI_Stb} for a period called t _restrt-low , After time the first forward traffic begins with a frame header packet, and then forward traffic packets are forwarded. The MDDI Stb signal is active during t _restrat-low periods and subsequent frame header packets.

Table VII shows the times showing the length of the various periods discussed above and the relationship to the exemplary minimum and maximum data rates, where

t _bit = 1 / (Link_Data_Rate).

Table 8

parameter Contents Min Typ Max unit t _service Display Service Request Pulse Duration 60 70 80 μsec t _restrat-high Host Link Restart High Pulse Duration 140 150 160 μsec t _restrat-low Host Link Restart Low Pulse Duration 40 50 60 μsec t _{display-detect} The time when the display detects the link restart sequence One 50 μsec t _host-detect The time when the host detects a service request pulse One 50 μsec 1 / t _bit-min-perf Link Data Rate for Minimum Performance Devices 0.001 One Mbps 1 / t _bit-max-perf Maximum link data rate range for the device 0.001 450 Mbps Reverse link data rate 0.0005 50 Mbps t _bit Period of one forward link data bit 2.2 10 ⁶ nsec

Those skilled in the art can understand the functions of the individual elements shown in FIGS. 41 and 42 well, and the function of the elements shown in FIG. 42 is confirmed by the timing diagram shown in FIG. Details of the series of terminations and hibernate resistors shown in FIG. 42 have been omitted from FIG. 41 because this information is unnecessary to describe how to perform data-strobe encoding and recover the clock from it.

B. Data-Strobe Timing Forward Link

The switching characteristics for data transfer on the forward link from the host driver output are presented in Table VII. Table VII shows the minimum and maximum table form required for typical times for any signal transitions that occur. For example, the typical length of time for a transition to occur from the beginning of a data value (output of '0' or '1' ₎ , the Data0 to Data0 transition, referred to as t _{dd- (host-output)} , is t _tbit The maximum time is approximately t _{tbit +0.5} nsec and the minimum time is approximately t _tbit -0.5 nsec. The relative spacing between transitions in Data0, other data lines DataX, and strobe lines Stb is shown in Figure 44, where Data0 to Strobe, Strobe to Strobe, Strobe to Data0, Data0 to non- Data0, non-Data0 to non-Data0, non-Data0 to Strobe, and Strobe to non-Data0 transitions are presented, each of 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)} .

Table 9

parameter Contents Min Typ Max Units t _{dd- (host-output)} Data0 to Data0 transition t _tbit -0.5 t _tbit t _tbit +0.5 nsec t _{tds- (host-output)} Data0 to Strobe transition t _tbit -0.8 t _tbit t _tbit +0.5 nsec t _{tss- (host-output)} Strobe to Strobe transition t _tbit -0.5 t _tbit t _tbit +0.5 nsec t _{tsd- (host-output)} Strobe to Data0 transition t _tbit -0.8 t _tbit t _tbit +0.5 nsec t _{tddx- (host-output)} Data0 to non-Data0 transition t _tbit -0.? t _tbit t _tbit +0.5 nsec t _{tdxdx- (host-output)} non-Data0 to non-Data0 transition t _tbit t _tbit +0.5 nsec t _{tdxs- (host-output)} non-Data0 to Strobe transition t _tbit -0.? t _tbit t _tbit +0.5 nsec _{tsdx- (host-output)} Strobe to non-Data0 transition t _tbit -0.? t _tbit t _tbit +0.5 nsec

General MDDI timing requirements of the client receiver input for the same signals carrying data on the forward link are shown in Table VIII. Since the same signals are discussed with only time delay, no new drawing is needed to describe the signal characteristics or meaning for each label, which will be understood by those skilled in the art.

Table 10

parameter Contents Min Typ Max Units t _{dd- (display-input)} Data0 to Data0 transition t _tbit -0.5 t _tbit t _tbit +0.5 nsec t _{tds- (display-input)} Data0 to Strobe transition t _tbit -0.8 t _tbit t _tbit +0.5 nsec t _{tss- (display-input)} Strobe to Strobe transition t _tbit -0.5 t _tbit t _tbit +0.5 nsec t _{tsd- (display-input)} Strobe to Data0 transition t _tbit -0.8 t _tbit t _tbit +0.5 nsec t _{tddx- (host-output)} Data0 to non-Data0 transition t _tbit -0.? t _tbit t _tbit +0.5 nsec t _{tdxdx- (host-output)} non-Data0 to non-Data0 transition t _tbit t _tbit +0.5 nsec t _{tdxs- (host-output)} non-Data0 to Strobe transition t _tbit -0.? t _tbit t _tbit +0.5 nsec t _{sdx- (host-output)} Strobe to non-Data0 transition t _tbit -0.? t _tbit t _tbit +0.5 nsec

45 and 46 illustrate the presence of delays in the response that may occur when the host disables or enables the host driver, respectively. In the case where the host transmits any packets, such as a reverse link seal packet or a round trip delay measurement packet, the host must transmit the required packets, for example, the parameter CRC, strobe alignment, and all zero packets shown in FIG. Disable the line driver. However, as shown in FIG. 45, although any control diagram is potentially achievable via circuit elements, as shown in FIG. 45, the state of the line does not necessarily switch immediately from '0' to the required high value. For response, the time required to refer to the host driver disable delay period is taken. This actually occurs immediately and this time period is 0 nsec and can easily be extended to longer time periods with the required maximum period length of 10 nsec occurring during guard time 1 or return 1 packet periods.

Referring to Figure 46, a signal level change is presented when the host driver is enabled to deliver a packet, such as a reverse link seal packet or a round trip delay measurement packet. Here, after a guard time 2 or round 2 packet period, the host driver is enabled and starts driving a level, where '0', and this value approaches or arrives at a time period referred to as the host driver enable delay period. Occurs during a driver re-enable period before one packet is transmitted.

Similar processing occurs for the drivers, and signals are passed to the client device, here a display. General guidelines for their lengths and their respective relationships are presented in Table II below.

Table 11

Contents Min Max unit Host Driver Disable Delay 0 10 nsec Host Driver Enable Delay 0 2.0 nsec Display Driver Disable Delay 0 10 nsec Display Driver Enable Delay 0 2.0 nsec

C. Data-Strobe Timing Reverse Link

Timing relationships and switching characteristics for the data and strobe signals used to carry data on the reverse link from the client driver output are shown in FIGS. 47 and 48. Typical times for any signal are given below. Figure 47 shows the relationship at the host receiver input between the timing of the data being transferred and the leading and trailing edges of the strobe pulses. That is, t _su-sr , referred to as the set-up time for the rising and leading edges of the strobe signals, and t _su-sf , referred to as the set-up time for the trailing or falling edge of the strobe signals, are presented. The typical length of time for these set-up periods is 8 nsec.

48 shows the corresponding client output delay and switching characteristics developed by reverse data timing. In Figure 48, the relationship between the leading and trailing edges of the strobe pulses describing the timing and induced delay of the data being transferred is presented. That is, propagation delay between rising or leading edge of data and strobe signals, t _pd-sr and propagation delay between trailing or falling edge of strobe signals and data, t _{pd -sf} . The typical length of these propagation delay periods is 8 nsec.

Iii. Implementation of Link Control (Link Controller Operation)

A. State Machine Packet Processor

Packets carried on the MDDI link are sent at very high speeds, typically 300 Mbps or more, although low speeds are acceptable as needed. This type of bus or transfer link speed is too large for general purpose microprocessors and the like, which are currently commercially available. Thus, practical implementations to achieve this type of signaling use a programmable state machine that parses the input packet stream to generate packets that are delivered to the appropriate audio-visual subsystem they intend.

General purpose controllers, processors, or processing elements may be used to properly operate or manipulate some information, such as control or status packets with low rate requirements. When such packets (control, state, or other predetermined packets) are received, the state machine passes through a data buffer or similar processing element to a general purpose processor, where audio and visual packets are delivered to the destination where they are appropriate for operation. It allows the packets to be operated to provide the required result.

A general purpose processor function is processing power, or excess cycles available, in the same manner as using a computer's CPU processing power to allow some modems or graphics processors to perform some functions and reduce hardware complexity and costs, It may be realized in some embodiments by using microprocessors (CPUs), or processors, digital signal processors (DSPs), or ASICs found in a wireless device of a computer application. However, since this negatively affects processing speed, timing, and the overall operation of these elements, dedicated circuits or elements are preferred for this general processing in many applications.

In order to allow image data to be observed on the display (micro-display), or to reliably receive all packets sent by the host, display signal processing must be synchronized with the forward link channel timing. That is, the signals arriving at the display and the display circuits must be time synchronized to allow proper signal processing. A high level diagram of the states achieved by the method or signal processing steps in which this synchronization is implemented is shown in FIG. In FIG. 49, the possible forward link synchronization "states" for the state machine 4900 are one sync frame state 4904, two acquisition sync states 4902 and 4906, and three internal sync states 4908, 4910, and 4912 is shown.

As shown by start step or state 4902, the display searches for a unique word in the detected first subframe header packet starting from a preselected " asynchronous " state. It should be noted that the asynchronous state represents the minimum communication setting or "return" setting for which the I type interface is selected. If a unique word is found during the search, the display stores the subframe length field. The check of the CRC bit is not performed for processing in the first frame or until synchronization is performed. If the subframe length is zero, then synchronization state processing proceeds according to the method of step 4904, labeled "asynchronous frame," indicating that synchronization has not yet been performed. The processing step is named cond3, or condition 3, which is met in FIG. In contrast, if the frame length is greater than zero, sync state processing proceeds to state 4906, where the interface state is set to "one sync frame found". The processing step is named cond5 or condition 5 which is met in FIG. Also, if the state machine recognizes a frame header packet and a good CRC decision for a frame length of zero or more, processing proceeds to a " one sync frame found " state. This is termed cond 6 or condition 6, which is met in FIG.

In each state where the system is in a state other than "asynchronous", a unique word is detected, a good CRC result is determined for the subframe header packet, and if the subframe length is greater than zero, the interface state is "internal sync". Is changed to state 4908. In processing the step is named to satisfy cond1, or condition 1 of FIG. In other words, if either the unique word or the CRC in the subframe header packet is incorrect, the sync state processing proceeds or returns to interface state 4902 in the "asynchronous frame" state. The processing portion is named as cond2 or condition 2, which is met in the state diagram of FIG.

B. Sync Acquisition Time

The interface may be configured to accommodate a certain number of "synchronization errors" before determining whether synchronization is lost and returning to the "asynchronous frame" state. In Fig. 49, if the state machine reaches the "internal sync state" and no error is found at all, it continuously meets the cond1 result and is in the "internal sync" state. However, if one cond2 result is detected, processing changes state to " one sync error " state 4910. At this point, if processing detects another cond1 result, the state machine returns to the "internal sync" state, meets another cond2 result, or moves to the "two sync error" state 4912. In other words, if cond1 occurs, processing returns the state machine to the "internal sync" state. Also, upon encountering another cond2, the state machine returns to the "asynchronous" state. Meeting the "link blocking packet" causes the link to terminate the data transmission, returning to the "asynchronous frame" state because there is nothing to synchronize, which is referred to as cond4 or condition 4 in the state diagram of FIG. do.

It is understood that there may be a repeating "failure copy" of unique words that may appear at any fixed location within the subframe. In this situation, the state machine cannot synchronize in the subframe because the CRC of the subframe header packet must be validated when processed for the MDD interface processing to proceed to the "internal sync" state.

The subframe length in the subframe header packet may be set to zero to indicate that the host will transmit the subframe before the link is blocked and the MDD interface is deployed or configured in a dormant hibernation state. In this case, the display must immediately receive the packet on the forward link after detecting the subframe header packet because a single subframe must be sent before the link transition to the dormant state. In normal or normal operation, the subframe length is not zero and the display processes the forward link packet while the interface is in the state shown collectively as " IN_SYNC " in FIG.

The time required for the display to synchronize the forward link signal may vary depending on the subframe size and the forward link data rate. The probability of detecting a "failure copy" of a unique word as part of random or more random data on the forward link is higher when the subframe size is larger. At the same time, the probability of recovering from failure detection is lower, and the time it takes to execute this when the forward link data rate is slower becomes longer.

C. Initialization

As described above, in the "start" time, the host is configured to operate at or below the minimum required or desired data rate of 1 Mbps, and to appropriately configure the subframe length and media frame rate for a given application. That is, both the forward and reverse links begin to operate using the Form I interface. The parameter generally allows the host to be used temporarily while determining the ability or desired configuration for the client display (or other device). The host sends or transforms a subframe header packet over the forward link following the reverse link capsule packet of the request flag of bit '0' set to a value of one to request the display to respond to the display capability packet. do. When the display acquires synchronization on the forward link (or via the forward link), it sends a Display Capability Packet and a Display Request and Status Packet on the reverse link or channel.

The host examines the contents of the display capability packet to determine how to configure the link for optimal or desired level of performance. The host checks the protocol version and the minimum protocol version to verify that the host and display use a protocol version that is compatible with each other. The protocol version is maintained with the first two parameters of the Display Capability Packet so that conformance can be determined if other protocol elements can be fully understood or may not be appropriate.

D. CRC Processing

For all packet types, the packet processor state machine ensures that the CRC checker is properly or properly controlled. The packet processor state machine also increments the CRC error counter if the CRC comparison causes one or more errors to be detected, and resets the CRC counter at the time each subframe begins to be processed.

IX. Packet processing

For every packet of the type described above that the state machine receives, it initiates a specific processing step or series of steps for performing the operation of the interface. Forward link packets are generally processed according to the example processing listed in Table XII below.

Table 12

Packet form Packet Processor State Machine Response Subframe header (SH) Identify good packets, obtain subframe length field, and send packet parameters to general purpose processor. Filter (F) Ignore the data. Video stream (VS) Describe video data format descriptors and other parameters, decode packetized pixel data as needed, convert pixels through colormaps if necessary, and write pixel data to appropriate locations within the bitmap. Audio stream (AS) Send audio sample rate settings to an audio sample clock generator, split it into audio samples of a specific size, decode audio sample data as needed, and route audio samples to the appropriate audio sample FIFO. Color map (CM) Read colormap size and offset parameters to write colormap data to colormap memory or storage location. Reverse Link Encapsulation (REL) On request by the host, send the packet type using the Reverse Link Flag field of the Reverse Link Encapsulation Packet. Display Capability (DC) Facilitating the transmission of packets in the reverse direction at the appropriate time. Reverse link flag is checked and sent if display capability packet is needed. Display request and status packet sent properly. Keyboard (K) If one is present, it communicates with the keyboard type device by passing the packet to and from the general purpose processor, and use is supported. Pointing Device (PD) If one is present it communicates with the pointing type device by passing the packet to and from the general purpose processor and use is supported. Link Blocking (LS) Record fact link notified by blocking the general purpose processor. Display Service Requests and Status (DSRS) Send the packet as a first packet in a reverse link capsule packet. Bit Block Transfer (BPT) Parse packet parameters such as video data format descriptors to determine which pixels to move first, and move pixels into bitmaps if necessary. Batmap Area Fill (BAF) Interpret packet parameters, convert pixels through colormaps if necessary, and write pixel data to appropriate locations in the bitmap. Bitmap Pattern Fill (BPF) Interpret packet parameters, decode packetized pixel data if necessary, convert pixels through colormaps if necessary, and write pixel data to appropriate locations in the bitmap. Communication Link Channel (CLC) Immediately send the data to the general purpose processor.

Display Service Request (DSR) during hibernation The general purpose processor controls low level transfer request functions and detects conflicts with link restarts on the general purpose processor. Interface Type Handoff Request (ITHR) and Interface Type Approval (ITA) Pass the packet to and from the general purpose processor. The logic for receiving this type of packet and formalizing the response to the grant is substantially minimal. Therefore, the operation can also be performed in a packet processor state machine. The resulting handoff results from low level physical layer operation and may not affect the functionality or functionality of a general purpose processor. Execution Mode Handoff (PTH) It can operate by sending the packet immediately or to a general purpose processor, instructing the hardware to execute the mode change.

X. Decreasing Reverse Link Data Rate

The specific parameters used for the host link controller can be adjusted or configured in a specific way to obtain a very desired maximum or more optimal (scale) of the margin link data rate. For example, during the time used to transmit the reverse data packet field of the reverse data packet of the reverse link capsule packet, the MDDI Stb signal pair toggles to generate a periodic data clock at half the forward link data rate. . This is because the host link controller generates an MDDI Stb signal that matches the MDDI Data 0 signal if all of the host link controllers are transmitting to zero. The MDDI Stb signal is transmitted from the host to the display when the reverse link is used to generate a clock signal for transmitting reverse link data from a display that is transmitted back to the host. The general amount of delay required for the transmission and processing of signals in the forward and reverse paths of a system using MDDI is shown in FIG. 50. In Fig. 50, a series of delay values 1.5 nsec., 8.0 nsec., 2.5 nsec., 2.0 nsec., 1.0 nsec., 1.5 nsec., 8.0 nsec., And 2.5 nsec. Are Stb +/- generation, cable to display. send. It is shown adjacent to the processing portions for the display receiver, clock generation, signal clock, Data () +/- generation, cable transmission to the host and host receiver stages, respectively.

Depending on the forward link data rate and the satisfied signal processing delay, it may require more than one cycle in the MDDI Stb signal for the "round trip" result or terminated event set, which may consume undesirable time or cycle amounts. have. To solve this problem, the reverse rate divisor allows one bit time over the reverse link to follow the various cycles of the MDDI Stb signal. This means that the reverse link data rate is less than the forward link rate.

It should be noted that the actual length of the signal delay through the interface may vary depending on each particular host-client system or hardware in use. Each system can generally be configured to better perform the actual delay measurement by using round trip delay measurement packets within the system so that the reverse rate divisor can be set to an optimal value.

Round trip delay is measured by the host sending a round trip delay measurement packet to the display. The display responds to the packet by sending a sequence inversely to the host within or during a preselected measurement window in a packet called a measurement duration field. Detailed timing of the measurement has been described above. Round trip delay is used to determine the rate at which reverse link data is safely sampled.

Round trip delay measurements include determining, detecting, or counting the number of forward link data clock intervals that occur between the beginning of the measurement period field and the beginning of the time period in which the 0xff, 0xff, and 0x00 response sequences are received back from the host to the display. do. It should be noted that the response from the display may be received in a small portion of the forward link clock period before the measurement coefficients are equivalent. If the unchanged value is used to calculate the reverse rate divisor, it may cause bit errors on the reverse link due to unreliable data sampling. An example of such a case is shown in FIG. 51, and the signals representing the MDDI_Data at the host, MDDI_Stb at the host, the forward link data clock in the host and the delay count are described in schematic form. In FIG. 51, the response sequence is received from the display at a portion of the forward link clock period before the delay count increases from six to seven. If the delay is assumed to be 6, the host will sample the reverse data immediately after the bit transition or possibly during the bit transition. This can cause erroneous sampling at the host. For this reason, the measured delay should generally be increased before it is used to calculate the reverse ratio divisor.

The reverse ratio divisor is the number of MDDI Stb cycles the host must wait before sampling reverse link data. Since MDDI Stb is cycled at half the rate of the forward link, the harsh round trip delay measurement must be divided by two and rounded up to the next integer. Expressed in a formula, the relation is as follows:

For a given expression, it is expressed as:

If the round trip delay measurement used in the above equation was 7, not 6, the reverse ratio divisor would be 4.

Reverse link data is sampled by the host on the rising edge of the reverse link clock. Similarly known circuits or devices exist in both the host and client (display) to generate a counter or reverse link clock. The counter is initialized so that a first rising edge of the reverse link clock occurs at the start of the first bit in the reverse link packet field of the reverse link capsule packet. This is shown in FIG. 52 for the example given below. The counter is incremented at each rising edge of the MDDI Stb signal, and the count number occurs until overlapping and is set by the reverse rate divisor parameter of the reverse link capsule packet. Since the MDDI Stb signal toggles at half the forward link rate, the reverse link rate is half the forward link rate divided by the reverse rate divisor. For example, if the forward link rate is 200 Mbps and the reverse rate divisor is 4, the reverse link data rate is expressed as follows.

An example illustrating the timing of MDDI_Data0 and MDDI_Stb signal lines in a reverse link capsule packet is described in FIG. 52, wherein the packet parameters used for explanation are as follows:

Packet Length = 1024 (0x0400) Turnaround 1 Length = 1

Packet Type = 65 (0x41) Turnaround 2 Length = 1

Reverse Link Flag = 0 Reverse Ratio Divisor = 2

Parameter CRC = 0xdb43 All 0s are 0x00

Strobe alignment is 0x00, 0x00, 0x60

The packet data between the packet occurrence and the parameter CRC fields are: 0x00, 0x04, 0x41, 0x02, 0x01, 0x01, 0x43, 0xdb, 0x00, 0x00, 0x60, 0x00, ...

The first reverse link packet returned from the display is a display request and status packet having a packet length of 7 and a packet form of 70. The packet starts with a byte value of 0x07, 0x00, 0x46, ..., and so on. Such a first byte (0x07) is shown in FIG. The first reverse link packet is time-shifted by an adjacent reverse link clock period in the figure to account for the actual reverse link delay. The ideal waveform with zero hosts in the display round tree delay is shown in dashed lines.

The MS byte of the parameter CRC field is sent after all zero fields along the strobe alignment byte. The strobe from the host switches from 1 to 0 and changes back to 1 as data from the host, forming a wide pulse. As the data progresses to zero, the strobe switches at a higher rate, and a change in data on the data line causes a change near the end of the alignment field. The strobe switches at a high rate during the remainder of the figure because of the fixed zero or one level of the data signal for an extended period of time, converting from a pulse pattern (edge) to a falling edge.

The reverse link clock for the host is zero until the end of the turnaround 1 period when the clock begins to regulate the reverse link packet, and the arrow in the lower part of the figure indicates when the data is sampled to be clear from the rest of the disclosure. . The first byte (here 11000000) of the packet field being transmitted starts after turnaround 1 and the line level is stabilized from the disabled host driver. The delay as seen for the first bit and for bit 3 can be seen as a dashed line for the data signal.

In FIG. 53, 1 may clarify the general value of the reverse rate divisor based on the forward link data rate. The actual reverse ratio divisor is determined as a result of the round trip link measurement to ensure proper reverse link operation. The first area 5302 corresponds to the safe operating area, the second area 5304 corresponds to the half-side that matches the area of the marginal performance, and the third area 5306 represents a setting that cannot function properly.

Round trip delay measurements and reverse rate divisor settings are the same while operating with any interface type setting on the forward or reverse link since they are represented and operated based on the unit of the actual clock period rather than the number of bits transmitted or received.

XI. Turnaround and protection time

As described above, the Turnaround 1 field in the Reverse Link Capsule packet and the Guard Time 1 field in the Round Trip Delay Measurement Packet specify a value for the length of time that allows the host interface driver to be disabled before the display interface driver is enabled. . The Turnaround 2 and Guard Time 2 fields provide a time value that causes the display driver to be disabled before the host driver is enabled. The guard time 1 and guard time 2 fields are usually filled with a preset or preselected value for the length not to be adjusted. Depending on the interface hardware to be used, the value can be developed using empirical data and in any case adjusted to improve operation.

Several factors provide the determination of the length of turnaround 1, which is the maximum disable time of the forward link data and the MDDI Data driver in the host. The maximum host driver disable time is described in Table XI, up to approximately 10 nsec for the driver to be disabled. And about 2 nsec. Shows what is taken. The minimum number of forward link clocks required for the host driver to be disabled is represented by the following relationship:

The allowable range of values for turnaround 1 is represented by the following relation:

The interface form element is 1 for Form I, 2 for Form II, 4 for Form III, and 8 for Form IV.

Combining the above two equations, the interface type element item cancels and turnaround 1 is defined as follows:

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

As the round trip delay increases, the timing gain improves from the point in time at which the host is disabled at the time the display is enabled.

In general, the factors that determine the length of time used for turnaround 2 are the forward link data rate, the maximum disable time of MDDI Data 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:

And the range of values allowed for turnaround 2 is expressed as:

For example, a 1500 Mbps Type III forward link with a round trip delay of 10 forward link clocks uses the following turnaround 2 delay:

XII. Physical Layer Interconnect Description

The physical connections that can be used to implement the interface according to the invention are part number 3260-8S2 (01) produced by Hirose Electric Company Ltd on the host side and part number 3240 produced by Hirose Electric Company Ltd on the display device side. It can be implemented using commercially available parts such as -8P-C. The assignment of exemplary Type I interface pins or “pinouts” for connectors used with Type I interfaces is specified in Table XIII.

Table 13

Signal name PIN number Signal name PIN number MDDI_Gnd One MDDI_Pwr 2 MDDI_Stb + 3 MDDI_Stb- 4 MDDI_DAT0 + 5 MDDI_DAT0- 6 MDDI_DAT1 + 7 MDDI_DAT1- 8 Shield

The interconnect element or device is selected or designed to be small enough to use a PDA and a cordless phone, or a portable gaming device, except that it is not disturbed or aesthetic in comparison to the associated device size. Any connector or cabling is durable enough for use in a typical consumer environment and must take into account particularly small size and relatively low cost for cabling. The transmission element must accept data and strobe signals that result in different NRZ data with transmission rates of up to about 450 Mbps for data and Form I and Form II and up to 3.6 Gbps for 8-bit parallel Form IV versions.

XIII. action

A summary of the general steps that begin with processing data and packets during operation of an interface using an embodiment of the present invention is shown in FIGS. 54A and 54B according to an overview of the interface apparatus for processing packets in FIG. 55. In the figure, the process begins at step 5402 by determining whether the client and host are connected using a communication path, here a cable or not. This occurs using the presence of a connector or cable, periodic registration by the host, software, or hardware to detect a signal at the input of the host (such as shown for the USB interface) or other known technique. If the client is not connected to the host, depending on the application, it may simply enter the wait state of any predetermined path and use future uses that may require the user to enter hibernate mode or perform an action to reactivate the host. Can be deactivated to wait. For example, when the host is in a computer-like device, the user may click on a sprink icon or request a program to enable host processing for the client. In other words, a simple plug-in can activate host processing for a USB type connection used as a type U interface.

If the client is detected as being connected to or existing on the host or visa versa, the client or host transmits the appropriate packet requesting service at steps 5404 and 5406. The client may send one of the display service request or status packet in step 5404. As discussed above, the link may already be blocked or may enter hibernate mode and thus cannot enter full initialization of the next communication link. If the communication link is synchronized and the host attempts to communicate with the client, the client must provide the display capability packet to the host as in step 5408. The host may begin to determine the type of supply that includes the transmission rate that the current client can accept.

In general, the host and client also negotiate a form (ratio / rate) of the service mode to be used with Form I, Form U, Form II, etc., at step 5410. Once the service type is set, the host can begin sending information. The host may also use the round trip delay measurement packet to optimize the timing of the communication link in response to other signal processing as shown at step 5411.

As described above, all transmissions begin with a subframe header packet shown as being transmitted in step 5412 and the data type shown as being transmitted in step 5414, wherein the video and audio stream packets and the charging packets are Follows. Audio and video data may be prepared in advance or mapped into packets, and a filling packet is inserted to fill the number of bits required for the media frame, if necessary. The host may send a packet, such as a forward audio channel enable packet, to activate the sound device, or the host may also describe the above described as transmission of a colormap, bit block transmission, or other packet of step 5416 herein. Commands and information using different packet types can be sent. In addition, the host and client can use the appropriate packets to exchange data related to the keyboard or pointing device.

In operation, one of several different events may occur to induce a host or client to satisfy different data rates or interface mode types. For example, a computer or other device that communicates data may meet loading conditions in processed data that slows down the preparation or presence of packets. The display receiving the data can be changed from dedicated AC power to a more limited battery power, and the faster data transfer can make it easier to process commands or use the same image or color depth under more limited power settings. . Optionally, the restricted condition can be reduced or eliminated so that a device transmits data at a higher rate. More preferably, the request can be changed to a higher transfer rate mode.

If such or other known conditions occur or change, the host or client can detect the occurrence and re-negotiate the interface mode. This is illustrated at step 5520, where the host sends an interface type handoff invitation packet to the client requesting a handoff in another mode, the client sends an interface type acknowledgment packet demonstrating that the change was found, and the host Transmits an action type handoff packet for executing the change in the particular mode.

Despite not requiring a specific processing order, the client and host may exchange packets in relation to data intended or received from a pointing device, keyboard or other user-type input device primarily associated with the client, while the element is a host May exist on the side. The packet is generally processed using elements of general or general form rather than state machine 5502. In addition, any of the instructions described above will be processed by general purpose processors 5504, 5558.

After the data and commands have been exchanged between the host and the client, it is determined at any point whether additional data is to be transmitted or whether the host or client is stopping servicing the transmission. This is shown at step 5542. If the link enters hibernation or is completely out of order, the host sends a link blocking packet to the client, and both ends sending data.

Packets sent in the processing operation will be sent using the drivers and receivers described above with respect to host and client controllers. The line driver and other logic elements are connected to the state machine and general purpose processor described above as shown in the diagram of FIG. 55. In FIG. 55, state machine 5502 and general purpose processors 5504 and 5508 affect the video control chip for data sources and visual display devices, including, but not limited to, designated USB residing outside of the link controller. It may be connected to other elements not shown, such as interfaces, memory elements, or other elements.

The processor and state machine provide control through enabling and disabling of the above-described driver related to guard time for transmitting packets and ensuring termination of an efficient establishment or communication link.

XIV. Appendix

In addition to the format, structure, and content organized for the various packets used to implement the architecture and protocols for embodiments of the present invention, more detailed field content or operations are provided for any packet type. This is provided to clarify the individual use or operation so that those skilled in the art can more easily understand and implement the use of the invention for various applications. Some fields not discussed above are discussed later.

A. About video stream packets

The display characteristic field (1 byte) has a series of bit values which are interpreted as follows. Bits 1 and 0 select how the display pixel data is routed. For bit values '00' or '11', data is displayed for both eyes, for bit value '10', data is routed only to the left eye, and for bit value '01', data is routed to the right eye only. . Bit 2 uses a value of '0', meaning that the pixel data is in the standard progressive format, indicating whether the pixel data exists in the crossover format and incrementing by one when the column number (pixel Y coordinate) advances from one column to the next. It is shown. When the bit has a value of '1', the pixel data is in a crossover format and the column number is incremented by two as it progresses from one column to the next. Bit 3 indicates that the pixel data is in an optional pixel format. This is similar to the standard crossing mode enabled by bit 2, but the crossing is not horizontal but vertical. When bit 3 is zero the pixel data is in the standard progressive format, and the row number (pixel X coordinate) is incremented by 1 for each successive pixel received. When bit 3 is 1 the pixel data is in an optional pixel format, and the row number is incremented by 2 each time each pixel is received. Bits 7 through 4 are reserved for future use and are set to zero in the general clause.

The 2-byte X Start and Y Start fields specify the absolute X and Y coordinates of the point (Xstart, Ystart) for the first pixel in the pixel data field. The 2-byte X Left Edge and Y Top Edge fields specify the X coordinate of the left edge and the Y coordinate of the top edge of the screen window filled by the pixel data field, while the X Right Edge and Y Bottom Edge regions are right of the window being updated. Specify the X coordinate of the edge and the Y coordinate of the lower edge.

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

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

The pixel data field contains the original video information to be displayed and is formatted in the manner described by the video data format descriptor. Data is transmitted one "row" at an hour as described above.

The pixel data CRC field (2 bytes) contains only pixel data of 16 bit CRC. If the CRC verification of the value fails, the pixel data can still be used but the CRC error count is incremented.

B. About Audio Stream Packets

The audio channel ID field (1 byte) identifies the specific audio channel through which audio data is sent by the client device. The physical audio channel is assigned or mapped to a value of 0, 1, 2, 3, 4, 5, 6, or 7 by the field, and the 0, 1, 2, 3, 4, 5, 6, or 7 The values of denote the left front, right front, left rear, right rear, front center, subwoofer, surround left and surround right channels, respectively. An audio channel ID value of 254 indicates that a single stream of digital audio samples is sent to both the left front and right front channels. This specifies an application where a stereo headset is used for voice communication, a product enhancement app in a PDA, or any application that generates a single beep. Values for ID fields in the range of 8 to 253, and 255 are currently reserved for use when the new design desires further instructions.

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

The bits per sample and packing field contain one byte that specifies the packing format of the audio data. The commonly used format defines the number of bits per PCM audio sample for bits 4 through 0. Bit 5 specifies whether digital audio data samples are packed. As discussed above, FIG. 12 shows the difference between packed audio samples and byte aligned audio samples. A value of '0' for bit 5 indicates that each PCM audio sample in the digital audio data field is byte-aligned with an interface byte boundary, and a value of '1' indicates that each successive PCM audio sample is the previous audio sample. To be packed against. The bit is only effective when the value defined in bits 4 through 0 (number of bits per PCM audio sample) is not a multiple of eight. Bits 7 through 6 are reserved for use if the system design desires further instructions and are generally set to a value of zero.

The Audio Sample Rate field (1 byte) specifies the audio PCM sample rate. The format used represents a rate of 8000 samples per second (sps) for a value of 0, the value of 1 is 16,000sps., The value of 2 is 24,000sps., The value of 3 is 32,000sps. And the value of 4 is 40,000. sps., value of 5 is 48,000sps., value of 6 is 11,025sps., value of 7 is 22,050sps., value of 8 is 44,100.sps, and values of 9 to 15 are reserved for future use. Is set to 0 at the same time.

The parameter CRC field (2 bytes) contains a 16 bit CRC of all bytes from the packet length to the audio sample rate. If the CRC fails the proper check, the entire packet is discarded. The digital audio data field contains the original audio sample for execution and is usually in linear format as an unsigned integer. The audio data CRC field (2 bytes) contains a 16 bit CRC of only audio data. If the CRC fails the check, audio data is still used, but the CRC error count is incremented.

C. About user-defined stream packets

The 2-byte Stream ID Number field is used to identify a particular video stream. The contents of the stream parameters and stream data fields are defined by the MDDI device manufacturer. The 2-byte Stream Parameter CRC field contains a 16-bit CRC of all bytes of the stream parameter starting with the audio coding byte from the packet length. If the CRC fails the check, the entire packet is discarded. The 2-byte stream data field contains only the CRC of the stream data. If the CRC fails the proper check, the use of stream data is optional at the request of the application. The use of stream data sharing on a good CRC generally requires that the stream data be buffered until the CRC is proven to be good. If the CRC fails to check, the CRC error count is incremented.

D. About Color Map Packets

The Colormap Data Size field (2 bytes) specifies the total number of colormap table entries present in the color map data in the packet. The number of bytes in the color map data is three times the size of the color map. The colormap size is set to zero to not send any map data. If the color map size is zero, the color map offset value is still sent but ignored by the display. The colormap offset field (2 bytes) specifies the offset of color map data in the packet from the beginning of the colormap table in the display device.

The 2-byte Parameter RCR field contains the CRC of every byte from the packet length to the audio coding byte. If the CRC fails the check, the entire packet is discarded.

For the colormap data field, each colormap position is a value of 3 bytes, where the first byte specifies a blue grade, the second byte specifies a green grade, and the third byte specifies a red grade. The color map size field specifies the number of 3-byte colormap table items present in the color map data field. If the color map does not match one video data format and color map packet, the entire color map can be specified by sending multiple packets using different colormap data and colormap offsets in each packet.

The 2-byte color map data CRC field contains a CRC of only the color map data. If the CRC fails the check, the colormap data can still be used but the CRC error count is incremented.

E. About Reverse Link Capsule Packets

The Reverse Link Flag field (1 byte) contains a series of flags for requesting information from the display. If the bit (here bit 0) is set to 1, the host uses the Display Capability Packet to request the specified information from the display. If the bit is zero, the host does not require information from the display. The remaining bits (bits 1 through 7 here) are reserved for future use and set to zero.

The Reverse Rate Fraction field (1 byte) specifies the number of MDDI Stb cycles that occur in relation to the reverse link data clock. The reverse link data clock is equal to the forward link data clock divided by twice the reverse ratio divisor. The reverse link data rate is related to the reverse link data clock and interface type of the reverse link. For the Type I interface, the reverse data rate is equal to the reverse link data clock, and for the Type II, Form III, and Type IV interfaces, the reverse data rate is equal to 2, 4, and 8 times the reverse link data clock, respectively. .

The turnaround 1 length field (1 byte) specifies the total number of bytes allocated to turnaround 1. The suggested length of turnaround 1 is the number of bytes required for the MDDI Data driver in the host to have the output disabled. This is based on the above described output disable time, forward link data rate, and forward link interface selection to be used. A more complete description of the setting of turnaround 1 is given above.

The Turnaround 2 Length field (1 byte) specifies the total number of bytes allocated for turnaround. The suggested length of turnaround 2 is the number of bytes required for the MDDI Data driver in the display to disable their output sum of round trips. A description of the setting of turnaround 2 is given above.

The parameter CRC field contains a 16 bit CRC of every byte from packet length to turnaround length. If the CRC fails the check, the entire packet is discarded.

Since the strobe alignment field (3 bytes) contains one value, the MDDI Stb signal makes high transitions low in the bit region between the last bit of all zero fields and the first field of the reverse data packet field. This works in such a way that the MDDI Stb signal matches with respect to the byte area in the reverse data packet field.

All zero fields (one byte) are set equal to zero and all MDDI Data signals are used to be in zero state before disabling the line driver for the first guard time period.

The Turnaround 1 field is used to set the first turnaround period. The number of bytes specified by the turnaround length parameter is allocated by the field to cause the MDDI Data driver in the host to be disabled before the line driver in the client (display) is enabled. The host disables the MDDI Data driver for bit 0 of turnaround 1 and the client (display) enables the line driver immediately after the last bit of turnaround 1. The MDDI Stb signal is active until the turnaround period is all zero.

The Reverse Data Packets field contains a series of data packets to be sent from the client to the host. As mentioned above, the charging packet is sent to fill the remaining space not used by other packet types.

The Turnaround 2 field is used to set the second turnaround period. The number of bytes specified by the turnaround length parameter is assigned by the field.

The driver re-enable field uses 1 byte equal to 0 so that all MDDI Data signals are re-enabled before the packet length field of the next packet.

F. About Display Capability Packets

The protocol version field uses two bytes to specify the protocol version used by the client. The initial version is set equal to 0, while the minimum protocol version field uses 2 bytes to specify the minimum protocol version that the client can use or interpret. The Display Data Rate Capability field (2 bytes) specifies the maximum data rate that the display can receive on the forward link of the interface and is specified in the form of megabits per second (Mbps). The Interface Type Capability field (1 byte) specifies the interface type supported on the forward and reverse links. It selects bit 0, bit 1, or bit 2 to select one of type II, type III, or type IV modes on the forward link, and selects one of type II, type III, or type IV modes on the reverse link. Designated simultaneously by selecting bit 3, bit 4, or bit 5 to select, bits 6 and 7 are reserved and set to zero. The bitmap width and height field (2 bytes) specifies 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 resolution that can be displayed in the monochrome format. If the display cannot support the monochrome format then the value will be set to zero. Bits 7 through 4 are reserved for perfume use and are therefore set to zero. Bits 3 through 0 define the maximum number of bits of grayscale that can exist for each pixel. The four bits allow for specifying a value of 1 to 15 for each pixel. If the value is zero then monochrome format is not supported for display.

The colormap capability field (3 bytes) specifies the maximum number of table items present in the colormap table in the display. If the display cannot use the colormap format then the value is zero.

The RGB Capability field (2 bytes) specifies the number of bits of the picture that can be displayed in the RGB format. If the display cannot use the RGB format then the value is zero. The RGB capability word consists of three individual unsigned values: bits 3 through 0 define the maximum number of bits in blue, bits 7 through 4 define the maximum number of bits in green, and bits 11 through 8 each. Defines the maximum number of bits of red in a pixel. Currently, bits 15 through 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 the picture that can be displayed in the Y Cr Cb format. If the display cannot use the Y Cr Cb format then the value is zero. The Y Cr Cb capability word consists of three individual unsigned values: bits 3 through 0 define the maximum number of bits in the Cb sample, bits 7 through 4 define the maximum number of bits in the Cr sample, and bit 11 8 through 8 define the maximum number of bits in Y samples, bits 15 through 12 are currently reserved for future use and are typically set to zero.

The Display Feature Capability Indicator field uses 4 bytes that contain a series of flags that indicate a particular feature in the supported display. One bit set to 1 indicates that the capability is supported, and one bit set to 0 indicates that the capability is not supported. The value for bit 0 indicates whether or not the bitmap block transport packet (packet type 71) is supported. The values for bits 1, 2, and 3 indicate that bitmap region charge packets (packet form 72), bitmap pattern fill packets (packet form 73), or communication link data channel packets (packet form 74) are supported, respectively. The value for bit 4 indicates whether or not the display has the ability to make one color transparent, while the values for bits 5 and 6 indicate whether the display can accept video data or audio data in packed packets. The value for bit 7 indicates whether the display can transmit a reverse link video stream from the camera. The values of bits 11 and 12 indicate when the client communicates with a pointing device capable of sending and receiving pointing device data packets or a keyboard capable of sending and receiving keyboard data packets. Bits 13 through 31 are reserved for optional indication that is currently available for future use or for system designers, and is generally set equal to zero.

The Display Video Frame Rate Capability field (1 byte) specifies the maximum video frame updater capability of the display at frames per second. The host may choose to update the image at a later rate than the value specified in the field.

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

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

The 2-byte Audio Sample Rate characteristic field for the forward link includes a flag set indicating the audio sample rate characteristic of the client device. Bit positions are allocated at different rates, i.e. bits 0,1,2,3,4,5,6,7 and 8 are 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, and 44,100 SPS per second Samples, respectively, bits 9 to 15 are reserved for future or other ratio use, so bits 9 to 15 are set to '0'. Setting a bit value for one of these bits indicates that a particular sample rate is supported, and setting a bit to '0' indicates that a sample rate is not supported.

The Minimum Subframe Rate field (2 bytes) indicates the minimum subframe rate per second. The minimum subframe rate maintains a display state update rate sufficient to read the display's pointing device or any sensor.

The 2-byte Mic Sample Rate Feature field for the reverse link includes a set of flags indicating the audio sample rate feature of the microphone at the client device. For MDDI, the client device microphone is configured to support at least 8,000 sample rates per second. The bit positions of these fields are allocated at different rates, with bit positions 0, 1, 2, 3, 4, 5, 6, 7 and 8 being 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, and Used to represent 44,100 SPS (samples per second), bits 9 to 15 are reserved for use in advance or other ratios as needed, and thus bits 9 to 15 are set to '0'. Setting the bit value for one of these bits to '10' indicates that a particular sample rate is supported, and setting a bit to '0' indicates that a sample rate is not supported. If a microphone is connected, each Mic Sample Rate feature bit is set to zero.

The content protected field (2 bytes) contains a set of flags indicating 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 use in other protection schemes when needed, Accordingly, bit positions 2 to 15 are currently set to zero.

G. About Display Requests and Status Packets

The Reverse Link Request field (3 bytes) specifies the number of bytes needed on the reverse link of the next subframe to send information to the host.

The CRC Error Count field (1 byte) causes many CRC errors to occur from the start of the media frame. The CRC count is reset when a subframe header packet with a subframe count of zero is transmitted. If the actual number of CRC errors exceeds 255, this value saturates to 255.

The characteristic change field uses 1 byte to specify the characteristic change of the display. This can occur when a user connects to a peripheral such as a microphone, keyboard, or display. When bit 7: 1 is zero, the characteristic does not change because the last display characteristic packet is sent. However, when bits 7: 0 are equal to 1 to 255, the characteristic changes. The display characteristic packet is tested to determine the new display characteristic.

H. About Bit Block Transport Packets

The window upper left coordinate X value and Y value fields use 2 bytes each to specify the X and Y values of the upper left corner of the window to be moved. The window width and height fields use 2 bytes each to specify the width and height of the window to be moved. The Window X Move and Y Move fields use 2 bytes each to indicate the number of pixels the window will move horizontally and vertically, respectively. A position value for X causes the window to move to the right, a negative value causes the window to move to the left, a positive value for Y causes the window to move down, and a negative value causes the window to move upwards. .

I. About Bitmap Area Fill Packets

The window upper left coordinate X value and Y value fields use 2 bytes each to specify the X and Y values for the upper left corner coordinate of the window to be filled. The window width and height fields (2 bytes each) detail the width and height of the window to be filled. The video data format descriptor field (2 bytes) specifies the format of the pixel region fill value. The format has the same fields as in the video stream packet. The pixel region fill value field (4 bytes) includes a pixel value to be filled into the window described above by the field described above. The format of this pixel is detailed in the Video Data Format Descriptor field.

J. About Bitmap Pattern Fill Packets

The window upper left coordinate X value and Y value fields use 2 bytes each to specify the X and Y values for the upper left corner coordinate of the window to be filled. The window width and height fields (2 bytes each) detail the width and height of the window to be filled. The pattern width and pattern height fields (2 bytes each) detail the width and height of the fill pattern, respectively. The 2-byte Video Data Format Descriptor field details the format of the pixel region fill value. 11 illustrates how a video data format descriptor is coded. The format has the same fields as in the video stream packet.

The parameter CRC field (2 bytes) contains the CRC of all bytes from the packet length to the video format descriptor. If this CRC is not checked, the entire packet is ignored. The pattern pixel data field contains raw video information detailing the fill pattern in the format described by the video data format descriptor. The data is packed into bytes, and the first pixel of each row is byte aligned. Fill pattern data is transmitted in rows at the same time. The pattern pixel data CRC field (2 bytes) contains only the CRC of pattern pixel data. If this CRC is not checked, the pattern pixel data will continue to be used, but the CRC error count will be incremented.

K. Communication Link Data Channel Packet

The parameter CRC field (2 bytes) contains a 16 bit CRC of all bytes from packet length to packet type. If this CRC is not checked, the entire packet is ignored.

The communication link data field contains raw data from the communication channel. This data is simply transmitted to the computing device of the display. The communication link data CRC field (2 bytes) contains only a 16 bit CRC of communication link data. If this CRC is not checked, the communication link data continues to be useful but the CRC error count is incremented.

L. About the Interface Type Handoff Request Packet

The interface type field (1 byte) specifies the new interface type to use. The value in this field details the interface type in the following manner. If the value of bit 7 is 0, the type handoff request is for the forward link, and if the value of bit 7 is 1, the type handoff request is for the reverse link. Bits 6 to 3 are reserved for the future and are generally set to one. Bits 2 through 0 are used to define the type of interface to be used, a value of 1 means handoff to Type-I mode, a value of 2 means handoff to Type-II mode, and a value of 3 Denotes a handoff to the Type-III mode and a value of 4 means a handoff to the Type-IV mode. Values of 0 and 5 to 7 are reserved for future mode design or combination of modes.

M. About Interface Type Ack Packet

The interface type field (1 byte) has a value identifying a new interface type to use. The value in this field details the interface type in the following manner. If bit 7 is 0, the type handoff request is for the forward link; if bit 7 is 1, the type handoff request is for the reverse link. Bit positions 6 through 3 are reserved for use when specifying other handoff types when needed and are generally set to zero. However, bit positions 2 through 0 indicate a value of 0 indicating a negative response that a handoff request cannot be performed, and 1 indicating a handoff to Type-I, Type-II, Type-III and Type-IV modes. Used to define the interface type to be used with the values 2, 3 and 4. Values 5 through 7 are reserved for other mode assignments as needed.

N. About Execution Type Handoff Packets

The 1-byte Interface Type field indicates the new interface to use. The value present in the field details the interface type by using the value of bit 7 to determine whether the type handoff is for the forward link or the reverse link. A value of '0' indicates that the type handoff request is a forward link, and a value of '1' indicates that the type handoff request is a reverse link. Bits 6 to 3 are reserved for future use and are set to a value of zero. However, bits 2 through 0 are used to define the type of interface to be used, and values 1, 2, 3, and 4 are handoffs to Type-I, Type-II, Type-III, and Type-IV modes, respectively. Will be described in detail. The values 0 and 5 to 7 for these bits are reserved for future use.

O. Forward Audio Channel Enable Packet

The audio channel enable mask field (1 byte) contains a flag group indicating that the audio channel is enabled at the client. Bits set to 1 enable the corresponding channel, bits set to 0 disable the corresponding channel, and bits 0 through 5 are left front, right front, left back, right back, front center, and sub, respectively. Indicates 0 to 5 addressing the woofer channel. Bits 6 and 7 are reserved for future use and are set to zero for the average time.

P. About Reverse Audio Sample Rate Packets

The Audio Sample Rate field (1 byte) details the digital audio sample rate. The values for this field are set at different rates, and the values 0, 1, 2, 3, 4, 5, 6, 7, and 8 are 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, And 44,100 SPS (samples per second), values from 9 to 254 are reserved for future use when needed, and values from 9 to 254 are therefore set to '0'. A value of 255 is used to disable the reverse link audio stream.

The sample format field (1 byte) specifies the format of the digital audio sample. Digital audio samples are in linear format when bits (1: 0) are zero, digital audio samples are in μ-law format when bits (1: 0) are zero, and digital audio samples when bits (1: 0) are two. Is in the A-law format. Bits (7: 2) are reserved for other use when specifying audio formats when needed, and are usually set to zero.

Q. About Digital Content Protection Overhead Packets

The Content Protection Type field (1 byte) details the digital content protection method used. A value of 0 indicates Digital Transmission Content Protection (DTCP) and a value of 1 indicates Wideband Digital Content Protection System (HDCP). Values from 2 to 255 are reserved for use with other protection schemes when needed. The content protection overhead message field is a variable length field containing a content protection message sent between the host and the client.

R. About Transparent Color Enable Packets

The transparent color enable field (1 byte) details when the transparent color mode is enabled or disabled. If bit 0 is 0, the transparent color mode is disabled. If bit 0 is 1, the transparent color mode is enabled and the transparent color is specified by the following two parameters. Bits 1 through 7 of this byte are set to zero, leaving for future use.

The video data format descriptor field (2 bytes) details the format of the pixel region fill value. 11 describes how a video data format descriptor is coded. The format is generally the same as the field in the video stream packet.

The pixel region fill value field uses 4 bytes allocated for the pixel value to be filled into the window described above. The format of this pixel is detailed in the Video Data Format Descriptor field.

S. About Round Trip Delay Packets

The parameter CRC field (2 bytes) contains a 16-bit CRC of every byte from packet length to packet type. If this CRC is not checked, the entire packet is ignored.

The strobe alignment field (2 bytes) contains a value that causes the MDDI Stb signal to make a transition from low to high on the previous bit boundary, just to the first bit of every zero field of the packet. This allows MDDI Stb to operate in the same way at the byte boundary of the measurement period in any period during which the packet is transmitted.

Every zero field (1 byte) contains zeros such that all MDDI data signals are in the zero state before ignoring the line driver for the first guard period.

The guard time 1 field (8 bytes) causes the MDDI data line driver in the host to be disabled before the line driver of the client (display) is enabled. The host disables its MDDI data line driver for guard time 1, and the display enables its line driver immediately after the last bit of guard time 1.

The measurement period field is a 512 byte window used to cause the display to respond with 0xff, 0xff, 0x0 at half the data rate used on the forward link. This data rate corresponds to a reverse link ratio divisor of one. The display immediately returns such a response at the beginning of the measurement period. This response will be received at the host at the round trip delay of the link after the start of the first bit of the measurement period at the host. The MDDI data line driver of the display is displayed immediately before and after responding to 0xff, 0xff, 0x00 from the display.

The value of the Guard Time 2 field (8 bytes) causes the client MDDI data line driver to be disabled before the host's line driver is enabled. Guard time 2 is always present, but simply required when the round trip delay is at the maximum magnitude that can be measured in the measurement period. The client disables the line driver during bit 0 of guard time 2, and the host enables the line driver immediately after the last bit of guard time 2.

The driver re-enable field (1 byte) is set equal to 0, so that all MDDI data signals are re-enabled before the packet length field of the next packet.

XV. conclusion

While various embodiments of the invention have been described above, it is to be understood that these embodiments are provided by way of example only, and not as limitations of the invention. Accordingly, the scope of the present invention is not limited by the above-mentioned embodiments but only by the appended claims.

Claims (107)

A digital data interface for transmitting digital presentation data at high data rates between a host device and a client device through a communication path, A plurality of packet structures linked together to form a communication protocol for communicating a preselected set of digital control and presentation data between a host and a client through the communication path; At least one link controller disposed in a host device connected to the client via the communication path, the at least one link controller configured to generate, transmit, and receive packets forming the communication protocol and to form digital presentation data into one or more data packet types; Including digital data interface. 2. The method of claim 1, further comprising packets grouped together in a media frame communicated between the host and the client with a predetermined fixed length, wherein the predetermined number of packets have different and variable lengths. Digital data interface. 4. The digital data interface of claim 1, further comprising a subframe header packet placed at the beginning of packet transmission from the host. The digital data interface of claim 1, wherein information is transmitted in both directions between the host and the client through the communication link. 2. The system of claim 1, wherein the link controller is a host link controller, and the digital data interface generates, transmits and receives a packet disposed at the client device connected to the host via the communication path and forming the communication protocol. At least one client link controller configured to form the digital presentation data into one or more data packet types. 6. The digital data interface of claim 5, wherein the host link controller comprises one or more differential link drivers and the client link controller comprises one or more differential link receivers connected to the communication path. 2. The system of claim 1, further comprising one or more video stream packets for video type data and audio stream packets for audio type data to transmit data from the host to the client over the forward link for presentation to a client user. Digital data interface, characterized in that. 2. The digital data interface of claim 1, further comprising one or more reverse link capsule packets for the client to send data to the host. 2. The digital system of claim 1, wherein the host link controller requests display characteristic information from the client device to determine what type of data and what data rate the client device can accept over the interface. Data interface. 10. The digital data interface of claim 9, wherein the client link controller communicates display or presentation characteristics to the host link controller using at least one display characteristic packet. The digital data interface as recited in claim 1, wherein said communication path comprises a cable having a series of four or more conductors and shields. 2. The digital data interface of claim 1, wherein said host link controller comprises a USB data interface operating as part of said communication path. The digital data interface as recited in claim 1, wherein said host device comprises a wireless communication device. The digital data interface as recited in claim 1, wherein said host device comprises a portable computer having a wireless modem disposed therein. The digital data interface as recited in claim 1, wherein said client device comprises a portable video display. 15. The digital data interface of claim 14 wherein the portable video display comprises a micro-display device. The digital data interface as recited in claim 1, wherein said client device comprises a portable audio presentation system. The digital data interface as recited in claim 1, wherein said host comprises means for storing multimedia data to be transmitted to said client device. 2. The digital data interface of claim 1, wherein each packet comprises a packet length field, one or more packet data fields, and a cyclic redundancy check field. 3. The system of claim 2, comprising a plurality of transmission modes, each of which enables the transmission of a maximum number of different data bits in parallel over a given period, wherein each mode is provided by negotiation between the host and the client link driver. Selectable; And said transmission mode is dynamically adjustable between said modes during said data transmission. 2. The method of claim 1, further comprising a plurality of packets usable for transmitting video information selected from the group of color maps, bit block transmissions, bitmap region fills, bitmap pattern fills, and transparent color enable type packets. Digital data interface. 2. The digital data interface of claim 1, further comprising a filler type packet generated by the host to occupy a forward link transmission period without data. 2. The digital data interface as recited in claim 1, further comprising a user defined stream type packet for transmitting interface user defined data. 2. The digital data interface of claim 1, further comprising a keyboard data and pointing device data type packet for transmitting data to and from a user input device associated with the client device. 2. The digital data interface of claim 1, further comprising a link pause type packet sent by the host to the client to terminate data transmission in either direction through the communication path. A method for transmitting digital data at high data rates between a host device and a client device via a communication path for presentation to a user, the method comprising: Generating one or more of a plurality of predefined packet structures and linking them together to form a predefined communication protocol; Communicating a preselected set of digital control and presentation data between the host and the client device over the communication path using the communication protocol; Connecting at least one host link controller disposed in the host device to the client device via the communication path, wherein the host link controller generates, transmits and receives a packet forming the communication protocol and generates a digital presentation. Configure presentation data into the one or more data packet types; And transmitting data in the form of a packet over the communication path using the link controller. 27. The method of claim 26, further comprising grouping the packets together within a media frame for communication between the host and the client, wherein the media frame has a predefined fixed length, and the predetermined number of packets is different. And a variable length. 27. The method of claim 26, further comprising initiating transmission of the packet from the host with a subframe header type packet. 27. The method of claim 26, further comprising transmitting information in both directions between the host and the client over the communication link. 27. The system of claim 26, further comprising at least one client link controller disposed in the client device connected to the host device via the communication path, wherein the at least one client link controller is configured to send packets forming the communication protocol. And generate, transmit and receive and form the digital presentation data into one or more data packet types. 31. The method of claim 30, wherein said host link controller comprises one or more differential link drivers, and said client link controller comprises one or more differential link receivers connected to said communication path. 27. The method of claim 26, further comprising: transmitting data from the host to the client for presentation to a client user using at least one video stream type packet for the video type data and an audio stream type packet for audio type data. Digital data transmission method characterized in that it further comprises. 27. The method of claim 26, further comprising transmitting data from the client to the host using one or more reverse link capsule type packets. 27. The method of claim 26, further comprising requesting display characteristic information from the client by a host link controller to determine what type of data and at what data rate the client can accept over the interface. Digital data transmission method, characterized in that. 35. The method of claim 34, further comprising communicating a display or presentation characteristic from the client link controller to the host link controller using at least one display characteristic type packet. 27. The method of claim 26, wherein said communication path comprises a cable having a series of four or more conductors and shields. 27. The method of claim 26, further comprising operating a USB data interface by each of the link controllers as part of the communication path. 27. The method of claim 26, wherein said host comprises a wireless communication device. 27. The method of claim 26, wherein said host comprises a portable computer having a wireless modem disposed therein. 27. The method of claim 26, wherein said client device comprises a portable video display. 41. The method of claim 40, wherein said portable video display comprises a micro-display device. 27. The method of claim 26, wherein said client device comprises a portable audio presentation system. 27. The method of claim 26, further comprising storing multimedia data to be transmitted to the client device at the host. 27. The method of claim 26, wherein each packet comprises a packet length field, one or more packet data fields, and a cyclic redundancy check field. 28. The method of claim 27, comprising negotiating use of one of a plurality of transmission modes in each direction between the host and the client link driver, wherein each transmission mode is a maximum number of different over a given period of time. To transmit data bits in parallel; And dynamically adjusting between the transmission modes during data transmission. 27. The method of claim 26, wherein one or more packets of the plurality of packets are used to transmit video information selected from the group of color maps, bit block transmissions, bitmap region fills, bitmap pattern fills, and transparent color enable type packets. Digital data transmission method further comprising the step. 27. The method of claim 26, further comprising generating a filler type packet by the host to occupy a forward link transmission period without data. 27. The method of claim 26, further comprising transmitting interface user defined data using a user defined stream type packet. 27. The method of claim 26, further comprising transmitting data to or from a user input device associated with the client device using keyboard data and pointing device data type packets. 27. The method of claim 26, further comprising terminating transmission of data in either direction over the communication path using a link pause type packet sent by the host to the client. Way. A device for transmitting digital data at a high data rate between a host device and a client device through a communication path for presentation to a user, Disposed within the host device to generate one or more of a plurality of predefined packet structures and link them together to form a predefined communication protocol, and between the host and the client device through the communication path using the communication protocol. At least one host link controller for communicating a preselected digital control and presentation data set in the apparatus; At least one client controller disposed in the client device and connected to the host link controller via the communication path; And each link controller configured to generate, transmit, and receive packets forming the communication protocol and to form digital presentation data into one or more data packet types. 53. The apparatus of claim 51, wherein said host controller comprises a state machine. 53. The apparatus of claim 51, wherein said host controller comprises a general purpose signal processor. 53. The method of claim 51, wherein the packets are grouped together in a media frame for communication between the host and client, wherein the media frames have a predefined fixed length, and a predetermined number of packets have different and variable lengths. Digital data transmission device characterized in that. 52. The apparatus of claim 51, further comprising a subframe header type packet at the beginning of packet transmission from the host. 53. The apparatus of claim 51, wherein the link controller is configured to transmit information in both directions between the host and the client device over the communication link. 53. The apparatus of claim 51, wherein said client controller comprises a client receiver connected to said client device. 59. The apparatus of claim 57, wherein the host controller comprises one or more differential line drivers and the client receiver comprises one or more differential line receivers connected to the communication path. 53. The digital display of claim 51 further comprising a video stream type packet for video type data and an audio stream type packet for audio type when transmitting data from the host to the client for presentation to a client user. Data transmission device. 53. The apparatus of claim 51, further comprising one or more reverse link capsule type packets for transmitting data from the client to the host. 53. The digital data of claim 51 wherein the host link controller is configured to request display characteristic information from a client to determine what type of data and at what data rate the client can accept the interface. Transmission device. 62. The apparatus of claim 61, further comprising at least one display characteristic type packet for communicating display or presentation characteristics from the client link controller to the host link controller. 52. The apparatus of claim 51, wherein said communication path comprises a cable having a series of four or more conductors and shields. 64. The apparatus of claim 63, wherein the cable comprises six conductors and a shield. 64. The apparatus of claim 63, wherein said cable comprises eight conductors and shields. 64. The apparatus of claim 63, wherein said communication path comprises a cable having four conductors, a USB type interface, and a shield. 64. The cable conductor of claim 63, wherein the cable conductors comprise a multistandard wire each having a resistance of about 110 ohms per 1000 feet in length, a signal propagation rate of about 0.66c, a maximum delay through the cable shorter than about 8.0 nanoseconds, and a shield. Digital data transmission device, characterized in that. 52. The apparatus of claim 51, wherein said host device comprises a wireless communication device. 52. The apparatus of claim 51, wherein said host device comprises a portable computer having a wireless modem disposed therein. 52. The apparatus of claim 51, wherein said client device comprises a portable video display. 72. The digital data transmission device of claim 70, wherein the portable video display comprises a micro-display device. 53. The apparatus of claim 51, wherein said client device comprises a portable audio presentation system. 53. The apparatus of claim 51, further comprising a data storage device for holding multimedia data to be transmitted to the client device by the host. 53. The apparatus of claim 51, wherein each packet comprises a packet length field, one or more packet data fields, and a cyclic redundancy check field. 53. The method of claim 51, wherein the host and the client link controller are configured to use one of a plurality of transmission modes in each direction, each transmission mode transmitting a maximum number of different data bits in parallel over a given period. And dynamically control between the transmission modes during data transmission. 53. The method of claim 51, further comprising one or more packets of a plurality of packets for transmitting video information selected from the group of color maps, bit block transmissions, bitmap region fills, bitmap pattern fills, and transparent color enable type packets. Digital data transmission device, characterized in that. 52. The apparatus of claim 51, further comprising a filler type packet sent by the host to occupy a period of forward link transmission without data. 52. The apparatus of claim 51, further comprising a keyboard data and pointing device data type packet for transmitting data to or from a user input device associated with the client device. 52. The apparatus of claim 51, wherein the host controller is configured to send a link pause type packet to terminate data transmission in either direction over the communication path. A computer program product for use in an electronic system for transmitting digital data at high data rates between a host device and a client device over a communication path for presentation to a user, A computer usable medium incorporating computer readable program code means for causing an application program to run on a computer system; The computer readable program code means, Computer readable first program code means for causing the computer system to generate one or more of a plurality of predefined packet structures and link them together to form a predefined communication protocol; Computer readable second program code means for causing the computer system to communicate a preselected set of digital control and presentation data between the host and the client device over the communication path using the communication protocol; Computer readable third program code means for causing the computer system to connect at least one host link controller disposed in the host device to at least one client jay located in the client device via the communication path; And Computer readable fourth program code means for causing the computer system to transmit data in packet form over the communication link using the link controller; And the link controller generates, transmits and receives packets forming the communication protocol and forms digital presentation data into one or more data packet types. An apparatus for transmitting digital data at a high data rate between a host device and a client device through a communication path for presentation to a user, Means for generating one or more of a plurality of predefined packet structures and linking them together to form a predefined communication protocol; Means for communicating a preselected digital control and presentation data set between the host and the client device over the communication path using the communication protocol; Means for connecting at least two link controllers together through the communication path, wherein the link controllers are disposed in the host and the client, respectively, wherein each link controller generates and transmits a packet forming the communication protocol. And receive and form the digital presentation data into one or more data packets, Means for transmitting packet-shaped data over the communication path using the link controller. 84. The apparatus of claim 81, further comprising means for grouping the packets together in a media frame for communication between the host and the client, wherein the media frame has a predefined fixed length, and wherein the predetermined number of packets are different and Digital data transmission apparatus characterized by having a variable length. 84. The apparatus of claim 81, further comprising means for initiating transmission of a packet from the host with a subframe header type packet. 84. The apparatus of claim 81, further comprising means for transmitting information in both directions between the host and the client over the communication link. 84. The apparatus of claim 81, wherein said one link controller is a host controller connected to said host device, and said second link controller comprises a client receiver connected to said client device. 86. The apparatus of claim 85, wherein said host controller comprises one or more differential line drivers and said client receiver comprises one or more differential line receivers connected to said communication path. 84. The apparatus of claim 81, further comprising: means for transmitting data from the host to the client for presentation to a client user using at least one video stream type packet for video type data and an audio stream type packet for audio type data. Digital data transmission device further comprises. 84. The apparatus of claim 81, further comprising means for transmitting data from the client to the host using the one or more reverse link capsule type packets. 84. The apparatus of claim 81, further comprising means for requesting display characteristic information from a client by the host link controller to determine what type of data and what type of data rate the client can accept over the interface. Digital data transmission apparatus comprising a. 90. The apparatus of claim 89, further comprising means for communicating display or presentation characteristics from the client link controller to the host link controller using at least one display characteristic type packet. 84. The apparatus of claim 81, wherein said communication path comprises a cable having a series of four or more conductors and shields. 84. The apparatus of claim 81, further comprising means for operating a USB data interface by each of said link controllers as part of said communication path. 84. The digital data transmission device of claim 81, wherein the host comprises a wireless communication device. 84. The apparatus of claim 81, wherein said host comprises a portable computer having a wireless modem disposed therein. 84. The apparatus of claim 81, wherein said client device comprises a portable video display. 97. The digital data transmission device of claim 95, wherein the portable video display comprises a micro-display device. 84. The apparatus of claim 81, wherein said client device comprises a portable audio presentation system. 84. The apparatus of claim 81, further comprising means for storing multimedia data to be transmitted from the host to the client device. 84. The apparatus of claim 81, wherein each packet comprises a packet length field, one or more packet data fields, and a cyclic redundancy check field. 83. The apparatus of claim 82, comprising means for negotiating between the host and the client link driver using one of a plurality of transmission modes in each direction, wherein each transmission mode is a maximum number over a given period of time. Send different data bits in parallel; And means for dynamically adjusting between the transmission modes during data transmission. 84. The method of claim 81, wherein one or more packets of the plurality of packets are used to transmit video information selected from the group of color maps, bit block transmissions, bitmap region fills, bitmap pattern fills, and transparent color enable type packets. Digital data transmission device further comprises means. 84. The apparatus of claim 81, further comprising means for generating a filler type packet by the host to occupy a forward link transmission period without data. 84. The apparatus of claim 81, further comprising means for transmitting interface user defined data using a user defined stream type packet. 84. The apparatus of claim 81, further comprising means for transmitting data to or from a user input device associated with the client device using keyboard data and pointing device data type packets. . 84. The apparatus of claim 81, further comprising means for terminating transmission of data in either direction over the communication path using a line pause type packet sent by the host to the client. Transmission device. A processor for use in an electronic system for transmitting digital data at high data rates between a host device and a client device over a communication path, Generate one or more of a plurality of defined packet structures and link them together to form a predefined communication protocol, form digital presentation data into one or more data packet types, and use the communication protocol to A processor for communicating a pre-selected set of digital control and presentation data between a host and said client device, said packet transmitting data over said communication path. A state machine used to obtain synchronization in an electronic system that transmits digital data at a high data rate between a host device and a client device through a communication path, And a state machine configured to have at least one Async frame state sync state, at least two acquisition Sync state sync states, and at least three In-Sync state sync states.