ethernet checksum nightmare

Discussion in 'VHDL' started by axr0284, Dec 28, 2006.

  1. axr0284

    axr0284 Guest

    Hi,
    I have been fighting with this for some time now and I cannot figure
    it out. I have read the 802.3 information and I have read a lot of
    forums and they all have some kind of general answer.

    I am trying to create a very simple MAC module that will send data to a

    PHY for transmission. I am currently using the aesic crc VHDL function
    to perform my CRC checks.


    Let's say I want to send the following packet (I know this is not a
    correct ethernet packet. Bear with me):
    00 00 12 33 FF FF (in bytes) The bytes will be sent with the left most
    byte first.


    0000 0000 0000 0000 0001 0010 0011 0011 1111 1111 (in bits)


    I would first switch the bits in each byte individually and then feed
    it to the CRC module which has been initialized with all 1s.


    Therefore


    0000 0000 0000 0000 1000 0100 1100 1100 1111 1111


    is fed into the CRC module starting with the byte on the left most
    side.


    Hopefully this is correct so far.


    After the last byte is fed through, I will grab the output of the CRC
    module, Invert it and shift it's bits.


    The output from the CRC is


    7E 11 64 34 ( in bytes)


    0111 1110 0001 0001 0110 0100 0011 0100 ( in bits)


    After inverting


    1000 0001 1110 1110 1001 1011 1100 1011 ( in bits)


    After switching


    1101 0011 1101 1001 0111 0111 1000 0001 ( in bits)


    D3 D9 77 81 ( in bytes)


    This means that my packet that I will send to the PHY will be start
    with the left most byte


    00 00 12 33 FF FF D3 D9 77 81 ( in bytes)


    This value seems to agree with some CRC32 software I found on the net.


    **************************************************


    NOW lets say i am receiving this data from the PHY.


    00 00 12 33 FF FF D3 D9 77 81 ( in bytes)


    I do the same as for sending, I switch the bits in each byte (including

    the FCS) and feed it to the CRC module which has been initialized to
    all 1. After sending the right most byte, I should get the magic number

    C7 04 DD 7B out which says that it is working but i don't. Below is the

    exact sequence of CRC output:


    Previous CRC Value | Input | Next CRC Value | Next FCS Value
    FFFFFF | 00 | 4E08BFB4 |
    D202EF8D
    4E08BFB4 | 00 | 00B7647D | 41D912FF
    00B7647D | 12 | A5EAE0CF | 0CF8A85A
    A5EAE0CF | 33 | 648CF998 | E660CED9
    648CF998 | FF | 82AF68FF | 00E90ABE
    82AF68FF | FF | 7E116434 | D3D97781
    7E116434 | D3 | BB9FD215 | 57B40622
    BB9FD215 | D9 | 07F1A3E0 | F83A701F
    07F1A3E0 | 77 | 16C33676 | 91933c97
    16C33676 | 81 | F86C1D9B | 2647C9E0


    The VHDL code I used is below:
    process(clk)
    begin
    if(clk'event and clk = '1') then
    crc_32_out <= nextCRC32_D8(input0(0) & input0(1) & input0(2) &
    input0(3) & input0(4) & input0(5) & input0(6) & input0(7), input1);


    for i in 31 downto 0 loop
    crc_32_final(i) <= NOT crc_32_out(31-i);
    end loop;
    end if;


    end process;


    My biggest issue is not getting the magic number after running the
    packet + CRC through the CRC module. I am at a lost here. I know this
    is a lot of information but i hope
    somebody can help me out. I guess this will also help anybody that
    researches this topic after me. Thanks a lot,
    Amish
     
    axr0284, Dec 28, 2006
    #1
    1. Advertising

  2. axr0284 wrote:

    > My biggest issue is not getting the magic number after running the
    > packet + CRC through the CRC module. I am at a lost here. I know this
    > is a lot of information but i hope


    There are many ways to get this wrong,
    and most have been discussed here:
    http://groups.google.com/groups/search?q=treseler crc 32

    -- Mike Treseler
     
    Mike Treseler, Dec 28, 2006
    #2
    1. Advertising

  3. axr0284

    axr0284 Guest

    I read through it and I still could not figure it out correctly but I
    think i got it right this time:

    So if I send 00 00 12 33 FF FF to the PHY from the FPGA,
    this is what is sent on the WIRE from the PHY

    00 00 84 CC FF FF

    lsb first for each byte

    So I feed the original data "00 00 12 33 FF FF" as is through the
    EASICS module with initialization of all 1, I get the <RESIDUE>
    AA C5 98 B0

    Now it clearly states in the 802.3 specs that "The bit sequence is
    complemented and the result is the CRC"

    So I need to complement the <RESIDUE> to get the <CRC> : 55 3A 67 4F

    Then I need to send it MSB first since the 802.3 spec says

    "The 32 bits of the CRC value are placed in the frame check sequence
    field so that the x31 term is the leftmost bit of the first octet,
    and the x0 term is the right most bit of the last octet.
    (The bits of the CRC are thus """transmitted""" in the order x31,
    x30..., x1, x0.)"

    So I need to switch the bits in each byte before appending to the
    Packet
    Therefore the <CRC> becomes the <FCS>
    AA 5C E6 F2

    So the full packet is
    00 00 12 33 FF FF AA 5C E5 F2

    but what is sent on the wire is
    00 00 84 CC FF 55 3A 67 4F
    since it is lsb first

    On receiving , I guess i need to flip the CRC back to 55 3A 67 4F
    before feeding it into the EASICS module to get the magic number.

    I hope I got it right this time. This took a while.
    I think i will just recompute the packet and compare the incoming FCS
    with that. It might be easier. Thanks
    Amish
     
    axr0284, Dec 29, 2006
    #3
  4. "axr0284" <> writes:

    > I read through it and I still could not figure it out correctly but I
    > think i got it right this time:
    >
    > So if I send 00 00 12 33 FF FF to the PHY from the FPGA,
    > this is what is sent on the WIRE from the PHY
    >
    > 00 00 84 CC FF FF
    >
    > lsb first for each byte
    >
    > So I feed the original data "00 00 12 33 FF FF" as is through the
    > EASICS module with initialization of all 1, I get the <RESIDUE>
    > AA C5 98 B0
    >
    > Now it clearly states in the 802.3 specs that "The bit sequence is
    > complemented and the result is the CRC"
    >
    > So I need to complement the <RESIDUE> to get the <CRC> : 55 3A 67 4F
    >
    > Then I need to send it MSB first since the 802.3 spec says
    >
    > "The 32 bits of the CRC value are placed in the frame check sequence
    > field so that the x31 term is the leftmost bit of the first octet,
    > and the x0 term is the right most bit of the last octet.
    > (The bits of the CRC are thus """transmitted""" in the order x31,
    > x30..., x1, x0.)"
    >
    > So I need to switch the bits in each byte before appending to the
    > Packet
    > Therefore the <CRC> becomes the <FCS>
    > AA 5C E6 F2
    >
    > So the full packet is
    > 00 00 12 33 FF FF AA 5C E5 F2
    >
    > but what is sent on the wire is
    > 00 00 84 CC FF 55 3A 67 4F
    > since it is lsb first
    >
    > On receiving , I guess i need to flip the CRC back to 55 3A 67 4F
    > before feeding it into the EASICS module to get the magic number.


    No don't do that. You need exactly one flipping to get the magic
    number (well, any odd number of bit inversions will do...)


    Kai
    --
    Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>
     
    Kai Harrekilde-Petersen, Dec 29, 2006
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michael Nicklas

    Ethernet MAC core

    Michael Nicklas, Nov 12, 2003, in forum: VHDL
    Replies:
    2
    Views:
    3,819
    Allan Herriman
    Nov 13, 2003
  2. Replies:
    1
    Views:
    1,599
    Mike Treseler
    Sep 20, 2005
  3. Replies:
    0
    Views:
    598
  4. Arun

    Ethernet Controller

    Arun, Apr 10, 2006, in forum: VHDL
    Replies:
    0
    Views:
    665
  5. Merk

    ethernet address

    Merk, Aug 27, 2004, in forum: C++
    Replies:
    2
    Views:
    371
    Jerry Coffin
    Aug 27, 2004
Loading...

Share This Page