TWI400889B - Systems and methods for implementing cyclic redundancy checks - Google Patents

Description

System and method for implementing cyclic redundancy check

Broadly speaking, the invention relates to data communication. More specifically, the present invention relates to a digital transmission chain that uses cyclic redundancy checking.

In the past few years, products related to computers, mobile phones, mobile phone cameras and video capture devices, personal data assistants, video games, and various video technologies (such as DVDs and high-definition VCRs) have made great strides to capture And to present still images with higher resolution, video, video on demand, and graphics. Combining these visual images with high-quality audio material, such as CD-type sound reproduction, DVD, and other devices that combine audio signal output, can create a more realistic, informative, or true multimedia experience for end users. In addition, highly mobile, high quality audio systems and music delivery mechanisms, such as MP3 players, have been developed that present audio only to the user.

The dramatic increase in the presentation of high-quality data has driven the need to create special interfaces that can transmit data at high data rates so that the quality of the data does not deteriorate or be compromised. One such interface is the Mobile Display Digital Interface (MDDI), for example for exchanging high speed data between the upper cover and the body of a cell phone with a camera. MDDI is a cost-effective, low-power transmission mechanism that enables extremely high-speed data transfer over short-range communication links between the host and the client. MDDI uses only a minimum of four lines plus power for bidirectional data transmission. With the current technology, it can transmit a maximum bandwidth of 3.2 Gbits per second.

While MDDI and other data interfaces can be used to efficiently provide high data rates across interfaces, the need to optimize performance and use digital transmission chains (such as MDDI chains) more efficiently is increasing.

The present invention provides systems and methods for implementing Cyclic Redundancy Check (CRC) to improve the initialization processing of the link and exchange system error information so that the digital transmission chain can be used more efficiently. In one aspect of the invention, a CRC checker is provided that includes a unique style detector, a CRC generator, a CRC initializer, and a CRC validator. The CRC checker prepopulates the CRC generator for a unique style. Since the CRC generator is pre-filled, the CRC checker can perform a CRC check after receiving a unique pattern from the data stream received on the digital transmission chain without the need to queue and store the data.

In another aspect of the invention, a CRC generator system is provided that deliberately delays the CRC value to convey system or associated system error information. The CRC generator system includes a CRC generator, a CRC error detector, an error detector, and an error value generator. The CRC generator generates a CRC value based on the data included in the data packet to be transmitted through the digital transmission chain. The CRC error detector CRC value generated by the CRC generator to communicate the host system or related system status information. The error detector detects an error condition in the host system or related system and provides an instruction for the CRC error to intentionally delay the CRC value.

In another aspect of the invention, the CRC generator system can provide specified information, including the type of error. In this case, in addition to the above unit, the CRC generator system further includes an error value generator that instructs the CRC error detector to replace the CRC value generated by the CRC generator with a specified CRC error value indicating the CRC error value. The type or status of the system error.

In one example, the digital transmission chain is an MDDI chain. The invention is not limited to the MDDI chain and can be used for any type of digital transmission chain using CRC.

Other embodiments, features, and advantages of the present invention, as well as details of the structure and operation of various embodiments of the present invention, will be described in detail below with reference to the drawings.

This specification discloses one or more embodiments that incorporate the features of the invention. The disclosed embodiments are merely illustrative of the invention. The scope of the invention is not limited by the disclosed embodiments. The invention is defined by the scope of the appended claims.

The described embodiments, and the "an embodiment", "an embodiment", "exemplary embodiment", etc., referred to in this specification, indicate that the described embodiment may include a particular feature, structure, or characteristic. It is not intended that all embodiments include such specific features, structures, or characteristics. Moreover, these terms are not necessarily referring to the same embodiment. In addition, when a particular feature, structure, or characteristic described is related to an embodiment, it is to be understood that the knowledge of those skilled in the art, whether or not explicitly described, may also be such a feature, structure, or characteristic. It is related to the embodiment.

Embodiments of the invention may be implemented using hardware, firmware, software, or any combination thereof. Embodiments of the invention may also be implemented using instructions stored in a machine readable medium that can be read or executed by one or more processors. Machine readable media can include any information stored or transmitted in a format that can be read by a machine (eg, a computing device). The machine readable medium includes, for example, a read only memory (ROM); a random access memory (RAM); a disk storage medium; an optical storage medium; a flash memory device; an electrical, optical, acoustic or other type of transmission. Signals (such as carrier waves, infrared signals, digital signals, etc.), and others. In addition, the firmware, software, routines, and instructions described herein perform certain actions. However, it should be understood that these descriptions are for convenience only, and that such acts are actually derived from the execution of computing devices, processors, controllers, or other firmware, software, routines, instructions, and the like.

1 is a digital data device interface 100 coupled to a digital device 150 and a peripheral device 180. Digital device 150 can include, but is not limited to, a cellular telephone, a personal data assistant, a smart phone, or a personal computer. In general, digital device 150 can include any type of digital device that acts as a digital instruction and processing unit that processes the data presented in digital form. The digital device 150 includes a system controller 160 and a link controller 170.

Peripheral devices 180 can include, but are not limited to, cameras, bar code readers, impact scanners, audio devices, and detectors. In general, peripheral device 180 can include any type of audio, video or image capture and display device in which data presented in digital form is exchanged between the periphery and the processing unit. Peripheral device 180 includes a control block 190. When peripheral device 180 is a camera, control block 190 may include, for example, but is not limited to, lens control, flash or white LED control, and shutter control. Digitally presented data may include audio, video and multimedia material in digital form.

Digital data device interface 100 transmits digitally presented data at a high rate over communication link 105. In one example, an MDDI communication link can be used that supports bidirectional data transmission with a maximum bandwidth of 3.2 Gbit/s. Other high data transfer rates above or below this example are also supported, depending on the communication link. The digital data device interface 100 includes a message translator module 110, a content module 120, a control module 130, and a chain controller 140.

