Wording issue with SPI-4 rev. 8

Richard Moore richard.moore at qlogic.com
Wed Jan 2 10:42:11 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Richard Moore" <richard.moore at qlogic.com>
*
Now that QAS is supported for non-IU devices, what is the best way
to interpret the QAS_REQ bit?

Does it mean, "I will participate in QAS", or does it mean, "I will
accept (as an initator) or generate (as a target) QAS REQUEST
messages"? Or maybe, "I will respond to a selection/reselection from
a QAS winner?"

The first meaning doesn't seem very useful. Devices shouldn't need to
advertise whether or not they will participate, and even if they did,
there shouldn't be a need for this to be established separately with
each device on the bus. What if the initiator sets QAS_REQ, and the
target clears it in response? The initiator should still be allowed
to participate in QAS. Also, if the initiator clears QAS_REQ, the
target is forced to respond with the bit cleared, but the target should
still be allowed to participate in QAS if it is capable of it.

I would think either the second or third interpretation is more likely
to be useful. And the second interpretation is almost redundant, since
QAS REQUEST messages are not allowed except at the end of an IU-mode
connection (though the bit could be cleared by an IU-capable initiator
to tell an IU-capable target not to send QAS REQUEST messages).

The third interpretation would probably be the most useful, since some
legacy devices might not respond to selections/reselections which are
not preceded by a BUS FREE/ARBITRATION phase sequence. In this
interpretation, one device can tell another device not to use QAS to
(re)select the first device. In this interpretation, there is no
ambiguity about when a device may participate in QAS (it may do so
to select/reselect a device that sent QAS_REQ = 1), and there is
no ambiguity about when a target may send a QAS REQUEST message (it
may do so anytime it disconnects from an initiator that sent QAS_REQ =
1).

The first interpretation is the one with the least utility (and most
ambiguity). Unfortunately, this interpretation is the one specified in
SPI-4. This interpretation (as well as the third interpretation) does
in fact require two lines in Table 11 for each transfer mode.

In the case of the second interpretation, devices not supporting IU
mode should never send or receive a QAS REQUEST message, so the
non-IU modes would never be combined with a QAS_REQ bit of 1.

 -- Richard Moore
    QLogic Corp.


-----Original Message-----
From: Elliott, Robert [mailto:Robert.Elliott at COMPAQ.com]
Sent: Friday, December 28, 2001 2:46 PM
To: t10 at t10.org
Subject: RE: Wording issue with SPI-4 rev. 8


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert" <Robert.Elliott at compaq.com>
*
I agree that the two tables conflict - when the offset is 00h, are the
transfer period factor and protocol options ignored or invalid?

In Rev 7 and in 01-131r4, table 11 listed the transfer period factor as
00h - FFh in this case, implying it is completely ignored.  Rev 8
changed the 00h to 0Ah but still has a range.  Some letter ballot
comment must have asked for the 0Ah change.

The protocol option bits, however, did not have "0 or 1" to indicate
they are ignored.  They should all (except QAS_REQ) be "0 or 1" if we
want them ignored. If we want them cleared, the table 7 change you
suggest makes sense.

Remember that QAS is supported without Information Units.  Non-IU
targets may participate in QAS generated by other targets; they just
won't generate QAS_REQUEST messages themselves.  Thus there are two rows
in table 11 for QAS and non-QAS asynch modes.

---
Rob Elliott, Compaq Server Storage
Robert.Elliott at compaq.com

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