QAS protocol

Tak Asami asami at itc.adaptec.com
Fri Nov 7 11:47:48 PST 1997


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Tak Asami <asami at itc.adaptec.com>
*
Bruce Leshay (Quantum) wrote:
> There seems to be continued misunderstanding to my objections to "snooping"
> of bytes being transferred using the asynchronous handshake.  The setup time
> has nothing at all to do with it.
> 
> The width of the REQ and ACK pulses during an asynchronous transfer are not
> defined by the standard.  For two devices which are physically close to each
> other on a SCSI bus, and which each implement asynchronous logic for portions
> of the handshake, these pulses can be arbitrarily narrow.  If the chips in
> the initiator and target both happen to be at the fast end of their
> semiconductor process corner, pulses in the 10ns range seem possible.

> My memory of the discussion is that this problem appeared insurmountable

I did not get that "insurmountable" impression in the meeting.

True enough, there is no minimum pulse width defined for asynchronous 
transfer.  Only the pulse interval minimum in the form of combined setup
(55nsec) and hold (0nsec).
But that's a technicality.
Seriously, while it is possible for a target to issue a message in that manner,
I know of no reliable way to make initiator behave to catch the message and
flash the ACK in no time so your REQ goes away just like that.
If your target is designed to be out of control asynchronously, your 
initiator will save you.  Whoever is receiving a message needs some time.
Most likely in terms of number of clock cycles, not "a few nanoseconds".
So we are all worried about something that cannot happen in reality just
because the text of standard suggests something.

So if we do not expect the feared situation from the existing products, 
why not define the timing so the feared situation not only does not happen,
it is "illegal"?
Currently, 9.1.20 "Transmit assertion period" is defined as "The minimum
time a target shall assert the REQ or REQQ signal while using synchronous 
data transfers... (also reference to an initiator for ACK signal)".
I'd say remove the reference to "asynchronous data transfer" from the 
definition.
Enter in the "Transmitter assertion period" row of Table 42, column 
"Asynch", 8nsec, which is a minimum number specified for Fast-40.
Whatever.  The real number is going to be much larger, so it will not
affect the legacy product.

We do not need to worry about Read assertion period for asynchronous.
It can remain "N/A".

Bottom Line:

I do not see any real issue with defining the minimum pulse width for
REQ.  Not until someone shows me a picture of the "excessively narrow
REQ happening during the asynchronous transfer".

It is, however, necessary to define a non-ambiguous start of QAS so
the feature can be used within legacy interlocked protocol.

Tak Asami ===========================================================
Adaptec ITC
P.O. Box 57020  Irvine, CA 92619-7020
(714) 455-8202 / Fax: (714) 455-8102
asami at itc.adaptec.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com




More information about the T10 mailing list