Low-power FPGAs?

Hi Hal,
Yeah, do you know about the Xilinx program 'speedprint'? You tell it Vcc and 
Temperature and it gives you personalised timings.
Cheers, Syms.
"Hal Murray" <hmurray@suespammers.org> wrote in message 
news:FrqdnW3ZmpgGHB3cRVn-uQ@megapath.net...
>
> A few generations ago, it used to be common to fudge ratings by
> "correcting" for VCC and temperature.  If you were willing to work
> a bit harder on your power supply, say promise it won't go below
> nominal, then you could pick up 5% on speed.  Old Xilinx data books
> had a nice writeup.  I'm pretty sure DEC did that with their high
> end Alphas.
>

Jim Granville wrote:
> 
> Symon wrote:
> > Simon,
> > I saw this article and thought of our musings about low power stuff!
> > http://www.reed-electronics.com/electronicnews/article/CA475494?nid=2019&rid=1090846109
> > "Royal Philips Electronics� Handshake Solutions and ARM today said they have
> > jointly developed a clockless, compact ARM processor to addresses (sic) low
> > power consumption"
> > It's based on this stuff
> > http://www.cs.man.ac.uk/apt/projects/processors/amulet/
> > http://www.cs.man.ac.uk/apt/projects/processors/amulet/AMULET3i_seminar.pdf
> > I wonder if self-timed circuits will come to the FPGA world soon? A whole
> > new level of pain!
> 
>   Interesting - Philips have been doing Async logic for a while,
> including Async 80C51 variants, and have the important tools needed to
> design in this area.
> 
>   Advantages are self-tracking of temp and Vcc, allowing wider operating
> tolerance. Power numbers I've seen for their earlier devices were good,
> but not stellar, but did improve rapidly as Vcc decreased.
>   FPGAs could use this, with the right tools.

I have thought about this a bit and I don't see how any of this is an
advantage.  If you are doing real time work, even if it is not
demanding, you have to meet a timing schedule.  Although the async
sequential devices are self timed and won't stop working from failing to
meet setup and/or hold times on the FFs, if the device slows down, it
will fail to meet the requirements of the application.  If you app can
tolerate a slow down of X% which allows the async logic to work over
temp, then you could likewise run the sync logic at a slower clock and
still meet the same system requirements over temp and voltage.  

So how is the async logic really better?  You still have to make sure
the device meets your timing constraints.  The async logic just pushes
it to a system timing problem rather than a low level timing problem.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Rick,
I think the advantage is that the circuit goes as fast as it can for the 
given voltage/temperature conditions. So, for example, if you're running a 
cpu flatout to do some task, it'll finish faster if it's cooler.
Like you, I'm struggling to see why it's necessarily lower power. Presumably 
the same number of nodes flip-flop during a logic algorithm in async or sync 
logic. Also, the clock distribution is saved, but replaced by a whole bunch 
of handshake lines.
Just found this, some bloke at Intel doesn't think async design is a good 
idea:- http://www.eet.com/in_focus/embedded_systems/OEG20030606S0037
Cheers, Syms.

"rickman" <spamgoeshere4@yahoo.com> wrote in message 
news:418088EB.F8286CA4@yahoo.com...
 I have thought about this a bit and I don't see how any of this is an
> advantage.  If you are doing real time work, even if it is not
> demanding, you have to meet a timing schedule.  Although the async
> sequential devices are self timed and won't stop working from failing to
> meet setup and/or hold times on the FFs, if the device slows down, it
> will fail to meet the requirements of the application.  If you app can
> tolerate a slow down of X% which allows the async logic to work over
> temp, then you could likewise run the sync logic at a slower clock and
> still meet the same system requirements over temp and voltage.
>
> So how is the async logic really better?  You still have to make sure
> the device meets your timing constraints.  The async logic just pushes
> it to a system timing problem rather than a low level timing problem.
>

rickman wrote:

