This message is from the T13 list server.
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.
