calibration times in U320 mode

[Bruce Leshay]

* From the T10 Reflector (t10 at t10.org), posted by:
* Bruce Leshay <Bruce.Leshay at quantum.com>
*
I believe there is an issue with the timing for starting calibration, or at
least some clarification is required.

Example:  A target changes phase from DTDATA_OUT to DTDATA_IN, and needs to
do a u320 calibration.
According to SPI4R0, the target changes the phase lines (CD,IO,MSG), waits
90ns, then asserts SEL.  Then he waits
another 90ns and can begin the training pattern.

However, the training pattern requires the target to drive the data lines,
which were driven by the initiator in the previous
DTDATA_OUT phase.  SPI-3 requires that the target wait a total of 800ns
before driving these lines - 400ns for the initiator
to recognize the phase change (including bus propagation delay), and an
additional 400ns for the initiator to tri-state the lines.

Thus it seems that after asserting the SEL line, the target should wait
800ns before starting the training pattern, if the previous phase was an
"OUT" phase. (Note that in this case the initiator can begin his training
pattern immediately after
detecting SEL assertion.) The additional training pattern overhead is not
serious if people implement the recently approved "retain training" feature,
in which calibration is done once, and then the cal values retained for any
later connection between the same device ID's.

Similarly, if switching to DTDATA_OUT phase and doing calibration, the
target would drive a training pattern on both REQ and P0, and must
untristate the P0 signal.  If the initiator was driving this signal
previously the target should wait 800ns before issuing the training pattern.
An example is a simple selection followed by the DTDATA_OUT phase to receive
the first LQ header packet - the initiator is driving P0 during the
selection phase.

In this case the initiator can again begin his training pattern immediately
after detecting SEL assertion.  The initiator's
training pattern should last 2400ns, and the target's is only 800ns long, so
even with the extra 800ns of delay before
the target starts, the initiator's training pattern will finish last.  So
there isn't any additional overhead cost to the 800ns delay in that
direction

						Bruce Leshay
						Quantum Corporation
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org