This message is from the T13 list server.
OK, I'll fess up - I'm the one that came up with the UDMA protocol (and specifically these sequences) years ago. Mark Evans is the keeper of the ATA standard in this area, and so is more current with the details of the document. But perhaps I can better explain how all of this works at a conceptual level. The termination of a UDMA DATA-OUT burst is divided into four conceptual stages - PAUSE, AGREEMENT, CLEANUP and CRC TRANSFER. In this case the concern is over both the host and device wanting to terminate the burst, so the PAUSE stage is fine (i.e. both have to be trying to pause the data transfer, which is always OK). So we then go into AGREEMENT. AGREEMENT is the toggling of the DMARQ and STOP lines so that both parties end up agreeing that this is a termination initiation, and not just a data transfer pause within a burst that can later be continued in the same UDMA burst. Note that it is an asynchronous event with a timing interlock. That is, it makes no different which party moves first - in all cases you cannot proceed to the next stage until BOTH STOP is asserted and DMARQ is negated (i.e. both have been toggled). The timing interlock starts whenever either party toggles its signal. So all you have to do is to monitor the other device's signal (device monitors STOP, host monitors DMARQ), and toggle the signal you control in a timely manner (meeting the interlock) to agree that this is indeed a termination initiation. Note that there IS NO OPTION TO DECLINE if the other party requests a termination initiation. If you do not negate within the timeout (Tli - 100 ns in the fastest modes), then we got broken hardware (i.e. gross violation of the protocol that indicates an environmental or logic failure). Another way of looking at this is that these two signals feed into a simply combinatorial circuit that detects agreement. So you see, it is really a lot easier than you think. If the other party moves first, then fine - your action is IDENTICAL whether you moved first or the other party moved first. And actions are the only thing that matter. Once you both agree that you are trying to terminate (STOP asserted, DMARQ deasserted), you are now in the CLEANUP stage. The host can safely assert HSTROBE - the device knows it is not a data transfer. Notice that the host can assert HSTROBE very quickly when it first saw DMARQ deassert (i.e. device initiated termination sequence) and then has to assert STOP and HSTROBE, but once again it makes no difference in the end. Another timing interlock (same value - Tli) prevents the host from taking too long. Note that at this point all of the signals are in identical states, regardless of which party started the termination sequence. The next step (CRC TRANSFER stage) is always initiated by the host, which can take its time (there is a minimum, but no maximum). I do think that adding some of these conceptual elements might help in the text. Note that PAUSE is already broken out as a distinct element, but the additional breakdown of termination into AGREEMENT, CLEANUP, and CRC TRANSFER might help clarify it for some folks, since the initiative changes (from a don't care for an AGREEMENT, to host driven for CLEANUP and CRC TRANSFER), and the device participates actively in only two stages (AGREEMENT and CRC TRANSFER). Of course, this is suggesting more work for the editor, which I will refuse to do as I value my life. Hope this helps. Jim McGrath -----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. Subscribe/Unsubscribe instructions can be found at www.t13.org.
