Asynchronous processor !?!

I was amazed by this press release:

http://www.epson.co.jp/e/newsroom/2005/news_2005_02_09.htm

Apparently the asynchronous design uses 70% less power compared to its
synchronous counterpart.

What do you think they mean by an asynchronous processor? I find it
hard to believe the majority of the circuitry (pipeline, etc) is
asynchronous.

Will asynch design ever be feasible in FPGAs? I suppose it would
require a new tool chain and new ways of thinking, but having never
done it, I have no idea.

Just something that's got me really curious.

-- Pete

Peter Sommerfeld wrote:

> I was amazed by this press release:

> http://www.epson.co.jp/e/newsroom/2005/news_2005_02_09.htm

> Apparently the asynchronous design uses 70% less power compared to its
> synchronous counterpart.

> What do you think they mean by an asynchronous processor? I find it
> hard to believe the majority of the circuitry (pipeline, etc) is
> asynchronous.

I believe it is also known as "self-timed logic", and much 
easier to search for using that name.

-- glen

Peter Sommerfeld wrote:
> I was amazed by this press release:
> 
> http://www.epson.co.jp/e/newsroom/2005/news_2005_02_09.htm
> 
> Apparently the asynchronous design uses 70% less power compared to its
> synchronous counterpart.
> 
> What do you think they mean by an asynchronous processor? I find it
> hard to believe the majority of the circuitry (pipeline, etc) is
> asynchronous.
> 
> Will asynch design ever be feasible in FPGAs? I suppose it would
> require a new tool chain and new ways of thinking, but having never
> done it, I have no idea.
> 
> Just something that's got me really curious.

It's also got to be the world's largest 8 bit uC :)

  The beauty of Async logic is it self adjusts to Vcc/Temp/Process,
so for what Epson are trying to target, it is quite a good choice.
They can avoid any regulation, and the hot spot that would create.

  The 70% claim is a 'best case' one, and relates to Async vs Vanilla
Sync design. [See an earlier thread here on Async ].

  Std Sync Cmos has to have margins for Vcc, Temp, and Process so
it is not uncomon to find you can 'clock on the bench' much faster
than the design speed.
  If you remove the older 'square box' design, and start to vary Vcc,
Clock, and measure chip core Temp to determine where the two need to
be, you can get closer to the Async powers. This is what Intel/AMD
routinely do now, on their Mobile processors. Typical SMPS chips have
4/5/6 bit DAC inputs, allowing the CPU to request it's own Vcc level.
  PLLs and clock generators are now routine.
- ie you now have std devices to vary CLK, Vcc, and measure Temp.

  In a FPGA, if you wanted to add a process track capability, you could 
use std Sync tools, and make deliberate test cell(s), that fail first.
  You then vary Vcc/Clk until those cells just fail, knowing that the
margin in the rest of the design keeps the system operating.
  Sailing close to the wind, of course, but it would maximise battery life.

-jg

Peter Sommerfeld wrote:
> I was amazed by this press release:
> 
> http://www.epson.co.jp/e/newsroom/2005/news_2005_02_09.htm
> 
> Apparently the asynchronous design uses 70% less power compared to its
> synchronous counterpart.
> 
> What do you think they mean by an asynchronous processor? I find it
> hard to believe the majority of the circuitry (pipeline, etc) is
> asynchronous.
> 

Hi Peter,

A modern processor is'n synchronous at all! It would be very hard to get 
a global clock all over the system (IMHO)

As far as I know is asynchronous design very well suitable for 
cryptographic processors, as it is very tough to use DPA or other 
methods to analyze it.

Nevertheless it is as far as I know in an experimental phase in 
workgroups at universities and large companies (e.g. INfineon).


I am not an expert in such things. Just mentioned what I heard.

Cheers

Reinhold


> Will asynch design ever be feasible in FPGAs? I suppose it would
> require a new tool chain and new ways of thinking, but having never
> done it, I have no idea.
> 
> Just something that's got me really curious.
> 
> -- Pete
> 

