dlopez wrote:
> Hi,
> There seems to be an endless numbers of way to mess up CRC calculations!
yes :-)

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

> 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 ? :-D
that makes 8 combinations, maybe you should try them all ?
when correctly done (automated), it does not take much time.

> I'm using
> 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.

> Thanks
good luck,
CRCs can be disturbing at first but it's not that difficult in the end.

> Diego
yg
-- 
http://ygdes.com / http://yasep.org

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

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

dlopez <d@n_o_s_p_a_m.designgame.ca>
wrote:

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

Initialize the shift register with what value?
When processing bytes, LSB or MSB first?
 
> 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

I have done the ethernet CRC (CCITT CRC32) and verified that 
it agreed with what it should do.

-- glen

>I have done the ethernet CRC (CCITT CRC32)
and verified that 
>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, followedby the known good CRC, and get 0! This used to work before I added theabove logic.  

Anyone has an idea?

Diego	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

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


-- 
These are my opinions, not necessarily my employer's.  I hate spam.

>
>>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 thematching 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 mentionedin 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 onlyneeds to ever compare the CRC output with 0, instead of capturing the knownCRC (32 flops) and doing a full 32 bit compare. Although now with a magicconstant it's pretty much the same.

Diego	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

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=A0pm, "dlopez" <d@n_o_s_p_a_m.designgame.ca> wrote:
> >>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. =A0
>
> >You aren't supposed to get 0. =A0You get some magic constant.
>
> You are absolutely right. You also need to feed in the 'what used to be t=
he
> 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 mention=
ed
> 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:
> =A0 =A0a. Separate the message and checksum. Calculate the checksum for
> =A0 =A0 =A0 the message (after appending W zeros) and compare the two
> =A0 =A0 =A0 checksums.
> =A0 =A0b. Checksum the whole lot (without appending zeros) and see if it
> =A0 =A0 =A0 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 kno=
wn
> CRC (32 flops) and doing a full 32 bit compare. Although now with a magic
> constant it's pretty much the same.
>
> Diego =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com