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."
If we see same thing applied to non ARM architectures, there a many strange things going to happen, as quite many things in current computers are based on the assumption that things have specific clock rates. Obviously things might get very intresting...
The benefit to today's high-functionality embedded operating systems like Linux, Symbian, iTron, and Windows CE is that they implement a preemptive task switching operating system. At any time, the clock interrupt may fire and the operating system will then queue up the next thread into the CPU.
Nowadays, the whole CPU is not powered at any one time. If an instruction does not access certain parts of the chip, they are dark. Now this does not hold for some predictive processors which may be processing not-yet-accessed instructions, but in general if an instruction is not using some part of the chip, that part of the chip does not require juice.
Taking out the clock and relying on the chip parts to fire and return means that each application in the system must return to the OS at some point to allow the OS a chance to queue up the next thread. Without the clock interrupt, the OS is at the mercy of the program, back to the bad old days of cooperative multitasking.
The clock is what tells the OS that it is time to give a time slice to another thread. If we say "OK, well we'll just stick a clock in there to fire an interrupt every x microseconds," then what have we accomplished? We are back at square one with a CPU controlled by a clock. No gain.
This kind of system would work in a dedicated embedded system which did not require a complex multitasking operating system. Industrial solutions for factories, car parts, HVACs, and other things that need reliability but don't really do that much feature-wise seem to be prime candidates for this technology. "Smart" devices? Not so much.
So the question is WHY didn't it make it out of the lab? Did it cost too much to produce? That's the only real possibility I can think of - I don't think Intel's Marketing Division had absolute power over the company in 1997 to push the MHz agenda.
The complexity of souch a core must be astounding. For all you non-ee's out there, a chip is full of little memory cells called flip-flops. At the end of each circuit rests a flip-flop in which normally the rising edge of the clock stores the results of that circuit so it pass that data on and start new stuff without loosing it. Everythig is synchronized to the clock. This is definently over-simplified but that's essentially why a circuit has a clock.
To eliminate clocks you would new circuitry such arbitrers and some sort of completion logic which could be used to trigger a flip-flop. To break a slashdot law, i haven't done any reading on any modern techniques so would some one enlighten me on some design issues involving simple tasks such as accessing a register file, or making a memory read. Surely a bus would still maintain a clock.
----
Go canucks, habs, and sens!
In English, Intel is not singular. It is a composite entity, made up of many people, and as such should be considered plural when choosing the verb conjugation. Many Americans make this mistake.
Also, anything that might boost my pitiful ARM shares value is most welcome! Why?... Why did I believe the hype?
Agreed that clockless cores have few chance to become mainstream, but still they have a better chance of being used now than before.
Let me explain: before to reduce power consumption the "easy" thing was to use a process which created smaller transistor, but smaller doesn't means 'reduced power consumption' anymore..
So clockless CPU becomes more interesting now.
When I was at university we studied standard ways to overcome these problems down to gate and transistor level. The impression i was given that its not that hard. Some of the standard ways include doing a calculation twice and waiting for the results to be the same. Of coarse there are no tools to do it in automated fashion that i am aware of like synchronous design. Here the tools are extensive from vhdl to handel C implenentation. Even dynamic logic can be synthesised automatically now. This means its to risky for asic design houses to implement on there own as they would have to do there own custom blocks. This also presents a design flow problem. How would a foundry verify the design for you. In the case of synchronous design the methodology is well established.
my 2 cents..
Philips has been a world-class R&D company for a long time. Philips Research was established in 1914, and has contributed much, from the invention of the pentode vacuum tube (valve) by Tellegen in 1929 to the audio cassette in the 1960s and their more modern work developing CDs and DVDs.
The fire has been lit under IBM and other corporate research organizations for a long time.
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.
It looks like Philips (through their tame spin-off Handshake Solutions) are letting the world see Tangram again (or something very like it.) Back in around 1994/1995 the Amulet team (already mentioned accurately by others) were looking into using the Tangram language to develop their asynchronous microprocessor technology - it was a fairly neat solution that did most of the things we wanted, though there were a few things it was crap at at the time - but then Philips decided to cut us off. It would be entirely fair to say that this was very annoying! Now it looks like they're letting the cat get its whiskers out of the bag again.
FWIW, ARM have probably known (at least informally and at a level not much deeper than your average slashdot article) a large fraction of what Philips have been up to in this area for at least a decade.
"Little does he know, but there is no 'I' in 'Idiot'!"
Yes, indeed they did. The article doesn't mention any collaboration between the teams, which seems strange because:
1) ARM like to licence CPU core design IP, as mentioned in a later thread.
2) One of the major upsides of asynchronous CPU design (said Prof. Furber on the Manc. Uni course) is that because the subcomponents of the CPU aren't nearly so tied to temperature, voltage and clock speed requirements (which directly affect flip-flop "set up" and "hold" time), the intellectual property invested in creating such a chip is far more reusable than any synchronous design.
So if this is (as I infer from the article) a clean-room implementation separate to the AMULET group's work, it's totally contrary to the ARM licensing model and duplicates a lot of effort. Which seems a shame.
That's another reason to scatter the delaying gates throughout the core, and use enough of them. You have to hope that you don't get too many instances of a logic element and one of its associated delaying gates falling on the opposite sides of a process variation boundary. Especially where the effects favour faster propagation in the delaying gate. So, my intention was to aim for the clock delay being slightly but definitely longer than, and not exactly equal to, the logic delay. It would still respond to dynamic effects like temperature better than an external clock oscillator.
This would also be one of those kinds of circuits that, if it's not built on the same silicon substrate, won't work at all. Power op-amps are another good example: they rely on better thermal coupling than you can achieve with discrete components, and better properties-matching than you can achieve by just pulling transistors out of a bag at random without doing any tests on them. {You can't control the absolute values of most on-chip components precisely, but you can be fairly sure of the relative similarities between them}. Build one out of carefully-gain-matched transistors exactly according to the schematic in the data book, and it might just about work if you put it in a constant-temperature oven. In the best case it will distort like hell, and in the worst case it will go literally into meltdown.
Je fume. Tu fumes. Nous fûmes!
It's a drastic departure from common CPUs. Definitely intresting.
Bye!
SeqBox
The idea is good and the physics is sound, but putting something like this into practice is much harder than you make out. Speed binning of chips goes part way to adjusting for process variation. Sophisticated chips have temperature monitors that will scale back the clock when things get too hot (but in a crude, broad-brush way). ARM is already working on more fine-grained closed-loop systems (see here), but as a way of saving power rather than going faster, and with an indirect link between chip speed and clock.
Owl tried to think of something wise to say, but couldn't.