[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [oc] wide crc_32 doesn't need to be slow.
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