Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!hplabs!amdcad!phil From: phil@amdcad.UUCP (Phil Ngai) Newsgroups: net.micro.68k Subject: Re: BYTE "68000" issue Message-ID: <12925@amdcad.UUCP> Date: Sat, 6-Sep-86 02:15:11 EDT Article-I.D.: amdcad.12925 Posted: Sat Sep 6 02:15:11 1986 Date-Received: Sat, 6-Sep-86 07:53:27 EDT References: <3868@ut-ngp.UUCP> <1058@hoptoad.uucp> <1327@lsuc.UUCP> Reply-To: phil@amdcad.UUCP (Phil Ngai) Organization: AMD, Sunnyvale, California Lines: 63 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