The CCITT-CRC32 for Ethernet.
Trygve Odegaard
In line with what has been described in some previous postings, I'm also
trying to use code generated from http://www.easics.be/webtools/crctool
to perform 8-bit parallel data CRC32 generation/check for Ethernet.
However, there are some aspects that confuses me, could you please
enlighten me !
1. The nextCRC32_D8 from www.easics.be.
- Convention: the first serial data bit is D(7).
OK, nice specification, I understand it !
- But for the CRC: std_logic_vector(31 downto 0).
Which end of the vector corresponds to the term x**31
and which end corresponds to the term x**0 ?
2. Actual usage for Ethernet CRC generation/check.
- Generation:
* "Complement the first 32 bit of the frame"
(or equivalently, initialize the CRC-reg to all ones).
OK, I can follow instructions, but I would very much like to
know why !
Is this a means to give fault coverage for the first
32 bits as well ?
* "After having computed the CRC, perform bit-reversal".
Why, if I could figure out what bit in the CRC that corresponds
to the term x**31, then according to the IEEE 802.3 this is the bit
that goes first onto my physical medium.
Can't I just find the correct end of my CRC-reg, and then shift
continuously from that end ?
* "After having computed the CRC, perform bit-inversion".
Why, is this to matematically correct for the initial
complement of the first 32-bit ?
- Check:
* Calculate the crc for the complete frame, including the crc, received.
Expect the residue to be 0xC704DD7B if the transmission went ok.
Ok, expect I should be able to do that ....
3. Other usages.
- Is the usage for HDLC 32-bit CRC exactly the same as for
Ethernet ?
If you found this posting a bit confusing, it just reflects
my current state of mind ..........
Regards
Trygve
Alan Coppola
The CRC system I implemented at:
supplies three levels of verification,
a vhdl test bench and documentation,
which would answer all the questions posed below.
alan
--
Alan Coppola
Mike Treseler
Trygve Odegaard wrote:
> Hi.
>
> In line with what has been described in some previous postings, I'm also
> trying to use code generated from http://www.easics.be/webtools/crctool
> to perform 8-bit parallel data CRC32 generation/check for Ethernet.
>
> However, there are some aspects that confuses me, could you please
> enlighten me !
>
> 1. The nextCRC32_D8 from www.easics.be.
> - Convention: the first serial data bit is D(7).
> OK, nice specification, I understand it !
> - But for the CRC: std_logic_vector(31 downto 0).
> Which end of the vector corresponds to the term x**31
> and which end corresponds to the term x**0 ?
x**31 is off the end -- not used by the shift operation
x**30 masks the left bit
x**0 masks the right bit
The xor mask constant for crc32 is is:
(26|23|22|16|12|11|10|8|7|5|4|2|1|0 => '1', others => '0'),
>
> 2. Actual usage for Ethernet CRC generation/check.
> - Generation:
> * "Complement the first 32 bit of the frame"
> (or equivalently, initialize the CRC-reg to all ones).
> OK, I can follow instructions, but I would very much like to
> know why !
Because that's what the spec is. You will get the wrong answer otherwise.
> Is this a means to give fault coverage for the first
> 32 bits as well ?
It makes the algorithm more sensitive to a stuck zero condition.
> * "After having computed the CRC, perform bit-reversal".
> Why, if I could figure out what bit in the CRC that corresponds
> to the term x**31, then according to the IEEE 802.3 this is the bit
> that goes first onto my physical medium.
> Can't I just find the correct end of my CRC-reg, and then shift
> continuously from that end ?
> * "After having computed the CRC, perform bit-inversion".
> Why, is this to matematically correct for the initial
> complement of the first 32-bit ?
This is not necessary for checking an FCS, only for generating one
> - Check:
> * Calculate the crc for the complete frame, including the crc,
> received.
> Expect the residue to be 0xC704DD7B if the transmission went ok.
> Ok, expect I should be able to do that ....
Make sure you cover the whole packet & fcs.
> 3. Other usages.
> - Is the usage for HDLC 32-bit CRC exactly the same as for
> Ethernet ?
>
It is if you are working with unstuffed data with bit order and byte order issues
handled correctly.
-- Mike Treseler
Allan Herriman
To further clarify (and hopefully not obfuscate):
CRCs are always defined in terms of their "serial prototype" and the
bit order on the line.
Some systems (e.g. Ethernet) will transmit bit 0 out of a byte first.
Some systems (e.g. POS, etc.) will transmit bit 7 out of a byte first.
HDLC is derived from something thought up at IBM, so it transmits bit
7 first. (BTW, Ethernet was a DEC/INTEL/Xerox thing, so it does it
the other way, just to make your life interesting.)
This means that two otherwise identical frames will have a different
CRC if one is transmitted on Ethernet and one is transmitted on HDLC,
even though the CRC is defined the same way in both cases.
Moral: You have to be really careful about how you connect your data
bus to the CRC generator.
It is not uncommon to see code that uses an Ethernet CRC generator for
HDLC (etc.) with a "bit reordering" stage in front.
It gets more interesting on wider buses, but that probably won't worry
you.
Regards,
Allan.
Joseph Dalton
...
>
> To further clarify (and hopefully not obfuscate):
> CRCs are always defined in terms of their "serial prototype" and the
> bit order on the line.
> Some systems (e.g. Ethernet) will transmit bit 0 out of a byte first.
> Some systems (e.g. POS, etc.) will transmit bit 7 out of a byte first.
>
> HDLC is derived from something thought up at IBM, so it transmits bit
> 7 first. (BTW, Ethernet was a DEC/INTEL/Xerox thing, so it does it
> the other way, just to make your life interesting.)
>
Ooo... You need to be careful there. First IBM's conventions for bit
ordering are (0 .. n-1) for (msb .. lsb). So for a byte of data the
msb would be bit 0, and the lsb would be bit 7. Which bit 7 are you
talking about? IBM's, or everyone elses?
Secondly, not all uses of HDLC may be the same. Frame Relay uses HDLC
as a framing protocol. It also transmits bit 0 first. So in the
standards document defining FR, you have an interesting mind-bending
definition for the CRC, (although I think it is usually CRC-16).
> This means that two otherwise identical frames will have a different
> CRC if one is transmitted on Ethernet and one is transmitted on HDLC,
> even though the CRC is defined the same way in both cases.
>
> Moral: You have to be really careful about how you connect your data
> bus to the CRC generator.
> It is not uncommon to see code that uses an Ethernet CRC generator for
> HDLC (etc.) with a "bit reordering" stage in front.
> It gets more interesting on wider buses, but that probably won't worry
> you.
>
> Regards,
> Allan.
--
Joe Dalton