On Mon, 07 Mar 2005 20:33:53 +0100, Reinhold Schmidt <rschmidt@aon.at>
wrote:

>Peter Sommerfeld wrote:
>> I was amazed by this press release:
>> 
>> http://www.epson.co.jp/e/newsroom/2005/news_2005_02_09.htm
>> 
>> Apparently the asynchronous design uses 70% less power compared to its
>> synchronous counterpart.
>> 
>> What do you think they mean by an asynchronous processor? I find it
>> hard to believe the majority of the circuitry (pipeline, etc) is
>> asynchronous.
>> 
>
>Hi Peter,
>
>A modern processor is'n synchronous at all! It would be very hard to get 
>a global clock all over the system (IMHO)
>

Your second comment is very true; but it doesn't support your first
statement. You should check some of Intel's clock distribution papers
in ISSCC and JSSCC. You would be amazed the lenghts they go to keep
their systems synchronous. It turns out designing a OO, 20 stage
pipeline 4GHz x86 processor is more difficult with an asynchronous
design  methodology.

"Peter Sommerfeld" <psommerfeld@gmail.com> wrote in message 
news:1110212334.327016.266460@o13g2000cwo.googlegroups.com...
>I was amazed by this press release:
>
> http://www.epson.co.jp/e/newsroom/2005/news_2005_02_09.htm
>
> Apparently the asynchronous design uses 70% less power compared to its
> synchronous counterpart.
>
> What do you think they mean by an asynchronous processor? I find it
> hard to believe the majority of the circuitry (pipeline, etc) is
> asynchronous.
>
> Will asynch design ever be feasible in FPGAs? I suppose it would
> require a new tool chain and new ways of thinking, but having never
> done it, I have no idea.
>
> Just something that's got me really curious.

ARM is working on one. I think it is based on the Amulet asynchronous 
processor developed at Manchester University, as that had an ARM 
architecture.

Leon 

> Will asynch design ever be feasible in FPGAs? I suppose it would
> require a new tool chain and new ways of thinking, but having never
> done it, I have no idea.

These guys have done an asynchronous DLX processor in a Xilinx Spartan
IIe FPGA:

http://www.ics.forth.gr/carv/async/demo/

-- Jecel

Great, thanks for the link. They're results are that the sync and async
versions of the same processor have the same area, speed, and power
consumption except that the async version apparently has less EMI. I
was hoping the async design would have advantages in other areas, but I
guess not.

-- Pete

Peter Sommerfeld wrote:
> Great, thanks for the link. They're results are that the sync and async
> versions of the same processor have the same area, speed, and power
> consumption except that the async version apparently has less EMI. I
> was hoping the async design would have advantages in other areas, but I
> guess not.

  This was done using FPGA tool flows, designed for Sync use, and also
speed files done the same way - So I would not read too much into
the area and speed comparisons.
  I'm impressed they got it to go thru the tools at all :)

  Keeping the async handshakes safe is likely to consume area, but you 
could expect to save on less beefy global glock trees and drivers.

  The benefits I expect Epson see from Async, are more in deployment than
area or speed - if they can save hot spots, eliminate regulators, and
spread the EMI, as well as extend battery life, those are all important
gains to make in portable consumer equipment.

-jg

"Peter Sommerfeld" <psommerfeld@gmail.com> wrote in message 
news:1110295700.990283.300930@f14g2000cwb.googlegroups.com...
> Great, thanks for the link. Their results are that the sync and async
> versions of the same processor have the same area, speed, and power
> consumption except that the async version apparently has less EMI. I
> was hoping the async design would have advantages in other areas, but I
> guess not.

Don't give up hope yet.

One guy tried making an asynch version of the ARM, called Amulet.

The first attempt actually used _more_ power than the synchronous ARM!

Later attempts used less power, after he'd sussed the reasons.

I get the feeling things will have to go asynch eventually, if only to get 
rid of a 40W RF transistor thrashing a global clock network.