This message is from the T13 list server.
Pat, I don't understand you issue. The concern over too many bytes is ill founded. Under all conditions, both the host and the device know how many bytes are sent (they get this from counting the number of clocks). And if for some reason they did not (i.e. a double clock), then that is what the CRC is for - they will not match. You are really talking about the host SENDING more bytes than was specified in the command. For an individual burst this is never an issue. So what if the burst was a bit longer than desired? All ASIC designers know to allow enough FIFO space to make sure any overflows like that can still be received (indeed, in devices at least the FIFIOs are often very long nowadays for performance reasons). The only problem occurs if the host/device fail to keep track of the total number of bytes sent, and thus fail to halt the last burst in the command (the only one that has to stop at a certain point) at the right point. At least all devices I know do so keep track (hosts are more spotty on this), and so there is not a problem. As I mentioned before, the protocol does work in practice, does it not? Jim PS I expect that if a host on an OUT ever tried to send out more data than the drive expected, that the result would be an error posted by the drive. It is however possible that device designers will allow this and just ignore the overflow (since the CRC check is still valid). Note however that in both cases the protocol is not at fault - no one (especially the standard) ever said that the host or device could ignore the number of bytes in the command! And I don't know of DMA systems where you don't program byte counts! -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Friday, November 30, 2001 1:37 PM To: [EMAIL PROTECTED] Subject: [t13] yea, UDma doesn't count bytes well This message is from the T13 list server. (((Apologies in advance if you see this twice. I sent this four hours ago, it has not yet arrived back. Is that life on the Internet ... or is something really wrong? It's inconvenient for me because I'm quoting t13 traffic in offline correspondence.))) > > [EMAIL PROTECTED] 11/26/01 10:42PM >>> > > [any bridge to Ata/pi is an Ata/pi host] > > a bridge thing should be able to detect > > when ... and when a command has transferred > > the correct number of data bytes, etc, > Pat LaVarre 11/27/01 09:09AM > But I've been told counting the bytes moved is > an unsolvable problem in the UDma protocol > as it stands? I'm pleased to report I can now back this rumour up with specific detail. Anyone care to confirm/deny this defect in the protocol to which we all apparently gleefully agreed without mention? The issue arises with UDma hosts & devices that are so rude as to move one to four bytes of extra data past the termination of the last burst in a UDma transfer. If the transfer is a write, the host cannot know if the device wrote that data to the media. If the transfer is a read, the host cannot know if that data came from the media. By design, the UDma Crc offers no protection: that Crc includes every byte that crosses the bus, no matter if the device wrote/read it on the media or not. > ... Workarounds? Ick, nothing that's good & fast & cheap. The key phrase in all of these is "if somehow magically". 1. 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. 2. If somehow magically the host & the device can establish that they both agree that the transfer was a block transfer, and also that they both agree how large a block was for this particular transfer, then they can round off the apparent count of byte pairs to the nearest block. 3. If somehow magically the host & the device can establish a maximum possible byte count for the transfer, then they can round down the apparent byte count to that max. 4. If the device reported an error on a non-block transfer, the host & device are out of luck. They flatly cannot know how many byte pairs the other did move. Of course, if we really meant computers to be useful for more than games, we would design them in many, many different ways. I once met a designer who spoke of issues like this as "farts in the wind". Pat LaVarre x4402 Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
