SPI Tolerance

[Bob Snively]

Folks,

Unfortunately, Bill Galloway is probably correct in saying that
there should be a change to SPI.

The generation of proper REQ pulses is not the problem.  It is
the management of the received data that is the problem.  Bill
found a machine that apparently does not have any spare cycles
in its data reception process, so that it was possible to
accumulate tolerance to the point where data was lost.  This
is very rare and is a "not good" design.

The guarantee should be that a device will not transmit
REQs with a period less than the specified period.  What SPI
is missing is a requirement that machines will operate correctly
with REQs or data received with a period that can be less than
the agreed to period by a timing tolerance.  Since the target
and initiator have separate internal clocking standards, it is
practically impossible for them to agree on how long 100 nsecs
really is.  Whichever machine is receiving the REQs or data
should be tolerant of variations of the clocking standards within
the normal variation of available clocking standards, say up to
0.05% fast relative to the negotiated speed.  That way, two machines
that both agree on a 100 nsec period will be able to interoperate
in a real world where tachyons may not add up to precisely 100 nsec.

That still makes a machine that generates a period of 99.776 nsec
non-compliant, but at least it allows a machine that cannot
track time closer than +/- 250 ppm to be tolerant of a machine that
does its best (using non-atomic clocks) to generate a 
real period of 100 nsec.



Robert Snively
Sun Microsystems Computer Corporation
Mail Stop UMTV15-46
2550 Garcia Avenue
Mountain View
California 94043-1100

Phone:		(415) 336-5332
FAX:		(415) 336-3392
e-mail:		bob.snively at Eng.sun.com