This message is from the T13 list server.


All your comments are true (and many more), which is why I advise being
prepared for any eventuality.  Given the complexities of ASIC and firmware
design, it is often the case that even the designers do not know how the
entire system will behave until they actually test it - and then of course
they only get the behavior for that particular test case, with those
particular circumstances.

That's why sticking to a strict state machine implementation is the best way
to go.  If both parties follow the rules the standard, and of course
interpret it in the same manner (which is why the standard has to be written
rather precisely), then everything will work out OK.  That is, if there is a
failure in testing it will be due to an interaction between the device/host
and its interface component, not between the device and host.  And that in
turn is the responsibility of only one party (device or host), not some
mysterious interaction between the two.

Jim


-----Original Message-----
From: Pat LaVarre [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 5:13 AM
To: [EMAIL PROTECTED]
Subject: Re: RE: [t13] UDMA Bursts - Pause versus Termination


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

Reply via email to