This message is from the T13 list server.
Looks good to me. Actually, on the last burst transferred the sender should never be sending any more bytes than the receiver should expect if the number of bytes for the COMMAND (not the bursts) was known ahead of time to both parties. If the sender does do that (i.e. in essence decrements the bytes to send for the command counter to a negative number), then feel free to shoot the vendor of the product. Note that for odd byte counts PIO specifies that the last byte send is ignored, since PIO is acually done physically in 16 bit words (like DMA). I could no fine similar wording for DMA, but I'd think that would be a reasonable interpretation of the standard. If the command never specified the number of bytes, then the upper levels have to parse things (but then, they would have had to do that anyway). For those of you for whom that does not make sense, remember that some tapes can stored data in an unblocked format (just a string of bytes), and rely on some sort of meta data stored somewhere, or indicators in the stream of data itself (e.g. flag bytes) to tell the system where things are logically partitioned. Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 04, 2001 10:37 AM To: [EMAIL PROTECTED] Subject: [t13] to AtapiUDma from AtapiPio - conclusion? 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.
