FPGA Central

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..?
Thanks in advance, Moti.

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..?

Howdy Moti,

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.

Good luck,

Marc

moti@terasync.net (Moti Cohen) wrote in message news:<c04bfe33.0407040651.2199a09f@posting.google. com>...
> 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..?
> Thanks in advance, Moti.

Hi,

I've developped, for my personnal needs, a crc software. I've took for
inputs : g(x)=x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7
+ x5 + x4 + x2 + x + 1
and 4 bits bus.
The results are :
-- x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7
+ x^5 + x^4 + x^2 + x^1 + 1
function fcrc(DIN : std_logic_vector(3 downto 0); CRC :
std_logic_vector(31 downto 0))
return std_logic_vector is
variable RESUL : std_logic_vector(31 downto 0);
begin
RESUL( 0):=CRC(28) xor DIN(0);
RESUL( 1):=CRC(28) xor CRC(29) xor DIN(0) xor DIN(1);
RESUL( 2):=CRC(28) xor CRC(29) xor CRC(30) xor DIN(0) xor DIN(1)
xor DIN(2);
RESUL( 3):=CRC(29) xor CRC(30) xor CRC(31) xor DIN(1) xor DIN(2)
xor DIN(3);
RESUL( 4):=CRC(0) xor CRC(28) xor CRC(30) xor CRC(31) xor DIN(0)
xor DIN(2) xor DIN(3);
RESUL( 5):=CRC(1) xor CRC(28) xor CRC(29) xor CRC(31) xor DIN(0)
xor DIN(1) xor DIN(3);
RESUL( 6):=CRC(2) xor CRC(29) xor CRC(30) xor DIN(1) xor DIN(2);
RESUL( 7):=CRC(3) xor CRC(28) xor CRC(30) xor CRC(31) xor DIN(0)
xor DIN(2) xor DIN(3);
RESUL( 8):=CRC(4) xor CRC(28) xor CRC(29) xor CRC(31) xor DIN(0)
xor DIN(1) xor DIN(3);
RESUL( 9):=CRC(5) xor CRC(29) xor CRC(30) xor DIN(1) xor DIN(2);
RESUL(10):=CRC(6) xor CRC(28) xor CRC(30) xor CRC(31) xor DIN(0)
xor DIN(2) xor DIN(3);
RESUL(11):=CRC(7) xor CRC(28) xor CRC(29) xor CRC(31) xor DIN(0)
xor DIN(1) xor DIN(3);
RESUL(12):=CRC(8) xor CRC(28) xor CRC(29) xor CRC(30) xor DIN(0)
xor DIN(1) xor DIN(2);
RESUL(13):=CRC(9) xor CRC(29) xor CRC(30) xor CRC(31) xor DIN(1)
xor DIN(2) xor DIN(3);
RESUL(14):=CRC(10) xor CRC(30) xor CRC(31) xor DIN(2) xor DIN(3);
RESUL(15):=CRC(11) xor CRC(31) xor DIN(3);
RESUL(16):=CRC(12) xor CRC(28) xor DIN(0);
RESUL(17):=CRC(13) xor CRC(29) xor DIN(1);
RESUL(18):=CRC(14) xor CRC(30) xor DIN(2);
RESUL(19):=CRC(15) xor CRC(31) xor DIN(3);
RESUL(20):=CRC(16);
RESUL(21):=CRC(17);
RESUL(22):=CRC(18) xor CRC(28) xor DIN(0);
RESUL(23):=CRC(19) xor CRC(28) xor CRC(29) xor DIN(0) xor DIN(1);
RESUL(24):=CRC(20) xor CRC(29) xor CRC(30) xor DIN(1) xor DIN(2);
RESUL(25):=CRC(21) xor CRC(30) xor CRC(31) xor DIN(2) xor DIN(3);
RESUL(26):=CRC(22) xor CRC(28) xor CRC(31) xor DIN(0) xor DIN(3);
RESUL(27):=CRC(23) xor CRC(29) xor DIN(1);
RESUL(28):=CRC(24) xor CRC(30) xor DIN(2);
RESUL(29):=CRC(25) xor CRC(31) xor DIN(3);
RESUL(30):=CRC(26);
RESUL(31):=CRC(27);
return RESUL;
end fcrc;
Tell me (in the news group) if it's ok.

Marc Randolph <mrand@my-deja.com> wrote in message news:<u4ednTCBZ4B5q3XdRVn-vA@comcast.com>...
> 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..?
>
> Howdy Moti,
>
> 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.
>
> Good luck,
>
> Marc

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

"Moti Cohen" <moti@terasync.net> wrote in message
news:c04bfe33.0407040651.2199a09f@posting.google.c om...
> 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..?
> Thanks in advance, Moti.


Hi Moti,

I have done a CRC32 with 16bit parallel input using easics and it took me
loads of time to figure out that it was working perfectly from the
beginning.!
Speaking with more people, I found out that most of them had similar
problems verifying the outcome.