> Jim Granville wrote:
> 
>>Symon wrote:
>>
>>>Simon,
>>>I saw this article and thought of our musings about low power stuff!
>>>http://www.reed-electronics.com/electronicnews/article/CA475494?nid=2019&rid=1090846109
>>>"Royal Philips Electronics� Handshake Solutions and ARM today said they have
>>>jointly developed a clockless, compact ARM processor to addresses (sic) low
>>>power consumption"
>>>It's based on this stuff
>>>http://www.cs.man.ac.uk/apt/projects/processors/amulet/
>>>http://www.cs.man.ac.uk/apt/projects/processors/amulet/AMULET3i_seminar.pdf
>>>I wonder if self-timed circuits will come to the FPGA world soon? A whole
>>>new level of pain!
>>
>>  Interesting - Philips have been doing Async logic for a while,
>>including Async 80C51 variants, and have the important tools needed to
>>design in this area.
>>
>>  Advantages are self-tracking of temp and Vcc, allowing wider operating
>>tolerance. Power numbers I've seen for their earlier devices were good,
>>but not stellar, but did improve rapidly as Vcc decreased.
>>  FPGAs could use this, with the right tools.
> 
> 
> I have thought about this a bit and I don't see how any of this is an
> advantage.  If you are doing real time work, even if it is not
> demanding, you have to meet a timing schedule.  Although the async
> sequential devices are self timed and won't stop working from failing to
> meet setup and/or hold times on the FFs, if the device slows down, it
> will fail to meet the requirements of the application.  If you app can
> tolerate a slow down of X% which allows the async logic to work over
> temp, then you could likewise run the sync logic at a slower clock and
> still meet the same system requirements over temp and voltage.  
> 
> So how is the async logic really better?  You still have to make sure
> the device meets your timing constraints.  The async logic just pushes
> it to a system timing problem rather than a low level timing problem.  

  There are some FPGA examples at
http://www.ics.forth.gr/carv/async/demo/

  You are broadly correct tho, no system is truly 'clockless', and so
at some stage you need to know that your Async core _did_ complete
the branch or thread or interrupt, within some system limit.

  Where Async can help, is in being more generally spread spectrum,
( so improves EMI ), and in having an automatic IDLE mode: When the
Sw completes, it can stop.
  Of course, a std uC can come close to the same with HW IDLE control,
and there are now many Spread spectrum clock generators.

  Downsides are: your core speed is now very elastic, and so cannot be
used for software timing, plus faster clocked peripherals and
interrupt type flags that can be dual port in nature (SW & HW access)
must get very tricky to prove. On a system that had such a bug, it
would be very enviroment sensitive.

  The biggest gain I can see from Async, is it (should?) self-track 
Vcc/Temperature/Process. Of these, Wide Vcc operation is likely to give
the most user benefit.
  In a Sync system you may have 50- >100% margin by
the time you apply Voltage/Temp/Process corners : In an Async system,
that margin is available for extended battery life.


-jg

 I saw the same posting too..

Self timed IC's tend to reduce power in several ways... for starts the peak
is lower.. as nothing switches at the same time :-)
second.. only the circuit active is running.. the next step is still idle
the last step is now idle.  The tend is to then be either idle or running..
not 'clocked and waiting'.
Third.. the ripple effect... as each stage runs as fast as it wants/needs,
things which would gobble time doing nothing, now take next to no time to
do, so simple instructions process faster, and overall, the 'speed' can
decrease.. or at least .. spend more time doing nothing as speed assumes a
clock ;-)

That's suppose to be good for a 30 % power drop.  That's according to the
thesis I read a few months back. The problem is, of course, the more you get
the chip to do.. the less the power saving.  Look at a hyper threading P4
for example.. all that silicon not doing anything until you hyper thread..
and then consume another 10 watts

The classic example of this is a MOVE to register instruction in a
processor...
If a standard FPGA or processor, you would setup the address, read, write,
allocate a bus, and on the next clock edge, execute a simultaneous read and
write, now the whole chip sees this read and write.. and everything else
decides its not for them.
In an Async system, the MOVE sets up a async path between the register and
the memory... everything else is still idle or doing something else (thru
other async paths) and the memory and register do the data transfer between
themselves nothing else knows / cares
Sounds simple .. but they've been working on this for 10 years. I think
because when things go wrong.. the system turns to custard, simulation
requires specialist tools... you can't prototype in a FPGA either.

From what I understand... there are a few MP3 players (?) also using async
clocks to reduce overall power wasted or at least in the process.

