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.
But how will we be able to tell time with our computers! Dear god no!
for the first guy who overclock's it ;-)
...maybe some day we'll actually get 64 bit processors for home use
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.
they can't take away the clock. how will i know what time it is?
Gyrate Dot Org - "Where high-tech meets low-life"
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
I have read this article, and it is a very cool technology. Portions of the UltraSparc IIi have gates (capacitance) in the datapath that let the chip capture state of a computation and finish the result later. This lets the chip do other calculations during the time it would usually be in the wait state. Like compile the bytecode to optimize a loop after iterations have begun, but before it terminates.
Wasn't the 68000 asynchronous?
The article talks about an advantage of clockless chips being the fact that you can do away with all of the overhead in sending out the clock signal to the various parts of the chip. It also discusses what kind data processing activities are more suited for clocked vs. clockless chips. To get a best-of-both-worlds chip design, what about farming out various responsibilities on the chip to clockless sub-sections? The analogy I have in mind is when I drop my laundry off at the dry cleaners. I am on a tight schedule, and I have a lot of things to do in a certain sequence, while the dry cleaners collects laundry and does it at various rates during the course of the day. This particular laundry of mine can be done at any point over the next 4 days, and held afterwards, just so long as I have the finished product exactly when I need it, Thursday at 4:15 p.m. Different people assign different limits on the time-sensitivity of their laundry. The clocked sections can drop off their data for processing, and pick it up when they need it, and what happens inbetween is up to the clockless subchip, which does more-or-less FIFO, but can be flexible based on the time-sensitivity of the task.
The man who does not read good books has no advantage over the man who cannot read them. - Mark Twain
withoutaclocksignal,howcanyoutellwhenoneinstructio nstopsandanotherbegins?
(kidding)
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
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
... won't the buss and storage devices be a bottleneck still?
Bring on the solid state storage.
----- Whats wrong with this picture? http://www.revoh.org:1234/whatswrong
- ClocklessCPU
- ClocklessCPU 2
- Super ClocklessCPU 2
- Super ClocklessCPU Turbo
- Super ClocklessCPU Turbo 2
- Super ClocklessCPU Turbo !!!
- Super Duper ClocklessCPU Turbo MAX
- Super Duper ClocklessCPU Turbo MAX 2
- etc. etc.
Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted.Kevin Nermoyle (Sun VP) advocated asynch at the 2001 uProcessor Forum. The biggest and most daunting objection I heard in response was that tool support would be a killer. There is no tool support for asynch design at the complexity level needed to do a processor. You're left to a bunch of Dr. Crays using the length of their forearm to resolve race conditions with wiring distance. Since a large portion of the industry would have to make the leap to get the tool guys to invest in development, this kills any realistic possibility of an overnight asynch revolution. Small niche applications will have to get the ball rolling on this. Even still, designer's would need to get a lot smarter to think asynch. Think of how many chip protocols rely on a clock. How do you do even simple flow control in a queue for example? Pipelining goes to pot - its a whole different world. My two-cents.. Loli
Why not have several smaller sections passing messages to each other? They could be clocked unclocked or just picking their noses.
Right now a network is a bunch of arbitrary speed systems just passing messages, can't we scale that down to the computer level?
It wouldn't even involve anything overly revolutionary.
...but what scale will I use to justify how cool I'm trying to be!?!?! How will people be able to judge just how much more successful they are than their fellow human beings.
I guess I'll just go back lifting weights, over compensating cars and the ruler. *sigh* I hate analog.
Well, its not like they are going to have no clock, obviously they'll have some crystals in there to keep other things synchronized. And lots of thing, especially interactive stuff needs accurate timekeeping (not to mention most of the chips in the overall system will need a clock)
autopr0n is like, down and stuff.
I have a professor here who swears by this asynchronous stuff. He told us that Intel actually developed an asynchronous version of the Pentium (I) processor. It worked just fine, and used less power than a normal clocked processor. Unfortunately, all of the processes and designs for everything else they were doing had to be redesigned for it, and it would have ended up costing a bundle in retraining and redesign in order to mass market the chip.
It seems to me that clockless chips like these would seem to work very well with MIPS style processors - where you have lots of little instructions. However, you can't take advantage of the extreme pipelining features that chips like the Pentium 4 use when you don't have a clocked design. It would take a lot of research and a lot of re-education to get the design engineers to start thinking asynchronously instead of clocked, but my professor seems to think that eventually there will be no other way to speed things up.
Its also like you'd be trading in one problem for a host of others. I remember doing tests on 1GHz clock chips, and those things had to be absolutely PERFECT in order work correctly on the motherboard. They ate up a lot of power too. However, an asynchronous design would have its own traps. You can design a state machine for it an then minimize the states, but glitches will do a lot more harm on a chip that is running asynchronously. Plus you have to take into account that chips run at different speeds at different temperatures. I think we have a long way to go in the quality of individual electronic components before we can actually implement a modern processor that is asynchronous.
By the way, that Professor's name is John McDonald, and he's here at Rensselaer Polytechnic Institute.
-Montag
Hopefully Sun's "ships" and "flotillas" won't go the way of the Spanish Armada;-) Will this be the new way to measure? "Sure this one has 10k ships, but they're only frigates. Even though this one only has 5k ships, they're all ships of the line."
If brevity is the soul of wit, then how does one explain Twitter?
withoutxxxx axxxxxxxxxx clockxxxxxx signalxxxxx ,xxxxxxxxxx howxxxxxxxx canxxxxxxxx youxxxxxxxx tellxxxxxxx whenxxxxxxx onexxxxxxxx instruction stopsxxxxxx andxxxxxxxx anotherxxxx beginsxxxxx ?xxxxxxxxxx
Because rephrasing your question as above is what synchronous looks like; every word has to be padded to the longest word length. Asynchronous is like normal written language; words end when they end, not when some 5 char clock says so. Another crude analogy is sync vs async serial comm, except using hoffman(sp?) encoded chars, so async can use variable length chars, but sync has to padd the short ones out to the length of the longest.
I tried underline instead of x but the stupid lameness filter objected/
Infuriate left and right
if we have clockless computers for the desktop, HOW will Intel and AMD market them?
After all, a large quick and dirty rating they have used for decades is the clock speed. Throw that away and what do you have?
I can see the panic in their faces now...
"It is a greater offense to steal men's labor, than their clothes"
It would be interesting to see some real-world speed results comparing an asynchronous and synchronous circuit with identical functionality, fab process, transistor size, transistor switching speed, etc.
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.
I am just curious. Would the way an asynchronous chip worked dictate anything about the instruction set of the chip? Would it be possible to use today's instruction sets in an asyn chip? Would you have to come up with something different? Would someone writing an asyn compiler have any special issues or optimisation techniques they would have to be aware of that would be inherent to the concept of the asyn chip itself?
Are there any "features" related to the asynchronocity of the chip that it would be possible to add to the assembly language of an asyn chip? Becuase individual sectors of the chip can function independently and not have to synchronize, can you kind of get a multiprocessing-within-a-single-chip effect? I.E. can you create a singular asyn chip split up into separate sectors, each of which functions as if it were an autonomous processor? Can you have one chip concurrently execute single threads?
If the answer to this last question is "yes", do you have to do this by organizing the chip such that the different sectors are basically seperate chips on the same cast, or can you just have it so that the exact borders of the the chip area working on a certain thread at a certain moment is reconfigured dynamically? Would it be possible someday to create a microchip whose internal execution model is somewhat like that of Cilk?
How does asynchronous design fit in with atomic-execution technologies like VLIW and EPIC?
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
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.
The Pentium IV is supposed to be partially clockless, but to the outside world, all the I/O is clocked, making it easy to benchmark. If the I/O, logic, memory, etc., were ALL clockless, how fast is the machine?
Government contracts of big systems are really picky about things like this.
I think marketing will be the most likely problem for this technology. (Interfacing to clocked equipment won't be.)
If you have looked at the "bucket brigade" graphic in the article, then you will know what I'm talking about...
Is it just me, or does that picture seem to imply that you get a lower "buckets per unit time" throughput from asynchronous processing?
I know that this is not the claim of the article... but it's still my gut reaction to the graphic.
"Gandy Dancers" (railroad manual track laying and repair teams) were so-called because the first part of their name was the Chicago tool maker that made track laying tools, and the second part of their name came from the fact that they worked to a rhythm.
A better analogy would be a work-content based multipath route, where the amount of time is based on the type of work to be performed.
This would have implied (correctly) that, in an synchronous system, you should be able to "make up for" slow elements by doubling them up: i.e., when you are faced with a slow section of pipe, rather than bottle-necking, make it wider, instead.
Or to use their analogy, if you have a slow guy, then get another slow guy to stand next to him so he doesn't bottlneck the brigade.
Probably a more apt analogy would be nice: it's hard to show throughput increases, except by number of buckets in the hands of the people.
-- Terry
Here's a somewhat shorter primer from Wired:
0 0.html
http://www.wired.com/news/topstories/0,1287,6179,
If your bitterest enemies are people who hack the heads off civilians, then I would say you're doing something right.
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
In the past I've mentioned here the role that popular publications like Scientific American have in creating hype. Be it the semantic web, nanotechnology, AI or asynchronous circuits, SciAm seems to focus on pie-in-the-sky ideas with a very small chance of success.
That would be fine if they acknowledged this in the text, but more often than not they take an extremely bullish approach and echo the wildest promises by the researchers as if they were to happen tomorrow.
Very smart people have been working for many years in asynchronous circuits, yet the likeliest scenario are hybrid designs mixing synch and asynch circuits (the asynch circuit stops the clock from propagating).
Why do SciAm and other such publications do this? According to Chomsky because they are told so by the trilateral comission. Personally, I think they do it because it sells magazines.
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.
I don't understand this at all - is it just Scientific American oversimplification? Why can't an Arbiter simply decide that if two pieces of data need to pass through the same component, it will let the left one through first this time, and next time there is a conflict it will let the right one through first (in order to avoid systematic "discrimination" against one part of the chip). This decision making process will always take the same amount of time.
Can anybody explain to me what I have misunderstood - I'm sure there must be something I'm not getting, otherwise Sun wouldn't be researching this one piece so deeply.
There's no reason for a sig here.
In 1993 I was a graduate student in the Caltech asynchronous circuit design group. That year we had a prototype asynchronous microprocessor that implemented a subset of the MIPS instruction set.
:-)
The guys in the lab used to demo this by hooking up an oscilloscope to show the instruction rate. They would then get out a can of liquid nitrogen, and pour it on the CPU. The instruction rate would climb right up... This lead to many jokes about temporary cooling during heavy loads. "Hey, get the ice cubes... He's starting gcc!"
I believe our group used a different basic latch design than Sutherland describes. We handled all bits asynchronously using three wires, one that went high for 0, one that went high for 1, and a feedback wire for "got it". His design looks like it could latch a bus of wires simultaneously. Forgive me if I'm wrong... it's been almost a decade.
One of the nice features of these chips is that they are tolerant of manufacturing errors. Often impurities in the silicon will change the resistance or capacitance of a long wire. In asynchronous designs, this just means operations that need that wire will be a little slower. In the synchronous world, either the whole chip fails or you have to underclock it.
A group of ex-Caltech graduate students started a company to sell these asynchronous processors. Details at Fulcrum Microsystems.
(For those at Caltech: Yes, that's me on the asynch VLSI people page. And yes, I wrote prlint. What an awful piece of software that was.)
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
They should.
One mechanism I came up with in my first year hardware course was to use "READY" lines for each component, which would toggle state when the device was actually ready for input. It was the responsibility of the individual components to respect this protocol and not try to do things faster than any device that it communicates with. The result would be that without parallel processing, the overall computing device would not function any faster than the slowest component. It worked for what I was doing in my class... but I'm not entirely sure how well it would scale to something many hundreds of thousands of times more complex. But I have no doubt that someone's come up with something that works if I could come up with that.
File under 'M' for 'Manic ranting'
No I don't, this is what I was told by my boss when I first started working in the traffic industry. We use AC power for all of our timing since it's FAR more accurate than a RTC. Cumulative drift in time is a very bad thing for us since the traffic controllers in a system would gradually get more and more out of step with each other.
Admit nothing, deny everything and make counter-accusations.
All the benefits this article touts about asynchronous designs are almost totally bogus, except the claim about power consumption.
As it stands now, it is more difficult to keep things happening in the right order in an asynch circuit than to route a clock.
The idea that clock has to operate only as fast as the slowest component--Well this is true, but it doesn't matter. The last design I did had numerous clocks in it. The fastest being in the tens of MHz (I know, not that fast), the slowest being less than 1KHz. The portions of my design that were able to run at high speed did. The portions that needed a slower clock got one.
And has anyone heard of a multi-cycle path? Just because a circuit can't complete its objective in one clock cycle doesn't mean you have to slow down the whole boat. If it needs more than one, give it two.
There are a lot of other aspects to be concerned about too... design validation (on paper, before building it), static timing analysis, fault coverage...
What does clock have to do with a turing machine?
A turing machine deals in discrete steps, but has no requirement for a constant clock.
Asynchronous logic always appears to be better than synchronous at first glance, but when you do the math, sometimes it isn't so clear...
Have you wondered why when traffic gets heavy on a freeway, it slows down? This is sort of like an asynchronous processor where every instruction is trying to get processed as quickly as they can (every driver is independent) but they need micro-synchronization to prevent collisions (brake lights, gas pedals). When the freeway is mostly empty, micro-synchronization works fine. However, as you approach the capacity limit, sometimes a global clock helps, sometimes it doesn't...
If you have a pipeline, you get back pressure waves as you approach the capacity which can make things slower than a synchronous system. If the processing topology is more complicated, it becomes even more difficult to analyze...
This effect is well known and affects things like processors and networks. Lookup articles on slotted ALOHA (a packet radio protocol) for some of the math if you are interested in some of the math behind this...
"Cockless Computing"?
There goes my sales to lonely Nunns.
Table-ized A.I.
I would think that pipelining would be a difficult feature to uphold in an asynchonous system. You can't really divide instrucitons into little bits of undetermined size...or mayeb you can, if anyoen can explain how one pipelines an asynchonous processor I would be grateful
I have written a paper and am writing my thesis on synchronous to asynchronous conversion. You simply write your design in vhdl/verilog/schematics and you get a self timed design out. I placed a mips processor through it and it was about 30% faster.
Mouse powered Chips, Open source Processors and Lego
Sorry I didnt post these sooner but I am at a asynchronous computing workshop.
If you are intrested in async then here is a list of cool websites:
Async home is the main website with resources events and background.
Amulet group have a selection of resources and news.
And if you want a laugh then check out rat powered cpus
Mouse powered Chips, Open source Processors and Lego
...if you can't define CLOCKS_PER_SEC
Why doesn't the gene pool have a life guard?
yep but you dont have to make each stage equal in time. so logical operaions happen faster and difficult arithmetic operations (e.g. 1-1) as fast as synchronous.
Mouse powered Chips, Open source Processors and Lego
Imagine working in async and once every 2 years someone on slashdot posts a message about async. Then 1000 slahsdotees who dont get out much and think theire experts about hardware will say something like "How do you tell the time?".
Their descussions continue untill they conclude between themselves that you cannot ever be sure if a register has returned back to the regbank and it will never work.
Ah well. BAck to work heh?
Mouse powered Chips, Open source Processors and Lego
I spent some time in the power distribution office of a local power plant, and they had a big indicator in red LEDs showing the AC frequency, which read 60.0000 most of the time, but occasionally I'd see it click to 59.9999 or 60.0001 for a moment, but I never seen an 8 or 2 on there...
Please consider making an automatic monthly recurring donation to the EFF
You can make anything in async that you make in sync.
Mouse powered Chips, Open source Processors and Lego
This is the point of asynchronous handshaking. You can do it across any speed components safely. Its request acknowledge wire pairs. Read my thesis, its a gentle inroduction to async.
Mouse powered Chips, Open source Processors and Lego
yeah but it will be slow and complicated.
You can do it by sticking latches across a few signals and drive then using a clock.
Mouse powered Chips, Open source Processors and Lego