This message is from the T13 list server.
> Jim ... Hale ... Mark ... other Jim ... Michael ... Harlan .. Tony ...
Thanks everyone for beginning/continuing to work to clue me in. I'll work to reply to
everyone in turn, but first ...
> > In direct-attached byte-wide Scsi, ...
> > ... an actual byte count that is
> > the min of those two max counts actually moves.
> "Mcgrath, Jim" <[EMAIL PROTECTED]> 12/18/01 01:48PM
> Your comment ... Confuses me.
Ahhh. This is key. We probably will get nowhere until we get me straight on this
much. Let's try focusing here for a moment.
> Are you thinking of REQ/ACK transitions?
Not exactly.
> ... Eventually the REQ/ACK offset would get to zero,
> but that does NOT signify command termination.
Just to keep our examples simple, let's stay for awhile with the slow full handshakes
of the original byte-wide "asynchronous" Scsi. For me this means working from a human
memory of 1995, but I trust you'll correct me where I err.
In the original byte-wide asynchronous Scsi, the device waits indefinitely for the
host to answer each new REQ clock with an ACK clock. With each REQ clock, the device
says to move data or not, in or out, by de/asserting C/D:I/O with each REQ.
In the simple circumstances analogous to Atapi Pio, the Scsi host & device move just
command, data, and status in that order.
The Scsi host & device discover the actual byte count of data transferred as soon as
the device stops asking to move data and starts asking to move status.
So far so good?
> The device would just wait endlessly for the host to send more data.
> It is only the command level values
> of TRANSFER LENGTH and PARAMETER LIST LENGTH
> that allow the device to determine,
> when compared to the total number of ACKs received,
> that the command is over (and so terminate it).
Not exactly.
By interpreting the command block, the device decides only the max count of bytes it
may transfer
The device may cut this transfer short arbitrarily.
The standard requires the device to cut transfers short on occasion. A perhaps
familiar example of cutting transfer short is:
x 12 0 0 0 FF 0 /i xFF
This six byte Cdb is an Inquiry for up to xFF bytes. The Scsi standard requires the
device to cut the transfer short without error unless it happens to have xFF bytes of
Inquiry data available.
A less commonly familiar example of cutting transfer short is:
x 12 0 0 0 FF 0 /i x1000
Here the host has allocated even more than the allocation of xFF bytes that a command
block with this x12 opcode can express. Nothing in the byte-wide asynchronous Scsi
protocol lets the device distinguish this case from the case where the host allocated
xFF bytes. Still the device cuts the data transfer short after moving however many
Inquiry bytes it has available.
A still less commonly familiar example of cutting transfer short is:
x 3B 0 02:00:00:00 0 01:FD 0 /o x1000
Here the host has allocated more than the x1FD minimum allocation that this command
block demands. Nothing in the byte-wide asynchronous Scsi protocol lets the device
distinguish this case from an allocation of precisely x1FD bytes. Still the Scsi
standard requires the device to cut the data transfer short, this time after moving
the max x1FD count of bytes that its interpretation of this command block permits.
So far so good?
> > In direct-attached byte-wide Scsi,
> > the host and the device
> > each decide a max count of bytes
> > that will move [whichever] way.
> >
> > Whenever host & device agree on direction,
> > an actual byte count that is
> > the min of those two max counts actually moves.
> >
> > It is the clash of this model with Ide Dma that is giving me pain.
This I standby, so if it's not now obviously true to you, then we're not using the
same words to mean the same thing. Can you help me guess which words are at issue?
I'm saying in Scsi, therefore likewise in Atapi, the host & device cooperate to decide
the byte count that actually moves, without ever actually communicating the max
permissible byte count that each has decoded independently and more or less indirectly
from the command block.
Pat LaVarre
Subscribe/Unsubscribe instructions can be found at www.t13.org.
