Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site peora.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!hjuxa!petsd!peora!jer From: jer@peora.UUCP (J. Eric Roskos) Newsgroups: net.arch Subject: Re: Timing loops (H/W vs. S/W design) Message-ID: <1997@peora.UUCP> Date: Tue, 4-Mar-86 08:28:00 EST Article-I.D.: peora.1997 Posted: Tue Mar 4 08:28:00 1986 Date-Received: Wed, 5-Mar-86 05:34:12 EST References: <156@motatl.UUCP> <530@hoptoad.uucp> <613@sauron.UUCP> <566@hoptoad.uucp> Organization: Concurrent Computer Corporation, Orlando, Fl Lines: 40 John Gilmore (gnu@hoptoad.UUCP) writes: > Peripheral chips are driven by strobes from the outside world. In > almost all cases (except tightly coupled coprocessor style chips), the > peripheral chip does not tell the CPU when it is done with a request; > the system designer is expected to have read the data sheet and set up > the right number of wait states and such. I must disagree with this! Although possibly my confusion (and possibly part of the debate itself) may arise because we are thinking of different types of "peripheral chips". Peripheral chips that perform I/O operations -- UARTs, disk controllers, DMA controllers, etc. -- should certainly tell the CPU when it is done with a request. That is what interrupts are for! I think that is what the original poster was referring to. It would be bad to convince people who may design new peripheral parts that they should do away with the "ready" pins on their devices; if they did that, the ability of I/O software to work in a reasonable manner would rapidly diminish, especially for "multitasking" systems. On the other hand, wait states for slow parts are a different matter, and I think maybe that was what the above poster was referring to? Still, it would be far better to handle this in hardware -- for example, suspending the processor's execution if it tries to access the part again before it has completed the previous operation -- than expecting a software timing loop to do it. Of course, this may have an adverse effect in the case of real time applications, where you need to know how long it will take to perform each operation; you could suspend execution as soon as the original access is done, until it is completed, which would give a constant delay regardless of the time between accesses. But for many applications, you could do something useful during that time. -- UUCP: Ofc: jer@peora.UUCP Home: jer@jerpc.CCUR.UUCP CCUR DNS: peora, pesnta US Mail: MS 795; CONCURRENT Computer Corp. SDC; (A Perkin-Elmer Company) 2486 Sand Lake Road, Orlando, FL 32809-7642 LOTD(5)=O ---------------------- Amusing error message explaining reason for some returned mail recently: > 554 xxxxxx.xxxxxx.ATT.UUCP!xxx... Unknown domain address: Not a typewriter (The above message is true... only the names have been changed...)