Response to SPI-4 proposal 01-251

Leshay, Bruce Bruce_Leshay at maxtor.com
Fri Aug 31 05:51:08 PDT 2001


* From the T10 Reflector (t10 at t10.org), posted by:
* "Leshay, Bruce" <Bruce_Leshay at maxtor.com>
*
First, I wonder if this an academic discussion, or is there really a target
that asserts REQ in DT, and then waits for the assertion of ACK before
deasserting REQ?  John - sinces its your proposal originally - has this
deadlock actually been observed?

However, it does seem to me that:

1. There is no requirement in the spec that the target must continue to
issue REQs up to the maximum offset.  In fact it is clear in the spec that
the target may pause its REQ at any time for any length of time.  So in DT
mode a target asserting REQ and then pausing is clearly OK.  The question is
"must the target eventually deassert REQ (in DT mode), even if the initiator
never responds to the REQ assertion?".  That is not required anywhere in
SPI-3 or SPI-4.

2. The spec does state that in DT phase "the REQ/ACK offset specifies the
maximum number of REQ transitions that shall be sent by the target in
advance of the number of ACK transitions received from the initiator", where
a transition is defined as either an asserting or negating edge. There is no
mention I could find of requiring transitions to occur in pairs, although
the total number at the end of the transfer must be even. In DT mode, an odd
negotiated offset is legal, and if negotiated, the target would have to
pause with REQ asserted when it reached max offset, and then wait for the
first assertion of ACK.  This was expressly changed in paced transfers,
where the offset refers to the transfer of a 32 bit value.

It seems to me that an initiator which only counts negating edges in DT is
making an assumption about target behavior that is not required in the spec.
The spec says that each transition contributes to the offset, not just
negations.  You may ask "why would a target ever assert REQ and then wait
for an ACK before deasserting?", but that's not the point - in DT mode each
edge is independent and analogous to an asserting edge in ST mode. In ST
mode, the initiator must eventually ACK every REQ received, since it has no
idea what the total number is, and each REQ might be the last one. This
isn't explicitly stated in the spec (at least I couldn't find it), but it
has to be true or ST transfers would break. By analogy, I'd argue that the
same behavior should be expected of the initiator in DT mode.  The initiator
must reduce the offset to 0.

I think I can invent a scenario - say a target is designed with a 16 bit
datapath throughout, and sends an odd number of REQs, then discovers that it
has emptied its FIFO, and so pauses with REQ asserted.  Then an internal
error occurs in the target (say parity error on some internal RAM) such that
it will never get any more data into its FIFO.  It could deassert REQ, wait
for offset to go to 0, then switch to MSG phase and send a check condition.
Or its logic (which may originally have been designed only with ST in mind),
could reverse the order, and first wait for the offset to go to 0, then
deassert REQ, wait for ACK to be deasserted, switch phase, etc.  This may
seem implausible, but in my current implementation I know there are error
conditions where I never notify firmware of the error until after the offset
is 0, since nothing can happen until this occurs (however, my hardware
always ensures that it deasserts REQ).  Now is the resulting deadlock the
intiator's fault or the target's fault? (and the real world answer is that
if you are the only target that does this, then its your fault! - no matter
what the spec says).

								My two
cents,

								Bruce Leshay
								Maxtor
Corporation

-----Original Message-----
From: Richard Moore [mailto:richard.moore at qlogic.com]
Sent: Thursday, August 30, 2001 11:58 PM
To: 'Bill Galloway '; ''T10 Reflector' '
Subject: RE: Response to SPI-4 proposal 01-251


* From the T10 Reflector (t10 at t10.org), posted by:
* Richard Moore <richard.moore at qlogic.com>
*
Bill,

I'm not sure of the context so the meaning of "independent" in the old
SPI wording may be open to interpretation. Certainly it didn't mean
"independent" in an absolute sense, because both devices must obey the
allowed offset range. The target cannot exceed the maximum offset,
and the initiator cannot drive the offset below zero. It very well may
have been intended to mean "independent" in a timing sense; i.e.,
there is no deterministic timing relationship between a REQ and the
corresponding ACK. I might look this up tomorrow, but since the words
don't appear in SPI-3 or SPI-4 I would say this particular citation
is a moot point.

>>You could say the same thing for the initiator but it is much more of a
>>slave in the REQ/ACK handshake.

SCSI doesn't really speak of "masters" and "slaves". Yes, the target is
in the driver's seat when it comes to deciding what phase is going to
happen next (with the initiator having some ability to override this via
attention condition or reset). But at the low-level handshake level the
relationship is much more symmetrical. Once you are at one offset
extreme, the target is a "slave" to the initiator because it cannot REQ
until it sees another ACK. At the opposite extreme, the initiator is the
"slave" because it cannot ACK what hasn't been REQed. In between these
extremes both may send REQs or ACKs at any time, but nothing is specified
as to when a target *must* REQ or when an initiator *must* ACK.

Furthermore, in DT mode, REQ edges (and ACK edges) must occur in assertion/
negation pairs, so if the target has sent an asserting edge, and the offset
is at one, why would it be unreasonable for the initiator to expect a
negating edge, especially given that the target cannot end the phase without
doing this? The problem John is trying to avoid could only occur at the low
end of the allowable offset range. Why wouldn't the target take advantage
of the offset range available to it and issue more REQ edges, especially if
not doing so causes a performance hit equal to a round-trip bus delay?

Finally, if this is indeed a hole in the spec, is a measure that would
outlaw existing (and currently allowable) designs the proper way to plug it?

Richard Moore
QLogic Corporation

*
* 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