Simon


"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:Qw0gd.23562$mZ2.872624@news02.tsnz.net...
> rickman wrote:
>
> > Jim Granville wrote:
> >
> >>Symon wrote:
> >>
> >>>Simon,
> >>>I saw this article and thought of our musings about low power stuff!
>
>>>http://www.reed-electronics.com/electronicnews/article/CA475494?nid=2019&
rid=1090846109
> >>>"Royal Philips Electronics&#4294967295; Handshake Solutions and ARM today said they
have
> >>>jointly developed a clockless, compact ARM processor to addresses (sic)
low
> >>>power consumption"
> >>>It's based on this stuff
> >>>http://www.cs.man.ac.uk/apt/projects/processors/amulet/
>
>>>http://www.cs.man.ac.uk/apt/projects/processors/amulet/AMULET3i_seminar.p
df
> >>>I wonder if self-timed circuits will come to the FPGA world soon? A
whole
> >>>new level of pain!
> >>
> >>  Interesting - Philips have been doing Async logic for a while,
> >>including Async 80C51 variants, and have the important tools needed to
> >>design in this area.
> >>
> >>  Advantages are self-tracking of temp and Vcc, allowing wider operating
> >>tolerance. Power numbers I've seen for their earlier devices were good,
> >>but not stellar, but did improve rapidly as Vcc decreased.
> >>  FPGAs could use this, with the right tools.

>  In a Sync system you may have 50- >100% margin by
>the time you apply Voltage/Temp/Process corners : In an Async system,
>that margin is available for extended battery life.

Huh?  Why does one use more battery than the other?

Power depends upon the work you do, not how fast you do it.

I'm assuming both systems go to sleep when the don't have
anything to do.  In the sync case, you picked the clock so
that the work gets done in time (with some slop for adding
features?) and designed the system so it runs that fast in
worst case conditions.

With the async system, you figured out how many cycles
you needed, added slop, then engineered the system so
that it would get done soon enough when it was running
hot and such.  Same general worst-case idea, just turned
inside out.

I admit I've never designed an async system.  You need
something like that in the data sheet in ordr to build auseful
systems.  Right?

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Hal Murray wrote:

>> In a Sync system you may have 50- >100% margin by
>>the time you apply Voltage/Temp/Process corners : In an Async system,
>>that margin is available for extended battery life.
> 
> 
> Huh?  Why does one use more battery than the other?
> 
> Power depends upon the work you do, not how fast you do it.
<snip>

  Yes, but the Async allows you to vary the Vcc, and the
chip runs as fast as possible at that Vcc.Temp, then
your P = K.F.V^2 works in your favour.
  Devices such as FLASH where the Active I/F curve does not pass thru 
the origin, also benefit from less ON time.

  Armed with a full Speed/Vcc curve from a precise data sheet,
plus on chip temperature sense, and variable supply, and you can
get almost the same thing from a Sync design, and that's how
many MobileCPUs work. However, they are more the exception,
and most small uC, and FPGAs are not specified to that detail.

  One could design a FPGA system for min possible power, using
TempSense, Variable Vcc, and a small Async block whose task was to 
provide either the main clock, or a reality check of the scalable-clock.

-jg

Jim Granville wrote:
> 
>   There are some FPGA examples at
> http://www.ics.forth.gr/carv/async/demo/
> 
>   You are broadly correct tho, no system is truly 'clockless', and so
> at some stage you need to know that your Async core _did_ complete
> the branch or thread or interrupt, within some system limit.
> 
>   Where Async can help, is in being more generally spread spectrum,
> ( so improves EMI ), and in having an automatic IDLE mode: When the
> Sw completes, it can stop.

But most sw never completes.  The program typically runs in a loop
waiting for something to do.  The async CPU is no different.  You can
use a HALT or IDLE instruction, but that is what they do on sync logic
CPUs. 


>   Of course, a std uC can come close to the same with HW IDLE control,
> and there are now many Spread spectrum clock generators.

See, great minds think alike...  ;)


