Linked by Thom Holwerda on Sat 8th Apr 2006 18:38 UTC
Hardware, Embedded Systems As expected processor licensor ARM Holdings and Handshake Solutions NV, a Royal Philips Electronics subsidiary, have developed an asynchronous processor based on the ARM9 core. The ARM996HS is thought to be the first commercial clockless processor and is being described as particular suited to use as an automotive microcontroller. Because clockless processors consume zero dynamic power when there is no activity, they can significantly extend battery life compared with clocked equivalents.
Thread beginning with comment 112984
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: somewhat dubious
by ZaNkY on Sat 8th Apr 2006 22:29 UTC in reply to "RE: somewhat dubious"
ZaNkY
Member since:
2005-10-18

That's exactly what I was thinking. The whole startup process would be the kicker. I mean, don't get me wrong, I think it would be great if it could get into PC tech, but I donít see it happening with major adjustments.

Good point (a post above) that this is targeted mainly at mobile devices, and most probably will stay that way.


And I must say, even if it appears your CPU is idle, it's is nearly ALWAYS computing something. Whether it's detecting minuscule mouse movements (mouse interrupt calls), or its processing background dhcp requests or other TCP stack stuff, it's always working.

We could say that the CPU may at times be doing negligible work, but I doubt it ever really "stops".

ZaNkY

Reply Parent Score: 2

RE[3]: somewhat dubious
by geist on Sun 9th Apr 2006 01:12 in reply to "RE[2]: somewhat dubious"
geist Member since:
2005-07-11

We could say that the CPU may at times be doing negligible work, but I doubt it ever really "stops".

It does. Perhaps only for 10 milliseconds or so, but there are huge swaths of time where there is nothing to do, and thus the idle thread is usually run. Typically the idle thread in most OSes does a little bit of housekeeping and then just halts the cpu until the next interrupt (network packet, keypress, timer, etc). On mobile devices this is doubly important, to save power.

Reply Parent Score: 2

RE[4]: somewhat dubious
by hobgoblin on Sun 9th Apr 2006 11:27 in reply to "RE[3]: somewhat dubious"
hobgoblin Member since:
2005-07-06

but, iirc, only in windows NT or maybe 2000 did microsoft add proper support for this. in windows 9x and older, they would just send dummy commands to the cpu when there was nothing to do...

Reply Parent Score: 1

RE[3]: somewhat dubious
by nbs_r on Sun 9th Apr 2006 13:24 in reply to "RE[2]: somewhat dubious"
nbs_r Member since:
2006-04-09

A very basic difference between synchronous and asynchronous (here self-timed, I guess) logic is that the first one is polling its inputs at every clock's tick, while the second is strobed by inputs directly (each data signal is a "clock").

So, for asynchronous circuits there is no notion of explicit "stops", "idle states" or "waking up" because these were invented to stop or limit "polling" activity in synchronous circuits. Asynchronous circuits respond to their input events instantly (i.e. a latency depends on processing time only). They are active only when there is something to do and the level of their activity adjusts automatically to the activity of input signals, temperature, supply voltage and process skew. It basically means that (at least for CMOS implementation) you can control the maximum processing power and maximum operating temperature by adjusting the supply voltage _only_. Internal handshaking structures will take care of the signal integrity, synchronisation and providing maximum performance.

So what is the problem about deploing these circuits more widely? There are at least two:
- circuit overhead - present CMOS synchronous circuits are ~2x smaller. Also processes are tuned to synchronous logic architectures. This results in often better performance although the theory says opposite.
- design methodology - synchronous logic is very simple to design. There are numerous problems with VLSI implementation (mostly related to clock and power management) but with time we learned how to cope with that. Again withouta robust design tool-chain, IP macros and support there is no resonable time-to-market what disqualifies asynchronous logic in typical applications.

Reply Parent Score: 5