Algorithm Analysis and program implementation of Cyclic Redundancy verification CRC

Cyclic RedundancyAlgorithmAnalysis andProgramImplementation

Author: Liu Dong

Overview

In digital communication systems, reliability and speed are often a conflict. If the requirement is fast, it will inevitably shorten the time occupied by each data element, narrow the waveform, and reduce the energy. In this way, the possibility of errors will increase after being disturbed, and the reliability of transmitted information will decrease. If reliability is required, the transmission speed slows down. Therefore, how to reasonably solve the contradiction between reliability and speed is one of the key issues in correctly designing a communication system. To ensure the correctness of the transmission process, the communication process must be put under error control. The most common methods for error control are automatic request re-sending (ARQ), forward correction (FEC), and hybrid correction (HEC ). The FEC method is ideal when the transmission error rate is low. When the error rate is high during transmission, the use of FEC is prone to "disorderly correction. The combination of ARQ and FEC in the HEC mode. In many digital communications, ARQ is widely used. At this time, error control only requires the error detection function. There are many error control methods to implement the error checking function. The traditional methods include parity verification, checksum detection, repeated code verification, constant rate code verification, and row and column verification, these methods increase the amount of data redundancy and send the verification code and data together to the receiver. The Receiver performs the same verification on the received data, and then compares the obtained verification code with the Received verification code. If the two are the same, the transmission is correct. However, these methods have their own shortcomings, and the probability of misjudgment is relatively high.

Cyclic Redundancy check CRC (cyclic redundancy check) is derived from the branch of the grouped linear code. Its main application is binary code group. Simple coding and low false positives are widely used in communication systems. The following describes the principle of CRC verification and Its Algorithm Implementation.

I. cyclic redundancy check code (CRC)

CRC verification adopts polynomial encoding. The processed data block can be viewed as an N-level binary polynomial, produced. For example, an 8-bit binary number of 10110101 can be expressed :. The process of multiplication and division is the same as that of ordinary algebra polynomials. The addition and subtraction operations of polynomials take 2 as the model. addition and subtraction are not performed. They are misaligned and consistent with logical exclusive or operations.

When CRC verification is adopted, the sender and receiver generate a polynomial g (x) with the same one, and the first and last coefficients of g (x) must be 1. The handling method of CRC is: the sender removes T (x) from G (x) and obtains the remainder as the CRC verification code. During verification, the system checks whether the data frame has an error based on whether the calculated calibration result is 0.

CRC check can detect all odd numbers of random errors and sudden errors whose length is less than or equal to K (K is g (x. Therefore, the higher the order of the generated polynomial of CRC, the smaller the probability of false positives. CCITT recommendations: 2048 kbit/s PCM base equipment using CRC-4 scheme, using the CRC checkcode generated polynomial g (x) =. The 16-bit CRC check ensures that only one undetected error is contained in the bit code. In the frame verification sequence of the IBM synchronization Data Link Control Procedure SDLC, using a CRC-16, it generates polynomial g (x) =; in frame verification sequence FCS of HDLc, the advanced data link control procedure recommended by CCITT generates polynomial g (x) = by using CCITT-16. The generation polynomial g (x) = Of The CRC-32. CRC-32 error probability is twice lower than CRC-16. Because of the reliability of CRC-32, CRC-32 is very suitable for important data transmission, so it is widely used in communication, computer and other fields. In some UART communication control chip (such as mc6582, intel8273 and Z80-SIO), all adopt CRC verification code for error control; ethernet card chip, MPEG decoding chip, CRC-32 is also used for error control.

Ii. Algorithm Analysis of CRC verification code

The CRC verification code is encoded by dividing the binary data t (X) to be sent by the generated polynomial g (x), and the remainder is used as the CRC verification code. The implementation steps are as follows:

(1) If the data block to be sent is m-bit binary polynomial T (x), the G (x) with the polynomial degree of R is generated ). Add R 0 at the end of the data block, increase the length of the data block to m + R bit, and the corresponding binary polynomial is.

(2) remove by generating polynomial g (x) and obtain the binary polynomial y (x) whose remainder is the order number of R-1 ). This binary polynomial y (x) is the CRC verification code generated by T (x) for polynomial g (x) encoding.

