FPGA Central

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: [email protected]

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




[email protected] 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: [email protected]
>
> 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 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é

[email protected] 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.

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....1e7d94dedc5733
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.

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

Yes, the simulation shows that.

Rgds
André