elektroda.net NewsGroups Forum Index - FPGA - Matching hadware and software CRC
dlopez
Guest
Guest
Thu Feb 04, 2010 1:53 pm
Hi,
There seems to be an endless numbers of way to mess up CRC calculations
Has anyone come up with the right way to match a software calculated CR
with whay comes out of either the 'easics' core or the 'outputlogic' cor
(both yielding the same result in simulation).
Here are questions:
-should I reverse or inverse the input data? What order?
-should I reverse or inverse the output data? What order?
Here is a great online tool, but I cannot match the output with the core
ever:
http://www.zorc.breitbandkatze.de/crc.html
I'm using
CRC-32: 0x04C11DB7 = x32 + x26 + x23 + x22 + x16 + x12 +
x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1
Thanks
Diego
---------------------------------------
Posted through http://www.FPGARelated.com
whygee
Guest
Guest
Thu Feb 04, 2010 1:53 pm
dlopez wrote:
Quote:
Hi,
There seems to be an endless numbers of way to mess up CRC calculations!
yes
There seems to be an endless numbers of way to mess up CRC calculations!
yes
Quote:
Has anyone come up with the right way to match a software calculated CRC
with whay comes out of either the 'easics' core or the 'outputlogic' core
(both yielding the same result in simulation).
write your own HDL code.
with whay comes out of either the 'easics' core or the 'outputlogic' core
(both yielding the same result in simulation).
write your own HDL code.
Quote:
Here are questions:
-should I reverse or inverse the input data? What order?
-should I reverse or inverse the output data? What order?
are you using a Galois or Fibonacci configuration ?
-should I reverse or inverse the input data? What order?
-should I reverse or inverse the output data? What order?
are you using a Galois or Fibonacci configuration ?
that makes 8 combinations, maybe you should try them all ?
when correctly done (automated), it does not take much time.
Quote:
I'm using
CRC-32: 0x04C11DB7 = x32 + x26 + x23 + x22 + x16 + x12 +
x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1
CRC-32: 0x04C11DB7 = x32 + x26 + x23 + x22 + x16 + x12 +
x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1
ok, CRC32 in bit-serial configuration is easy, simple and fast,
you need about 32 bits of bit-shifting storage with about 15 XOR2 (or 5 LUT4).
have you read http://www.ross.net/crc/download/crc_v3.txt ?
it is HIGHLY recommended and easy to read.
Quote:
Thanks
good luck,
good luck,
CRCs can be disturbing at first but it's not that difficult in the end.
Quote:
Diego
yg
yg
--
http://ygdes.com / http://yasep.org
glen herrmannsfeldt
Guest
Guest
Thu Feb 04, 2010 3:34 pm
dlopez <d_at_n_o_s_p_a_m.designgame.ca> wrote:
Quote:
There seems to be an endless numbers of way to mess up CRC calculations!
Has anyone come up with the right way to match a software calculated CRC
with whay comes out of either the 'easics' core or the 'outputlogic' core
(both yielding the same result in simulation).
Here are questions:
-should I reverse or inverse the input data? What order?
-should I reverse or inverse the output data? What order?
Has anyone come up with the right way to match a software calculated CRC
with whay comes out of either the 'easics' core or the 'outputlogic' core
(both yielding the same result in simulation).
Here are questions:
-should I reverse or inverse the input data? What order?
-should I reverse or inverse the output data? What order?
Initialize the shift register with what value?
When processing bytes, LSB or MSB first?
Quote:
Here is a great online tool, but I cannot match the output with the core,
ever:
http://www.zorc.breitbandkatze.de/crc.html
I'm using
CRC-32: 0x04C11DB7 = x32 + x26 + x23 + x22 + x16 + x12 +
x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1
ever:
http://www.zorc.breitbandkatze.de/crc.html
I'm using
CRC-32: 0x04C11DB7 = x32 + x26 + x23 + x22 + x16 + x12 +
x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1
I have done the ethernet CRC (CCITT CRC32) and verified that
it agreed with what it should do.
-- glen
dlopez
Guest
Guest
Fri Feb 05, 2010 8:01 pm
Quote:
I have done the ethernet CRC (CCITT CRC32) and verified that
it agreed with what it should do.
-- glen
it agreed with what it should do.
-- glen
Thanks, I actually got it to match.
-need to 'reverse' the individual bytes going in.
-need to 'inverse', then 'reverse' the CRC coming out.
-do NOT play with the internal feedback work within the CRC calculator.
However, the new problem is that I cannot feed in a data message, followe
by the known good CRC, and get 0! This used to work before I added th
above logic.
Anyone has an idea?
Diego
---------------------------------------
Posted through http://www.FPGARelated.com
Hal Murray
Guest
Guest
Sat Feb 06, 2010 11:30 am
Quote:
However, the new problem is that I cannot feed in a data message, followed
by the known good CRC, and get 0! This used to work before I added the
above logic.
by the known good CRC, and get 0! This used to work before I added the
above logic.
You aren't supposed to get 0. You get some magic constant.
--
These are my opinions, not necessarily my employer's. I hate spam.
dlopez
Guest
Guest
Sat Feb 06, 2010 3:19 pm
Quote:
However, the new problem is that I cannot feed in a data message
followed
by the known good CRC, and get 0! This used to work before I added the
above logic.
You aren't supposed to get 0. You get some magic constant.
You are absolutely right. You also need to feed in the 'what used to be th
matching CRC' in reverse BYTE order (on top of reversing the bits).
Now I'd like to understand why it doesn't give 0. This is what is mentione
in the 'painless guide to CRC error detection algorithm', line 575.
http://www.ross.net/crc/download/crc_v3.txt
''At the other end, the receiver can do one of two things:
a. Separate the message and checksum. Calculate the checksum for
the message (after appending W zeros) and compare the two
checksums.
b. Checksum the whole lot (without appending zeros) and see if it
comes out as zero!''
I thought this was a nice approach since the receiver in the FPGA onl
needs to ever compare the CRC output with 0, instead of capturing the know
CRC (32 flops) and doing a full 32 bit compare. Although now with a magi
constant it's pretty much the same.
Diego
---------------------------------------
Posted through http://www.FPGARelated.com
Krem
Guest
Guest
Mon Feb 08, 2010 11:33 am
For your information A really great tool to generate VHDL or verilog
files is here : http://www.easics.be/webtools/crctool
On Feb 6, 2:19 pm, "dlopez" <d_at_n_o_s_p_a_m.designgame.ca> wrote:
Quote:
However, the new problem is that I cannot feed in a data message,
followed
by the known good CRC, and get 0! This used to work before I added the
above logic.
You aren't supposed to get 0. You get some magic constant.
You are absolutely right. You also need to feed in the 'what used to be the
matching CRC' in reverse BYTE order (on top of reversing the bits).
Now I'd like to understand why it doesn't give 0. This is what is mentioned
in the 'painless guide to CRC error detection algorithm', line 575.http://www.ross.net/crc/download/crc_v3.txt
''At the other end, the receiver can do one of two things:
a. Separate the message and checksum. Calculate the checksum for
the message (after appending W zeros) and compare the two
checksums.
b. Checksum the whole lot (without appending zeros) and see if it
comes out as zero!''
I thought this was a nice approach since the receiver in the FPGA only
needs to ever compare the CRC output with 0, instead of capturing the known
CRC (32 flops) and doing a full 32 bit compare. Although now with a magic
constant it's pretty much the same.
Diego
---------------------------------------
Posted throughhttp://www.FPGARelated.com
followed
by the known good CRC, and get 0! This used to work before I added the
above logic.
You aren't supposed to get 0. You get some magic constant.
You are absolutely right. You also need to feed in the 'what used to be the
matching CRC' in reverse BYTE order (on top of reversing the bits).
Now I'd like to understand why it doesn't give 0. This is what is mentioned
in the 'painless guide to CRC error detection algorithm', line 575.http://www.ross.net/crc/download/crc_v3.txt
''At the other end, the receiver can do one of two things:
a. Separate the message and checksum. Calculate the checksum for
the message (after appending W zeros) and compare the two
checksums.
b. Checksum the whole lot (without appending zeros) and see if it
comes out as zero!''
I thought this was a nice approach since the receiver in the FPGA only
needs to ever compare the CRC output with 0, instead of capturing the known
CRC (32 flops) and doing a full 32 bit compare. Although now with a magic
constant it's pretty much the same.
Diego
---------------------------------------
Posted throughhttp://www.FPGARelated.com
elektroda.net NewsGroups Forum Index - FPGA - Matching hadware and software CRC
