section 10.8.3.3.4

Sriram Srinivasan srirams at lsil.com
Tue Oct 17 08:59:59 PDT 2000


* From the T10 Reflector (t10 at t10.org), posted by:
* Sriram Srinivasan <srirams at lsil.com>
*
Bill,

   I kinda agree w/ some things that u wrote, but disagree w/ some ... 
just like u did w/ my proposal :).  Please see my comments interspersed 
with your statements below.
   
~ 
~ Srinivasan,
~ 
~ I do not agree with some of your changes in 00-384r0.
~ 
~ In your DT DATA OUT error handling your are requiring the target to 
send the
~ status IU during the same connection as the bad data IU.  That has 
never
~ been the requirement before and should not be now.  We do not require 
this
~ in non-packetized and we do not need to require it in packetized.  I 
can not
~ think of anything the initiator would do differently, so why mandate 
that
~ the target can not go bus free and reconnect later???

   No I DO NOT mandate (in 00-384r0) that the target send the status in 
the same connection.  It just says "after receiving all ACKs" so it 
could be in a later bus connection ... and SPI-4 rev0 DOES want it the 
other way; i.e. send status right away!  So I have to disagree w/ you 
when u say "it has never been a requirement before" :) ... the only 
thing that I did was mandate that status be sent right away for data 
stream IUs ... and that is changing in 00-384r1.  Also I'll make it 
explicit that "this status can be sent in the same or a subsequent bus 
connection".
   

~ 
~ The only strict requirement on the target is to stop a "multi" command
~ sequence so that it does not receive the commands out of order.
~ 
  
  I must agree w/ u on this one.  I'll remove the idea of receiving more 
commands in 00-384r1.

~ 
~ Also your are adding a new unwarranted feature for command IUs.  Today
~ commands are only sent on the FIRST DT DATA OUT phase after a 
selection.
~ Why should we add anymore complications to a low performance error 
recovery
~ case by allowing the target to go back to DT DATA OUT and troll for 
more
~ commands (that the initiator may not even want to send now)??
~ 
~ 

   I disagree w/ you on this one though! 00-384r0 does not say that we 
need to "get back to receiving command IUs" it only says "keep receiving 
the command IUs w/o sending the status for the command IU in error right 
away".  So, no, it did not try to introduce new transitions into the 
"command IU receiving" state from states where other SPI IUs were sent 
or received. ... but all this is going away in 00-384r1 since I agree 
that the initiator wants the target to see the commands in order.
   
   Hope my comments clarify certain issues.
   
   regards,
   Sriram
   
~ In your DT DATA IN error handling, I think we agree. I can think of no 
good
~ reason to limit how many data stream packets the REQ offset can cover. 
 I
~ think the target should be able to send as many REQs as the offset 
allows
~ across any number of data stream packets (NOT L_Q packets) and should 
be
~ allowed to respond to the ATN condition after any number of data 
stream
~ packets.
~ 
~ Bill Galloway
~ BREA Technologies, Inc.
~ P: (281) 530-3063
~ F: (281) 988-0358
~ BillG at breatech.com
~ 
~ 

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