This message is from the T13 list server.
Pat, On your third point, PIO also does not distinguish (at the physical level) between N and N-1 bytes transferred. At that level multiples of 16 bits are always transferred, regardless of whether it is PIO ro DMA (see the data transmission section of the PACKET command). For PIO it is stated explicitly that the last byte should be ignored by the receiver. For DMA it is not so stated, although I'd consider that to be a resonable interpretation. In either case this issue only appears on the last transfer of the command, and the host has the same information in both cases to figure out whether the last byte should be ignored or not (for reading). For writing the device does not know whether to ignore the last word or not unless it knows the number of bytes for the command (since it can count down to 0 or -1 correctly). So the only issue I can see if odd bytes in a command, bytes not specified ahead of time to the device, and a write command. Conceptually I don't think that is a real issue, since the host should know the number of bytes ahead of the start of the write, and so can tell the device. I assume it would do this via the content of the command packet (i.e. not the registers on a DRQ basis, as is done with PIO). Does that make sense? Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 04, 2001 11:05 AM To: [EMAIL PROTECTED] Subject: [t13] from whatever to AtapiUdma: three questions we should ask This message is from the T13 list server. I'm inclined restate all this as three concrete questions to include in the procurement evaluation of any bridge-X-to-AtapiUDma effort. These questions apply to AtaUdma as well, but I imagine wrong answers are less of an issue there. I'm posting these here to encourage fellow customers to ask the same questions. 1) When receiving pairs of UDma bytes, when you ask to receive H bytes but you then in fact receive D = H + N bytes, for N positive and even, did you take care to be sure you noticed? Even if N is small and all the N appeared only after you initiated the final terminating pause? 2) Have you tried this case with Atapi devices that receive UDma? How good is their record for complaining of this hole? Do they ever include in the final terminating Crc bytes they don't actually process and never would have requested in Pio mode? 3) What is your algorithm for choosing when to use UDma and when to use Pio? Aye, the TalkLikeWindows algorithm is to talk UDma always. But any Ide Dma fails to distinguish N - 1 from N for N positive and even, and with UDma we also face the issue of how well or not the receiver handle clocks from the sender past what the receiver saw as the final terminating pause. Pat LaVarre >>> "Pat LaVarre" <[EMAIL PROTECTED]> 12/04/01 10:36AM >>> This message is from the T13 list server. Courtesy people kind enough to clue me in by phone, I think I have now heard a coherent AtapiPio vs. AtapiUDma story that I can now go try to learn to say in spec words. // Key Walkway: Because the UDma protocol does not distinguish the final terminating pause from other terminating pauses, neither should the receiver or the sender. // The Bottom Line: Standard Atapi UDma DOES count bytes as well as standard Atapi Sw/MwDma. And that's as good as merely standard Atapi Pio for any even total of bytes. // The Whole Story In Three Parts: 1) From Atapi Pio Yes AtapiPio accelerators have been bursting as fast as Sw/MwDma but now won't keep up with UDma. Yes any compliant AtapiPio device differs from a merely AtaPio device by giving its host a precise, possibly odd, total of bytes moved. 2) To Atapi Sw/MwDma Yes, for N positive and even, nothing in the standard Sw/Mw/UDma protocols lets the receiver of data distinguish a sending of N bytes from a sending of N - 1 bytes, such as distinguishing 5 bytes of Atapi Inquiry data in from 6 bytes of Atapi Inquiry data in, or distinguishing 511 bytes of Atapi WriteBuffer data out from 512 bytes. 3) To Atapi UDma Yes a UDma receiver can't stop the sender on a dime, not even after receiving the last expected byte pair. Specifically in UDma 33, after any pause, the sender has the right to send another 1 or 2 clocks. Yes at even higher burst rates, the sender gains the right to send more clocks: since the round trip time holds constant, more burst clocks fit inside it. The UDma protocol passes one Crc across the bus for each terminating pause, but does not distinguish the final terminating pause of a command from any other terminating pause. Because the UDma protocol does not distinguish the final terminating pause from other terminating pauses, neither should the receiver or the sender. After any terminating pause, once the Crc's match, the receiver and sender can believe they each saw the same number of byte pairs cross the bus. Accordingly, a compliant host that has more byte pairs to send can know the device did not receive them. And a compliant device that has more byte pairs to send cannot clear DRQ and raise INTRQ. With Ata UDma, all standard traffic is block traffic, so a sender who sends more byte pairs than expected typically sends another whole block, so the host easily perceives the trouble. With Atapi UDma, we will less rarely see a sender send just one or a few unexpected additional byte pairs past the final terminating pause. This will highlight a quality of implementation issue in the receiver. To transfer bytes as reliably as Ata block transfers do, the receiver has to pass those byte pairs on or signal trouble. Most simply, the receiver could exclude the byte pairs from the Crc. Infinitesimally more reliably, the receiver could distinguish this case and complain of it. 4) Yes? Pat LaVarre P.S. I'll write back if I can dig out more about that major hard drive requiring receivers to quietly toss byte pairs received after the final terminating pause. The story I heard was that device would always clock N * 512 + 4 bytes whenever you sent an Ata xC8 Read Dma of N blocks. Hopefully I heard wrong. Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
