Simulating CRC32 according to IEEE Std. 802.3

A

ALuPin@web.de

Guest
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 ned by the following procedure:
a)The rst 32 bits of the frame are complemented.
...
e)The bit sequence is complemented and the result is the CRC.
Click to expand...

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: tools@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 = "00000000" (Integer 0)
byte1 = "00000001" (Integer 1)
....
byte255="11111111" (Integer 255)

Are the following assumptions correct ?

1. The CRC has to be initialized to
NOT ("00000011 00000010 00000001 00000000")

2. 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. To which value do I have to reset the "remote" CRC module ?

4. 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ĂŠ
 
Hi AndrĂŠ

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) <= not CRCReg(31 - i);
end loop;
3) On the receiver you pass the whole packet through the CRC generator
including the CRC.
The result in the CRC register after the last byte has gone through
is called the residue, and in the
case of 802.3 it is 0xC704DD7B if there are no errors. All you need
to do is compare the CRC register
with the residue. Note that this is not the bit reversed and
inverted value.

Hope this will help
Sudhir




ALuPin@web.de wrote:
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 ned by the following procedure:
a)The rst 32 bits of the frame are complemented.
...
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: tools@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 = "00000000" (Integer 0)
byte1 = "00000001" (Integer 1)
...
byte255="11111111" (Integer 255)

Are the following assumptions correct ?

1. The CRC has to be initialized to
NOT ("00000011 00000010 00000001 00000000")

2. 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. To which value do I have to reset the "remote" CRC module ?

4. 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ĂŠ
Click to expand...
 
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 => '1')).

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

means when claiming
a)The rst 32 bits of the frame are complemented.

Do you have any idea ?

Rgds
AndrĂŠ
 
ALuPin@web.de wrote:
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 => '1')).

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

means when claiming
a)The rst 32 bits of the frame are complemented.
Click to expand...
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:
http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/587b14d0fc43dbc1/cf1e7d94dedc5733#cf1e7d94dedc5733
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
 
It means exactly what it says. You invert the first 32 bits of the
frame.
Click to expand...
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.
 
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.

Thanks again for your help.

Rgds
André
 
Hi Sudhir,

The result in the CRC register after the last byte has gone through
is called the residue, and in the
case of 802.3 it is 0xC704DD7B
Click to expand...
Yes, the simulation shows that.

Rgds
André
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top