[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: CRC (was Re: [f-cpu] F-CPU architecture...)
Michael Riepe wrote:
Yann Guidon wrote:
Well, there is a general formula.
But many variations, beyond the basic issue of the Poly.
direct/reversed ? bit-reversed poly ? Init value ? final XOR ?
Most of these can be done in software with little overhead.
not the "reverse" or "reflected" things.
But that would require that the crc is computed bitwise, which would
take too long.
well, in the case the poly is provided by the user.
That 's what I assumed for a _generic_ crc.
if the poly and all the parameters are hardwired, then it is much
However, putting a CRC32 in the "DMA/blitter engine" would be way cool
(that would require a 32-bit field in the block descriptor with
like "set/verify"; "irq on error", "valid/invalid CRC" etc.)
You mean, one could DMA some data to /dev/null
if data is to be read only, why "write" them and consume useless
adding a simple "verify only" flag is enough and 2x faster (no write
That's what I meant: just read the data and throw it away.
that is : "only read".
the most usual CRC32 implementation is the Ethernet one, it is used
Is it the same as adler32?
huhh .... no sé.
as google :-)
I/O bus transfers should always include a checksum for verification
anyway. But on the other hand, that need not be a programmable CRC,
which makes its implementation a lot easier.
so if we can program DMA blocks wich are CRC32-protected with
even more complex NUMA architectures (with complex Xbar network)
(imagine something like a Myrinet-enabled CPU core, or even a
but we have yet to find a way to "protect" 64-bit words faster than
8-bit at a time.
Normally, SEC/DED is used for each word, which can be computed in //
pipelined (there is no word-to-word dependency). But ECC is quite
I wouldn't use ECC on a medium that is meant to be lossless.
With today's technologies, don't expect lossless behaviour :-P
there are so many troubles with unmatched tracks (leading to ringing and
capacitive coupling and even cosmic rays that errors (even only
spurious) are expected.
i really wonder how it is possible to compute or check the syndrome
in one cycle.
Depends on the cycle, I guess ;-)
hmmm i prefer to believe what Kim said :-)
To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/