Revisiting the "starting paced transfers with no training pattern" requirement

Bill Galloway BillG at breatech.com
Mon Mar 18 12:08:16 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Bill Galloway" <BillG at breatech.com>
*
After reading Gerry's comments I agree with him.  I do not remember all
of the wording changes along the way but I do seem to remember that
100ns was what was intended.

This issue needs to be resolved NOW.  My preference is for 100ns.

For Gerry's first question, my hardware only requires 50ns of invalid
data before going to valid data.

For the second question I would like to keep the number of transitions
the same and halve the time. I do not believe that you can use a pll to
lock on the incoming clock.


Bill Galloway
BREA Technologies, Inc.
P: (281) 530-3063
F: (281) 988-0358
BillG at breatech.com 

-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Gerry.Houlder at seagate.com
Sent: Monday, March 18, 2002 11:13 AM
To: t10 at t10.org
Subject: Revisiting the "starting paced transfers with no training
pattern" requirement


* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
I did some research (with George Penokie's help) into the requirement
for starting paced transfers with no training pattern. This was the
wording from rev. 0 (dated 5/28/2000) of SPI-4. Particularly notice the
line preceded with >.


10.8.4.3.3  Starting pacing transfers with no training pattern

At the start of DT Data phase with no training pattern (i.e., the SEL
signal is not asserted at the start of the DT data phase) the target
shall begin pacing transfers by:

  1) The target shall begin asserting and negating the REQ signal at the
negotiated rate 400 ns, or 800 ns if the previous phase was a DT Data
Out phase, after asserting the MSG and I/O lines and negating the C/D;
  2) simultaneously with the assertion of REQ the target shall begin
asserting and negating P1 at twice the negotiated rate (e.g., 12.5 ns
for fast-160);
> 3) the target shall assert and negate P1 for at least 16 transfer 
> periods
(e.g., 100 ns at fast-160); and
  4) the target may establish a data valid state as described in
10.8.4.3.1.


Note that this wording used the term "16 transfer periods" to express
the amount of time P1 must be transitioning for. The transfer period
term only makes sense when referring to the data transfer period, which
is 6.25 ns interval for fast-160. The period (meaning leading edge to
next leading
edge) of the P1 line is actually four times that number, however. This
made the reference to "transfer period" ambiguous and the wording was
changed in rev. 1. At least note that this description seems consistent
with "100 ns worth" of P1 transitions as the required preamble.

The wording changed in rev. 1 (dated 10/05/2000) to read as shown below.
This is substantially the same wording as SPI-4 rev. 9. Again notice the
line preceded by >.

10.8.4.3.3  Starting pacing transfers with no training pattern

Before starting the DT DATA IN phase the target shall wait at least two
deskew delays after the SEL signal is negated before the first assertion
of the REQ signal.

The DT DATA IN phase without training starts on the first assertion of
the REQ signal.

The target shall begin paced transfers only after meeting all of the
following:
a) signal restrictions between information transfer phases listed in
10.13;
b) the signal restrictions between a RESELECTION phase and a DT DATA IN
phase listed in 10.7.2;
    or
c) the signal restrictions between a SELECTION phase and a DT DATA OUT
phase listed in 10.6.3.

The target shall begin pacing transfers by:
  1) simultaneously with the assertion of REQ the target shall begin
asserting and negating P1 at twice the negotiated transfer period (e.g.,
12.5 ns for fast-160);
> 2) the target shall assert and negate P1 at least  8 times (e.g., (2 x
6.25) x 8 = 100 ns at fast-160); and
  3) the target may establish a data valid state as described in
10.8.4.3.1.


Note that the description in 1) talks about asserting and negation P1 at
twice the negotiated transfer period. The quoted time for fast-160 (12.5
ns) is the time from a leading edge to a trailing edge transition of P1
for fast-160, or half of the period for P1. This provides background to
suggest that the "assert and negate 8 times" statement was intended by
the writer to indicate 4 assertions and 4 negations and the 100 ns time
correctly indicated the period of time for this.

All this brings into question the decision made at the Parallel SCSI
Working Group on document 02-114. During the working group I was
informed the wording had to be fixed by increasing the time to 200 ns
instead of decreasing the number of "asserts and negates". I now believe
this was the wrong historical interpretation and the original intent was
more correctly described by the 100 ns, not the number of transitions.

I would like everyone to review their implementations to see if 4
periods (i.e. cycles, 100 ns elapsed time at fast-160) of P1 is adequate
to get proper frequency lock. If everyone believe this is long enough, I
would like to see the requirement put back to 100 ns and the committee
should declare this to be the correct "editorial fix" at the next
Parallel SCSI Working Group meeting. We should also consider changing
line 1) to read (changes in <> ):

  1) simultaneously with the assertion of REQ the target shall begin
asserting and negating P1 at <four times> the negotiated transfer period
(e.g., <25 ns period for P1> for fast-160);

A second issue that we need to address for SPI-5. Should the P1 preamble
time be specified in terms of number of transitions or in terms of time?
We recently decided that sections of the training pattern should be
based on time interval, not number of transitions. Should this also be
true for the P1 preamble, or should it be just a number of transitions
(which would be normal for a PLL trying to acquire a frequency? This
affects whether the time for this interval can be reduced for SPI-5. I
ask everyone to state their preference for this at the next Parallel
Working Group meeting as well.



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

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




More information about the T10 mailing list