ARM Offers First Clockless Processor Core

Sam Haine '95 writes "EETimes is reporting that ARM Holdings have developed an asynchronous processor based on the ARM9 core. The ARM996HS is thought to be the world's first commercial clockless processor. ARM announced they were developing the processor back in October 2004, along with an unnamed lead customer, which it appears could be Philips. The processor is especially suitable for automotive, medical and deeply embedded control applications. Although reduced power consumption, due to the lack of clock circuitry, is one benefit the clockless design also produces a low electromagnetic signature because of the diffuse nature of digital transitions within the chip. Because clockless processors consume zero dynamic power when there is no activity, they can significantly extend battery life compared with clocked equivalents."

Comments

Synchronisation?

[Poromenos1]

Can a processor like this do things like play sounds? If it doesn't have a clock I don't think it could measure time accurately so it could reproduce the samples. What other drawbacks are there?

Asyncrhonous == Clockless

[Mateorabi]

Processors like this do not have a clock. Each piece of the processor is self-timing, with handshaking done between components to pass the data (compare this with clocked processors, where you can assume the data is at your input and valid just by counting cycles.) Asynchronous processors don't have global 'cycles' when all components must pass data.

But your assertion about critical path is slightly off. Asynch processors still have a critical path. If you immagine the components as a bucket-bregade and the data the buckets, then they may not all be heaving the buckets at exactly the same time anymore, but they will still be slowed down by the slowest man in the line. The difference is that critical path is now dynamic. You don't have to time everything to the static, worst-case component on your chip. If you consistenly don't use the slowest components (say, the multiply unit), then you will get a faster IPT (instruction per time) on average.

And yes, you don't have clock skew any more which is nice, but you now have to handshake data back-and-forth across the chip. Of course putting decoupling circuitry in can help.

Not That Difficult

[Mateorabi]

I took an undergrad class on asynchronous chip design back in 2000. The class project was to implement the ARM7 instruction set (well, most of it) in about 5 weeks. We split it up into teams doing the Fetch, Decode, Reg file, ALU, etc. The nice thing about asynch is that as long as you have well defined, four phase handshaking between blocks you don't have to wory about global timing (there is no global "time" reference!). We were able to get it mostly done in those 5 weeks. Nothing manufacturable, and not tuned for performance, but we could simulate execution.

One of the neatest things about asynch processors is their ability to run in a large range of voltages. You don't have to worry that lowering the voltage will make you miss gate setup timing since the thing just slows down. Increasing voltage increases rise time/propegation and speeds the thing up. The grad students had a great demo where they powered one of their CPUs using a potato with some nails in it (like from elementary school science class.) They called it the 'potato chip'.

Re:Not That Difficult

[Manchot]

Another cool thing about asynchronous processors is that you can see the effect of temperature on the processor's speed. Wikipedia describes a demonstration in which hot coffee placed on the processor caused it to visibly slow down, while liquid nitrogen caused its speed to shoot up.

Clockless chip overview

[Charan]

This seems to be a good overview of clockless chips. I can't vouch for its accuracy (not my area), but the source - IEEE Computer Magazine - should be good. The article was published March 2005.

(warning: PDF)
http://csdl2.computer.org/comp/mags/co/2005/03/r30 18.pdf

Transmeta's Crusoe was supposed to be clockless

[Vexar]

For those of us with short-term memories, we can go back in time and read historical articles about the Transmeta Crusoe processor, which was supposed to be clockless. Of course if you go to their Crusoe Page today, their pretty diagram sure has a clock.

What did I miss? I remember the hype, the early diagrams of how it was all supposed to weave through without the need for a clock. Would someone care to elaborate on the post-mortem of what was supposed to be the first clockless processor, 4 years ago?

You are confused

[comingstorm]

I think the confusing part is that, in the terminology of conventional, "synchronous" design, "asynchronous logic" is used to mean "the combinatorial logic in a single stage". What conventional, clock-based design typically does is break the logic up into stages with clocked latches in between, thus limiting the depth of each "asynchronous" logic stage.

Unfortunately, self-clocked design (like the reported ARM uses) is also sometimes called "asynchronous" logic design; however, this is a completely different kind of thing than the "asynchronous" combinatorial logic used in clock-based design. Self-clocked design also does combinatorial logic in latched stages, but uses a self-timed asynchronous protocol to run the latches instead of a synchronous clock. Basically, the combinatorial logic figures out when it's finished, and tells both the next stage ("data's ready, latch it") and the input latch from the previous stage ("I'm done; gimme some more data").

To close the loop, each stage can wait until there's new data ready at its inputs, and space to put the output data. Thus, in absence of some bottleneck, your chip will simply run as fast as it can.

To overclock a self-timed design, you simply increase the voltage. No need to screw around with clock multipliers; as long as your oxide holds up, your traces don't migrate, and the chip doesn't melt...

Re:Why is async good

[bigberk]

> Security: Async designs give security against side channel power analysis attacks

You're right about that. I research side channel attacks on crypto hardware, and my first response to this was --- well, this would make EM analysis more complicated. For those not familiar with the general approach, in side channel attacks you don't try to do anything as complicated as breaking the underlying math of the crypto. Instead you observe the hardware for emissions that can give some clues as the instructions being carried out. If your observations help give you any info about what the chip is processing, you might learn parts of keys or gain a statistical advantage in other attacks. So if it's harder to observe signals emitted (electromagnetically from the chip, then attacking the hardware is harder.