Quick arbitration questions

[gop at us.ibm.com]

* From the T10 Reflector (t10 at symbios.com), posted by:
* gop at us.ibm.com
*
Andrew,
Here are the SPI-3 editors proposed results of your comments on SPI-3 rev
3.

1-I have been told that the ACK signal was supposed to have the same
minimum timing requirement as the REQ signel, however, that is not what was
in the proposal that was voted on by the t10 committee. I have made the
change but have marked it as requiring a plenary vote to accept the change.
I agree the one system deskew delay should be two system deskew delays. I
have made the change but have marked it as requiring a plenary vote to
accept the change.

2- As Bill Galloway noted e) gives the time-out value. of QA arbitration
delay as the time-out. Causes no change to SPI-3 rev3.

3- Bill also answered this one. In the standard a,b,c lists do not define
any ordering it is just a list of things, on the other hand, a 1,2,3 list
does define an ordering of events. Causes no change to SPI-3 rev3.

4-I have added an entry that describes the initiators behavior which is to
complete the handshake and release all signals within 2 system deskew
delays.

5-I changed the released to negated.

6-Changed the wording to indicate that fairness is using to determine
participation in arbitration not the outcome of an arbitration.


      Bye for now,
      George Penokie

      Dept EGB  114-2 N212
      E-Mail:    gop at us.ibm.com
      Internal:  553-5208
      External: 507-253-5208   FAX: 507-253-5208




Andrew Roy x2180 <andrewr at eng.adaptec.com> on 02/01/99 06:35:00 PM

To:   T10 Reflector <t10 at Symbios.COM>
cc:    (bcc: George Penokie/Rochester/IBM)
Subject:  Quick arbitration questions





* From the T10 Reflector (t10 at symbios.com), posted by:
* Andrew Roy x2180 <andrewr at eng.adaptec.com>
*
Greetings, all!

These questions are based on SPI-3 revision 2 (16 Nov 1998).  If I
should be looking at a later revision, please let me know what revision
and how to get it.  Thanks very much.

1)  Section 11.1.2.2.1 "QUICK ARBITRATION phase", under the procedure
for the target releasing the bus by quickarb instead of busfree says
"The target shall hold each of the message byte(s) for a minimum of 33
ns after detection of the ACK signal being asserted."  That was part
"a".  Part "b" says "...the target shall release all SCSI signals except
the BSY signal...within one system deskew delay."  Since the system
deskew delay is only 45 ns, this only gives the poor target a 12 ns
window to release the low SCSI data signals.  I was hoping to implement
this stuff with a state machine running at much less than 100 MHz, but I
cannot meet this timing this way because I cannot guarantee that there
will be a clock edge in the appropriate window.  Can we please loosen
the timing to releasing everything within TWO system deskew delays after
ACK assertion?

2)  Part C of the target procedure says "The target shall wait for the
SEL signal to be asserted."  Unfortunately, if there are no participants
in the arbitration, this will not happen.  There will be no participants
if nobody happens to want the bus right now or if nobody else has
quickarb enabled.  Can we add some sort of timeout escape clause to go
to busfree?

3)  Parts E and F of the target procedure says "...the target shall
transition to the busfree phase."  I'm not sure how this is possible.
The target released SEL in part B and released BSY in part D.  If the
bus is not already in busfree, it is not this device that is holding it
out of busfree.  If the reference is to some internal state machine of
the target, we may have just unsynced the state of the cable and the
poor target's internal logic, which seems undesirable.  Please help me
figure out what is going on here.

4)  There is no explicit definition of what the initiator should do when
it receives a QA request message from a target with which it had
negotiated quickarb.  Once the initiator asserts ACK without asserting
ATN, the target quickly negates MSG, CD, and IO, which would normally be
dataout phase and the initiator would drive the data bus.  This would
cause problems with the arbitration, so I assume that the initiator is
required to disconnect from the bus, but when?  Must the async REQ/ACK
handshake complete normally, or may the initator vacate the bus
(releasing ACK) before the target releases the REQ?

5)  Under the procedure to obtain control of the bus, part C ends with
"...signals being released."  I think it should read "... signals being
negated.", even though some other device would have trouble telling the
difference.

6)  Part D of the procedure to obtain control of the bus includes the
phrase "...or the fairness algorithm prevents the SCSI device from
winning...".  Isn't it true that if the fairness register were non-zero,
the SCSI device would be a nonparticipating device and would neither win
nor lose?

Thank you all for whatever help you can give me clearing up the fog in
my own head.

Andy Roy
Adaptec

PS  These questions and suggestions are purely my own and not in any way
official Adaptec policy.


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



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