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