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 ;-)
That will never happen. Users are aleady too used to having a clock in the computer to tell them the time & to remind them of their appointments. :)
...maybe some day we'll actually get 64 bit processors for home use
If you have a clockless computer than doesn't that mean everthing is running at the same speed and if that is true doesn't that mean good for the computer world??? If you think about it that sortof means that everything is going at the same speed which means no more lag in any of the programs we run as well that means that when something on the computer goes down then it may cause major side effects on the systems timing sending the whole thing out of wack? Oh well it does seem for the most part a good idea, every syustem will run a hell of a lot smoother and faster.....
If only it was truly external to a need for time.
"Why yes docotor, we will write that program!"
What makes you say that
"The printer just spit out the results.
Or; Why can't I set a global to tell myself not to run that devide by zero after the crash has occoured before I execute..?
-Gih
Loopy does not even begin to describe my current mental state.
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
Apple will certainly be please if it is still around since it will obviously end the megahertz myth, which giga-hurts the Mac.
But imagine: they will need to find real, actual benchmarks to compare the performance. This does not sound reasonable...
Or should these chips be called cockless...
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?
How will they market stuff now? They might hve to thing of real architecture solutions! Woe is them.
Jimmy _______ | | | \__/
Looking at the progression of programming languages it makes sense that the rest of the computer would follow. I don't know as much about older languages as I really need to make a strong argument but it seems that they are for the most part procedural and very few have any means for events or being driven by input or other actions. New incarnations of languages such as Java, C#, VB.net and even C++ (form my limited experience) are completely event driven or moving in that direction.
From a programmer's standpoint the code is generally easier to write and there is less of it with an event driven system. The other bonus is you aren't wasting cycles by waiting in a programmer created loop (I know there is a loop in there some where). With an asynchronous chip (and hopefully whole PC) one could design a truly event driven system. It would use very little in the way of resources when nothing was going on, instructions would only take as long as they need instead of having to wait for the clock in many cases and the logical design seems like it would be much simpler.
I hope asynchronous computing technologies become more available. The biggest obvious bonus is reduced energy consumption & heat output but I think and entirely asynchronous computer would be a marvelous piece of equipment and be extremely powerful for it's complexity.
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
My eyes just crossed through the words without really reading. Then my brain started puzzling itself about why were people taking their macho feelings about their hardware so far as to have a company explicitly launching a "Cockless" computer.
withoutaclocksignal,howcanyoutellwhenoneinstructio nstopsandanotherbegins?
(kidding)
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
Always sorta been curious but never bothered to take any initiative and actually look it up myself:
How precise is the frequency of AC from a typical power company? And how much does it change over time (if any)?
since the article is completely slashdotted... can someone who can figure out the google cache link post a link for the lazy ones among us?
-ac
With all that talk of spinning you make it sound like there's a little gerbil in my CPU.
-- Scientist: You aren't going to leave me here, are you? Boagh! Thump...
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
Perhaps they need asynchronus web servers -
Or maybe asynchronous users...
Where the fuck did you get that one from?
1. The so called 60 Hz sine wave hasn't got a 60.0 Hz frequency, since deviations from that are acceptable, so your clock wouldn't be precise. It's not guaranteed to be a perfect sine wave either.
2. Despite being relatively simple, it's much more complicated to measure the AC supply's frequency than to use a crystal for the time-keeping clock.
And this doesn't even start addressing issues such as possible power outages.
In the future, please refrain from posting about matters from which you know nothing about.
If memory serves... Isn't Intel already utilizing asynchronous technology in thier StrongARM line of processors? I thought they developed an asynchronous processor back in the early pentium days, but the costs of mass producing it were pretty steep.
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.
What I see wrong with asynchronous logic and the progression to faster technology is that it requires timing wires to measure the time it takes for a signal to propagate. That's a problem because then the assumption is that there should only be one signal on a wire at a time. That means the fastest speed between two circuits is dependent on the distance between them. That will severely limit the speed scalability of asynchronous circuitry! I'd like to see a high-speed CPU design take an example from networking-- have more than one bit on a line at a time. For example, suppose you have a highspeed network (i.e. 100Mbps or something similar). Along several meters of network wire there are multiple bits of data. I'm too lazy to calculate actual numbers, but it's probably somewhere around 70 or so bits. Each spread out by a distance of perhaps a few centimeters-- remember it takes time for electrical signals to propagate. I believe whoever develops an architecture allowing multiple bits on a CPU bus (like a LAN network) will win the race for speed.
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?
That sound nice except that it would mean that games would run unplayably fast, since there is no clock to regulate the game speed. How would you write a game (or even a video/audio player) so that it would only run or play at a given speed. I wouldn't want to watch a movie at 20x normal speed just because the hardware is capable of it (though running Final Fantasy 8 for the PSX at 5 times normal would be nice).
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.
try this paper. there are others, of course, this is only part of the architecture.
Give me an asynchronous life!!!
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.)
Somehow I don't think "advocates" is the proper word here. Perhaps the following rule will prevent you from looking like an idiot in the future:
;o)
If you don't know what the word means, DON'T USE IT!
Then again, this implies that you even know what you don't know....
Hic iacet Arthurus, rex quondam rexque futurus.
If you had a completely clockless system running at speed "x," whatever that means, how do you upgrade the same system with chips that are capable of running at "10x" speed?
Will slower clockless chips talk to/interface with faster clockless chips? How do you avoid overruns?
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
Back in the late 1970's - when I was first involved in "DP" (data processing), this type of technology was already being implemented in computers (which were all mainframes back then -except Datapoint, but that's another story). General Electric was using this concept in their GE 600 series, which became the Honeywell 6000 series, which begat Multics which begat UNIX etc. etc. etc. Anyhow, the only "new" thing about this idea is that its being implemented on a microprocessor. I've been waiting for micro-engineers to catch on; glad to see that at least someone finally has. On the other hand, this may be already in use at Intel or Motorola etc. but Sun has a blow-your-horn policy(?)
Use all the benchmarks we have today.
The clockless chip will still have instructions/operations, so the concept of MIPS, FLOPS, etc. hasn't gone anywhere.
You just won't be able to use MHz to do any judging, no matter how approximate it may be.
The URL of the website reminds me of a joke:
Repeat after me:
Ohwah
Toggoo
Sciam
Now, say it faster and faster out loud.
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
And help others to learn from their mistakes. Usually I'm just glad if people help me to improove. But "DON'T USE IT" doesn't really contribute to his / her learningprocess.
;)
;)
Ok. In the case of the 'what does this button do' mistakes you're right
I make mistakes. Why? Because I can
Privacy is terrorism.
Asyncronous
This
is a term
message
used to describe
is written
the ability to
asynconously.
do many things at once.
Thax remxxxx me of the old Forxx sysxxxx thax usex onlx the firxx thrxx letxxxx plux the numxxx of letxxxx in eacx worx. It souxxx terxxxxx in thexxx, but in praxxxxx if you keex it in minx it worxx quixx welx.
(Alsx, I thixx you meax "Hufxxxx encxxxx")
It IS slashdotted ... why is this modded troll?
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.
Do you have a citation for that? I'd be interested in knowing where/why that was mandated.
The whole network needs to in phase or else you can get some real hight loop currents and voltage spikes.
How will marketing types hype the processors without a my clock is bigger than your clock numbering system? People won't know what to buy.
Error Occurred While Processing Request Error Diagnostic Information Timeout waiting for request to execute The server is unable to fulfill your request due to extremely high traffic. Please attempt your request again (if you are repeatedly unsuccessful you should notify the site administrator).
DISCLAIMER:
I don't believe what I write, and neither should you.
If you change form synchronous to asynchronous isn't it going to be alot slow for the bigger programs that you use and faster for the smaller ones? If that is true then why would you do that, all of the newer programs a bigger therefor taking a longer time to load? IMHO that is pointless!
I use a yardstick myself...
Check out a power systems book. They'll most likely have something in there about it. At the very least they'll describe the extreme fine-tuning the power companies due to the line frequencies (fraction of a percent changes).
Higher Logics: where programming meets science.
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.
[Sarcasm]
I pride myself on having the latest and greatest! That'll just kill my bragging rights!
[/Sarcasm]
That is a good point. As is said in other posts a hybred chip would probably be the most success full. You will need a clock for anything that is time based. You may just be able to get by on a clock with say a 1ms resolution for timing things and controling program execution speed.
Currently a program doesn't send extra instructions to run at "normal speed" though it bases it's execution speed off the time kept by the OS. So even with an async chip you would still need a very accurate way to keep track of time.
-Eric Dalquist
In the near-term chips using this asynchronous approach will most likely still be clocked, but will have a number of different blocks with independent clocks, and some asynchronous hand-shaking interfaces between them. This is because pipelining is a useful technique for parallelizing operations at the instruction level, but is difficult to do without a clock. Without a clock you need to investigate wave pipelining.
Vote for Pedro
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.
I cannot believe that you meant to post that message as a response to my comment. Yeah, I remember my Intro to Digital Logic class, as well as my advanced VLSI Design class, but your points have no relevance regardless of how much education I've had. An overclocker is someone who makes the computer run faster than spec, post production, by setting the clock rate higher. I don't care about your points concerning the design of the chip unless you're suggesting that a person crack it open or something, which you're not. I'm not claiming to know more than you on the subject, or anything like that, but I would advocate debating on topic.
Grumble, Grumble
What is the difference between what you describe and a "Multiple Core" processor?
I believe you meant "Huffman."
It is like the Canadian Postal service. It gets there when it gets there (if they haven't lost it)... :(
How would the power user be able to keep up with the Jones when there are no numbers to compare. How would real time os be implemented ? The speed is non-deterministic!!! Fast != on time
Look at Chuck Moore's home page, at the 25x chip -- there ya go. This is not the first async chip Chuck's done. They go way back. Also have a look at UltraTechnology where plenty of that history is documented.
I finish when I'm done 'cause I'm clock free.
sorry
The code/proc could interface with an external timer so time can be kept.
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.
Good post. It deserves at least +2 Insightful.
Without some kind of clock chip (such as a RTC chip), it would be impossible to program games or any other software except by CPU speed. So even on a "clockless" system, you would have to keep the real time clock for controlling program delays, if nothing else. Of course, such a chip would not need to be as precise as current CPU clock chips, even 1ms precision should be good enough for most people.
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...
I remember getting interested in the idea of asynchronous computing back in my Acorn using days. At the time Acorn had set up ARM and sent the company off on it's merry way, but all the users and developers of Acorn machines were looking for something a bit faster - ain't that always the way. The two big things that were setting the community buzzing were the collaboration with Digital (the now well known StrongARM chip) and the AMULET (http://www.cs.man.ac.uk/amulet/) project at the University of Manchester. I've moved on from using Acorns but now own a number of ARM based devices - the Sharp Zaurus and Gameboy Advance. Forgive my soppy reminiscence, but it's good to see that even though Acorn themselves are no more (and even with RISC OS 4 the community is even smaller than it used to be) seeds which they planted and projects they were involved with are still going and being innovative. "From little Acorns grow...."
Can a clockless circuit be represented/simulated by a Turing machine (and thus any clocked digital computer)? Unless I'm not thinking right today, it seems to me like a Turing machine can only accurately simulate discrete systems. Sure, you could discretize the time steps of a clockless circuit simulation, but I can't think of how to do that without potentially losing accuracy.
The answer to this question may be relevant to other areas as well, as the brain could potentially be viewed as a clockless circuit (albeit a very complicated one with exotic operations).
I spend much of my time at work designing clock recovery circuits. Guess I'll be joining the unemployed soon?!?
Vote for Pedro
Wouldnt a async processor remove the need for task switching, scheduling? That would increase speed, efficiency. Yes - you might need thread, process priorities, but that could be achived via other methods. (Hmmm.. Does priority mean getting through the queue faster? probably..).
The OS would need some interesting work done - but I dont see why it couldnt insulate the programmer to a degree. The compiler would have to take care of the rest. The world runs event driven (async) GUIs now.. Yep - it wouldnt be simple at first, but it would be better.
Bring on the Async CPU - im ready for the next revolution. Async Linux or Async OpenBSD, Async X, Async what have you.
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...
Some here have recognized that you could speed it up by cooling it... But you'd almost certainly break it also unless the design was extremely conservative and thus not exploiting full potential. Complex asynchronous designs are very sensitive to the delays between components. Even if they all change by the same factor, the delays within components probably would not. An asynchronous processor that is designed without wide margins in this timing (and thus truly pushing limits) would likely need good temperature control to ensure accuracy. Wider margins = lower performance.
Heh heh ...he said "CLOCKLESS"...
everyone knowns ya gotta have a "CLOCK" to compute, baby.
Hmmmm... guess I better lay off the pron for a while.
I guess I've had one too many when the headline reads, "Cockless Computing." Oh well, a girl can dream...
-- Switchvox: Bringing big business phone sy
Well, according to the article, the speed of a synchronous processor is limited to the speed that the circuit can handle... so wouldn't an asynchronous processor be limited by the same factors?
"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
asynchronous chips only use the part of the chip that needs to be used. So when a computer is idle it would get cooler. Fans would not be requierd as much as a synched chip. I'm just hoping that a CPU fan would become obsolete or required to run only when high stress is put on the processer. Computing could be quieter.
(appended to the end of comments you post)
Well, FLOPS stands for FLoating-point Operations Per Second. It has nothing to do with the system clock, it's an empirical measurement of how many aritmetical operations a processor can do in a second. You can measure the performance of a clockless system just as easily as a clocked system. On the other hand, processor temperature would have a much bigger effect on performance with an asynchronous system, so there'd have to be some standard for what temperature you do your benchmarking at.
The original Howling Frog is a fictional character and has no UID.
They better do an extremely good design because complex asynchronous digital electronics are extremely difficult to debug due to the inherent complexity of simulation and testing involved, as electrical signals become events in themselves, actually!
I've been programming electronics, mostly EPLD for different designs and I've found that even inside the same chip. Although sometimes asynchronous digitals are very convenient (and very nice, too), you have to very much more careful and pay much more attention, which ends being much many development hours.
How many times can we beat to death the same piece of information? This is, at a minimum, the third time in the past year that we've heard the stunning "news" that async could potentially have speed advantages - and seen the endless user comments about design complexity, how it's been done with a K6/PI/PII/P3/Vic20, and how some guy's friend-who-works-at-best-buy thinks it is the wave of the future. Even the same jokes about telling time.
The editors at Slashdot really need to start doing some proper editing for once - the need for fast publication does not excuse monstrous sloppiness. Is it more important to get that article out in 5 minutes, or spend another 3 checking that you haven't posted the identical article a month ago?
Clockless Computing Wednesday November 14, @04:50PM
Clockless Computing: State of the Art Saturday September 15, @09:26AM
Some guy talks about computers without clocks Monday March 05, @09:29AM
I am hardly a fanatical reader with nothing better to do than bitch about trivialities. I am a casual, occasional reader, coming back at random intervals only to find essentially the same content.
While we are at it discussing the trends in CPUs, I had an interesting conversation with a friend about CPUs that are simultaneously multithreaded. The idea being that since most usage of CPUs is actually to process data, you can do it in parallel by having multiple Program Counters and multiple decoders, a similar superscalar architecture of your ALU with more registers in the register cache, and no interrupts. Without interrupts, you just need a thread to poll...
Apparently such work is being done at the University of Washington (in Seattle). Just imagine that now your computer CAN do work while it branches all over the place... because the other threads don't stop. This has to be more efficient usage of your CPU.
Moore's law states that the number of transistors that you can fit onto silicon doubles roughly every 18 months. That has nothing to do with how much you can clock it, or how long the delay between gates will be, nor does it solve the problem that you now have to have even more input lines and clock synchronization problems to deal with. I think that SMP on a chip will be more promising than asynchronous computing. We're talking about processors that run typical applications, not special case stuff.
-Mike F
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?
Way back in the pre-PC era, RCA had an interesting 8 bit microprocessor that I remember slowing the clock down to 60 hertz and it would function. I belive there was also a rad-hard one used in satellites. Very handy for reducing power consumption.
6F 9E A9 1E 96 9F 74 27 ED B8 81 6D 0C 4E 1E 78
My other Sig is a 229.
Thats the only clock i have in my room! How will I know what time Yu*Yu*Hakusho comes on. Dear god...
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
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
...it's pronounced 'noo-kyu-ler'
While I agree that you still use a FLOPS benchmark, there is still the issue that FLOPS, MIPS etc are not terribly good benchmarks. Especially for modern processor architectures which have seperate integer, FP and vector ALUs (G4). In the vector ALU case, it can process 4 FP ops per clock tick, 4 32 bit ops per clock, 8 16 bit ops per tick, or 16 8 bit ops per tick. How to you combine all these possible scenarios into one benchmark?
You might have multiple parallel load/store units. How do you benchmark these?
Also, how do you deal with issues such as cache. With cache now being on the processor die, should it be considered when creating a benchmark for a given processor?