a painless guide to crc error detection algorithms.docx

1、a painless guide to crc error detection algorithms目录原文网址http:/www.repairfaq.org/filipg/LINK/F_crc_v3.html 22. Introduction: Error Detection 23. The Need For Complexity 44. The Basic Idea Behind CRC Algorithms 55. Polynomial（多项式） Arithmetic 7Chapter 6 Binary Arithmetic with No Carries 10Chapter 7 A F

2、ully Worked Example 13Chapter 8 Choosing A Poly 16Chapter 9) A Straightforward CRC Implementation 17Chapter 10 A Table-Driven Implementation 19Chapter 11 A Slightly Mangled(损坏的) Table-Driven Implementation 23Chapter 12) Reflected Table-Driven Implementations 27Chapter 13) Reversed Polys 29Chapter 14

3、) Initial and Final Values 30Chapter 15) Defining Algorithms Absolutely 30Chapter 16) A Parameterized Model For CRC Algorithms 31Chapter 17) A Catalog of Parameter Sets for Standards 33Chapter 18) An Implementation of the Model Algorithm 35Chapter 19) Roll Your Own Table-Driven Implementation 35Chap

4、ter 20) Generating A Lookup Table 36Chapter 21) Summary 37Chapter 22) Corrections 37Chapter 23) Glossary 37Chapter 24) References 38Chapter 25) References I Have Detected But Havent Yet Sighted 39原文网址http:/www.repairfaq.org/filipg/LINK/F_crc_v3.html2. Introduction: Error DetectionThe aim of an error

5、 detection technique is to enable the receiver of a message transmitted through a noisy (error-introducing) channel to determine whether the message has been corrupted. To do this, the transmitter constructs a value (called a checksum) that is a function of the message, and appends it to the message

6、. The receiver can then use the same function to calculate the checksum of the received message and compare it with the appended checksum to see if the message was correctly received. For example, if we chose a checksum function which was simply the sum of the bytes in the message mod 256 (i.e. modu

7、lo 256), then it might go something as follows. All numbers are in decimal. Message : 6 23 4 Message with checksum : 6 23 4 33 Message after transmission : 6 27 4 33In the above, the second byte of the message was corrupted（变坏） from 23 to 27 by the communications channel. However, the receiver can d

8、etect this by comparing the transmitted checksum (33) with the computer checksum of 37 (6 + 27 + 4). If the checksum itself is corrupted, a correctly transmitted message might be incorrectly identified as a corrupted one. However, this is a safe-side failure. A dangerous-side failure occurs where th

9、e message and/or checksum is corrupted in a manner that results in a transmission that is internally consistent. Unfortunately, this possibility is completely unavoidable and the best that can be done is to minimize its probability by increasing the amount of information in the checksum (e.g. wideni

10、ng the checksum from one byte to two bytes).Other error detection techniques exist that involve performing complex transformations on the message to inject it with redundant（冗长的） information. However, this document addresses only CRC algorithms, which fall into the class of error detection algorithm

11、s that leave the data intact（原封不动的） and append a checksum on the end. i.e.: 3. The Need For ComplexityIn the checksum example in the previous section, we saw how a corrupted message was detected using a checksum algorithm that simply sums the bytes in the message mod 256: Message : 6 23 4 Message wi

12、th checksum : 6 23 4 33 Message after transmission : 6 27 4 33A problem with this algorithm is that it is too simple. If a number of random corruptions occur, there is a 1 in 256 chance that they will not be detected. For example: Message : 6 23 4 Message with checksum : 6 23 4 33 Message after tran

13、smission : 8 20 5 33To strengthen the checksum, we could change from an 8-bit register to a 16-bit register (i.e. sum the bytes mod 65536 instead of mod 256) so as to apparently reduce the probability of failure from 1/256 to 1/65536（why？因为结果有65536种可能性，不变只占其中一种）. While basically a good idea, it fail

14、s in this case because the formula used is not sufficiently random; with a simple summing formula, each incoming byte affects roughly only one byte of the summing register no matter how wide it is. For example, in the second example above, the summing register could be a Megabyte（兆字节） wide, and the

15、error would still go undetected. This problem can only be solved by replacing the simple summing formula with a more sophisticated formula that causes each incoming byte to have an effect on the entire checksum register.Thus, we see that at least two aspects are required to form a strong checksum fu

16、nction:WIDTHA register width wide enough to provide a low a-priori probability of failure (e.g. 32-bits gives a 1/232 chance of failure).CHAOSA formula that gives each input byte the potential to change any number of bits in the register.Note: The term checksum was presumably used to describe early