(3) subtract y (x) in mod 2 to obtain the binary polynomial. It is the string to be sent that contains the CRC verification code.

From the CRC encoding rules, we can see that CRC encoding is actually converting the M-bit binary polynomial T (x) sent on behalf of the system into G (x) the m + R bit binary polynomials are exhausted. Therefore, g (x) can be removed from the received data during decoding. If the remainder digit is zero, it indicates that the transmission process is correct; if the remainder is not zero, there must be an error during transmission. Many CRC hardware decoding circuits perform error checking in this way. At the same time, it can be seen as a combination of T (X) and CRC verification codes. Therefore, during decoding, the received binary data is removed from the R-bit data at the end, and the original data is obtained.

To better understand the coding process of the CRC verification code, we will use a simple example to illustrate the coding process of the CRC verification code. Since the CRC-32, CRC-16, CCITT and CRC-4 encoding process is basically the same, only the number of digits and the generated polynomial is not the same. In order to describe the process of CRC Coding, an example of CRC-4 encoding is used.

Set the T (x) of the data to be sent to 12-bit binary data 100100011100; the generated polynomial of the CRC-4 is g (x) =, and the Order R is 4, that is, 10011. Add four zeros at the end of T (x), and the data block is 1001000111000000. Then remove it with G (x), regardless of the number of vendors. You only need to obtain the remainder y (X ). The following table shows the division process.

Divisor times divisor/g (x)/result Remainder

0 1 001000111000000 100111000000

1 0011

0 000100111000000

1 00111000000 1000000

1 0011

0 00001000000

2 1 000000 1100

1 0011

0 001100

We can see from the above table that CRC encoding is actually a Model 2 Operation of cyclic shift. For the CRC-4, we assume there is a 5 bits register, through repeated shift and CRC division, then the final value in the Register to remove the highest bit is the remainder we require. You can use the following process to describe the above steps:

// Reg is a 5 bits register

Set the value in Reg to 0.

Add the original data to R 0.

While (data not processed)

Begin

If (REG first 1)

Reg = reg XOR 0011.

Move the value in Reg to the left, read a new data, and place it in the 0-bit location of register.

End

The last four digits of Reg are the remainder we require.

This algorithm is simple and easy to implement. It is applicable to G (x) that generates polynomials of any length. It can be used when the sent data is not long. However, this method is not suitable for sending a long data block. It can only process one bit of data at a time, and the efficiency is too low. To improve processing efficiency, you can process four, eight, 16, and 32 bits at a time. Because the processor structure basically supports 8-bit data processing, it is appropriate to process 8-bit data at a time.

In order to have an intuitive understanding of the optimized algorithm, let's take a look at the above algorithm from another angle. In the above example, the encoding process can be considered as the following process:

Since we only need the remainder, we only need to look at the last four digits. Construct a four-digit register Reg. The initial value is 0. The data is migrated to reg0 (the 0-bit REG) in turn, and the data of reg3 is removed from Reg. The above algorithm knows that Reg and g (x) perform XOR operations only when the data to be removed is 1. When the data to be removed is 0, Reg and g (x) are not) perform XOR operations, equivalent to XOR operations on 0000. That is to say, Reg and what types of data are used to determine the XOR data to be removed. There is only one bit, so there is a choice. The preceding algorithm can be described as follows,

// Reg is a 4 bits register

Initialize T [] = {0011,0000}

Set the value in Reg to 0.

Add the original data to R 0.

While (data not processed)

Begin

Move the value in Reg to the left, read a new data, and place it in the 0-bit location of register.

Reg = reg xor t [REMOVED bit]

End

The above algorithm is processed in BIT units, the above algorithm can be extended to 8 bits, that is, processing in bytes, that is, CRC-32. Construct a four-byte register Reg. The initial value is 0x00000000. The data is migrated to reg0 in sequence (The 0th byte of Reg, similar to the following), and the data of reg3 is removed from Reg. The preceding algorithm and so on show that the removed data bytes determine the type of data XOR and Reg. Because there are 8 bits, there is a choice. The preceding algorithm can be described as follows:

