ATN condition in Packetized

gop at us.ibm.com gop at us.ibm.com
Tue Dec 28 08:52:47 PST 1999


* From the T10 Reflector (t10 at t10.org), posted by:
* gop at us.ibm.com
*
Sriram,

There are a few different issues you are rising.

1-The case where a CRC error is detected by the initiator and then does not
get the ATN signal asserted before the next UI is started should never
happen. That's because the initiator cannot ACK the last byte of the CRC
until the CRC is correct. This requirement is stated in section 10.8.3.3.3
as:

'The initiator shall not negate the ACK for the last byte of the last iuCRC
in an information unit until the entire information unit has been verified
and any required attention condition has been established.'

2-The requirement for the remaining of the IU to be transferred if a CRC
error is detected in to help with the flow control. By making this
requirement the point at which the transfer will end is always the same
(i.e., at the end of an IU). Without the requirement multiple
implementations would end the IU at different times which would be
detrimental to initiators attempting to control the flow. The assumption is
that once the IU transfer is setup it will continue until the end no matter
what happens with any errors or ATNs being handled at the end of the
transfer. Yes it is possible that this requirement many make the size of
the IUs be smaller, but it is more likely that the requirement that the
target take in the entire IU without disconnecting will be the limiting
factor in the size of the IU.

3-The initiator asserting the ATN between IUs must accept or send all of
the next IU (i.e., it gets what it asked for). This is something the
initiator should not do for that reason. The initiator should assert the
ATN signal before the end of the current IU if it wants to control the flow
by forcing a disconnect.

Note: The size of the IU is not as much of an issue for performance as it
used to be. This is because with write streaming the relationship between
the size of the IU is not closely related to the time it takes to transfer
the IU. (This was always true for reads).

Bye for now,
George Penokie

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



Sriram Srinivasan <srirams at propwash.co.lsil.com> on 12/17/99 05:13:00 PM

Please respond to Sriram Srinivasan <srirams at propwash.co.lsil.com>

To:   t10 at t10.org
cc:
Subject:  ATN condition in Packetized




* From the T10 Reflector (t10 at t10.org), posted by:
* Sriram Srinivasan <srirams at propwash.co.lsil.com>
*
     I have some questions on ATN condition in packetized.

     In subclause 12.2 it states the following:

     "h) If the attention condition is detected between SPI information
units, the target shall enter MESSAGE OUT phase at the completion of the
next
SPI information unit."

     So, in the case of a read data transfer, if the target decides to send
out a DATA IU w/ several iuCRC intervals, then the following happens:

     1) target sends out a SPI L_Q
     2) ATN condition is detected between SPI L_Q and following DATA IU
     3) Target sends out complete DATA IU.

     In this case, the target was required to transfer the complete DATA
IU,
before it could honor the ATN condition.  It would have been better if the
target was allowed to honor the ATN condition at the end of the first CRC
interval in the DATA IU.  This way, the bus might be better utilized
avoiding
the transfer of the entire DATA IU.  If this restriction were to be
maintained,
then the target would have little incentive to make use of the CRC interval
during read data transfers and would probably choose to start transferring
small
DATA IUs w/ one CRC at the end and precede each one of these w/ a SPI L_Q.

     The same applies when the ATN condition is detected in the middle of a
DATA IU transfer.  It would be better if the target is allowed to honor the
ATN
condition at its "next most convenient CRC boundary" which could be a CRC
interval instead of the end of the DATA IU.

     Also if the ATN was detected between two IUs and the second of this
pair
was a SPI L_Q IU, would it not make sense if the target is allowed to stop
(if
it could) before sending out the SPI L_Q IU?

     Also NOTE 35 in subclause 14.1 states:
      "An initiator may request a BUS FREE phase by creating an attention
condition and sending a DISCONNECT message on the corresponding MESSAGE OUT
phase. This allows an initiator to request the target break up a long
sequence
of SPI L_Q information unit/SPI data information unit pairs int osmaller
sequences"

      So, in this case again, we would not honor the initiator's ATN
condition until we got to the end of transferring the big DATA IU that we
are
currently transferring to the initiator.  This defeats the whloe purpose of
the
initiator's request for flow control of data.  Also the way that I
understand
NOTE 35 is this:

       Initiator wants the target to send "larger" DATA IUs (implies that
there are fewer SPI L_Q/DATA IU pairs transferred) instead of what it (the
target) is currently doing, viz. transferring a whole lot of SPI L_Q/DATA
IU
pairs.  This idea kinda seems the reverse of how u would think the
initiator
would want to implement flow control (assuming that is what it is there for
in
the first place!).  Wouldn't the initiator rather use the DISCONNECT
message as
a means of saying "break up your long DATA IU; go BUS FREE now"?  Is my
understanding right on this NOTE?

     Please clarify.

Thanx,
Sriram


-------------------------------------------------------------------------

Sriram Srinivasan,
ASIC Design Engineer, LSI Logic,         Phone : (970) 206 5847
2001 Danfield Ct., Ft. Collins, CO 80525      FAX   : (970) 206 5244
--------------------------------------------------------------------------


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



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