This message is from the T13 list server.
> "Mcgrath, Jim" <[EMAIL PROTECTED]> 12/06/01 05:52PM
> If a more comprehensive package of changes were developed....
My intent is to offer a fully comprehensive package.
Somebody tell me what's missing?
> other changes would have to be made as well
> (as Hale pointed out).
With all due respect ...
... no matter that Hale is Hale
... this moment, temporarily, inexplicably, ...
Hale was wrong.
We have something of an existence proof to the contrary. I'm saying adding an
accurate report of residue will permit a bridge to duplicate standard Pio byte-moving
behaviour bug-for-bug.
Anybody got a counter example? My simultations all pass now.
> standard Pio byte-moving behaviour
Only standard Pio. Sometimes in Pio you'll see a burst of, say, 5 and then 7. If the
device wants Dma to move 5 + 7 bytes rather than 6 + 8 bytes, the device may have to
do some work. Ansi and Sff before Ansi don't permit this: they say only the last byte
count can be odd.
> Personally I'd just accept that badness happens,
> and make my design flexible and customizable
> enough to handle it.
Fun choice of words.
This is exactly my thinking.
A fully transparent bridge is exactly this: trivially reprogrammable by the Atapi
device. The Atapi device can tell the bridge precisely how many bytes to move to
which way, subject to the restriction that bytes only move one way for each command.
Fully transparent parallel/Scsi and Usb/AtapiPio bridges have shipped in the
millions. FULLY transparent: these devices do not examine the command block, they
pass it thru BLIND, as was explicitly required in procurement and tested by
randomising the command block content during qualification.
("ArbitraryDRQ" qualification of a transparent bridge includes bridging to a device of
special design that can be reprogrammed on the fly to interpret a randomised command
as meaning burst a separately randomised series of byte counts.)
> A fully transparent bridge is exactly this:
> reprogrammable by the Atapi device.
The Atapi devices we buy from third parties reprogram our bridges unwittingly: all
they do is decode command blocks to decide the count of bytes to move which way.
The Atapi devices whose firmware we code ourselves work harder. They supply distinct
idProduct:idVendor:iSerial. They report what bInterfaceSubClass command set they
implement. They monitor Usb power modes. They wake up Usb in response to a disk
insert/ eject or ejectButton push. Etc. etc. etc.
> BTW ... this is NOT a byte count issue -
> in a transparent bridge you don't care
> about the byte count (or you can count it yourself).
> It is just an issue of the last byte's validity.
Agreed this is an issue of distinguishing the count of bytes clocked across the bus
from the count of bytes willingly requested.
If I had fully understood this portion of your reply before I wrote some of my
replies, I might have tried to change my choice of words ...
... but don't I remember seeing Hale & Jim also speak of "bytes transferred" as
meaning bytes willingly requested?
I'm not wedded to any particular terminology.
So far I like "accurate Ide residue" for people who understand, but for people who
don't understand, ...
... I think "accurate byte counts" might clue them in fastest? I don't think people
broadly appreciate that Ide can force the move of X * 2 + 1 more bytes than the
receiver of clocks wished.
The whole issue is over which bytes to count. Counting bytes clocked across the bus
is the wrong answer. That's an incidental count of no fundamental importance. Change
that to be what you like, what host & device have to agree is how many of the bytes
they both consider meaningful: how many of the bytes at the end crossed just to suit
the protocol.
> The only issue I've seen identified
> is the issue of the odd byte residue on transfers
> (which occurs in PIO or DMA,
> but DMA has no indication of it like PIO).
I tried to establish, in my first, 12/07/01 07:23AM, reply to your reply,that we face
of inaccuracy of X * 2 + 1 in every mode, with max X = 0 for Pio/SwDma, max X = 1 for
MwDma, max X up to five or so as we raise burst rates from UDma 17 to UDma 133.
I trust you'll tell me how I did.
> It seems that the underlying issue here
> is the ability to implement a bridge
> without a uP to parse the commands.
For me, aye.
Am I wrong to imagine more than bridge people are interested in the idea of accurate
byte counts? I wasn't trying to be coy when first I framed the issue in terms of
accurate byte counts - I was making the assumption that not only bridge people cared
about accurate non-whole-block byte counts.
> ... implement a bridge
> without a uP to parse the commands.
> Assuming for the moment that this is desirable,
Thank you for this latest example of your customary courtesy.
(-: As you might imagine, I find me continuing to get paid desirable. Here I can even
drink the water and breathe the air. :-)
> So just making this one change would introduce problems
> (i.e. instability for a lot of designers)
All change is bad, agreed.
> you would still have to handle older devices
> for at least 3 more years ...
> ... before you could really take advantage
> of the feature for all products.
Yes older devices will matter. The words I used to say what I think you mean here
were:
'I imagine the final choice of a heuristic [to guess the non-whole-block residue]
might end up a tightly guarded trade s*cret that gives people competitive edge. That
is, this heuristic will become a "secret sauce", like how creatively boot Bios
interpret our quasi-public Ansi Ide standards. Secret sauce gets purchased
expensively by paying people to isolate the root evil in a series of plug 'n play
troubles over time.'
> you would still have to handle older devices
> So it is actually HARDER than the 48 bit addressing
> (by definition you do not care about older devices,
Sorry, I'm lost again.
Older devices will break only when non-whole-block residue matters. That's common
enough to care to improve, but not common enough to keep from shipping. Newer devices
will work better for once. That's a Good Thing.
> here you really do need it
> on all devices to take advantage of it in your bridge design).
Again, I'm lost, sorry. In a bridge, you take advantage of reported residue where
present, you don't where absent. The xEC/A1 Identify bit to tell if you present or
not is key. You always win, you never lose. You can apply whatever heuristics you
prefer to guess residue when it's not reported.
> If you do want a simple state machine in the hardware,
> then you can accomplish this today.
> You might even be able to make it work
> with "compliant ATAPI devices" (as per your earlier email).
This I didn't quite follow either, sorry again.
I can't easily unilaterally extend the xEC/A1 Identify standard to report that my
device is polite enough to bother to report accurate Ide residue ... can I?
I can easily unilaterally extend the standard Atapi protocol to report an accurate Ide
residue, yes.
> will not save you from bad implementation
Aye.
Pat LaVarre
Subscribe/Unsubscribe instructions can be found at www.t13.org.
