This message is from the T13 list server.
Without disagreeing with the claim that pause vs. termination by printed spec "should not" much matter, back in the real world I too would enjoy hearing "under what conditions a device would typically terminate a UDMA burst." I'm interested in part because I imagine visiting such conditions would be a cheap & easy way of beginning to see if a particular host can cope with more or less arbitrary termination? Myself, I've not spent much time with bus analysers and Udma devices. But I've heard of devices terminating at will, because of trivial internal provocations that would appear as random noise to a host. For example, I hear of devices that terminate at physical discontinuities in memory e.g. before wrapping around the end of a circular buffer, e.g. between header/ pages/ fields of data copied in that isn't read block data. And I hear of people who include in the qualification of a host a device designed to terminate arbitrarily ... because some so-called "compliant" hosts that in fact do trip over such rudeness from a device e.g. by quietly dropping/ repeating/ otherwise corrupting bytes of the data stream. And I can't remember if we here resolved the question of whether occasionally terminating in order to trust less bits to any single Crc was a good thing. (I know Atapi can ask for xFFFF blocks per command, I think I remember 48 bit Ata can likewise.) Can anyone comment further? Curiously yours, Pat LaVarre >>> McGrath, Jim 04/03/02 16:29 PM >>> This message is from the T13 list server. Mark, A device (or host) can terminate a burst at any time, for whatever reason, by following the protocol in the standard. I'd strongly advise against reading anything into that event other than that the device/host did not want to transfr more data at that time. If the command is to continue, then eventually another burst will be initiated (once again, as specified in the standard). If not, then the command can be terminated as per the standard (typically with a device posting status after getting the host's attention, with an interrupt if they are enabled). The key thing here is just to treat your implementation as a state machine - there is no need to understand why something happens, just embody the protocol in the standard. Note that while the bus is clear (i.e. no burst active), other activity can take place - this is covered in the overlapped and queued commands. But as I said, this is just one of a lot of possible reasons for multiple bursts during a command. Jim -----Original Message----- From: Mark Sawyer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 03, 2002 8:59 AM To: [EMAIL PROTECTED] Subject: [t13] UDMA Bursts - Pause versus Termination This message is from the T13 list server. Hello, T13: The question of pausing versus terminating a UDMA burst has come up on a project I am involved with and I would like to ask the T13 reflector to help me understand the differences. The project involves custom IDE/ATA/ATAPI hardware and in-house firmware development. I have read the relevent sections of the ATA/ATAPI-6 specification (paragraph 6.6.2). As I understand it, a UDMA burst termination is not the same as command termination so it would seem to me that the intention of the device would probably be to complete the command under normal circumstances. I would like to know under what conditions a device would typically terminate a UDMA burst. Is there a benefit of one method over the other? Is it common for a device to choose burst termination as a method of flow control? Assuming that a device terminates a burst, would it be safe to say that the HOST could choose to utilize I/O resources for I/O with other devices whereas during a pause the ATA bus is still deicated to UDMA with the device? Thanks, /mbs --- Mark Sawyer Sawyer Software Solutions, LLC 2 Lincoln Drive, Bow, NH 03304-3209 Tel: 603-228-9214 / Cell: 603-496-3509 / FAX: 603-228-4810 --- AOL's AIM: FirmwareWizard
