Response to SPI-4 proposal 01-251

Richard Moore richard.moore at qlogic.com
Fri Aug 31 10:24:48 PDT 2001


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

See my responses below each of your paragraphs.

Richard Moore
QLogic Corporation


* From the T10 Reflector (t10 at t10.org), posted by:
* "Leshay, Bruce" <Bruce_Leshay at maxtor.com>
*
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.

	What you say is true, but is no less true if turned around into
	an analogous statement with initiator and target roles reversed.

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.

	I don't believe I said pairs were required (well, eventually there
	must be a negation for each assertion so the reality is that they
are
	required); I did say that it's a reasonable expectation that a
matching
	negation will be received at some point in the future if the current
	offset is 1 (meaning the target has plenty of offset left to work
with).

	An odd value for maximum offset does not create a problem, except
	for the specific case of a maximum offset of 1. If any target were
	daft enough to negotiate for a synchronous offset of 1, we would
	just renegotiate to ST (or even asynchronous; there's no performance
	benefit to synchronous transfers with a maximum offset of 1). Not
	supporting an offset of 1 in DT mode was a conscious decision on the
	part of our designers.

	If the maximum offset is odd (and greater than 1), and the target
	reaches the maximum offset, there is no issue. Since the offset
	is greater than 1, the initiator will respond with ACKs.

	The situation John is describing can only be reached if the target
	insists that the offset reach zero before it sends another REQ.
	In this case, the target would be *behaving* as if it had negotiated
	a maximum offset of 1, even though it had in fact negotiated for
	more.

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.

	Again, the argument is symmetrical between the target and the
	initiator, so I can see no reason to hold the initiator solely
	accountable.

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.

	No problem; the target deasserted REQ and the initiator responded.

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).

	Well, your second example is confusing and I'm not sure I get the
	point, but if you have to invent a scenario based on internal error
	conditions -- then if that error condition causes a hang, eventually
	there will be a timeout and we'll use the big hammer (reset). We'll
	never have a world where every possible error can be recovered
	without resorting to reset.

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