This message is from the T13 list server.
Pat, Comments included. Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 2:58 PM To: [EMAIL PROTECTED] Subject: [t13] to Dma from Pio - willingly requested bytes counted not? 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? JPM - it parses the command and sees that 5 bytes were requested and sends on 5 bytes. Parsing commands is a pain, but many off the shelf bridges have fast embedded processors that so precisely that. You can always try and avoid this approach by having the bridge send all 6 bytes back to the host. Then some software on the host, which has parsed the command, will see the extra byte and ignore it (another popular bridge does it this way). The point is that SOMEONE in the receiving chain has to parse the returned data, and that someone knows that only 5 bytes was requested (it actually knows a lot more than that of course). I advise using the embedded uP approach, but that's ultimately a design call. // 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. JPM - once again, I don't see the issue if the host knows how many bytes are expected. Like the Inquiry case, either the bridge or the host software ignores the odd byte. // 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. JPM - once again, this is definitely a difference, but I don't see where the problem is. UDMA WORKS - over 1 bilion ports use it today. I've never heard of the host and device getting confused about the number of bytes, or handling that issue wrong. It is the responsibility of the host (and/or bridge) and device designers to make the UDMA protocol work at that level. JPM - And at the command level, once again any command where a length was specified it is the job of the host (and/or bridge) and device to implement things so that they understand the total number of bytes that are logically needed. // 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. JPM - Once again, I'm still not seeing the issue. ATAPI UDMA CD-ROM drives have been shipping for some time now, and I have not heard of any problems like this. Agreed? JPM - no, since I'm stil not seeing the problem. If the command information the bridge has is bad, then everything is trashed. If the information is good, then why cann't the bridge use that to fix all of these problems? JPM - Notice, I'm not saying that changing protocols could not improve them But it takes two years to get those changes to market, and you will always have to contend with older designs without the "fix." So my thinking is always centered around how to avoid the issue to begin with. Is there any case where the bridge would not know the number of bytes that it wanted (and therefore be able to parse the returned data correctly?). I'm just not worried about things like Inquiry, since the workaround appears to be so simple. Thanks in advance. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