My advice is to sit down and find a methodical way to test it.

http://rcswww.urz.tu-dresden.de/~sr21/crc.html
using this calculator and putting the settings
CRC order (1..64) : 32

CRC polynom (hex) :4C11DB7

Initial value (hex) :FFFFFFFF

Final XOR value (hex) : 0

direct : checked

and the rest of options: unchecked

worked for me at least.

Check this link too, it has one more crc_gen, (I haven't used it myself
though).

http://www.ee.ualberta.ca/~elliott/e...rnet.html#vhdl

Did you use the correct reset value for the CRC (usaly 0xFFFFFFFF)?
I thing that the checksum that is included in the Ethernet packet is the
complement of thr CRC result, i.e. checksum = not CRC.

/Patrik

st wrote:
> moti@terasync.net (Moti Cohen) wrote in message news:<c04bfe33.0407040651.2199a09f@posting.google. com>...
>
>>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..?
>>Thanks in advance, Moti.
>
>
> Hi,
>
> I've developped, for my personnal needs, a crc software. I've took for
> inputs : g(x)=x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7
> + x5 + x4 + x2 + x + 1
> and 4 bits bus.
> The results are :
> -- x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7
> + x^5 + x^4 + x^2 + x^1 + 1
> function fcrc(DIN : std_logic_vector(3 downto 0); CRC :
> std_logic_vector(31 downto 0))
> return std_logic_vector is
> variable RESUL : std_logic_vector(31 downto 0);
> begin
> RESUL( 0):=CRC(28) xor DIN(0);
> RESUL( 1):=CRC(28) xor CRC(29) xor DIN(0) xor DIN(1);
> RESUL( 2):=CRC(28) xor CRC(29) xor CRC(30) xor DIN(0) xor DIN(1)
> xor DIN(2);
> RESUL( 3):=CRC(29) xor CRC(30) xor CRC(31) xor DIN(1) xor DIN(2)
> xor DIN(3);
> RESUL( 4):=CRC(0) xor CRC(28) xor CRC(30) xor CRC(31) xor DIN(0)
> xor DIN(2) xor DIN(3);
> RESUL( 5):=CRC(1) xor CRC(28) xor CRC(29) xor CRC(31) xor DIN(0)
> xor DIN(1) xor DIN(3);
> RESUL( 6):=CRC(2) xor CRC(29) xor CRC(30) xor DIN(1) xor DIN(2);
> RESUL( 7):=CRC(3) xor CRC(28) xor CRC(30) xor CRC(31) xor DIN(0)
> xor DIN(2) xor DIN(3);
> RESUL( 8):=CRC(4) xor CRC(28) xor CRC(29) xor CRC(31) xor DIN(0)
> xor DIN(1) xor DIN(3);
> RESUL( 9):=CRC(5) xor CRC(29) xor CRC(30) xor DIN(1) xor DIN(2);
> RESUL(10):=CRC(6) xor CRC(28) xor CRC(30) xor CRC(31) xor DIN(0)
> xor DIN(2) xor DIN(3);
> RESUL(11):=CRC(7) xor CRC(28) xor CRC(29) xor CRC(31) xor DIN(0)
> xor DIN(1) xor DIN(3);
> RESUL(12):=CRC(8) xor CRC(28) xor CRC(29) xor CRC(30) xor DIN(0)
> xor DIN(1) xor DIN(2);
> RESUL(13):=CRC(9) xor CRC(29) xor CRC(30) xor CRC(31) xor DIN(1)
> xor DIN(2) xor DIN(3);
> RESUL(14):=CRC(10) xor CRC(30) xor CRC(31) xor DIN(2) xor DIN(3);
> RESUL(15):=CRC(11) xor CRC(31) xor DIN(3);
> RESUL(16):=CRC(12) xor CRC(28) xor DIN(0);
> RESUL(17):=CRC(13) xor CRC(29) xor DIN(1);
> RESUL(18):=CRC(14) xor CRC(30) xor DIN(2);
> RESUL(19):=CRC(15) xor CRC(31) xor DIN(3);
> RESUL(20):=CRC(16);
> RESUL(21):=CRC(17);
> RESUL(22):=CRC(18) xor CRC(28) xor DIN(0);
> RESUL(23):=CRC(19) xor CRC(28) xor CRC(29) xor DIN(0) xor DIN(1);
> RESUL(24):=CRC(20) xor CRC(29) xor CRC(30) xor DIN(1) xor DIN(2);
> RESUL(25):=CRC(21) xor CRC(30) xor CRC(31) xor DIN(2) xor DIN(3);
> RESUL(26):=CRC(22) xor CRC(28) xor CRC(31) xor DIN(0) xor DIN(3);
> RESUL(27):=CRC(23) xor CRC(29) xor DIN(1);
> RESUL(28):=CRC(24) xor CRC(30) xor DIN(2);
> RESUL(29):=CRC(25) xor CRC(31) xor DIN(3);
> RESUL(30):=CRC(26);
> RESUL(31):=CRC(27);
> return RESUL;
> end fcrc;
> Tell me (in the news group) if it's ok.

