Slashdot Mirror
Clockless Computing
ender81b writes "Scientific American is carrying a nice article on asynchronous chips. In general, the article advocates that eventually all computer systems will have to move to an asynchronous design. The article focuses on Sun's efforts but gives a nice overview of the general concept of asynchronous chip design." We had another story about this last year.
For any large project (such as an MPU), using asynchronous logic isntead of synchronous for the entire thing means it goes from being "merely" really-really-hard to damn-near-impossible.
Yet another old idea revived. The Amiga's Zorro expansion bus was asyncronous and plug n play in the 80s (although the rest of the machine was clocked).
To clear a few things up, just because a processor/motherboard is "clockless" does not mean it won't be able to tell time. They can still use the 60 Hz AC signal for ticks.
This is really cool. I was learning a little about asynchronous systems in my Logic Design and Computer Organization class last fall...they seemed pretty cool on a small scale, however they could get really difficult to work with when you're dealing with something as complex as a processor.
"I may be quite wrong." - Socrates
Wasn't the 68000 asynchronous?
After reading the article, I have to wonder why asynchronous processors (or smaller logic devices, such as ALUs) haven't been considered before. The ideas have certainly been around for awhile--and in fact, asynchronous is intrinsically simpler than synchronous logic. The only conclusion on this I can reach is that while asynchronous designs may be "simpler" in theory, in that they don't include a clock pulse, they are much more difficult to work with in practice. Here's an example for those of you that have worked with logic design: try creating the logic for a simple vending machine that dispenses the product whenever a combination of coins (triggered by 3 switches, quarter, dime, and nickel) adds up to $0.50. Which would you prefer to use--synchronous or asynchronous logic? I know when I did this example I got myself stuck by using asynchronous logic, because while asynchronous logic meant less memory states (all states above $0.50 were treated the same), it also meant lots of added complexity, which I didn't need for the problem at hand.
I foresee lots of bugs, but if they can pull this off, more power to them.
"I may be quite wrong." - Socrates
It's dead accurate. By law, the number of zero crossings on an AC line must be 10368000 every day. If there are too many in the morning, they have to make up for it that afternoon.
But I think an asynchronous computer would still use a RTC to keep track of calendar time. It has to keep time even when it's turned off.
Admit nothing, deny everything and make counter-accusations.
A while back I saw a whitepaper on an asynchronous design, but it was being done for low power applicatios. Basically, you had two lines for each bit. Condition 00 wasn't allowed and could be used to detect faults. 10 was one, 01 was zero, and 11 was idle. Nothing would happen until one of the lines dropped, so there was no clock but the CPU still knew when it was time to do something. It was a fully static design where no power was being used unless there was some user interaction. You could run it off a few nanoamps, so a piece of citrus fruit would run it until the fruit rotted. Simple chemistry.
I think this was from Seiko-Epson. I might have the states screwed up but that's the idea.
An industry standard benchmark (SPEC CPU benchmark for example) will be used.
This of course has problems because a lot factors into the speed of a computer. For instance motherboard chipsets will become increasingly important.
The famous PDP-6 was asynch logic. It made a very fast machine out of very few transistors, but was a nightmare to maintain. The follow-on PDP-10 was syncronous logic.
There must be some history out there somewhere of the problems DEC had with the asynchronous logic. Any old MIT research notes?
Despite the marketing problems associated with clockless machines (as a one-time computer retail sales guy, it was easy to talk a 1st-time-buyer into upgrading from the 800MHz system for the identical 900MHz for $50 difference) there are some other asynchronis aspects which may throw a wrench into design. First, if the chip is asynchronous, there must be a way to signal that the chip is ready for the next instruction - i.e. a "ready" line. Similarly since everyonw is pumped about the chips coming out in the last few years which execute multiple instructions simutaneously in different parts of the chip (think pipelines) there would have to be several of these signal lines. This will require additional logic circuits simply to decode these lines and figure out what instuctions can be executed, where they can, when they can, and so on. A related problem occurs with large, time consuming instructions which require the majority of the chip to execute. It would be difficult to implement a system which is by its nature asynchronous with a system of semaphores and time-estimating logic. And how much faster would this type of design actually be than a RISC based chip with a fast floating point unit. Since flops are typically the operation bottleneck in a new breed of processor, are we really saving time? I realize that the whole presumption of an asynchronous chip is that in traditional clocked chips we have to wait a finite amount of time (usually determined by the most complex operation) for every cycle, even if the op can be completed in less time. But personally I don't think that we'll see these on the market for at least ten years (well... maybe in a few microcontrollers, but only for really, really specialised tasks). Still it's good to see a few novel ideas (or in this case applying an old idea on a completely different scale) in this industry of re-packaging buzzwords.
"A dictatorship would be a heck of a lot easier, there's no question about it." -George W. Bush
The problem with slapping active cooling on an asynchronous chip is that the chip will *stop* working if it gets too cold, just like if it gets too hot.
Here's why:
There are two main aspects to consider in an asynchronous chip, gate delay (the time for a gate to open/close) and propagation delay (the time it takes for a signal to go from one gate to the next).
Asynchronous logic works by carefully arranging the length and geometry of the wiretraces between gates, so that the signals coming from those traces all hit their target gate (nearly) simultaneously.
The problem is that gate delays are affected by temperature differently than propagation delays. They both get faster with cooling, and slower with heating, but they do so nonlinearly, and at *different rates*. And asynchronous logic requires those rates to be carefully matched. Change the rates too much, and the chip breaks.
Synchronous logic doesn't have this problem (as much), because the whole point of latching everything between clock cycles is to give the slower signals time to catch up to the faster ones, and to force them all to wait up until everybody is ready (at which point the clock releases the latch, and the next cycle starts). But this has the downside of the extra wiring, circuitry, and power required to run all the clock lines and latches.
If you want to get rid of the bathwater, you've got to throw out a few babies.
How would an asynchronous process affect determinism requirements, such as those of a hard real-time system?
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
Unless I missed it, there was no mention of Theseus Logic's Null Convention Logic at all which is a real disappointment. Theseus has one of the few approaches that doesn't require a PhD-level of education to understand and design in.
-- Bryan "TheBS" Smith
Independent Author, Consultant and Trainer