Packetized L_Q IU type field changes

Bill Galloway BillG at
Tue Dec 14 14:05:12 PST 1999

* From the T10 Reflector (t10 at, posted by:
* "Bill Galloway" <BillG at>

1) sounds fine.

2) I do not want to make it complicated but... If the target just goes bus free
the initiator may think that the target did the requested action. I think that
returning a status LQ is best. I do not see why the target has to take ANY data
with the bogus LQ.

While we are talking about the TYPE field.... You said in Rochester that you
believed that a target is required to honor the "Multiple Command" type.  I do
not see any words that require this. The way I read the current version of the
SPI, this type is an advisory to the target that the initiator has more
commands but the target can ignore this advisory. I cannot find any words
prohibiting the target from breaking a command stream with a QUE FULL or going
bus free after a command just because it feels like it.

Now that I have kicked the hornets nest let me say that I see nothing wrong
with it being only an advisory to the target.

Bill Galloway
BREA Technologies, Inc.
P: (281) 530-3063
F: (281) 988-0358
BillG at

-----Original Message-----
From: owner-t10 at [mailto:owner-t10 at]On Behalf Of
gop at
Sent: Tuesday, December 14, 1999 2:03 PM
To: t10 at
Subject: Packetized L_Q IU type field changes

* From the T10 Reflector (t10 at, posted by:
* gop at
During a review of the TYPE field in the L_Q IU a few issues were pointed
out that should be resolved in SPI-3.

1) The current wording in the description of the type codes of last
command, multiple command, and status  is:'The IUCRC INTERVAL field shall
be set to zero.' This is correct but the first thing the tester guys want
to do is set the IUCRC INTERVAL to a non-zero value to see what will
happen. And with no help from the standard I am sure there will be several
responses depending on who implemented it. I would like to suggest the
wording be changed to: 'The IUCRC INTERVAL field shall be set to zero and
ignored by the target.'

2)There is no wording that tells what to do in the case where an invalid
type code is sent to a target (This would be another test case that would
be tried by our tester friends). I have two suggestions as to what should
be the response and we need to pick one:

-Bring out the big hammer and go bus free.
-Bring out the little hammer and, after dumping all the bytes for the
unidentified IU the follows the L_Q IU (remember in this case the iuCRC is
good so there is a valid length in the L_Q IU and the target is still
required to transfer that number of bytes before doing anything else except
bus free) the target would change to the DT DATA IN phase and send a L_Q
IU/Status IU with the RSPVALID bit set and the packetized failure code set
to 02h (or a newly defined code). If we use the 02h it's definition would
have to be changed from 'SPI command information unit fields invalid' to
'SPI command or SPI L_Q fields invalid'. Or we define a new code xxh that
would be defined as SPI L_Q information unit fields invalid.

Any comments??

Bye for now,
George Penokie

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

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

* 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