Moti Cohen wrote:

> Marc Randolph <[email protected]> wrote in message news:<[email protected]>...
>
>>Moti Cohen wrote:
>>
>>>Hy all,
>>>I'm currently implementing a receiver (vhdl) part of the ethernet mac
>>>which is responsible for the MII interafce. I'm need an crc32
>>>calculator (RTL) to check the FCS field. I've tried using the easics
>>>crctoll in order to create the mechanism (for a 4 bit data input) but
>>>it does not seems to work. does anyone have a working (rtl) vhdl
>>>implementation for this block? or at least a detailed expalnation on
>>>how to create it..?
>>
>>
>> I'd be willing to bet that your problem is bit ordering (hint: take
>>an 8 bit chunk and reverse the order of the bits before throwing it into
>>the easics checker). Although I'm sure there is probably a way, I don't
>>quickly see how you'd do it four bits at a time.
>>
>
> Hi Marc,
> Thanks for your answer so first of all I have already tried revesring
> the bits order without any success - I read something about a "magic
> number" but I'm not sure what to do with it. regarding the 4 bit data
> path - the easics "crctoll" can generate a vhdl file for 1,2,4,8...64
> bits so its not the problem..

Howdy Moti,

I probably could have been clearer on my previous post. I may be
wrong, but it is my understanding that the BYTE must be bit-reversed.
i.e., bit(0) <= bit(7), bit(4) <= bit(3), etc. If you only have four
bits, you can't very well bit reverse 0 to 7.

We have used the 8 bit, 16 bit, and 32 bit easics code and they all work
fine (after you figure out the right bit order and such).

There are two ways to verify a CRC. One is to compute the check CRC on
everything up to, but not including, the received CRC. Then do a
compare between the two CRC's. The second way is to include the
received CRC in the calculation for the check CRC. If you do this, the
result is the magic number (assuming the checker was initialized with
all 1's).

Good luck,

Marc