1. Home
  2. Field-Programmable Gate Arrays
  3. Simulating CRC32 according to IEEE Std. 802.3

Simulating CRC32 according to IEEE Std. 802.3

Hi,

I have been googling for a while having noticed that there is no clear answer to my following problem:

The IEEE Std. 802.3 says the following: (section 3.2.8 Frame Check Sequence field)

Mathematically,the CRC value corresponding to a given frame is de =EF=AC=

=81ned by the following procedure:

a)The =EF=AC=81rst 32 bits of the frame are complemented. >=2E.. >e)The bit sequence is complemented and the result is the CRC.

I use the following CRC32-VHDL module:

-- File: PCK_CRC32_D8.vhd

-- Purpose: VHDL package containing a synthesizable CRC function

-- * polynomial: (0 1 2 4 5 7 8 10 11 12 16 22 23 26 32)

-- * data width: 8

-- Info: snipped-for-privacy@easics.be

Now I want to simulate the CRC according to the IEEE standard. I have a transmitter including the CRC32 module and a receiver including the CRC32 module. But I have some doubts on how to perform a conform simulation.

Let's assume that the following bytes are transmitted via Ethernet(one byte interface), they are fed into the easics- module: byte0 =3D "00000000" (Integer 0) byte1 =3D "00000001" (Integer 1) .=2E. byte255=3D"11111111" (Integer 255)

Are the following assumptions correct ?

1=2E The CRC has to be initialized to NOT ("00000011 00000010 00000001 00000000") 2=2E The calculated CRC has to be inverted and appended in the following manner: first byte appendix: NOT CRC(31 DOWNTO 24) second byte appendix NOT CRC(23 DOWNTO 16) third byte appendix NOT CRC(15 DOWNTO 8) fourth byte appendix NOT CRC(7 DOWNTO 0) 3=2E To which value do I have to reset the "remote" CRC module ? 4=2E Do I have to remove the CRC32 appendix of the Ethernet packets and replace the four bytes with "00000000" ?

I would be very thankful if you could shed some light on it.

Rgds Andr=C3=A9

Reply to
ALuPin
Loading thread data ...

Hi Andr=C3=A9

I have just completed a 802.3 implementation and I think I can give you some answers. First of all my CRC implementation was based on the following paper "A Symbol Based Algorithm for Hardware Implementation of CRC", R. Nair, G. Ryan and F Farzaneh. This implementation uses xor equations to calculate CRC. In this case the CRC is reset to zero before commencing a new computation.

2) The final output needs to be bit reversed and inverted i.e for i in 31 downto 0 loop CRC(i) Hi,

=81ned by the following procedure:

Reply to
Sudhir.Singh

Hi Sudhir,

thank you for detailed answer.

If I do that the manner you describe I also get that residuum when using the easics-module (CRC-Reset Value (OTHERS =3D> '1')).

But I wonder what the IEEE Std. 802.3 (section 3.2.8 Frame Check Sequence field)

means when claiming a)The =EF=AC=81rst 32 bits of the frame are complemented.

Do you have any idea ?

Rgds Andr=C3=A9

Reply to
ALuPin

It means exactly what it says. You invert the first 32 bits of the frame.

I listed a number of CRC properties in this thread:

formatting link
Property 3 says: " Initialising the register to all ones is equivalent to initialising the register to all zeros and *inverting the first N bits of the message*."

Regards, Allan

Reply to
allanherriman

Note that you get the same results if you initialize the CRC register with all ones and do not complement the first 32 bits, due to the properties of the CRC algorithm.

Inverting the first 32 bits (or equivalently using a start valuie of

0xFFFFFFFF) detects erroneous 0s inside the start sequence (first 32 bits). If you initialize with 0 and have additional 0s at the beginning, standard CRC will not detect it (CRC uses polynom division, dividing 0 always gives 0).

Hubble.

Reply to
Reiner Huober

Hi Allan, hi Reiner,

thank you for your responses. They have shed some light on my problem.

I have simulated the test design with respect to your considerations and they are correct.=20

Thanks again for your help.

Rgds Andr=E9

Reply to
ALuPin

Hi Sudhir,

Yes, the simulation shows that.

Rgds Andr=E9

Reply to
ALuPin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.