[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: CRC (was Re: [f-cpu] F-CPU architecture...)


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.



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.

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.


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 :-)


To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/