ATN condition in Packetized

Sriram Srinivasan srirams at
Fri Dec 17 15:13:00 PST 1999

* From the T10 Reflector (t10 at, posted by:
* Sriram Srinivasan <srirams at>
	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 
	 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.


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

More information about the T10 mailing list