This message is from the T13 list server.
Pat, The case you mention is explicitly covered in the ATA standard. Obviously it is in the state that gets involved only at burst termination (indeed, actually only at burst termination on the last burst, when status is presented). The nominal transfer counts are gotten from the command parameters, which is fed into the beginning of at least the device state machine (as once again documented in the ATA standard). For those of you interested, the ATA standard actually contains a state machine for command execution. The only thing it lacks is a state machine for the actual DMA protocol. This is instead defined in words as an algorithm, with tables and charts for specifying the timing and critical timing points. Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Monday, April 08, 2002 4:13 PM To: [EMAIL PROTECTED] Subject: [t13] strictly state machines This message is from the T13 list server. > I advise being prepared for any eventuality. Me too. How then is it ok for an Ide data transfer state machine to assume that the host and the device have agreed in advance over how many bytes to copy which way? Viewing the data transfer as a state machine, the device may request more or less than the host expected, and when that occurs the state machine has to do something. Isn't it evil that the specification doesn't even mention these cases? It doesn't even say the host and the device may do as they please - not out loud anywhere. x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/ >>> McGrath, Jim 04/05/02 11:30AM >>> 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
