This message is from the T13 list server.
> "Mcgrath, Jim" <[EMAIL PROTECTED]>
> Looks good to me.
Thank you for saying, I'm very glad to hear that. Thanks again to everyone for
receiving all My email, for replying with corrections, for the tutorial phone calls,
and the clarifying visits in person.
> PIO also does not distinguish
> (at the physical level)
> between N and N-1 bytes transferred.
Absolutely true, sorry I was slow to appreciate that point. I now think maybe that's
the best place to begin the discussion.
> only issue I can see
> if odd ... and a write ...
I don't yet see that only odd counts get us into trouble. If we emphasise your point
re Pio, I think maybe we end up with a more accessible summary of what we see here now
on bus traces.
// 0. Contents
1. One Short Concrete Example
2. What's Missing from Standard AtapiDma
3. Specific Consequences By Dma Mode
4. The Fix
// 1. One Short Concrete Example
Let's begin with a short simple concrete example of the kind of byte counting
difficulties any bridge to 16-bit Ide faces.
Suppose we're bridging a command to read five bytes in, like the ever popular Atapi x
12 0 0 0 05 0 Inquiry for five bytes.
The bridge and the device both see three byte pairs of data clock across the bus.
How does the bridge decide if it should pass on 5 bytes or 6 bytes?
// 2. What's Missing from Standard AtapiDma
AtapiPio mode differs from all other Ide transfer modes in that AtapiPio mode requires
the device to communicate more to the host than just the N pairs of bytes clocked
across the bus.
AtapiPio mode also requires the device to communicate what I'll term the variable D:
the count of bytes the device "willingly requested". In AtapiPio mode, D is the sum
of samples of x1F5:1F4 AtaCylinder = AtapiByteCount taken with each DRQ INTRQ.
What's clearly missing from the Ansi standard for any AtapiDma mode is a method for
the device to communicate D as accurately to its host as in AtapiPio mode.
Leaving the communication of D out of the Dma standard makes it tough for a Usb2
bridge to pass D on accurately ... in Usb bus traces, this appears as inaccurate
dCSWDataResidue, since dCSWDataResidue is by definition simply (dCBWDataTransferLength
- D).
Anybody shipping a transparent Usb2/AtapiUDma bridge without fixing this problem is
not accurately reproducing an image of what a direct-attached AtapiPio host would see.
For more or less of us, to determine confidently when that inaccuracy does and does
not matter will be a much harder task than to eliminate it entirely.
// Specific Consequences By Dma Mode
In any Ide data transfer mode, Pio or Dma, a compliant device and host can agree how N
pairs of bytes clocked across the bus.
What's at issue is only how few of those bytes were willingly requested.
With SwDma, any Ide host that guesses D = N * 2 is wrong by one whenever D is odd.
With MwDma, few real devices are, but a standard device may be, rude enough to turn
DMARQ around so slowly that the host sees one extra clock. This means a host that
guesses D = N * 2 can be wrong by 0, 1, 2, or 3 bytes.
With UDma data moving in to the host, the device clocks the data, not the host, so the
host is again never off by more than one: no worse than SwDma, theoretically but not
practically better than MwDma.
But with UDma data moving out to the device, the host clocks the data faster than it
ever moved before. Consequently, UDma senders popularly ARE rude enough to clock more
pairs of bytes past the receiver's request to pause the transfer.
If M more clocks arrive, then a sender that guesses the receiver willingly requested D
= N * 2 bytes can be wrong by anywhere from 0 to M * 2 + 1 bytes.
I hear standard UDma 33 lets M be 2, though in my as yet near zero experience I much
more often see 1. Given M = 2, a host's guess of D = N * 2 can be wrong by as much as
5.
I hear standard UDma 66, 100, 133 ... lets M be larger still.
// 4. The Fix
Easy enough to fix this when we control both bridge and device: just teach the device
to observe and report the { I = N * 2 - D } inaccuracy.
Easy enough to teach the device to do this. For data out, I is the number of extra
bytes leftover in a receive fifo. For data in, I is the number of extra bytes that
were stuffed into the send fifo to move the last willingly requested byte.
Maybe hard to get devices and bridges all turned together in time to avoid this
growing into more of an issue.
Agreed?
Thanks in advance. Pat LaVarre
Subscribe/Unsubscribe instructions can be found at www.t13.org.
