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."
Isn't that when your boss gives you several conflicting ideas on how he wants a product to be implemented, all at the same time?
Isn't this the same as having a CPU without a timer? (i.e. no MHz/GHz rating).
On the flip side, the millions of simultaneous transitions in synchronous logic begs for a better way, and that may well be asynchronous logic
The advantage outlined here seems to be independant functionality between different areas of the PC. It would be nice if the components could work independently and time themselves, but is there really a huge loss in sustained synchonous data transfer?
From what I've understood, in most aspects of computing, synchronous data communication is preferable. IE, network cards, sound-cards, printers, etc. Don't better models support bi-directional synchronous communication?
Isn't this where the idea of digital logic really got started? At least its how it was taught when I was in school.
We even did some design work in async. Cool stuff. Easy to do, fast as hell...
Never did figure out why it never caught on. Except for the difficulty in being general purpose.. so easy of a job with sync logic. And i guess it does take a certian mind-set to follow it.
---- Booth was a patriot ----
Intel recognise clockless as the future, and hence the P4 actually has portions designed that are clockless.
Before know-it-all's follow this up with "but it runs at 2.xx GHz", let them please read an article on about how much of your chip is oscilating at that immense speed.
As it's said in the EE industry, "oh god imagine if that clock speed was let free on the whole system"
and it doesn't work all that great.
It usually goes like this: little head decides to take some action that big head later decides wasn't such a good thing to do.
Fortunately I've invested in a logic synchronization device, which I like to call "wife". Wife now keeps little head from failing to sync with big head through availability (not use) of tools "alimony", "child support", and "knife" (aka "I'll chop that damn thing off while you sleep!")
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!!
In a way, an asynchronous circuit design already is a parallel computer. An asynchronous machine contains many (largely) independent components that communicate with each other in order to solve computational problems more efficiently by breaking them down into small pieces and working on them in parallel.
In this context, your notions of parallel computing will change greatly. Currently, individual nodes in a cluster are islands of computation, separated by (comparably) vast distances. Messages between nodes take orders of magnitude more time than messages within a node.
When you set out to build a supercomputing cluster in the asynchronous world, ideally the entire cluster would be within a single die. Then the latency between nodes would be reduced to microseconds or nanoseconds, and nodes could split work more effectively. The high-speed buses and complex arbitration schemes required for asynchronous computing will be equally useful for designing massively parallel clusters-on-a-chip.
I'm wondering how asynchronous logic stand up against transiant errors induced by a cosmic ray?
On a synchronous circuit most of the time such glitch won't do anything because it won't occur at the same time the clock "ring" so the incorrect transient value will be ignored.
As the "drawing size" of circuits gets lower and lower, every circuit must be hardened against radiations, not only circuits which must go on space or in planes..
There was an article in Scientific American about this just recently...
I'm sure that many /. readers, like me, are wondering if asynchronous chips get faster if you pour liquid nitrogen on them.
Seriously though, does the temperature affect the switching time? Or does the liquid nitrogen trick just prevent meltdown of an overclocked chip?
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.
Am I ready for asynchronous logic? It doesn't really matter -- it can come along whenever it wants, and I'll come use it when I have some spare cycles.
Josh Woodward
Surely Digital Equipment Corporation's PDP-6 had it in 1963?
Or is this modern "asynchronous" logical some totally different concept?
"How to Do Nothing," kids activities, back in print!
Those of us that have been around the block more than twice know that asynchronous design has been the technology of the future for a long, long time. My personal experience goes back to the mid-seventies, but I'm sure there were asynch he-men doing their thing with vacuum tubes and RTL. :-)
The catch, then as now, is that asynch logic is just plain more difficult for our tiny little human brains to grok. This was true back in the days when humans designed their own logic, and it is even more true now when 99%+ of all logic is designed not by humans, but by logic synthesis software (Synopsys DC and Cadence PKS).
That said, there are always folks out there doing Cool Stuff w/asynch circuits. Hope that Ivan Sutherlands's group at Sun Labs survives Sun's recent massive layoffs.
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.
I couldn't agree more. I remember reading a comparison between the current state of AI and the state of early Flight Technology. (it may have even been here, I don't recall. I make no claim to thinking this up myself. Perhaps someone can point me to a link discussing who first thought of this?)
One of the reasons that early attempts at flight did not do well is because the people designing them merely tried to imitate things that fly naturally, without really understanding why things were built that way in the first place. So, people tried to make devices with wings that flapped fast, and they didn't work. It wasn't until someone (Bernoulli?) figured out how wings work - the scientific principles behind flight - that we were able to make flying machines that actually work.
Current AI and "thinking machines" are in a similar state as the first attempts to fly were in. We can do a passable job at using our teraflops of computing power to do a brute-force imitation of thought. But until someone understands the basic scientific principles behind thought, we will never make machines that think.
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?
Fourth, when an ANN is trained, every weight in the network is changed. In a biological brain, particular links form and are destroyed, but learning is not a global process. I'm not a neuroscientist, so if I'm wrong, someone please point that out.
Fifth, you can ask a human why he/she came to a particular conclusion. You can't ask an ANN why it reached a particular conclusion. Sometimes, analysis is possible on smaller networks. But for multi-layer networks with thousands of hidden units, this becomes impossible. I really don't think it's a question of computational power. I have a deep sense that somehow, biobrains are fundamentally different from their mathematical cousins.
I won't claim that ANNs have no place in thinking machines. But having worked with them extensively, I feel that, although they are extremely valuable computational tools, they are not a magic wand. Many pattern recognition and data organization tasks can be much better performed by traditional symbolic algorithms.
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?