--
------
Patrik Eriksson

Moti Cohen wrote:

> Marc Randolph <mrand@my-deja.com> wrote in message news:<u4ednTCBZ4B5q3XdRVn-vA@comcast.com>...
>
>>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

> 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).

Is this magic number (residual) given by all CRCs?
I have experienced that the USB CRC5/CRC16 have residuals which are
for all correct calculations the same. But what about other CRCs?

Rgds

ALuPin@web.de (ALuPin) wrote in message news:<b8a9a7b0.0407052258.6f1be41f@posting.google. com>...
> > 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).
>
> Is this magic number (residual) given by all CRCs?
> I have experienced that the USB CRC5/CRC16 have residuals which are
> for all correct calculations the same. But what about other CRCs?

Yes, all CRC's produce a residual - it is a function of the following items:

* The CRC polynomial being used (CRC-16 vs. CRC-CCITT vs. CRC-32, etc)
* The initial value (sometimes all 1's, but not always)
* Bit and byte ordering (application dependant)
* Bit inversion (application dependant: sometimes XOR with all 1's)


Have fun,

Marc

> Yes, all CRC's produce a residual - it is a function of the following items:
>
> * The CRC polynomial being used (CRC-16 vs. CRC-CCITT vs. CRC-32, etc)
> * The initial value (sometimes all 1's, but not always)
> * Bit and byte ordering (application dependant)
> * Bit inversion (application dependant: sometimes XOR with all 1's)
>
>
> Have fun,
>
> Marc

Hi Marc,

thank you for your answer.

I want to use a CRC16 with the polynomial 0XBAAD (paper "Cyclic
Redendany Code
Poynomial Selection for Embedded Networks" Philip Koopman).

But when I simulate it (VHDL code generated by CRC TOOL) and
initialize it with '1's than I do not get a residual when trying
different data to calculate.
So maybe there has to be used a different initial value. But how do I
get to know
which one to use as initial value?

Kind regards

ALuPin wrote:
>>Yes, all CRC's produce a residual - it is a function of the following items:
>>
>>* The CRC polynomial being used (CRC-16 vs. CRC-CCITT vs. CRC-32, etc)
>>* The initial value (sometimes all 1's, but not always)
>>* Bit and byte ordering (application dependant)
>>* Bit inversion (application dependant: sometimes XOR with all 1's)
>>
>>
>
> thank you for your answer.
>
> I want to use a CRC16 with the polynomial 0XBAAD (paper "Cyclic
> Redendany Code
> Poynomial Selection for Embedded Networks" Philip Koopman).
>
> But when I simulate it (VHDL code generated by CRC TOOL) and
> initialize it with '1's than I do not get a residual when trying
> different data to calculate.
> So maybe there has to be used a different initial value. But how do I
> get to know which one to use as initial value?

We're pretty far off topic here, but I'll give it one last stab while
presenting some links that might be useful for the FPGA crowd... I found
a neat tool on the web:

http://rcswww.urz.tu-dresden.de/~sr21/crc.html

which lets you play with various things. You might be able to feed your
simulated data into this tool and see if things match up. Using this
tool, I was able to get the residual (MAGIC NUMBER) by clicking
"nondirect" then clicking "Convert"... The initial value field will
turn into the residual (or bit flipped residue, depending on the CRC
implementation).

IE, for CRC-32, clicking nondirect and convert results in C704DD7B and
CRC-CCITT results in 1D0F. Using the same procedure for Koopman's new
polynomial 0xBAAD results in a possible residue of 3BE9 when calculated
in the same way a CRC-CCITT (initial value of FFFF with no bit flipping
or reversing).

Various links to HDL code:
http://www-ee.eng.hawaii.edu/~msmith...ation_code.htm
http://www.bydzw.com/cpldpage/download/crc32.txt
http://www.elecdesign.com/Articles/A...3961/3961.html

Lastly, make sure you are feeding the whole received data block into the
CRC checker (including the received CRC). If you can't use the tool
above to verify your values, you could use a C program.

Good luck,

Marc

Good morning
In fact, my problem sums up as follows:
I have a "word" of 512 bits (6 bytes of address of destination + 6 bytes of source address + 2 bytes of ether type + 50 bytes of data) which is the presentation of a party of a ethernet packet which is necessary for us to calculate CRC-32 which is going to end this packet.
I wanted to know if the calculation of this CRC will be able to be built byte by byte if I have an algorithm which takes a word of 8 bits in entrance and that calculates a first CRC and uses this last to calculate the following etc... up to exhaustion of the 512 bits?
Or make an algorithm which takes the word of 512 in entrance directly?

Thank you in advance