This message is from the T13 list server.
Pat, Your experience with DATA IN (i.e. you acting as a receiver) in PIO, and devices wanting to pause on block boundaries, is due to two underlying issues. First, devices read/write in blocks, so it is natural that they have some internal pauses at those boundaries. Second, in PIO the receiver in DATA IN is driving the transfer (i.e. supplying the clock). So if you just keep on clocking in data assuming the the device is keeping up with you, you can run into problems. Since you do not want to be checking device STATUS every word you clock, the heuristic people use is to check it on block boundaries. They assume (correctly) that if a device can start a block transfer it can finish it (indeed, for ATA that is actually the definition of a block - the unit you can transfer without the need to check for status). In UDMA one of these issues does not exist - the device is clocking the data to you, so if it needs to pause on a block boundary it just does so itself. If for some reason it continues to clock data when it actually has none to send - well, that's a broken device. Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 13, 2001 9:06 AM To: [EMAIL PROTECTED] Subject: [t13] significant byte counts other than the total This message is from the T13 list server. > "Mcgrath, Jim" <[EMAIL PROTECTED]> 12/12/01 07:44PM > a host with small amounts of buffer memory > can set up a physical buffer smaller > than the command transfer size Yes the asic's I work with are silicon-bound rather than i/o-bound in part because their buffers are small and inside - in the 2KiB to 32KiB neighbourhood: they don't have enough pins to connect to a cheap parallel memory outside. I didn't mention this because I didn't know it was significant. >> [EMAIL PROTECTED] 12/12/01 06:57PM > Do you think that a DMA burst > is always equal to a media data block? ... not Agreed, thank you for clarifying. > a DMA burst ... a media data block ... > there is *NO* relationship between this two things. In Pio many of our asic's pause at block boundaries in order to TalkLikeWindows. We have a history of pain involved in enumerating which Pio devices shipped by other people behave badly if you don't pause at block boundaries. I'm clear on how a UDma sender can pause at block boundaries ... I'm not clear on how to use this history of Pio pain to guide life as a UDma receiver. My best guess is to have the receiver try to cooperate with a sender who delays for at least a turnaround at block boundaries, for example after bursting one block while still reading the next from slow media. I figure if the receiver always pauses transfer except when a whole block is free, if the sender always delays for a turnaround at block boundaries, then all pauses will occur on block boundaries, which shouldn't matter, but might. Clearly a better way to TalkLikeWindows would be to add more buffer, but that would cost dollars, so I can't effectively advocate that until after I actually prove we need to use Dma to connect with devices broken enough to need to connect to large buffers like Windows has. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
