🚀 go-pugleaf

In article <1327@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes:
>>
>>* Having an asynchronous bus has nothing to do with whether it supports
>>multiple masters.
>
>     John, are you sure about that?  I would think that an asynchronous
>with a processor like the 68000 would be advantageous,
{I'm a hardware designer. The first thing I do when I get an
asynchronous signal is run it into a synchronizer. I run the output of
that into another synchronizer. The problem with asynchronous signals
is that the circuitry receiving it may once in a while be unable to
decide what it saw. What happens then is a matter of luck. Often it
will oscillate for a while. This is called a metastable state.

This is a problem with all asynchronous systems. It is inherent in the
nature of the universe. What you can do is reduce the probability of
it happening to acceptable levels. This is done with two methods.  1)
Allow the circuit enough time to decide what came in before depending
on its output. 2) Use fast logic which can decide quickly.

The double synchronizer allows the first synchronizer to have time to
decide before the second synchronizer samples it.

Studies were done by a University in the mid-west (I think, anyone
remember the name?) which found a range of roughly 10E10 (plus or
minus a lot, I only remember it was a LARGE number) among the various
logic families' probability of going metastable.

>first in any multiple
>processor environment because the processor tends to need the bus at irregu-
>lar intervals.  If processing was synchronous then a rotation scheme would
>appear to me to be the best way to impliment multiple bus masters.  Because
>it's difficult to predict when the bus will be needed on the widely varied
>times in the rich 68K instruction set, a straight rotation looks very
>inefficient to me and thus multiple bus masters would not be very practical.

No, what you do is give the bus to the first one asking. If more than
one asks you have several methods available. The easiest, but not very
fair, is to rank the processors in a static priority. A more fair
method is to rotate the priority among the processors.  But since you
are only arbitrating among the processors who want the bus, there is
no inefficiency. There are no time slots which go wasted while a
processor is waiting as you imply in your rotation scheme.

>Nor am I convinced you're necessarily right.  It would seem to me that a
>multi-tasking environment would be a good way to utilize co-processing
>and/or multi-processing.  In fact, any multi-processing is multi-tasking
>in the broad usage of the word.

Faulty logic. A Cray is a computer but that does not mean a computer
is a Cray. Multi-processing is multi-tasking but multi-tasking is not
multi-processing.

To me, at least, coprocessor implies a very tight relationship between
the main and the coprocessor. The 8086/8087 fit this definition.  A
68000 and a Z80 do not. Your keyboard Z80 is a peripheral controller.
I would probably call the other Z80 an auxilary processor.
-- 
 Rain follows the plow.

 Phil Ngai +1 408 749 5720
 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
 ARPA: amdcad!phil@decwrl.dec.com