Quick arbitration questions
r_moore at qlc.com
Tue Feb 2 10:53:27 PST 1999
* From the T10 Reflector (t10 at symbios.com), posted by:
* Richard Moore <r_moore at qlc.com>
> -----Original Message-----
> From: Andrew Roy x2180 [mailto:andrewr at eng.adaptec.com]
> Sent: Monday, February 01, 1999 4:35 PM
> To: T10 Reflector
> 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 220.127.116.11.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
> 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?
According to the QAS proposal (97-199r9), "The current target, after sending
the QAS message and receiving an ACK with ATN de-asserted, shall release all
SCSI signals except for BSY. The maximum time from the earliest signal
(other than REQ) to the latest signal release by the current target shall be
one system deskew delay."
I think when edited into SPI-3 some of the original intent was lost. I
what should happen after the target detects ACK asserted is this: The target
should hold the message byte valid for 33 ns; it should negate REQ once the
minimum REQ assertion time is satisfied; after negating REQ it should wait
ACK negated; and after detecting ACK negated it should only THEN begin
the SCSI signals as described in the paragraph I referenced above. This
a larger window than the 12 ns Andy mentions.
> 2) Part C of the target procedure says "The target shall wait for the
> SEL signal to be asserted." Unfortunately, if there are no
> in the arbitration, this will not happen. There will be no
> 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?
Again this seems to have been lost in translation. 97-199r9 again: "After
at least a QAS arbitration delay from its release of MSG, CD, and IO, if
are no SCSI ID bits asserted then the current target shall transition to the
> 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.
It looks like there has been a change in SPI-3 that has the target first
negating the phase control lines (part b) and then releasing them (part d).
I don't know the justification for this change. Since the original proposal
had the time-out measured from the release of these signals (which would
have been in part b originally), it seems this description was erroneously
pushed out to beyond part d, so that it is now in part e.
> 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?
The handshake should complete normally.
> 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
Yes, as far as the observing device is concerned released and negated look
the same. "Negated" would be the better term to use here.
> 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?
-- Richard Moore
* 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