Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.arch Subject: Re: Totally asynchronous computers Message-ID: <17214@cbmvax.commodore.com> Date: 8 Jan 91 05:52:09 GMT References: <3523@bruce.cs.monash.OZ.AU> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Distribution: comp Organization: Commodore, West Chester, PA Lines: 69 In article <3523@bruce.cs.monash.OZ.AU> zik@bruce.cs.monash.OZ.AU (Michael Saleeba) writes: >When I first started learning about computer architecture one thing struck >me as an incredibly obvious improvement - asynchronism. At that time I >was messing around with 6800s and such things where one clock cycle was >the same as one bus cycle. This seemed pretty silly since some operations >didn't even use the bus, yet they still had to hang around for an entire >microsecond. It seemed that a sensible architecture would only wait for as >long as was warranted, not some arbitrary time. Well, in lots of systems, these kinds of chips were driven in a somewhat asynchonous manner. In several 6502 family systems I worked on (same bus interface as a 6800 for the most part), we played games with the CPU clock. Basically, it would run ordinary cycles at the fastest clock speeds around, stretching part of the system as necessary to deal with slower devices. On such systems, real wait states were both hard to add and inefficient, so this was always the best approach. Modern CPUs are generally too dynamic to deal with clock stretching, and it's a bad idea anyway, since with big pipelines, you may have six things happening at one, only one of which is an external bus cycle. >When the 68k came along I was pleased to see that it had provision for >asynchrnous bus timing. Essentially this was due to the processor clock being >so much faster than the usual bus cycle. Even so, most designs used >synchronous circuits to simplify design. And these days asynchronism has >basically gone by the wayside in favour of things like burst modes. >Still, the basic concept still applies. Why not design a processor without >any sort of clock at all? A processor which is based on the thought that >you shouldn't have to wait any longer than absolutely necessary for _anything_. It might be kind of difficult for a processor to work this way. The hardest part of an asynchronous system is generating the timings -- delay lines are easy to buy for a systems design, but did you ever try to build a really tight one, on a chip. Whereas, a clock is easy to build timers, state machines, etc. with. I think asynchronous systems certainly have their place, though. In fact, the Amiga 3000 expansion bus protocol (called the "Zorro III" bus) I designed is completely asynchronous. A bus master and bus slave negotiate various phases of a bus cycle with different strobe lines. So a bus cycle need only take as long as the fastest bus master/slave combination, but if slower devices are on the bus, the cycles are naturally extended. Of course, reality sets in when you have to put something synchronous, like a 68030, on as bus master. The theoretical maximum speed of the bus is 50 MB/s (excluding burst cycles), the maximum speed the current 68030 bus-master implementation can hit is around 20 MB/s. Though many I/O and memory devices work very naturally as asynchronous slave devices. >It'd be really nice to be able to accelerate your machine by just popping in >a faster processor or faster RAM and watching things just happen faster without >any extra twiddles. In theory, that's what happens on a Zorro III bus. If you add a faster bus master, any memory boards capable of going faster do so. Then you add faster memory, and jump up again. Of course, if the bus master is a 68030 or similar synchronous device, things get quantizied into 68030 cycles -- you'll run in 40ns quanta on the current 25MHz system, though that's just an implementation detail, not part of the bus specification, and a different bus master might work much closer to the asynchronous ideal. > Michael Saleeba - sortof postgraduate student - Monash University, Australia > zik@bruce.cs.monash.edu.au -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "Don't worry, 'bout a thing. 'Cause every little thing, gonna be alright" -Bob Marley