17、summing formulas, but has now taken on a more general meaning encompassing more sophisticated algorithms such as the CRC ones. The CRC algorithms to be described satisfy the second condition very well, and can be configured to operate with a variety of checksum widths.4. The Basic Idea Behind CRC Al

18、gorithmsWhere might we go in our search for a more complex function than summing? All sorts of schemes spring to mind. We could construct（建造） tables using the digits of pi, or hash（散列） each incoming byte with all the bytes in the register. We could even keep a large telephone book on-line, and use e

19、ach incoming byte combined with the register bytes to index a new phone number which would be the next register value. The possibilities are limitless.However, we do not need to go so far; the next arithmetic step suffices（足够）. While addition is clearly not strong enough to form an effective checksu

20、m, it turns out that division is, so long as the divisor is about as wide as the checksum register.The basic idea of CRC algorithms is simply to treat the message as an enormous binary number, to divide it by another fixed binary number, and to make the remainder from this division the checksum. Upo

21、n receipt of the message, the receiver can perform the same division and compare the remainder with the checksum (transmitted remainder).Example: Suppose the the message consisted of the two bytes (6,23) as in the previous example. These can be considered to be the hexadecimal number 0617 which can

22、be considered to be the binary number 0000-0110-0001-0111. Suppose that we use a checksum register one-byte wide and use a constant divisor of 1001, then the checksum is the remainder after 0000-0110-0001-0111 is divided by 1001. While in this case, this calculation could obviously be performed usin

23、g common garden variety 32-bit registers, in the general case this is messy. So instead, well do the division using good-ol long division which you learned in school (remember?). Except this time, its in binary: .0000010101101 = 00AD = 173 = QUOTIENT _-_-_-_-9= 1001 ) 0000011000010111 = 0617 = 1559

24、= DIVIDENDDIVISOR 0000.,.,., -.,.,., 0000,.,., 0000,.,., -,.,., 0001,.,., 0000,.,., -,.,., 0011.,., 0000.,., -.,., 0110.,., 0000.,., -.,., 1100.,., 1001.,., =.,., 0110.,., 0000.,., -.,., 1100,., 1001,., =,., 0111., 0000., -., 1110, 1001, =, 1011, 1001, =, 0101, 0000, - 1011 1001 = 0010 = 02 = 2 = RE

25、MAINDERIn decimal this is 1559 divided by 9 is 173 with a remainder of 2.Although the effect of each bit of the input message on the quotient is not all that significant, the 4-bit remainder gets kicked about quite a lot during the calculation, and if more bytes were added to the message (dividend)

26、its value could change radically（完全的） again very quickly. This is why division works where addition doesnt.In case youre wondering, using this 4-bit checksum the transmitted message would look like this (in hexadecimal): 06172 (where the 0617 is the message and the 2 is the checksum). The receiver w

27、ould divide 0617 by 9 and see whether the remainder was 2.5. Polynomial（多项式） ArithmeticWhile the division scheme described in the previous section is very very similar to the checksumming schemes called CRC schemes, the CRC schemes are in fact a bit weirder, and we need to delve（钻研） into some strang

28、e number systems to understand them.The word you will hear all the time when dealing with CRC algorithms is the word polynomial. A given CRC algorithm will be said to be using a particular polynomial, and CRC algorithms in general are said to be operating using polynomial arithmetic. What does this

29、mean?Instead of the divisor, dividend (message), quotient（商）, and remainder (as described in the previous section) being viewed as positive integers, they are viewed as polynomials with binary coefficients. This is done by treating each number as a bit-string whose bits are the coefficients of a pol

30、ynomial. For example, the ordinary number 23 (decimal) is 17 (hex) and 10111 binary and so it corresponds to the polynomial: 1*x4 + 0*x3 + 1*x2 + 1*x1 + 1*x0or, more simply: x4 + x2 + x1 + x0Using this technique, the message, and the divisor can be represented as polynomials and we can do all our ar

31、ithmetic just as before, except that now its all cluttered（弄乱） up with Xs. For example, suppose we wanted to multiply 1101 by 1011. We can do this simply by multiplying the polynomials:(x3 + x2 + x0)(x3 + x1 + x0)= (x6 + x4 + x3 + x5 + x3 + x2 + x3 + x1 + x0) = x6 + x5 + x4 + 3*x3 + x2 + x1 + x0At this point, to get the right answer, we have to pretend that x is 2 and propagate binary carries from the 3*x3 yielding: x7 + x3 + x2 + x1 + x0Its just like ordinary arithmetic except that the base is abs