Slashdot Mirror
Philips, ARM Collaborate On Asynchronous CPU
Sean D. Solle continues "Back in the early 1990's there was a lot of excitement (well, Acorn users got excited) about Prof. Steve Furber's asynchronous ARM research project, "Amulet". The idea is to let the CPU's component blocks run at their own rate, synchronising with each other only when needed. Like a normal RISC processor, one instruction typically takes one clock cycle; but in a clockless ARM, a cycle can take less time for different classes of instructions.
For example, a MOV instruction could finish before (and hence consume less power than) an ADD, even though they both execute in a single cycle. As well as energy-efficiency, running at effectively random frequencies reduces a chip's RFI emissions - handy if it's living in a cellphone or other wireless device."
See here. Developed by Steve Furber and his team at The University Of Manchester
the very first drafts of microprocessors were clockless.
just with higher speed and hence, brute force, performance could be achieved easily.
The problems which could not be solved back then were the obvious synchronisation issues. Setting up a common clock seemed the only way to resolve them.
The idea behind clockless designs is less a "back-to-the-roots" idea, but more a step to gain the advantages of such a design, which are, amongst others:
Reduced Power Consumption
Higher Operation Speed
Moreover, highly sophisticated compilers could tune program code to match a given performance/power ratio.
Yet, I would not bet on clockless cores to become the new mainstream, by far not. Clockless cores will most likely be aimed at embedded design appliances, and low- and ultra-low-power applications.
Powerful is he who overpowers his temptations.
I think you are getting clock confused with ticker interrupt. A CPU clock is typically measured in nanoseconds. A ticker interrupt is typically measured in milliseconds. A clockless core will still need to field interrupts (for I/O) and very well can still field a ticker interrupt. -cdh
You appear to be confusing the CPU's clock with a real-time clock interrupt. They are fundamentally not the same thing.
The clock being dispensed with is the one that causes the registers inside the CPU to latch the new values that have been computed for them. At 3GHz, this happens every 333ps. The reason this clock exists is basically because it makes everything in a digital system much, much easier to think about, design, simulate, manufacture, test and re-use. But, it's not an absolute requirement that it be present, if you're clever. (Too clever by half, in fact.)
The other clock, which you were referring to, fires off an interrupt with a period on the order of milliseconds, to facilitate time-slicing. If your application requires such a feature, you can have one, regardless of whether your CPU is synchronous or asynchronous internally. It's a completely separate issue.
These sigs are more interesting tha
As for the power problem, all parts of the CPU is powered, except that gates that aren't switching consume less power (mostly leakage, which seems to be quite significant now). In synchronous circuits, at least the gates connected directly to the clock signal switch all the time, while in asynchronous circuits unused parts of the CPU can avoid switching altogether, so some power may be saved, but I don't know how much it will be.
A long long time ago (1970s) Charlie Molnar, designer of the Linc tape (the Linc computer was an NIH funded (late 1960s) minicomputer that evolved into the PDP 8 and pushed DEC into the minicompuer business) explored asynchronous computing. Along the way they discovered synchronizer failure - i.e. the inability to reliably synchronize asyncronous subsystems - see Chaney, T.J. and Molnar, C.E. 1973. Anomalous behavior of synchronizer and arbiter circuits. IEEE Trans. Comp. pages 421-422. The bottom line is that it is physically impossible to guarantee that the data setup requirements (the minimum time the data must be asserted before it can be reliably clocked into the flip flop) of a flip flop can be met when the clock is asserted by one async component and the data are asserted by another async component. To my knowledge, this fundamental limitation has never been overcome.