// Reg is a 4 byte register.

Initialize T [] = {...} // Total = 256 Items

Set the value in Reg to 0.

Add the original data to R/8 0 bytes.

While (data not processed)

Begin

Move the value in Reg to the left one byte, read a new byte, and place it at the 0th byte position of Reg.

Reg = reg xor t [REMOVED bytes]

End

The basis of the algorithm is related to the division of polynomials. If a m-bit polynomial T (X) is divided by an R-level generative polynomial g (x), each digit (0 = <k <m) is proposed, after less than R 0, g (x) is removed separately to obtain the remainder bitwise. Then, the formula T (X) is obtained from the generated polynomial g (x. For the CRC-32, each byte can be supplemented with 32 zeros and then computed with the generated polynomial, the remainder is the value in the preceding algorithm T []. Because one byte has 8 bits, t [] has a total of = 256 Items. For more information about the nature of Polynomial operations, see [1]. This algorithm processes one byte each time and performs computation through the look-up table method, greatly improving the processing speed. Therefore, this algorithm is used by most applications.

Three, CRC-32 program implementation.

In order to improve the coding efficiency, most of the use of look-up table method to complete the CRC-32 verification, the following is a CRC-32 verification subroutine.

Unsigned long crc_32_tab [0, 256] = {

0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3, 0x0edb8832 ,..., 0x5a05df1b, 0x2d02ef8d

}; // Parameters table calculated in advance. There are a total of 256 Items, not all listed.

Unsigned long generatecrc32 (char xdata * databuf, unsigned long Len)

{

Unsigned long oldcrc32;

Unsigned long CRC32;

Unsigned long oldcrc;

Unsigned int charcnt;

Char C, T;

Oldcrc32 = 0x00000000; // The initial value is 0.

Charcnt = 0;

While (Len --){

T = (oldcrc32> 24) & 0xff; // The value of the byte to be removed

Oldcrc = crc_32_tab [T]; // query table based on the removed bytes

C = databuf [charcnt]; // The New byte value.

Oldcrc32 = (oldcrc32 <8) | C; // Add the new byte value to the last byte of the register.

Oldcrc32 = oldcrc32 ^ oldcrc; // perform XOR operations on the registers and the detected values.

Charcnt ++;

}

CRC32 = oldcrc32;

Return CRC32;

}

The parameter table can be calculated on the PC or completed during program initialization. The following table is used to calculate the parameter table C Language Subroutine, compiled in Visual C ++ 6.0.

# Include <stdio. h>

Unsigned long int crc32_table [256];

Unsigned long int ulpolynomial = 0x04c11db7;

Unsigned long int reflect (unsigned long int ref, char ch)

{Unsigned long int value (0 );

// Exchange bit0 and bit7, bit1 and bit6, and so on

For (INT I = 1; I <(CH + 1); I ++)

{If (ref & 1)

Value | = 1 <(CH-I );

Ref >>= 1 ;}

Return value;

}

Init_crc32_table ()

{Unsigned long int CRC, temp;

// 256 values

For (INT I = 0; I <= 0xff; I ++)

{Temp = reflect (I, 8 );

Crc32_table [I] = temp <24;

For (Int J = 0; j <8; j ++ ){

Unsigned long int T1, T2;

Unsigned long int flag = crc32_table [I] & 0x80000000;

T1 = (crc32_table [I] <1 );

If (flag = 0)

T2 = 0;

Else

T2 = ulpolynomial;

Crc32_table [I] = T1 ^ T2 ;}

CRC = crc32_table [I];

Crc32_table [I] = reflect (crc32_table [I], 32 );

}

}

Conclusion

CRC verification is widely used in various data verification applications due to its simple implementation and strong error checking capability. It occupies less system resources and can be implemented using software and hardware. It is a good method for data transmission error detection.