This message is from the T13 list server.
Keith, You might be making this more complicated than necessary. For instance, command completion is only relevant in so far as it is an observable event on the bus. In order to complete a command the host has to read the STATUS register, and the device return appropriate status. By definition this cannot be done during an UDMA burst (i.e. the host cannot do a PIO read while DMACK- is asserted, since in UDMA the signals required - specifically DIOR- - do not exist). So there is an inherent time sequencing between any UDMA burst activity and either the device or the host participating in the command completion part of the protocol. Notice that the command completion sequence is not at all unique to UDMA - it is the same as that used for all commands. Indeed, one of the key principles behind UDMA is that any uniqueness is only allowed during a DMA burst - when you are doing PIO operations (whether for data or command information transfer), the rules that go back to the very first ATA implementations still apply. So in asking "who terminates a UDMA command" you are really asking the more general question of "who terminates any ATA command?" Jim -----Original Message----- From: Keith Clausen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 27, 2001 5:55 AM To: [EMAIL PROTECTED] Subject: Re: [t13] Command completion of an UDMA OUT burst ... This message is from the T13 list server. Hi Mark, Now you really have confused me...... "3.1.17 command completion: Command completion is the completion BY THE DEVICE of the action requested by the command or the termination of the command with an error, the placing of the appropriate error bits in the Error register, the placing of the appropriate status bits in the Status register, the clearing of both BSY and DRQ to zero, and the asserting of INTRQ if nIEN is cleared to zero and the command protocol specifies that INTRQ be asserted." By 'the action' I presume this includes, for a DMA operation, the writing/reading of all data - which says to me it definitely IS ALWAYS the responsibility of the device to complete a command (error or not) (save for resets). I see nothing which excludes the device from terminating the final burst - indeed, according to 9.15 10) a host can continue to send 'excess' data to the device and it is the DEVICE which terminates the burst (and by implication the command). "6.6.2.3 Ultra DMA burst termination phase rules : 2) Ultra DMA burst termination is not the same as command completion. If an Ultra DMA burst termination occurs before command completion, the command shall be completed by initiation of a new Ultra DMA burst at some later time or aborted by the host issuing a hardware or software reset to the device." It is not clearly stated that command completion includes a Ultra DMA burst termination phase (though it must). It is clear what happens if there is a Ultra DMA burst termination BEFORE command completion - what about the other case - Ultra DMA burst termination ON command completion? The clause implies this alternative scenerio exists, and that it is different. Given observations on clause 3.1.17. a statement along the lines of "only the device can terminate UDMA burst on command completion" or "only the host can terminate UDMA burst on command completion" or whatever are the rules need to be stated. I note that the term Command Termination isn't actually used (though the expression "termination of the command" is!!) - guessing closest is Command Completion - this is confusing! Given these observations, it still looks to me like the device must complete the command, (not the host) - which includes the device being the prime instigator to terminating the final burst. K On Nov 26, 11:57am, [EMAIL PROTECTED] wrote: > Subject: RE: [t13] Command completion of an UDMA OUT burst ... > Hi Keith, > > The ATA protocol is very straightforward. A device may only terminate a > command (ANY command) if a device-detected error occurs during execution of > that command (see the definition for "command completion" in clause 3.1). A > DEVICE SHALL NEVER, NEVER, NEVER TERMINATE A COMMAND UNDER ANY OTHER > CIRCUMSTANCES. > > There are only three methods described in the ATA/ATAPI-6 standard for a > host to terminate a command, "...by issuing a hardware or software reset or > DEVICE RESET command if implemented by the device." The protocol for each > of these is described in separate clauses. > > These concepts are so fundamental to the ATA protocol that I don't feel > there is any need to add any further description for them in the Ultra DMA > clauses. > > If you have any additional questions about Ultra DMA burst termination, > please feel free to call or send an email to me. > Regards, > Mark Evans > Maxtor Corporation > 500 McCarthy Boulevard > Milpitas, CA 95035 USA > Tel: 408-894-5310 > FAX: 408-324-7432 > > -----Original Message----- > From: Keith Clausen [mailto:[EMAIL PROTECTED]] > Sent: Monday, November 26, 2001 10:25 AM > To: [EMAIL PROTECTED] > Subject: Re: [t13] Command completion of an UDMA OUT burst ... > > This message is from the T13 list server. > > > Hi Mark, > > Think you'll find that the second question relates to my questions earlier > (~month ago) - it concerns the same product indeed! > > I think Stephane's second query may relate to who is responsible for the > command termination (rather than burst termination) - > > *** > the extract you gave clearly states there's a difference between burst and > command termination, but doesn't give detail on how command termination > actually differs (if at all). The command termination protocol should also > be > stated. > *** > > I think(?) it was established that the host should give the device > opportunity > to terminate the command, rather than assume it (the host) knows best. Of > course, the device and host should agree (... but the host can send 'extra' > data if it likes). If the device doesn't terminate, then the host and device > disagree and the ONLY recourse is a DEVICE RESET, s/w reset or h/w reset > (which > is sensible - after all the host and device disagree). > > Not sure how realistic this scenerio is, but ... assuming the host is very > eager to terminate the command - terminating the final burst when all data > is > sent before the device has had time to realise all data has been sent > (depending on device implementation) - is it possible a device may not do a > command completion (interrupt flag etc) under these circumstances and is > basically waiting for the next (empty!!) burst? This sounds a little > unlikely > (wrong) to me, but..... > > K > > On Nov 26, 9:22am, [EMAIL PROTECTED] wrote: > > Subject: RE: [t13] Command completion of an UDMA OUT burst ... > > This message is from the T13 list server. > > > > > > Hi Hale, > > > > What exactly is it that you think is missing? Clause 6.6.2.3 in > ATA/ATAPI-6 > > provides an excellent overview of Ultra DMA burst termination phase rules > > (even if I do say so myself). The content of this clause has been in > every > > A/A standard since the introduction of Ultra DMA. This clause reads: > > > > 1) Either a sender or a recipient may terminate an Ultra DMA burst. > > 2) Ultra DMA burst termination is not the same as command completion. If > an > > Ultra DMA burst termination occurs before command completion, the command > > shall be completed by initiation of a new Ultra DMA burst at some later > time > > or aborted by the host issuing a hardware or software reset or DEVICE > RESET > > command if implemented by the device. > > 3) An Ultra DMA burst shall be paused before a recipient requests a > > termination. > > 4) A host requests a termination by asserting STOP. A device acknowledges > a > > termination request by negating DMARQ. > > 5) A device requests a termination by negating DMARQ. A host acknowledges > a > > termination request by asserting STOP. > > 6) Once a sender requests a termination, the sender shall not change the > > state of STROBE until the recipient acknowledges the request. Then, if > > STROBE is not in the asserted state, the sender shall return STROBE to the > > asserted state. No data shall be transferred on this transition of > STROBE. > > 7) A sender shall return STROBE to the asserted state whenever the sender > > detects a termination request from the recipient. No data shall be > > transferred nor CRC calculated on this edge of DSTROBE. > > 8) Once a recipient requests a termination, the responder shall not change > > DMARDY from the negated state for the remainder of an Ultra DMA burst. > > 9) A recipient shall ignore a STROBE edge when DMARQ is negated or STOP is > > asserted. > > > > If this isn't sufficient, excruciating detail on exactly what is supposed > to > > happen in each specific case of Ultra DMA burst termination is provided in > > clauses 9.13 and 10.2.4. > > > > If, after reading these clauses, you have any additional questions about > > Ultra DMA burst termination, please feel free to call or send an email to > > me. In addition, I have found that using the "find" function in Word or > > Acrobat is most helpful when looking for specific details about something > > like this in these documents. > > > > Regards, > > > > Mark Evans > > Maxtor Corporation > > 500 McCarthy Boulevard > > Milpitas, CA 95035 USA > > Tel: 408-894-5310 > > Cell: 408-391-7805 > > FAX: 408-324-7432 > > email: [EMAIL PROTECTED] > > > > -----Original Message----- > > From: Hale Landis [mailto:[EMAIL PROTECTED]] > > Sent: Monday, November 26, 2001 7:51 AM > > To: T13 List Server > > Subject: Re: [t13] Command completion of an UDMA OUT burst ... > > > > This message is from the T13 list server. > > > > > > On Fri, 23 Nov 2001 18:36:46 +0100, Stephane Cattaneo wrote: > > >I have a question regarding the completion of a burst in udma out. > > >Who has to do the termination protocol ? The device or the host ? > > > > Here again is an example of something that is missing from the > > ATA/ATAPI-x documents. I have lost count of the number of times this > > question has been posted to the T13 list server. Anyone want to > > attempt to provide the missing information? Anyone know where the > > missing information should go in the document? > > > > > > *** Hale Landis *** [EMAIL PROTECTED] *** > > *** Niwot, CO USA *** www.ata-atapi.com *** > > > > > > Subscribe/Unsubscribe instructions can be found at www.t13.org. > > Subscribe/Unsubscribe instructions can be found at www.t13.org. > > > >-- End of excerpt from [EMAIL PROTECTED] > > > > -- > Keith Clausen, STMicroelectronics, > Mail: 1000 Aztec West, Bristol BS32 4SQ, UK > Email: [EMAIL PROTECTED] > Phone: +44 1454 462457 Fax: +44 1454 617910 > > Subscribe/Unsubscribe instructions can be found at www.t13.org. > >-- End of excerpt from [EMAIL PROTECTED] -- Keith Clausen, STMicroelectronics, Mail: 1000 Aztec West, Bristol BS32 4SQ, UK Email: [EMAIL PROTECTED] Phone: +44 1454 462457 Fax: +44 1454 617910 Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