>   Downsides are: your core speed is now very elastic, and so cannot be
> used for software timing, plus faster clocked peripherals and
> interrupt type flags that can be dual port in nature (SW & HW access)
> must get very tricky to prove. On a system that had such a bug, it
> would be very enviroment sensitive.
> 
>   The biggest gain I can see from Async, is it (should?) self-track
> Vcc/Temperature/Process. Of these, Wide Vcc operation is likely to give
> the most user benefit.
>   In a Sync system you may have 50- >100% margin by
> the time you apply Voltage/Temp/Process corners : In an Async system,
> that margin is available for extended battery life.

Now that is something I can understand.  Right now the best you can do
is reduce clock speed, which many power sensitive systems use.  In the
async system you can also cut voltage saving power by the square of
voltage.  But couldn't you do that in a sync system as well?  A lot of
the low power CPUs, PICs for one (or is that millions?) spec the chip to
run at one range of speeds for a higher voltage and a lesser range of
speeds at a lesser voltage.  So these CPUs could also save power by
cutting their own voltage and running slower.

Oh, the margin is no more available in async parts.  They have to run a
handshake clock between circuits that is assured to be slower than the
logic path.  Don't you think they put a lot of margin into that
difference?  In fact, when running hot at low voltage, I bet the margin
is a lot less with sync parts.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Simon Peacock wrote:
> 
>  I saw the same posting too..
> 
> Self timed IC's tend to reduce power in several ways... for starts the peak
> is lower.. as nothing switches at the same time :-)

Is the smily indicating a joke?  That doesn't save power, right? 


> second.. only the circuit active is running.. the next step is still idle
> the last step is now idle.  The tend is to then be either idle or running..
> not 'clocked and waiting'.

If you have separately clocked circuits, that is like pipelining.  Why
wouldn't you run them in parallel?  If you take out the pipeline
registers, you will not use any more power and you will make the circuit
smaller.  


> Third.. the ripple effect... as each stage runs as fast as it wants/needs,
> things which would gobble time doing nothing, now take next to no time to
> do, so simple instructions process faster, and overall, the 'speed' can
> decrease.. or at least .. spend more time doing nothing as speed assumes a
> clock ;-)

In a sync design the circuits are balanced since they all run together. 
Of course this is never perfect.  But this way things can run in
parallel and stay in step.  In an async circuit you would have to have
traffic cops directing results based on availability at a very low
level.  That would add a lot of logic.  


> That's suppose to be good for a 30 % power drop.  That's according to the
> thesis I read a few months back. The problem is, of course, the more you get
> the chip to do.. the less the power saving.  Look at a hyper threading P4
> for example.. all that silicon not doing anything until you hyper thread..
> and then consume another 10 watts
> 
> The classic example of this is a MOVE to register instruction in a
> processor...
> If a standard FPGA or processor, you would setup the address, read, write,
> allocate a bus, and on the next clock edge, execute a simultaneous read and
> write, now the whole chip sees this read and write.. and everything else
> decides its not for them.
> In an Async system, the MOVE sets up a async path between the register and
> the memory... everything else is still idle or doing something else (thru
> other async paths) and the memory and register do the data transfer between
> themselves nothing else knows / cares
> Sounds simple .. but they've been working on this for 10 years. I think
> because when things go wrong.. the system turns to custard, simulation
> requires specialist tools... you can't prototype in a FPGA either.

But logic that is not being used in a sync design may be clocked, but it
uses far less power than if it were actually working.  I still don't see
the power savings.  To some extent, this is comparing apples to oranges
since the two methods will use very different design techniques.  I
think if you were designing a CPU from scratch you would not even have
the same instruction sets for the two designs.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:4181274C.875E4850@yahoo.com...
> Simon Peacock wrote:
> > Self timed IC's tend to reduce power in several ways... for starts the
peak
> > is lower.. as nothing switches at the same time :-)
>
> Is the smily indicating a joke?  That doesn't save power, right?
>
Well, I think he's trying to say the instantaneous power peak is less for
async. In a sync circuit, most of the energy is consumed at the clock
switching edge. So, the power during the tiny moment of that switch is
enormous, compared to the average power. For async, the transitions are
spread out, as they're delayed in time from one another. This also relates
to the lower EMI thing mentioned in this thread.
Cheers, Syms.
p.s. Good points in the rest of your post, Rick.