[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: CRC (was Re: [f-cpu] F-CPU architecture...)
re-hi,
Michael Riepe wrote:
Hi F-gang,
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.
see http://www.geocities.com/SiliconValley/Pines/8659/crc.htm
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
easier.
Right.
[...]
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
additional flags
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
cycles ?
adding a simple "verify only" flag is enough and 2x faster (no write
cycle).
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
almost everywhere.
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.
exactly.
so if we can program DMA blocks wich are CRC32-protected with
automatic retry,
even more complex NUMA architectures (with complex Xbar network)
become possible
(imagine something like a Myrinet-enabled CPU core, or even a
T3E-like architecture).
but we have yet to find a way to "protect" 64-bit words faster than
8-bit at a time.
Yep.
Normally, SEC/DED is used for each word, which can be computed in //
and easily
pipelined (there is no word-to-word dependency). But ECC is quite
complex :-(
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
reflexions),
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 :-)
YG
*************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/