This message is from the T13 list server.
Thanks Mark for the helpful detailed description and sorts things out in my
mind - I'll give you a call if it fogs up again!
Meanwhile:
How critical is it to access the (eg) Alternate Status Register between bursts
- current thinking here is there's no need to perform such (REGISTER) access
until the data transfer is completed (as far as the host is concerned). The
only other scenario I can think of is the device is busy for longer than the
host thinks appropriate, so it does a check first before deciding whether to
reset or continuing to wait for the device.
In our (video) application, the system requires that the device doesn't remain
busy for 'too long' (implying a HD device is chosen which has a acceptable max.
limit) - if this limit were exceeded, then the system fails (loss of video) -
so in reality for us either the burst resumes in time or reset is issued, there
won't be an acceptable 'let's wait on the device for a bit longer' period, so
no need for REGISTER accesses between bursts. Our current h/w design is
optimised from this latter type of behaviour ('blind' complete or reset), to
actually perform a REGISTER access between bursts is possible, but requires
more software intervention.
K
On Nov 27, 3:00pm, [EMAIL PROTECTED] wrote:
> Subject: RE: [t13] Command completion of an UDMA OUT burst ...
> Hi Keith,
>
> Maybe I'm just to close to the trees on this one. I'll try to go up a
> level. Maybe it's easiest to think about the Ultra DMA protocol as being
> almost exactly like the Multiword DMA protocol as it has all of the same
> features (they're just implemented with a couple of additions). It is
> important to note that these are data transfer protocols only. These are
> not command protocols. How commands are issued and completed are described
> in other protocols. For Ultra DMA, a burst is intiated by the device
> asserting DMARQ and ultimately ends when DMACK is negated by the host (just
> like Multiword DMA). This encompasses the entire scope of these protocols:
> first assertion of DMARQ to last negation of DMACK.
>
> Either a host or device may pause either a Multiword DMA or Ultra DMA burst
> for things like providing a little time for FIFO synchronization. A pause
> typically lasts for only a very short amount of time and does not allow for
> the host to change the state of the address lines. A Multiword DMA data-in
> burst may be paused by the host not sending strobe transitions (i.e.,
> toggling DIOR) or an Ultra DMA burst (data-in or data-out) may be paused by
> the sender at any time by not sending STROBE edges. Because the strobe
> signal is always generated by the host for Multiword DMA, a device may pause
> a Multiword data-out burst by negating DMARQ. Because STROBE is generated
> by the sender for Ultra DMA there is a slightly different mechanism defined
> to allow the recipient to pause an Ultra DMA burst. HDMARDY is negated by
> the host to pause an Ultra DMA data-in burst, and DDMARDY is negated by the
> device to pause an Ultra DMA data-in burst.
>
> Either a host or device may terminate either a Multiword DMA or Ultra DMA
> burst at the completion of the data transfer for the command or for things
> like providing a way for the host to read the other device's Alternate
> Status register The mechanisms are slightly different for Multiword DMA and
> Ultra DMA (I won't go into detail here), but the end result is the same.
> When the burst is terminated, the host may change the state of the address
> lines, write the Device/Head register, etc. Though a burst termination will
> always occur after all data is transferred for a command, a burst
> termination may be initiated by either host or device after at least one
> word has been transferred. If all data for a command has not been
> transferred when a termination occurs, another burst shall be initiated to
> continue the data transfer in order to complete the command. Thus, a burst
> termination for either Multiword DMA or Ultra DMA does not necessarily
> indicate command completion. However, a burst must have terminated to allow
> the host to change the state of the address lines to read the device's
> status register after "command completion", but, once again, command
> completion is outside the scope of the DMA protocols. It really doesn't
> make any difference who initiates burst termination when all of the data for
> a command has been transferred.
>
> The protocols for command termination are the same for all ATA commands: 1)
> when done with all of the stuff it is supposed to do for the command (like
> transfer all of the requested data) or when an error occurs during execution
> of a command, the device sets or clears the appropriate bits in the Error
> and Status registers, including clearing both BSY and DRQ to zero, and
> asserts INTRQ if nIEN is cleared to zero and the command protocol specifies
> that INTRQ be asserted, and the host may then read the Status or Alternate
> Status register. The host reading the Status register causes the device to
> release INTRQ, if set.
>
> There is no protocol that allows a device to complete a command in any other
> way. If at some point something stops (like a host not responding for a
> very long time), the device is required to sit there and perform no action
> for eternity. Any device that does anything else is a BAD DEVICE (as Hale
> says). It's different for a host. If at some point something stops (like a
> device not responding for a very long time), a host may issue a hardware or
> software reset or DEVICE RESET command if implemented by the device.
>
> If you still have additional questions about this stuff, you might give me a
> call and maybe we can talk through this.
>
> Regards,
>
> Mark Evans
> Maxtor Corporation
> 500 McCarthy Boulevard
> Milpitas, CA 95035 USA
> Tel: 408-894-5310
>
> -----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.
>
>-- 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.
