This message is from the T13 list server.
> Larry Barras <[EMAIL PROTECTED]> 12/03/01 03:26PM Thanks for speaking - on any reflector, I much prefer to see more than Two speaking, here now I think I've seen Four speak. > doesn't seem like a great example, > but I'll play your game a bit here anyway. > From what I can gather, you are unhappy > because the udma burst protocol > doesn't indicate precise byte counts. > I'll concede that you are correct, Ouch. I am NOT misunderstanding? This is true? We stand by "Ansi UDma allows the sender (host when writing, device when reading) to clock zero, two, or four bytes of extra garbage past the terminating pause"? > the host-side DMA hardware > *should* be capable > of indicating with a great degree of precision > the amount of data that has transferred. Yes. An uncelebrated discriminating factor in the quality of your quick-turn UDma silicon is: can your hardware not only count byte pairs but can it also separately report the count of clocks, if any, that occurred past the terminating pause. This matters because "If somehow magically the host & the device can establish that the sender of the data will never be so rude as to clock garbage, then both the host & the device can count byte pairs clocked. Then they both can know how many byte pairs the receiver moved." > the host-side DMA hardware > *should* ... > This should be true of a personal computer > or any protocol bridging device > serving as host to the ATA/ATAPI drive. Yes. > the host-side DMA hardware I'd say the receiver/sender symmetry of UDma implies what we need in host-side hardware we need likewise in device-side hardware? Of course, a bridge to Ide can fix only the host-side hardware. Specifically, if when writing we need the host to never send garbage write data so that we can know the device did not receive it, then likewise when reading we need the device to never send garbage read data so that we can know the host did not receive it. > The fact that there are DMA controllers > which lack this capability and systems > that have chosen to use them > is another argument altogether. Ok. > If someone is building a bridge > between different protocols, > then it is their job to perform > all of the translation > between the different capabilities > and error reporting/recovery protocols > between the devices. In theory, sure. > Unfortunately, the world at large > has been blessed > with a variety of bridge chips > that work with variable predictability. Yes. And if UDma throws indeterminate byte counts into the mix, this will get worse. Look at the trouble I'm having here persuading people that byte counts matter. If even the people who care enough to pay the cost of participating in talk like this can't easily believe how real a problem this is, how likely are bridge and device makers at large to look out to take care of it? More specifically, let's suppose bridging to AtapiUdma can be as transparent as bridging to AtapiPio except when the out-of-band communication of the host's expected and the device's actual count of bytes is incorrect. Who then will include, in a bridge, the cost and interoperability risk of trying to interpret Atapi commands? Noone. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
