🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #11936

Re: ACE (Was Re: Will NeXT survive? Grow with the times?)

#11936
From: Dave Haynie
Date: Tue, 04 Jun 1991 09:17
74 lines
4906 bytes
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.
Technical Details
Message-ID: <22152@cbmvax.commodore.com>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!dimacs.rutgers.edu!rutgers!cbmvax!daveh
References: <11399@uwm.edu> <32580026@hpcuhe.cup.hp.com> <4638@batman.moravian.EDU>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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