This message is from the T13 list server.
> if ... independent state-machines to ... data > and to send commands ... Aye, the trouble common and recurrent in sloppy prototypes that caught me most unaware when first I began to work in mass storage was: As you increase the speed of the engine that moves status back in, you discover that the engine that moves data reports done prematurely. For example, maybe the data in has moved in towards the host from the Dram block fifo but hasn't yet left the Sram byte fifo, or vice versa: the data out has entered the Sram byte fifo but hasn't yet reached the Dram buffer fifo. This is the most common cause I've seen for moving less than the expected count of data without reporting an ERR. With this personal history of pain, I've accordingly learned to duplicate redundantly the logic of the firmware controlling the data engine, e.g. to see that DRQ is clear before asking to move good status back in. I was interested to hear people here speak of silicon that automagically reports good status, resorting to firmware only for errors ... I trust the designers of such silicon have been adequately informed by analogous personal histories of pain. I wonder how consistently people divide the work of drive firmware? Here, streaming read/write block data is another job, factory/field format is another job, and the leftovers of command parsing, status reporting, mode setting, and the rest of plug 'n play is another job. Sometimes one person does N jobs, but any two jobs recognised as separate can be assigned to separate people. And it's the interfaces between people that break down most commonly (often this is misstated as a claim that the interfaces between modules break down - yes that's true, no that's not the point). Pat LaVarre >>> Curtis Stevens <[EMAIL PROTECTED]> 02/12/02 10:34AM >>> ... The way IO and CD get used really depends on the design of the host. Since there is no CRC or Checksum on the command you send to the drive, there is no real way to validate that the right hing is happening. IO and CD give you at least some confirmation that the right thing is happening. Further, if the host side is designed with independent state-machines to read data and to send commands the IO and CD bits become very important. I am aware of some firmware that works this way... The firmware is not broken because IO and CD are well defined in the specification as to how they operate during data transfers. Subscribe/Unsubscribe instructions can be found at www.t13.org.
