Clockless proccesors?

[Cristatus]

First of all, for me and most of the AT'ers, what difference does the clock speed of a proccer make?

In relation to the above, how can you have one that is clockless? Wouldn't that just mean 0 clocks, which means that nothing is being done?

edit: forgot to mention, this is what got me thinking

 

[krotchy]

I suppose clockless could essentially be a processor that runs at the speed of propogation. This is technically possible, as long as all wire lengths and transistor locations are 100% precisely designated. This would be a nightmare to design however.

Essentially if this were to happen though, you would still have some finite rate which you could call a clock rate, based on the speed of light (or more specifically propogation in a wire/optical circuit)

As far as that article is concerned, the processor they are talking about seems to be basically a single stage processor. So everytime you give it a command it executes the entire command at that moment. This would still have a finite speed for commands you could issue it, which I would consider a clock rate.

 

[Bassyhead]

The first digital computers utilized combinatorial logic, not sequential, so they didn't require a clock however they weren't general purpose computers. A modern clockless processor is pretty impressive. I believe Epson made a clockless 8 bit processor that was physically flexible. Wouldn't be possible with a clocked design. Basically with a clockless processor, the circuit applies the inputs to the processor, flags a bit to signal that the input data is ready, propagates through the processor doing work, then the output bits are presented and another bit is flagged to signal that the output data is ready.

 

[TuxDave]

Well, if a processor is clockless it doesn't necessarily mean it doesn't use sequentials. It could imply that there is simply no central free running clock distributed across the chip. Most modern asynchronous processors that I know still want to take advantage of pipelining so they want to keep sequentials there. So instead they use one of two methods to 'clock' through stages.

The first would be a simple hand shaking system where some combination at the output of one stage gives the indication that the computation is done. It then sends a signal back to the previous sequential to indiciate that it's safe to open and send in the next stage of data.

The other method is using some delay chain that will trigger the next set of sequentials at the worst case rate of the logic it's trying to copy.

Eitherway, it's difficult to ignore the performance overhead of an asynchronous design BUT the fact that you no longer have a central free running clock will save so much power that in markets where power is much more important than performance, it could be used.

 

[Bobthelost]

They do exist, but they are rather hard to develop. Clocked are a much simpler concept especially when you start to scale up. I think manchester university is working on them at the moment.

 

[Matthias99]

Originally posted by: TuxDave
Eitherway, it's difficult to ignore the performance overhead of an asynchronous design BUT the fact that you no longer have a central free running clock will save so much power that in markets where power is much more important than performance, it could be used.

It also avoids clock skew/propogation issues in extremely large chips (or multi-chip boards/circuits). Trying to maintain a common clock to all your gates at gigahertz speeds is VERY hard in a big chip like a CPU or GPU; over a big circuit board (like a motherboard), the time it takes for a clock pulse to travel from one end of the board to the other also becomes significant once the clock rate gets high enough.

Light travels at ~300,000,000 m/s; assume for the moment that your signals do as well. if the clock is at one corner of a sizable board (like an ATX motherboard), you may have close to a meter of wire to run through to get to some of those chips. So if your clock rate gets lower than maybe ~1/100,000,000th of a second (ie, 1Mhz), you have to start considering clock skew across the whole board as well. Inside a chip, where a clock pulse might have to travel as little as 1mm, you have to start getting real creative over ~1Ghz to make sure the clock stays synchronized.

 

[pm]

It also avoids clock skew/propogation issues in extremely large chips (or multi-chip boards/circuits). Trying to maintain a common clock to all your gates at gigahertz speeds is VERY hard in a big chip like a CPU or GPU; over a big circuit board (like a motherboard), the time it takes for a clock pulse to travel from one end of the board to the other also becomes significant once the clock rate gets high enough.

The 24MB L3 cache on the upcoming Itanium microprocessor codenamed Montecito uses asynchronous logic to reduce power and clock skew issues.

The AMULET CPU (which uses the ARM instruction set) is one of the more famous examples of an asynchronous CPU.

Still, they are niche designs, and despite several designs using "clockless" logic over the years, it has never caught on as a design technique. Some say this is due to the lack of asynchronous design tools and, while this is certainly true, I think the main reason for the lack of designs has more to do with a lack of compelling reasons to switch over from clocked logic. Power is a good reason, but the logic overhead of clockless logic makes the power savings far less clear than a first analysis might suggest.

 

[Matthias99]

Originally posted by: pm
Still, they are niche designs, and despite several designs using "clockless" logic over the years, it has never caught on as a design technique. Some say this is due to the lack of asynchronous design tools and, while this is certainly true, I think the main reason for the lack of designs has more to do with a lack of compelling reasons to switch over from clocked logic. Power is a good reason, but the logic overhead of clockless logic makes the power savings far less clear than a first analysis might suggest.

That's basically the same sort of things my EE classes mentioned. At the moment, it's still feasable to deal with clock skew and distribution even at gigahertz speeds within a chip, and clocked logic is generally simpler and faster.

If/when we hit a point where scaling down transistor feature size to increase speeds is no longer easily doable, options like asynchronously clocked chips may start to look more attractive.

 

[theeedude]

You can think of it this way.
Clocked processor is like assembly line, you have 1 minute to work on every part, then you pass it on to the next guy after 1 minute, no matter what. So everyone better do their work in 1 min or you are screwed.
Asynchronous processor is like an assembly line, except you only pass to the next guy when he is done with his previous part, and you are done with your part. The advantage is that if some guy is slow at any given time, the work is slowed, but it still gets done. That's why asynchronous processors can run at different speeds depending on voltage and temperature.
The disadvantage is that it's two way communication. The guy before you cannot give you his part until the guy in front takes your part from you. There is overhead communicating back and forth. Now imagine that you take two parts from two different guys and put them together and pass them on to third guy, like say an adder does in a CPU. Then you have to communicate with the two previous guys, and the guy in front of you. So the more branching that goes on, the higher this overhead becomes.
Also, instead of writing RTL, which every logic designer knows, you generally have to write handshaking expansions, which almost noone knows. Handshaking expansions define the logic and the communication protocol between the various asynchronous parts to basically tell each other when they are ready to accept the next piece of data. This can add a lot of overhead to the circuitry as well. For example in a synchronous processor, you may have a simple flip flop that fans out to say 20 other flip flops. No problem, only need one wire to go to all of them. But asynchronous, that is a much bigger issue, because you also need to get an acknowledge back from all those receivers. So what was a simple wire, becomes 20 wires coming back, plus you need a huge logic gate to AND all these wires, since you need to know that everyone has received your transmission before you stop transmitting it and move on to the next one. So building something like a shifter in delay insensitive asynchronous logic is not easy.
There are other things like GASP, which is asynchronous clocking for synchronous logic, but basically it's no longer delay insensitive, since you have race conditions between your asyncronous clock and data making it a lot harder to design and taking a lot of advantages of asynch away, though it is capable of very high speeds.