This message is from the T13 list server.
Jim, in this case both methods would bring their own special insight. The count before doesn't guarantee data was actually sent, just requested, whereas count afterwards doesn't guarantee intent, just what actually happened. The HBA doesn't know in either case if the data is good, so "testing" the data is not possibe. That is what UDMA is supposed to do. The host will allocate a buffer the expected length, then once the transfer was complete has to assume the data is good. A post-count guarantees that the expected size transferred and would be good error checking. A post-CRC guarantees data integrity across the interface and is also good error checking. So, an added count test would be good. Having a post-completion "Word Count" in the drive would be a good way to easily get this feature in to all existing systems, plus useable for the future. I'm amiss about the odd-byte issue floating around, since ATA is a word interface (well, ok, CFA is an exception). Anyone willing to fill me in (Hale, not you!)? A byte-based bridge must be responsible for dealing with the extra byte (when an odd-byte count was requested) since ATA cannot deal with it. Software must deal with it for the same reason the bridge must deal with it. MKE. -----Original Message----- From: Jim Castleberry [mailto:[EMAIL PROTECTED]] Sent: Friday, December 07, 2001 8:48 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [t13] a fix for imprecise UDma residue? Eschmann, Michael K wrote: >Only thing about the device sending a count before data is transferred is >not good error checking. If the DMA transfer dies before the count that we >indicate we want would be no different than saying nothing at all. A >post-check as Pat indicated would be better for DMA. If the host knows the count before the transfer can't it simply compare the expected to actual after the transfer and detect errors easily? A count before the burst would be better for bridges and DMA engines that aren't allowed to transfer the extra badding byte upstream on odd lengths, and that Pat wants to report accurate residues. And it's the same as the way PIO does it, so it's nothing new; I doubt there's any drive around that currently counts how many extra words the host sends/takes after the command is done. With a count afterward, the host has to buffer the last word of every read burst, go read the count, then commit the 1 or 2 last bytes. For writes it has to go read the count afterward and possibly back up it's residue and DMA pointers to account for the 0-4 extra words that might have gone over UDMA after the drive hit the end and did a Pause. Yuck. BTW, how did/does 1394's Tailgate handle this? That spec might be worth a read to see if there's a better way than changing drive specs and abandoning the installed base. jcastle Subscribe/Unsubscribe instructions can be found at www.t13.org.