A chain controller 140 located within the digital data device interface 100 establishes a communication chain 105 with a chain controller 170 located within the digital device 150. Chain controller 140 and chain controller 170 may be MDDI chain controllers.

The Video Electronics Standards Association ("VESA") MDDI standard, which is incorporated by reference in its entirety, describes the requirements of a high-speed digital packet interface that enables portable devices to transfer digital images from small portable devices to larger External display. MDDI's miniaturized connector system and flexible thin cable are ideal for connecting portable computing, communication and entertainment devices to upcoming products such as wearable microdisplays. It also includes information on how to simplify the connection between the host processor and the display device in order to reduce costs and increase the reliability of these connections. Chain controllers 140 and 170 establish communication path 105 in accordance with the VESA MDDI standard.

U.S. Patent No. 6,760,772 (the '772 patent) issued to the U.S. Pat. Interfaces are chained together using a packet structure to form a communication protocol for presenting data. The inventive embodiment taught in the '772 patent is directed to the MDDI interface. The signal protocols used by the chain controllers (such as the chain controllers 140 and 170) are framed to generate, transmit, and receive packets to form a communication protocol, and the digital data is formed into one or more types of data packets, at least one of which resides in the host device. And coupled to the guest device via a communication path, such as communication path 105.

The interface provides a bi-directional high-speed data transfer mechanism that is cost-effective and consumes less power in a short-range "serial" type of data link, and is suitable for implementation with miniaturized connectors and flexible thin cables. Embodiments of chain controllers 140 and 170 establish communication path 105 in accordance with the teachings of the '772 patent. The entire text of the '772 patent is incorporated herein by reference.

In other embodiments, chain controllers 140 and 170 can be USB chain controllers, or both can include a combination of various controllers, such as MDDI controllers and other types of chain controllers, such as USB chain controllers. Alternatively, chain controllers 140 and 170 may include a combination of controllers, such as an MDDI chain controller and a single link for exchanging accreditation information between digital data device interface 100 and digital device 150. In addition, chain controllers 140 and 170 can also support other types of interfaces, such as an Ethernet or RS-232 serial port interface. Those skilled in the relevant art will also appreciate other interfaces that may be supported in light of the teachings herein.

In the digital data device interface 100, the message translator module 110 receives the command of the system controller 160 via the communication link 105, and generates a response message to the system controller 160, translates the command message, and routes the command information content. (route) to the appropriate module in the digital data device interface 100.

The content module 120 receives the data from the peripheral device 180, stores the data, and transmits the data to the system controller 160 via the communication link 105.

Control module 130 receives the information from message translator 110 and routes the information to control block 190 of peripheral device 180. Control module 130 also receives information from control block 190 and routes the information to message translator module 110.

2 is a block diagram of a cell phone 200 having an upper cover and a body that provides high speed data communication between the upper cover and components within the fuselage using the MDDI interface. The following discussion related to cellular telephone 200 provides an illustrative example that further illustrates the use of digital data device interface 100 and provides other details related to implementation and use. In light of the discussion herein, it will be appreciated that the digital data device interface 100 can be used with other devices, such as personal digital assistants and other types of mobile phones, and is within the spirit and scope of the present invention.

Referring now to Figure 2, the body 202 of the cell phone 200 includes a Mobile Station Modem (MSM) baseband chip 204. The MSM 204 is a digital baseband controller. The upper cover 214 of the cell phone 200 includes a liquid crystal display (LCD) module 216 and a camera module 218. Both the body 202 and the upper cover 214 are packaged in a plastic case, such as that used in typical cell phones. Hinge 250 and 252 mechanically connect body 202 and upper cover 214. The bendable coupling 254 provides electrical coupling between the body 202 and the upper cover 214.

The MDDI chain 210 connects the camera module 218 to the MSM 204. Typically, camera module 218 and MSM 204 are both equipped with an MDDI chain controller. For example, within cell phone 200, MDDI host 222 is integrated within interface system 230, which is coupled to camera module 218, while MDDI client 206 is located on the MSM side of MDDI chain 210. Typically, the MDDI host is the host controller for the MDDI chain.

Within the cell phone 200, the interface system 230 receives the pixel data from the camera module 218 using the MDDI host 222, which is formatted into an MDDI packet before being transmitted to the MDDI chain 210. The MDDI client 206 receives the MDDI packet and reconverts it to the same pixel data as the camera module 218 generated. The pixel data is then sent to the appropriate block within MSM 204 for processing.

Likewise, MDDI chain 212 connects LCD module 216 to MSM 204. The MDDI chain 212 interconnects the MDDI host 208 integrated within the MSM 204 with the MDDI client 220 integrated within the interface system 232, which is coupled to the LCD module 216. The MDDI host 208 receives the display material generated by the graphics controller of the MSM 204 and formats it into an MDDI packet before transmitting it to the MDDI chain 212. The MDDI client 220 receives the MDDI packet and converts it into display material and processes the display data via the interface system 232 for use by the LCD module 216.

Interface systems 230 and 232 represent different embodiments of digital data device interface 100. In the case of the interface system 230, the digital data device interface 100 unit is implemented to support data transfer of camera images and camera control functions of the camera. In the case of the interface system 232, the implementation of the digital data device interface 100 unit is a control function that supports display of data on the LCD and LCD. The interface system 230 will be further explained below to illustrate an embodiment of a digital data device interface 100 when using a cellular telephone with a camera, such as a cellular telephone 200 having a camera module 218.

The relationship between the device of Fig. 1 and the cellular telephone 200 is as follows. Interface system 230 represents digital data device interface 100. The MDDI host 222 represents the chain controller 104. Camera module 218 represents perimeter 180. MSM 204 represents system controller 160, and MDDI client 206 represents chain controller 107.

3 is a diagram of upper cover 214 and provides further details regarding interface system 230 to highlight an exemplary embodiment of digital data device interface 100 for a cell phone containing a camera. The interface system 230 includes an MDDI host 222, a camera message translator 302, a camera video interface 304, an I2C main bus 303, a motor controller 308, and a flash/white LED timer 310. The I2C bus is a general purpose control bus that provides communication links between circuits. The I2C busbar was developed by Philips Electronics N.V. in the 1980s.

The recall interface system 230 corresponds to the digital data device interface 100. The components of the interface system 230 correspond to components of the digital data device interface 100 as follows. Camera video interface 304 corresponds to content module 120. The collective I2C main bus 303, the motor controller 308, and the flash/white LED timer 310 correspond to the control module 130.

The camera message translator 302 receives the command and generates a response message to the MSM 204 via the MDDI host 222. Camera message translator 302 translates the message and routes the information content to appropriate blocks within interface system 230, which may be referred to as MDDI camera interface devices. The camera video interface 304 receives image data from the camera 320, stores the image data, and transmits the image data to the MDDI host 222. The collective I2C main bus 306, motor controller 308, and flash/white LED timer 310 form a camera control block. In this case, the I2C main bus 306 provides the controls needed to control the management camera 320 (eg, the lens zoom function), and the flash/white LED timer 310 provides the management flash/white LED 324 (eg, flash brightness and duration) required. control.

4A is a diagram of the MDDI host 222. The MDDI host 222 includes a microprocessor interface 410, a command processor 420, a scratchpad 430, a direct memory access (DMA) interface 440, an MDDI packet constructor 450, a data contact switch module 460, and a data pad 470. The microprocessor interface 410 interfaces with a bus to the host processor, which controls the MDDI host 222. The host processor uses the microprocessor interface 410 to set the scratchpad, read the scratchpad, and issue commands to the MDDI host 222. The microprocessor interface 410 pays attention to the address value and passes the data to the appropriate module in the MDDI host 222, including transferring the write to the command processor 420, and reading and writing the temporary memory in the scratchpad 430. Value.

Command processor 420 processes commands received from the host processor. The commands include shutting down the MDDI chain 210, powering up the MDDI chain 210, resetting the MDDI host 222, and generating a particular type of data packet.

The register 430 stores the registers used for data transfer across the MDDI chain 210. The scratchpad within the scratchpad 430 controls the behavior of the MDDI chain 210 and the configuration of the MDDI host 222.

The DMA interface 440 provides a burst request to the external memory to receive information from the interface system 230 and buffer the data for the MDDI packet constructor 450. The DMA interface 440 parses the data of the link table node header and adjusts the indicator to read the actual packet data. The DMA interface 440 presents information about the next data packet for delivery to the MDDI packet constructor 450.

The next packet to be sent is determined by the MDDI Packet Builder 450 and constructs an entity packet that needs to pass through the MDDI chain 222. The packets are constructed from internal registers, counters, and DMA interface 440. When data is to be output on the MDDI chain 222, the data to be output can be generated from several sources. The first source of the packet is a control packet generated internally by the MDDI Packet Builder 450. Examples of such packets include sub-frame header packets, padding packets, and link closure packets. Another source of packets is via the DMA interface 440. These packets include packets that are passed through the linked list. In other embodiments, the video material can be passed directly to the MDDI packet constructor 450 when the perimeter includes a video camera. Regardless of the source of the packet, all packets are processed via a CRC generator system located within the MDDI packet constructor 450.

The data contact switch module 460 manages the entity's MDDI chain 210. This is done by a state machine responsible for contacting the exchange process, data output, round trip delay management, and reverse data. The data contact switch module 460 receives the data of the MDDI packet constructor 450 and passes the information to a data pad 470 that moves the data out onto the MDDI chain 222.

FIG. 4B illustrates the flow of providing a packet to the MDDI chain 210. As previously mentioned, the packet may be internally generated, received from the DMA interface 440, or directly received by the video packet. The internally generated packet is generated by the control packet generator 452. All types of packets are passed to the data contact switch module 460 via the CRC generator system 454. The data contact exchange module 460 sequentially provides the packets to the data pad 470, which places the data on the MDDI chain 210.

4C illustrates the flow of the MDDI Packet Builder 450 receiving packets on the MDDI chain 210. In this case, data pad 470 receives the packet from MDDI chain 210 and then passes the data to data contact switch module 460. The data contact switch module 460 passes the data to the CRC checker 456 located within the MDDI packet constructor 450. Once the CRC checker 456 confirms the CRC of the incoming packet, the packet provided to the DMA interface 440 is placed on the processor bus for distribution within the digital data interface device 100.

Figures 5 through 6 illustrate examples of packet types. These exemplary packages are used to illustrate the invention, but are not intended to limit the invention to the use of these types of packets. Other unique styles of packets (described below) and CRC fields can also be used with the present invention.

Figure 5 is a diagram of a sub-frame header packet format 500 in accordance with the VESA MDDI interface standard. The sub-frame header packet format 500 includes a packet length column 510, a packet type column 520, a unique word field 530, a sub-frame header parameter field 540, and a CRC field 550. The packet length field 510 includes a 16-bit (2-byte) value that specifies the total number of bytes in the packet that do not include the packet length column 510. The packet type field 520 includes a 16-bit unsigned integer that specifies the type of information contained within the packet. The unique word field 530 includes a unique 16-bit word. The unique word and packet type fields 520 are identified to form a unique 32-bit style to align the material. That is, when the packet is received, the MDDI packet constructor 450 can determine which portion or field the MDDI packet constructor 450 is processing the data packet based on the unique pattern. The sub-frame header parameter field 540 includes control parameters that manage the MDDI chain 222. The CRC column includes a 16-bit CRC value.

6 is a diagram of a video stream packet format 600. The video stream packet carries video data to update the rectangular portion of the display. The video stream packet format 600 includes a packet length column 610, a packet type column 615, a client ID field 620, a video format field 625, a pixel data attribute column 630, an X left edge column 635, a Y top edge column 640, and an X right edge column 645. The Y bottom edge column 650, the X start column 655, the Y start column 660, the pixel count column 665, the parameter CRC column 670, the pixel data column 675, and the pixel data CRC column 680.

The packet length field 610 includes a 16-bit (2-byte) value that specifies the total number of bytes in the packet that do not include the packet length field 610. The packet type column 620 includes a 2-bit unsigned integer that specifies the type of information contained within the packet.

Fields 620 through 665 are each a 2-byte field containing parameter data on how the video display should be formatted. A clear definition of these fields can be found in the VESA MDDI interface standard. The parameter CRC column 670 is a 2-byte field containing the CRC value generated by processing the parameter data in fields 610 through 665.

Pixel data field 675 includes any number of pixel data up to the size of the packet and the amount allowed by the pixel count column. The pixel CRC field 680 is a 2-byte field that contains the CRC value generated by processing the pixel data in the pixel data field 675.

Each packet transmitted on the MDDI chain 210 includes at least one CRC field, such as a CRC field 550 within the sub-frame header packet format 500. Two CRC fields will be included in some of the longer packets, such as the parameter CRC column 670 and the pixel CRC field 680 within the video stream packet format 600.

The CRC generates a small number of bits from a large block of data (such as packets of network traffic or blocks of computer files) to detect errors in transmission or storage. The CRC is calculated as a function of the data to be transmitted and is appended (eg, appended with the CRC column 550) prior to transmission or storage and verified thereafter to confirm that no changes have occurred.

The CRC is calculated by pushing the packet data through a CRC generator, such as CRC generator system 454, to generate a unique CRC value associated with the packet material. A CRC checker (such as CRC checker 456) generates a CRC value of the received data based on the received data. The CRC value of the received data is then compared to the transmitted CRC value. If the two match, the data can be considered as valid data, otherwise a CRC error will occur.

The reason why CRC is popular is that they are very simple to implement in binary hardware, easy to mathematically analyze, and especially good at detecting common errors caused by noise in the transmission channel. Those skilled in the art of this aspect should be aware of the specific implementation of the CRC generator.

As illustrated in Figures 5 and 6, the CRC column appears at the end of the packet (e.g., CRC column 512 and pixel data CRC column 680), and sometimes behind some of the more critical parameters in the packet, which may be quite large. The data field (e.g., parameter CRC column 670), and thus the likelihood of an error occurring during transmission increases. In a packet with two CRC fields, when only one is used, after the first CRC, the CRC generator is reinitialized so that the CRC calculation following the length data field is not subject to the beginning of the packet. The impact of the parameters.

Packets with many erroneous bits have a very low chance of producing a good CRC. In the error probability of containing many extremely long packets detected good CRC is about 7.6 × 10 ^{- 6.} By design, the MDDI chain will have a very low or zero error rate. The CRC is intended to monitor the health of the link and is not intended to detect errors in a particular packet to determine whether or not to forward the packet.

In an exemplary embodiment, the polynomial used to calculate the CRC is conventional CRC-16 or X16+X15+X2+X0. An example of the implementation of CRC generator 454 and CRC checker 456 for practicing the present invention is shown in Figure 4D. In FIG. 4D, before the first bit of the transport packet is transmitted, the value of the CRC register 471 is initialized to 0x0001, the packet is input from the Tx_MDDI_Data_Before_CRC line, and then the byte of the packet is first shifted from the LSB to the temporary bit. Inside the memory. Note that the number of bits in the scratchpad in this figure corresponds to the power of the polynomial used, not the bit position used by MDDI. It can more efficiently shift the CRC register in a single direction, which causes the CRC bit 15 to appear in the bit position 0 of the MDDI CRC field, and the CRC register bit 14 appears in the bit of the MDDI CRC field. Position 1, and so on, until the MDDI bit position 14 is reached.

For example, if the contents of the packet are: 0x000c, 0x0046, 0x000, 0x0400, 0x00, 0x00, 0x0000 (or represented by a sequence of bytes: 0x0c, 0x00, 0x46, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00 , 0x00, 0x00), and using the input of multiplexers 472, 473 and AND gate 474, the CRC output obtained on the Tx_MDDI_Data_With_CRC line is 0xd9aa (or represented by a sequence of 0xaa, 0xd9).

When the CRC generator 454 and the CRC checker 456 are grouped to form a CRC checker, the CRC received on the Rx_MDDI_Data line is input to the multiplexer 472 and the exclusive-OR (XOR) gate 476, and the NOR gate 475, AND gate is used. 474, and AND gate 477 are compared to the value found in the CRC register bit by bit. If there is any error, it is output by the AND gate 477. By connecting the output of the gate 477 to the input of the register 471, each packet containing the CRC error increments the CRC once. Note that the circuit example shown in Figure 4D can output more than one CRC error signal within a specified CHECK_CRC_NOW window (see Figure 4E). Therefore, in each interval of the CHECK_CRC_NOW action, the CRC error counter can usually only count the first CRC error condition. If the CRC generator is grouped, the CRC is timed out of the CRC register at the time coincident with the end of the packet.

The timing of the input and output signals, as well as the enable signal, is illustrated in Figures 4E and 4F. 4E shows the generation of the CRC and the transmission of the data packet with the states (0 or 1) of the Gen_Reset, Check_CRC_Now, Generate_CRC_Now, and Sending_MDDI_Data signals, along with the Tx_MDDI_Data_Before_CRC and Tx_MDDI_Data_With_CRC signals. 4F displays the receipt of the data packet and the CRC value in the states of the Gen_Reset, Check_CRC_Now, Generate_CRC_Now, and Sending_MDDI_Data signals, along with the Rx_MDDI_Data_Before_CRC and Rx_MDDI_Data_With_CRC signals.

The presence of CRC within the packet presents operational challenges and opportunities for more efficient use of the MDDI chain 210. Although the discussion herein is focused on the environment in which the CRC is used for the MDDI chain 210, the invention is not limited to the MDDI environment. The invention is applicable to any type of digital data transmission chain using CRC.

One of the challenges associated with using CRC is related to the initialization of the link. When the link is initiated, the MDDI host 222 transmits the sub-frame header packet (e.g., sub-box header packet format 500) to the MDDI client 206. After the link is initialized, typically the CRC checker 456 does not know the arrangement of the data in the data stream. That is, the CRC checker, for example, does not know that it is processing the data in the unique word field 530 or the CRC field 550. As a result, the CRC checker 456 needs to continuously queue the data into the memory until it recognizes the location of the data in the data stream. This results in inefficient and requires more memory and wafer area to queue and store data. The CRC checker 456 does not know the correct location of the data in the data stream, i.e., cannot generate a CRC compared to the received CRC to verify the received data.

Figure 7 is a diagram of a CRC checker 456 that addresses these challenges. The CRC checker 456 includes a unique pattern detector 710, a CRC generator 720, a CRC initializer 730, and a CRC validator 740. The unique style detector 710 detects unique patterns within the incoming data stream to identify a particular point in the data stream. The CRC generator 720 is a standard CRC generator for generating CRC values associated with the received data. The CRC initializer 730 pumps the CRC generator 720 with data values associated with the unique pattern and packet length. The CRC verifier 740 compares the received CRC value with the CRC value generated by the CRC generator 720 based on the received data to verify the data.

8 is a flow diagram of a method 800 of initializing a link, in fact using the CRC checker 456 described in FIG. In one method, it is assumed that the packet length of the sub-frame header remains fixed and the pre-computed value is loaded into the CRC checker, which is based on the packet length, the packet type, and the partial CRC of the unique character. Another method supports the case where the packet length is variable. In this case, the packet length along with the unique pattern can be pumped through the pre-calculator to produce a value, which can then be placed into the CRC checker at that point when the unique pattern is received.

The method 800 begins at step 810. In step 810, a request to initialize or wake up a transport chain is received, for example, MDDI client 206 receives a request from MDDI host 222 to initialize or wake up MDDI chain 210. Within the MDDI client 206, the CRC checker 456 is initialized by this link wakeup request. In particular, CRC initializer 730 is initialized by the request.

At step 820, the CRC generator is pre-populated with the data values associated with the unique pattern and packet length column 510 so that the CRC generator can generate a CRC value associated with the unique pattern and packet length column 510. As previously mentioned, in one embodiment, the packet length field is assumed to be fixed. For example, CRC initializer 730 can provide a unique style and packet length column to CRC generator 720. In the case of MDDI, the unique style is the data value associated with the material contained in the package type column 520 and the unique word field 530. The values of these fields are known after awakening a link. Thus, CRC initializer 730 can store these values and provide these values to CRC initializer 730 at a location when a request to wake up the link is received. In another method, instead of providing a data value to the CRC generator, the pre-computed CRC value generated by the CRC generator with the unique pattern and packet length field provided to the CRC generator is preloaded into the CRC checker.

At step 830, the CRC generator (such as CRC generator 720) is disabled. The generator is de-energized so that no further data that would change the CRC value is processed until the unique style and packet length fields are received.

At step 840, the incoming data is monitored to check for receipt of the unique material style. For example, the unique style detector 710 monitors the data received from the MDDI chain 210.

At step 850, a determination is made as to whether a unique style has been received. For example, the unique style detector 710 determines that the packet length column 510, the packet type column 520, and the unique word field 530 have been received.

At step 860, the CRC generator is energized. After being enabled, CRC generator 720 will construct an existing CRC value generated using the unique style of preloading. As a result, the CRC generator 720 immediately aligns with the data and does not need to queue or store the data in memory. Upon receiving the CRC value contained in CRC column 550, CRC verifier 740 can compare the value in CRC column 550 with the value generated by CRC generator 720 to determine if a CRC error is present. At step 870, method 800 ends.

Usually, during data transmission, the CRC value is used to determine if the transmission chain has a problem that corrupts the data. In another aspect of the invention, the CRC value is used to carry information related to system errors and status. In this way, the CRC field within the message can be used to more efficiently support the identification of transmission chain problems, system status or error information.

In an embodiment of the invention, the CRC column data is delayed to simply indicate that the system is transmitting data with some problems, and thus the received data may be problematic. For example, in some cases, data leaving the MDDI chain 210 may be corrupted because the MDDI packet constructor 450 receives incoming data that is not fast enough. Even if there is not enough data available for the packet, a packet should still be transmitted according to MDDI specifications. Therefore, even if a package is delivered, the material may be invalid or insufficient in some respects.

In this case, the CRC value (such as parameter CRC 670 or pixel data CRC 680) can be deliberately delayed so that MDDI client 206 can recognize the problem of compromised integrity of the transmitted packet. In the MDDI specification, this is a method of indicating that the MDDI client 206 has a problem with the data. Or, after sending the packet with the error, you need to send another message, specifically saying "The last packet I sent is bad."

When the MDDI client 206 receives a CRC value with a deliberate error in a packet, it decides how to process the packet. Algorithms for detecting and deciding how to handle packets with deliberately delayed CRC values can be developed. For certain types of packets, the MDDI client 206 can simply log a CRC error and continue to use the material. In other cases, however, MDDI client 206 may discard the received packet and request a new packet.

For example, in a video packet (such as video stream packet 600), if the pixel data CRC value 680 is intentionally corrupted, the MDDI client 220 does not notify the MDDI client 220 that the logic outside the packet is corrupted. In this case, the received data is buffered before the classification of any error notifications is provided. Here, there is not enough memory available to buffer all potential video data (ie, all pixel data to be displayed). Therefore, once the pixel data is received, it is provided to the display. The result is that if there is a CRC error somewhere in the video message, it is too late to stop using the video message. In this case, no action is taken except that the problem has been recorded. In summary, if a deliberately corrupted CRC value occurs in the pixel data and is not in the parameter data, the MDDI client simply records the CRC error in the CRC counter, but still uses the subsequent pixel data. On the other hand, if a parameter CRC value is intentionally corrupted, the MDDI client will not use the pixel data.

9 is a diagram of a cyclic redundancy generator system 454 that provides a mechanism to deliberately delay CRC values. The cyclic redundancy generator system 454 includes a CRC generator 910, a CRC error detector 920, an error detector 930, and an error value generator 940.

The CRC generator 910 generates a CRC value based on the data to be included in the data packet to be transmitted on the digital transmission chain (e.g., but not limited to, the MDDI chain 210).

The CRC error 920 corrupts the CRC value generated by the CRC generator 910 to carry host or remote system status information. For example, if interface system 230 is unable to provide information to MDDI host 222 quickly enough to properly fill the MDDI packet, CRC error 920 deliberately delays the CRC value of the packet to be transmitted.

Error detector 930 detects an error condition within the host system (such as MDDI host 222) or receives error status information based on information received from interface system 230 and provides instructions to CRC error 920 to intentionally delay the CRC value. In one embodiment, error detector 930 simply detects errors, but does not determine a particular error condition. In a later embodiment, the error detector 930 carries the type of error to the error value generator 940. The error value generator 940 instructs the CRC error 920 to replace the CRC value generated by the CRC generator 910 with a particular value indicating the type of system error or status condition.

When the CRC value is delayed, the algorithm must be chosen to ensure that the intentional corruption does not lead to the CRC value corresponding to the valid data, and therefore will not be received by the CRC checker at the receiving end of the transmission chain as a unique CRC. value. A possible algorithm can identify these CRC values that are not generated by valid data and use these values as a unique value that intentionally delays a CRC value. In view of the teachings herein, those skilled in the art will be able to determine other algorithms, which are included within the spirit and scope of the present invention.

10 is a diagram of a CRC checker 456 that can translate a deliberately corrupted CRC value from the CRC generator system 454. The CRC checker 456 includes a CRC error value detector 1010, a CRC generator 1020, and a CRC verifier 1030. The CRC error value detector 1010 detects the value in the CRC column of the data packet received from the digital transmission chain. The CRC error value detector 1010 detects when the CRC value corresponds to a CRC value that was intentionally corrupted to identify a system error condition. When the CRC value corresponding to the system error condition is identified, the CRC error value detector 1010 notifies the host processor of the receiving client (e.g., MDDI client 206). The host processor takes action based on the type of error being detected. The CRC generator 1020 generates a CRC value based on the received data stream. The CRC verifier 1030 detects the difference between the CRC value generated based on the received data stream and the CRC value transmitted within the received data stream. CRC generator 1020 and CRC verifier 1030 operate in a conventional manner as is known to those skilled in the art.

11 is a flow diagram of a method 1100 of transmitting system error information over a digital transmission chain with a deliberately delayed CRC value. Method 1100 begins at step 1110. In step 1110, an error is detected within the host system or associated system. For example, error detector 930 detects errors within MDDI host 222 or interface system 230. In step 1120, a CRC value is generated. For example, CRC generator 910 generates a CRC value for the material associated with the transmitted packet. At step 1130, the CRC value is corrupted. For example, error detector 930 instructs CRC error detector 920 to delay a CRC value. The method 1110 ends at step 1140. Note that while method 1100 is directed to a system description with respect to MDDI, method 1100 can be applied to any digital transmission system that uses CRC.

In the present invention, the CRC field can also be used to transmit error code information representing the type of error. At any time, only the data packet and the CRC are transmitted between the host side and the client, and no error code is accommodated therein. The only mistake is to lose synchronization. Otherwise, we must wait for the link to break away from the poor data transfer path or pipeline, then reset the link and continue. Unfortunately, this can be time consuming and somewhat inefficient.

In an embodiment a new and developed technique is used in which the CRC portion of the packet is used to convey error code information. That is, the processor or device that manages the transmission of data generates one or more error codes to indicate that a particular error or flaw may be pre-defined within the communication process or link. When an error is encountered, an appropriate error code is generated and transmitted using the bit of the CRC of the packet. That is, the CRC value is overwritten or overwritten by the desired error code, which can be detected at the receiving end by an error monitor or checker that monitors the value of the CRC column. In these situations, the error code is matched to the CRC value for some reason, and the complement of the error is transmitted to prevent confusion.

In one embodiment, to provide a robust error reporting and detection system, a series of transmitted or sent packets (usually all) may be transmitted a number of times after the error is detected. This action occurs until the point at which the error condition occurred is cleared from the system, at which point the normal CRC bit is transmitted and not overwritten by another value.

This technique of overlaying CRC values provides an extremely fast response to system errors while minimizing the number of extra bits or fields used.

As shown in FIG. 12, the CRC overwrite mechanism or device 1200 shown in the figure uses an error detector or detection mechanism 1202, such as error detector 930, which may be part of any of the other circuits previously described or known. Detect errors that are present or present in a communication link or process. An error code generator or mechanism 1204, such as CRC value generator 940, which may be part of other circuitry, or use, for example, lookup table technology to store pre-selected error messages when a predefined specificity has been detected When an error or defect occurs, it generates one or more error codes for indication. It will be readily apparent to those skilled in the art that devices 1202 and 1204 can be formed as a single circuit or device, or can be part of a sequence of programmable steps for other conventional processors and units.

A CRC value comparator or comparison mechanism 1206 (such as CRC verifier 1030) is used to check if the selected error code or code is the same as the transmitted CRC value. If the same, a complementary code generator or generation mechanism or device is used to provide complementation of the error code so that the original CRC pattern or value is not misinterpreted and the detection design is confusing or complicated. Next, the error code selector or selection mechanism unit or device 1210 selects the error code or value that it is desired to insert or overwrite, or its respective appropriate complement. The error code CRC overrider or overwrite mechanism or mechanism 1212 (such as CRC error 920) is a means for receiving data streams, packets, and codes that are intended to insert and overwrite corresponding or appropriate CRC values in order to resolve the desired error. The code is transmitted to the receiving device.

As previously mentioned, the error code can be transmitted multiple times using a series of packets, so during processing, the overlayer 1212 can utilize the memory storage unit to save a copy of the code, or to store or save from the previous unit as needed. The known storage locations of the values of these codes recall these codes.

Figures 13 and 14 show additional details of the general process of implementing the overwrite mechanism of Figure 12. In FIG. 13, one or more errors in the communication material or process are detected in step 1302, and an error code is selected in step 1304 to indicate this condition. At the same time, or at an appropriate point, the CRC value to be replaced is checked at step 1306 and compared to the desired error code at step 1308. As discussed earlier, the result of this comparison is a decision as to whether the desired code or other representative value is the same as the current CRC value. If they are the same, then processing proceeds to step 1312 where complementary (or in some cases other representative values) is selected as the code to be inserted. At steps 1310 and 1314, it is determined what error code or value to insert, i.e., the appropriate code is selected for insertion. The purpose of these separate steps is to make it clear that it is usually a selection based on the output determined in step 1308. Finally, at step 1316, the appropriate value is overwritten into the CRC location for transmission with the packet calibrated by the process.

On the packet receiving side, as shown in FIG. 14, the CRC value of the packet is monitored in step 1422. Typically, the CRC value is monitored by one or more processes within the system to determine if an error has occurred in the transmitted data, and whether to request the retransmission of the packet or packets, or to prohibit further operations, etc., some of which are in the foregoing Discussed. Part of this monitoring is that the information can also be used to compare values to know or pre-select an error code or representative value and detect the occurrence of an error. Alternatively, an independent error detection process and monitoring can be implemented. At step 1424, if a code presentation is to be present, it is retrieved or otherwise noted for further processing. At step 1426 it is determined if this is the actual code or is complementary, in which case an additional step 1428 can be used to convert the value to the desired code value. In either case, at step 1430, the retrieved code, complement, or other recovered value is used to detect what constitutes the error in the transmitted code.

in conclusion

Illustrative embodiments of the invention have been presented. The invention is not limited to these examples. The examples are presented herein for purposes of illustration and not limitation. It will be apparent to those skilled in the art from this disclosure that various alternatives, including equivalents, extensions, derivatives, or mutagenesis of the various examples described herein, are also included herein. These alternatives are within the spirit and scope of the invention.

All publications, patents, and patent applications referred to in this specification are hereby incorporated by reference in their entirety to the extent to the extent of Incorporated herein by reference.

100. . . Digital data device interface

1010. . . CRC error value generator

1020. . . CRC generator

1030. . . CRC validator

105. . . Communication chain

110. . . Message translator module

120. . . Content module

1200. . . CRC overwriting mechanism or device

1202. . . Error detector or detection mechanism

1204. . . Error code generator or mechanism

1206. . . CRC value comparator or comparison mechanism

1210. . . Error code selector or selection mechanism unit or device

1212. . . Overwrite

130. . . Message translator

140. . . Chain controller

150. . . Digital device

160. . . System controller

170. . . Link controller

180. . . Peripheral device

190. . . Control block

200. . . Cellular phone

202. . . body

204. . . Mobile station data base frequency chip

206. . . MDDI client

208. . . MDDI host

210. . . MDDI chain

212. . . MDDI chain

214. . . Upper cover

216. . . LCD module

218. . . Camera module

220. . . MDDI client

222. . . MDDI host

230. . . Interface system

232. . . Interface system

250. . . Hinge

252. . . Hinge

254. . . Flexible coupling

302. . . Camera message translator

303. . . I2C main bus

304. . . Camera video interface

306. . . I2C main bus

308. . . Motor controller

310. . . Flash/white LED timer

322. . . lens

324. . . Flash/white LED

410. . . Microprocessor interface

420. . . Command processor

430. . . Register

440. . . Direct memory access interface

450. . . MDDI packet constructor

452. . . Control packet generator

454. . . CRC generator

456. . . CRC checker

460. . . Data contact switch module

470. . . Data pad

471. . . CRC register

472. . . Multiplexer

473. . . Multiplexer

474. . . AND gate

475. . . NOR gate

476. . . Mutually exclusive -OR (XOR) gate

477. . . AND gate

500. . . Sub-frame header packet format

510. . . Packet length

520. . . Packet type

530. . . Unique character

540. . . Sub-frame header parameter

550. . . Cyclic redundancy check

600. . . Video stream packet format

610. . . Packet length column

615. . . Packet type column

620. . . Client ID column

625. . . Video format bar

630. . . Pixel data attribute bar

635. . . X left edge bar

640. . . Y top edge bar

645. . . X right edge bar

650. . . Y bottom edge

655. . . X start bar

660. . . Y start bar

665. . . Pixel count bar

670. . . Parameter CRC column

675. . . Pixel data column

680. . . Pixel data CRC column

710. . . Unique style detector

720. . . CRC generator

730. . . CRC initializer

740. . . CRC validator

910. . . CRC generator

920. . . CRC error

930. . . Error detector

940. . . Error code generator

In the respective figures, the same reference numerals indicate the same or functionally similar elements. The leftmost digit in the reference number indicates the first occurrence of the unit.

1 is a diagram of a digital data device interface coupled to a digital device and peripheral devices.

2 is a block diagram of a cellular telephone having an upper cover and a body that provides high speed data communication using the MDDI interface.

Figure 3 is a top cover view of a cell phone with a camera.

4A is a diagram of an MDDI host.

Figure 4B is a flow diagram of the packet from the MDDI packet wrapper to the MDDI chain.

4C is a flow diagram of the MDDI packet wrapper receiving a packet from the MDDI chain.

4D is a diagram of a CRC checker.

Figure 4E shows a timing diagram of the generation of CRC.

Figure 4F shows a timing diagram for the reception of the CRC.

Figure 5 is a diagram of a sub-frame header packet format.

Figure 6 is a video stream packet format diagram.

Figure 7 is a CRC checker.

Figure 8 is a flow diagram of a method of initializing a link including a pre-filled CRC generator.

9 is a diagram of a CRC generator system that provides a mechanism to deliberately delay CRC values.

Figure 10 is a diagram of a CRC checker that can explain a CRC value that is intentionally corrupted.

11 is a flow diagram of a method of transmitting system error information via a deliberately corrupted CRC value over a digital transmission chain.

Figure 12 is a diagram of a CRC overwrite mechanism.

Figure 13 is a flow chart of the CRC overwrite method.

Figure 14 is a flow diagram of a method of receiving a CRC value that has been overwritten.

454. . . CRC generator

910. . . CRC generator

920. . . CRC error

930. . . Error detector

940. . . Error code generator

Claims (24)

A cyclic redundancy check (CRC) checker system comprising: a host CRC generator that generates a CRC value and a CRC error based on a transmitted data stream, which delays the generated CRC value to a particular error a CRC error value corresponding to a special system error or status condition detected by the host; a selector at the host end, one of the data packets in the transmitted data stream CRC Sending the generated CRC value or the delayed CRC error value in the field; a client generator at the client, which generates a client CRC unique style based on the data stream received from the host terminal; a CRC verifier at the client that detects an error condition by comparing the client CRC unique pattern with the generated CRC value from the host; a CRC error at the client a value detector that detects the corrupted CRC error value generated by the host, corresponding to the special system error or status condition; and an indicator at the client for Detected by the CRC error value detector CRC error by the corruption of values and instruct the client to take specific corrective action. The CRC checker system of claim 1, wherein the error condition includes an error in the data stream. The CRC checker system of claim 1, wherein the special error or status condition comprises at least one member consisting of: identification of transmission link information, system status information, and system error information. . The CRC checker system of claim 1 further includes a recorder at the client for recording the corrupted CRC error value. The CRC checker system of claim 1 further includes an error detector at the host end for detecting the particular system error or status condition. The CRC checker system of claim 1 further includes a Mobile Display Digital Interface (MDDI) transmission link. A method for checking a cyclic redundancy check (CRC) in a digital transmission system, the method comprising the steps of: generating a host cyclic redundancy check (CRC) that generates a CRC value based on a transmitted data stream and The generated CRC value is delayed to a special delayed CRC error value corresponding to a special system error or status condition detected by the host terminal; the generated CRC value is selected via the host terminal or the The delayed CRC error value is used for transmission in one of the CRC fields of one of the data streams in the transmitted data stream; a client CRC unique style is generated on the client based on the data stream received from the host side Detecting an error condition at the client by comparing the client CRC unique pattern with the generated CRC value from the host; detecting the generation generated by the host at the client The delayed CRC error value, which corresponds to the particular system error or status condition; The client is instructed to take a special corrective action based on the detected corrupted CRC error value. The method of claim 7, wherein the error condition includes an error in the data stream. The method of claim 7, wherein the special error or status condition comprises at least one member consisting of: identification of transmission link information, system status information, and system error information. The method of claim 7, further comprising the step of recording, by the client, the corrupted CRC error value. The method of claim 7, further comprising detecting, by the host, the special system error or status condition. The method of claim 7, further comprising an MDDI transmission link. A machine readable medium for storing executable program instructions for executing an inspector system for a cyclic redundancy check (CRC) in a digital transmission system for storing the machine readable medium comprising: causing One of the CRC values generated by the transmission of the data stream is generated by one of the host cyclic redundancy check (CRC) and a program instruction causing the CRC value to be corrupted to a particular delayed CRC error value, the special delayed CRC error The value corresponds to a particular system error or status condition detected by the host; via the host terminal, one of the generated CRC value or the corrupted CRC error value is selected for use in the transmitted data stream a program instruction for transmission in one of the CRC fields of one of the data packets; Generating a program instruction generated by one of the client CRC unique styles at the client based on the data stream received from the host; by comparing the client CRC unique style with the script from the host Generating a CRC value to detect an error condition and causing a program command to detect one of the error conditions at the client; causing at the client one of the corrupted CRC error values generated by the host The detected program command, the delayed CRC error value corresponds to the special system error or status condition; and the client is instructed to take a special corrective action based on the detected corrupted CRC error value. A machine readable medium as claimed in claim 13 wherein the error condition comprises an error in the data stream. The machine readable medium of claim 13, wherein the special error or status condition comprises at least one member consisting of: identification of transmission link information, system status information, and system error information. The machine readable medium of claim 13 further comprising program instructions for causing the client to cause the one of the corrupted CRC error values to be recorded. The machine readable medium of claim 13 further comprising program instructions for causing the special system to detect one of the special system errors or status conditions. A machine readable medium as claimed in claim 13 further comprising an MDDI transmission link. A cyclic redundancy check (CRC) checker system that includes Means for generating a Host Cyclic Redundancy Check (CRC) that generates a CRC value based on a transmitted data stream and delays the generated CRC value to a particular corrupted CRC error value corresponding to the host a special system error or status condition detected by the terminal; for selecting the generated CRC value or the corrupted CRC error value for use in one of the CRC fields of one of the data packets in the transmitted data stream a means for transmitting; generating a client CRC unique style on the client based on the data stream received from the host through a digital transmission link; for uniquely comparing the client CRC a means for detecting an error condition at the client with the generated CRC value from the host; for detecting, at the client, the corrupted CRC error value generated by the host And the component, the delayed CRC error value corresponding to the special system error or status condition; and means for indicating that the client takes a special corrective action based on the detected corrupted CRC error value. For example, the system of claim 19, wherein the error condition includes an error in the data stream. The system of claim 19, wherein the special error or status condition comprises at least one member consisting of: identification of transmission link information, system status information, and system error information. The system of claim 19, further comprising The component that records the corrupted CRC error value. A system as claimed in claim 19, further comprising means for detecting a particular system error or condition. The system of claim 19, wherein the digital transmission link is an MDDI transmission link.