crc32 vhdl implementation (4 bit data)

M

Moti Cohen

Guest
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..?
Click to expand...
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.
Click to expand...
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
Click to expand...
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.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.
Click to expand...

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/ee552/studentAppNotes/1998f/ethernet/ethernet.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.
Click to expand...
--
------
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..
Click to expand...
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).
Click to expand...
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?
Click to expand...
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
Click to expand...
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?
Click to expand...
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/XCoNET/Demonstation_code.htm
http://www.bydzw.com/cpldpage/download/crc32.txt
http://www.elecdesign.com/Articles/ArticleID/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
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top