Slashdot Mirror
Asynchronous Logic: Ready For It?
prostoalex writes "For a while academia and R&D labs explored the possibilities of asynchronous logic. Now Bernard Cole from Embedded.com tells us that asynchronous logic might receive more acceptance than expected in modern designs. The main advantages, as article states, are 'reduced power consumption, reduced current peaks, and reduced electromagnetic emission', to quote a prominent researcher from Philips Semiconductors. Earlier Bernard Cole wrote a column on self-timed asynchronous logic."
It'll be enlightening for people to just go there and read your information in context anyway, plus there are links to papers and stuff. You shoulda posted the link!!
Within the space of a single clock cycle, the Pentium (or other designs) might make use of asynchronous logic, but (and this is the important bit) the asynchronicity only exists within the domain of the CPU. The external interface to the CPU is still governed by a clock: you supply the CPU with inputs, trigger its clock, and a short (fixed) while later it supplies you with outputs. Asynchronous logic removes the clock entirely.
There was an article in Scientific American about this just recently...
In synchronous circuits, there are power spikes as most of the gates transition at the clock edge. It's interesting that this issue is becoming a major one. ICs are starting to draw a zillion amps at a few millivolts and dissipate it in a small space while using a clock rate so high that speed of light lag across the chip is an issue. Off-chip filter capacitors are too far from the action, and on-chip filter capacitors take up too much real estate. Just delivering clean DC to all the gates is getting difficult. But async circuitry is not a panacea here. Just because on average, the load is constant doesn't help if there are occasional spikes that cause errors.
One of the designers interviewed writes: "I suspect that if the final solution is asynchronous, it will be driven by a well-defined design methodology and by CA tools that enforce the methodology." That's exactly right. Modern digital design tools prevent the accidental creation of race conditions. For synchronous logic, that's not hard. For async logic, the toolset similarly has to enforce rules that eliminate the possibility of race conditions. This requires some formal way of dealing with these issues.
If only programmers thought that way.
The root problem is data transfer within the CPU, not data transfer between I/O devices.
The clock speed (now >10E9 Hz) is the upper limit of your chip's ability to move a voltage signal around the chip. Modern CPUs are "staged" designs, where data is basically broken into an opcode "decode" stage, "register load", "operation", and "register unload" stages. For a given stage, you cannot clock the output of the stage faster than the time it takes for the computations to complete, or you're basically outputting garble.
A synchronous design indicates that every flip-flop on the chip is tied to the same clock signal, which can mean one HUGE amount of wiring just to get everything running at the same speed, which raises costs. On top of that, you have charging effects due to the switching between HI and LO, which can cause voltage problems (which is why capacitors are added to CPUs) Then add resistive effects, where current becomes heat, and you run the risk of circuit damage. All of this puts some hard limits on how fast you can make a chip, and for what price.
Asynchronous chip design allows us to throw away the clock circuitry, and every stage boundary becomes status polling (are you done yet, are you done yet, ok, lets transfer the results). With proper design, you can save a lot of material, you can decouple the dependance of one stage on another, so the max instruction/second speed can now run at the raw rate of the material.
Yes, for many reasons which are somewhat glossed over in the article (I guess the author assumes you are an EE or CPE familiary with the subject). Here's a quick breakdown of the two major issues:
1. Power Distribution & Consumption - In a synchronous system, every single unit has a clock associated with it that runs at some multiple of the global clock frequency. In order to accomplish this you must have millions of little wires running everywhere which connect the global clock to the individual clocks on all the gates (a gate is a single unit of a logic function, sorta like a 0 or 1). Electricity does not run through wires for free except in superconductors. Real wires are like little resistors in that to push the current through them, you have to give up some of the power you are distributing (how much is a function of the cross-sectional area of the wire). The power which doesn't make it through the wire turns into heat. One of the reasons you can fry an egg on your P4 is because it's literally throwing away tons of power just trying to syncrhonize all the gates to the global clock. As stated in the article, in an asynchronous system, the clocks are divided up on a modular basis, and only the modules that are running need power at all. This design technique is already used to some degree in synchronous designs as well (sorta like the power saving feature on your laptop), but does not benefit as much since in a synchronous design must always trigger at the global clock frequency rather than only triggering when necessary.
2. Processor Speed - Much like the speed of an assembly line is limited to the slowest person on the line, so too is the speed of a CPU limited to the slowest unit. The problem with a synchronous design is that *everything* must run at the slower pace, even if they could theoretically move faster. In an asynchronous design, the parts that can go faster, will, so the total processing time can be reduced.
Hope that helps.
The largest ascynchronous project (to my knowledge)is the MiniMips that was developed at Caltech 1997 and has 1.5 M transistors. It was modelled after the R3000 mips architecture.
The best selling larg scale asynchronous circuit seems to be a micro controler that Philips developed and used in a pager series.
In most modern CPUs, all of those occur independently in different units in the pipeline.
But they still do their function once per global clock cycle. After that, they pass their results on to the next stage.
As a result, the clock rate is limited by the longest propagation time across a given pipeline stage. A solution that allows for higher clock speeds is to increase the number of pipeline stages. This means that each stage has to do less. (The P4 one-ups this by having stages that are the equivalent of a NOP just to propagate the signal across the chip. But they're still globally clocked and synchronous.)
P4 has (I believe) a 20-stage pipeline. (It's in that ballpark) - The Athlon is sub-10, as are almost all other CPUs. This is why the P4 can achieve such a high clockrate, but it's average performance often suffers. (Once you have a 20-stage pipeline, you have to make guesses when branching as to WHICH branch you're going to go on. Mispredict and you have to start over again, paying a clock cycle penalty.)
Shorter pipelines can get around the branch misprediction issue by simply dictating that certain instruction orders are invalid. (For example, the MIPS architecture states that the instruction in memory after a branch instruction will always be executed, removing the main pipeline dependency issue in MIPS CPUs.)
With asynch logic, each stage can operate independently. I see a MAJOR boon in ALU performance - Adds/subtracts/etc. take up FAR less propagation time than multiplies/divides - but in synch logic the ALU has to operate at the speed of the slowest instruction.
Most important is the issue of power consumption - CMOS logic consumes almost no power when static (i.e. not changing its state), power consumption is almost exactly a linear function of how often the state changes, i.e. how fast the clock is going. With async logic, if there's no need for a state change (i.e. a portion of the CPU is running idle), almost no power consumed. It is possible to get some advantages in power consumption simply by changing the clock speed. (e.g. Intel SpeedStep allows you to change between two clock multiplier values dynamically, Transmeta's LongRun gives you FAR more control points and saves even more power, many Motorola microcontrollers such as the DragonBall series can adjust their clock speed in small steps - One Moto uC can adjust from 32 kHz to 16 MHz with a software command.)
retrorocket.o not found, launch anyway?
I'm studying chip design and my supervisor scoffs at asynchronous logic. I don't have any real input of my own, but his view is that we've been waiting for commercially viable asynchronous designs for as long as cheap fusion, and neither has happened yet despite many loud enthusiasts.
One of the real problems of asynchronous logic is in testing. With synchronous logic your design is partitioned into registers and combinational logic. The combinational stuff can be tested at production by use of every possible test vector, while registers are rather easy to test. Together these two tests virtually guarantee that the state machine works. Do that for every state machine and you're done.
Asynchronous state machines, however, have no obvious way to break them down. You have to give them sequences of inputs and check their sequential outputs. Even if you think it's working you can never be sure, and what happens when the temperature changes? Race conditions can result in the state machine breaking under changing temperatures.
Synchronous design is a very mature field. Nowadays you can be sure that a design works before fabrication (well, almost.. =) and then synthesise it into gates that ought to work first go. If they didn't then AMD and Intel would go under pretty soon!Asynchronous design is hard and my hat goes off to the people who do it for a living. But the same amount of effort would result in far more development using standard techniques. I guess you really have to want to do it.
Yes, synchronous logic has serious issues with clock distribution, but it's still the most commercially viable design technique. The fact that your CPU is fully synchronous is testament to that.
So, which will come first: cheap fusion or reliable asynchronous logic?