Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!dimacs.rutgers.edu!rutgers!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.arch Subject: Re: ACE (Was Re: Will NeXT survive? Grow with the times?) Message-ID: <22152@cbmvax.commodore.com> Date: 4 Jun 91 09:17:53 GMT References: <11399@uwm.edu> <32580026@hpcuhe.cup.hp.com> <4638@batman.moravian.EDU> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 74 In article <4638@batman.moravian.EDU> halkoD@batman.moravian.EDU (David Halko) writes: >In article <32580026@hpcuhe.cup.hp.com>, edwardm@hpcuhe.cup.hp.com (Edward McClanahan) writes: >> peter da silva writes: >> > The NeXT and the Amiga 3000UX have the same problem here: they're 68000 >> > based, so you won't expect any outstanding improvements in the next few >> > years. Even if NeXT and Commodore make like Sun and switch to RISC processors >> > your existing machine is likely to be left behind. Though the asynchronous >> > bus on the Amiga means that a RISC coprocessor board would be quite a >> > workable compromise. The NeXT bus is much slower, more designed as a >> > peripheral bus instead of a general backplane like the Amiga's. >> Is this true? I understand that NeXT uses a 25MHz NuBus (2.5 times the NuBus >> used in the Mac II series). Actually, I've heard both that the NeXT uses a 25MHz NuBus clock and that it uses a 12.5MHz NuBus clock. Anyone know for certain? >This upsets me since the relative performance of the 68040 over the 68030 >was over a 100% improvement in speed at the same CPU speed, according to >some of the journals I read about 1 year back. At least. But everyone reads specsheets these days, and when you see specsheets for HPs and MIPS R4000s and all, the 68040 is judged only a small improvement. When you have one one your desk, you find it a big improvement. Everything's relative... >A 25 MHz backplane is a quick backplane, definitely not slow! The analog bus, >while superior in many ways, doesn't mean that it is any slower. I syncronous >25 MHz bus and asyncronous 25 MHz bus should be about the same speed, but >the analog bus should be slightly slower due to the handshaking needed which >is not required for the syncronous bus. Am I off target here? Analog bus? We're all digital here, really. The Amiga 3000's expansion bus was designed as an asynchronous bus for a number of reasons. First of all, your NuBus-style synchronous bus is always tied to that bus clock. You get into ugly synch-up/synch-down delays unless the bus clock and the processor clock are derived from the same base clock. On the 3000's bus, there are no inherent synch delays, though there may be in any given implementation of master or slave. There's also no inherent clock; as long as you meet setup and hold times for a couple of strobes, you're golden. So while the current system drives the bus based on a 25MHz clock, a future system or bus master could drive it based on a 50MHz clock. Because of the handshaking, slaves will work to the best of their ability with the current bus master. >The main advantage of an analog bus is the ability of the other cards over >the bus to run at a slower speeds. All the cards on the bus who are using >the bus (master and slave card during the communication) operate as fast >as the slowest card can communicate. Actually, on the _asynchronous_ bus, the speed of any given transaction is determined by the master and slave involved. Slave and masters not involved in a bus transaction have no effect on the speed of that transaction, but all masters and slaves will be able to communicate with one another. >With a syncronous bus, all cards must operate at the same clock rate, which >means problems when you start increasing the clockrate of the CPU on the >bus, in general. Slaves certainly can add wait states, of course. But in general, clocked buses define a maximum clock rate. Beyond that rate, nothing is expected to work. The advantage of a synchronous bus is generally that it's easier to design for; all your timing can be derived from a bus clock. In the A3000 bus, we did attempt to keep some of this flavor by providing strobe edges where you need them for bus events. Synchronous buses often allow the bus clock to be used for state timing, which is impossible on the asynchronous bus. Not every card needs a state clock, but those that do must provide their own and resolve any synchronization issues, thus making the asynchronous bus sometimes more complicated to design for. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "This is my mistake. Let me make it good." -R.E.M.