Re: [oc] wide crc_32 doesn't need to be slow.

[Allan Herriman <allan_herriman.hates.spam@agilent.com>]

Hi Blue,

llbutcher wrote:
> I looked into making wider CRC's run faster.
> 
> At first glance, it seems that the logic grows and grows.  So
> wider CRC's would seem to run slower due to logic depth.
> 
> But I found that the dependence on the internal CRC state does
> NOT grow more and more complicated.
> 
> What this means is that you can do a calculation based on the
> new data in, and combine it with a calculation based on the
> internal state.
> 
> The advantage of this is that you can pipeline the complicated
> calculation based on input data.  It can take more than 1 clock.
> 
> I think that one should be able to make the CRC calculation for
> any width wider than 32 bits take roughly the same time as
> a 32-bit calculation, with a pipeline depth which grows with
> the input width.  Plus lots of extra pipeline flops.

I was extrapolating the results from tests done with LFSRs.  I expected
that the results for CRCs would be the same but as you found, they are
not.  This is good news, actually.
 
> 
> As you say, it looks like a 64-bit CRC should be able to run at
> 10 GBit/sec in an FPGA.  I have no idea what IBM needs to do
> checksums on which runs substantially faster.  Curious.

We had product in the field last year (last century!) that did 10Gbit/s
CRC and LFSR.

I don't know what rates IBM are using.  Next in the SONET/SDH hierarchy
is 40Gbit/s, which sounds somewhat challenging in an FPGA.

Bye,
Allan.
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml