SPI-2 Timing Tolerance

[Tak Asami]

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Tak Asami <asami at itc.adaptec.com>
*
Gentlemen:

Attached below is the message I sent out several weeks ago about timing
tolerance specification (Clause 9, Table 41 of SPI-2 draft rev 15).
I sent out the message in the hope of sparking some discusssion, but I
got a whopping two or three respondents and debate stopped very quickly.

November meeting is only a few weeks away (time flies), so I am re-posting
the message along with my proposal here in preparation to discuss the
subject in SPI-2 Workgroup meeting (probably Monday PM).

If you are not familiar with the topic, please read the attached message
below first.

The point is, for Ultra-2 and beyond implementations, it should not be
necessary to stick to 0.5/0.25% accuracy, due to already-resolved 
implementation issues.

So here is my proposal.
Since my proposal governs the negotiated synchronous transfer rate timings,
I propose:

1) Remove "Transmit Period Tolerance" and "Receive Period Tolerance" 
   from the Table 41 and move the subject to Clause 11.5.2.12 "Synchronous
   Data Transfer Request".
2) Delete reference to "Receive Period Tolerance", for it deals with 
   internal implementation of the receiver device and does not belong
   to a standard.
3) Change the transmitter timing accuracy for Fast-40 and beyond to be
   10% (peak jitter, edge-to-edge).
   This means that for 40.0MXfr/sec Ultra-2, the minimum cycle time 
   between REQ-REQ or ACK-ACK is 25nsec x 0.9 = 22.5nsec.

NOTE: currently, there is no scientific basis for 10% figure. I just 
   introduced an arbitrary large number, and suggesting today's imple-
   mentations easily tolerates even that. I am actually happy with a
   number as low as 1%, but we do not need to tighten the specification
   when it is not needed to insure interoperability.
   I welcome any reasonable counter-proposal.

This enables the usage of monolithic PLL basec frequency synthesizer,
which can keep the cost of implementing high end SCSI devices low.


Tak Asami =============================================================
Adaptec / ITC
P.O. Box 57020, Irvine, CA 92619-7020
(714) 455-8202 / Fax: (714) 455-8102
asami at itc.adaptec.com


--------------------- Attachment Below -----------------------------------

>From t10-owner at Symbios.COM Thu Sep  4 18:47:56 1997
To: t10 at Symbios.COM
Subject: More SPI-2 comment...
Sender: owner-t10 at Symbios.COM
Content-Length: 3500
X-Lines: 74

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Tak Asami <asami at itc.adaptec.com>
*
Now that SPI-2 rev 14 is out and meeting is coming up next week (which 
means it is already too late), but while discussion is hot on 
capacitance balance, allow me to regorgitate on what I think is an
over-specified (and difficult to meet) parameter.

On Page 94, Table 41 lists "Receive Period Tolerance" and "Transmit 
Period Tolerance".
They specifies the required accuracy of the clock frequency for receiver
and transmitter circuit.  Basically, when a certain synchronous speed is
negotiated between an initiator and a target, any instantaneous cycle
time between each transfer should stay within the "transmit tolerance"
and receiver should tolerate up to "receive tolerance" range.

Current document specify 0.5% for receiver tolerance and 0.25% for 
transmitter tolerance.  This is fine for up to Fast-20 speed, where
most implementations are using crystal clock references.

Now enter Fast-40 and beyond. Including ours, a few implementations
I am aware of utilize PLL to synthesize required frequencies.
I expect more if we go Fast-40 and beyond.  Thing about PLL are, that
they are very accurate and stable over a long period of time.  But on
a cycle by cycle basis, you would expect jitters.
This is a nature of the circuit and there is no two ways about it.

Generally, if you need to keep the peak jitter to less than 1nsec, 
you will need a special process and/or precision component, therefore
higher silicon and/or integration cost.

If you use such clock source to generate the timing signals, they 
obviously contains that much jitter.
Now, for Fast-40, a transfer cycle is 25nsec.  0.25% of that is 62.5
psec.  So it will be expensive to implement to meet this spec.

The point is, though, for most, if not all, implementations at Ultra
SCSI and beyond products, this tight tolerance is absolutely unnecessary.
Including ours, these high-end SCSI implementations can tolerate 
receiving signals as much as 50% faster than negotiated.
So if the incoming signal had several percent of jitter in it, these
devices won't feel a thing and I presume future products remain that
way.
Another way of saying this is, that if your design has to tolerate 0.25%,
then it'll tolerate several percent higher frequency as well, because you 
will use extra clock edges to absorb those jitters.

I rather see something in the order of 1nsec for Fast-40 and beyond 
transmission tolerance, and require receiver to tolerate significantly 
higher percentage, in order to enable lower cost implementations
that works anyway.

This is not an official proposal (as I said, it is already too late for
that for the upcoming meeting), but I'd like interested people to think
about it.

Now above assumption is not true with many low-end products and legacy 
devices, some of which will not tolerate sub-PPM drift from 5MHz or 10MHz
transfer rate they were designed for.
So I favor keeping the existing specification for 0.25% and 0.5% for
all speed up to Fast-20.
I'd like this relaxation (actually tightening for receiver) incorporated
for Fast-40 and beyond.

Please think about it.

Tak Asami ===============================================================
Adaptec / ITC
P.O. Box 57020  Irvine, CA 92619-7020
(714) 455-8202 / Fax: (714) 455-8102
asami at itc.apdatec.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com