Low-power FPGAs?

rickman wrote:

> 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 :-)

(snip)

>>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.  

It takes different kinds of logic.  Ordinary FF's would be useless,
so standard FPGA's would not be such a good fit.  Synchronous design
can use a lot of logic keeping things synchronized.   Also, it means
that the whole system is clocked at the rate of the slowest subsystem.

Extra logic and extra design work is then needed to make up for
the speed lost to the synchronous requirement.

(snip)

>>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.

I don't see why you couldn't prototype in an FPGA.  It might take
a larger FPGA than a synchronous design, and all those FF's would
be wasted.  Also, the design tools tend to assume synchronous logic
putting more work on the designer.

> 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.  

For the PDP-10 line, the KA-10 was asynchronous (self timed) while the 
KI-10 and KL-10 were synchronous, pretty much the same instruction set.

-- glen

If current peaks are smaller.. than the PSU is smaller => smaller can be
more efficient.  Also if current doesn't die down instantaneously but decays
due to L & C, then in theory, circuits which idle between clocks would draw
more power than a circuit which gathers all the idles at the end and just
sits there as there is no capacitors to charge and discharge on every clock.
(Just a theory!)

All the rest valid points.. all made it the thesis too...
And you did hit the nail on the head with traffic cops.. That's the big
chunk of true async HDL.  Sync runs at the speed of the slowest device async
goes as fast as possible. so traffic lights are on every corner.
The other big chunk is the variable delay used set minimum times for signal
transportation or for work to happen.  That's why FPGA's don't work.. no
async delays. you would be forced to use constant delays and that breaks the
async rules.

Also I believe that a flip flop that is clocked but does nothing, still
consumes more power than a flip-flop doing nothing. (i.e. no clock)
CMOS is all about changes not static conditions.  The 'average' for async
systems doing the same task as sync systems is longer static periods.

then there aren't any clock buffers in an async system, no need, in large
systems, they can form a significant chunk of power.

Your right about different architectures too... As a sync designer I
synchronise everything. its the mind set... but to design async you need to
think async... and its not easy.. all the rules are thrown out for a new
set.  Async is all about just in time delivery.

And, of course, there are some async designs that draw more power than sync
designs... but as time goes by they will get better.  and you have a silicon
overhead for all the extra 'timing' circuits 20% maybe .. and in reality,
today, silicon is more expensive than power.  for the manufacturer that is.

Simon


"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:4181274C.875E4850@yahoo.com...
> 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

Simon Peacock wrote:
> 
> If current peaks are smaller.. than the PSU is smaller => smaller can be
> more efficient.  Also if current doesn't die down instantaneously but decays
> due to L & C, then in theory, circuits which idle between clocks would draw
> more power than a circuit which gathers all the idles at the end and just
> sits there as there is no capacitors to charge and discharge on every clock.
> (Just a theory!)

These currents spikes are never seen by the PSU.  They are so short that
you have to have decoupling capacitors on your board (and very close to
the chips) to smooth them out so they don't cause havoc with all the
chips on the board.  


> All the rest valid points.. all made it the thesis too...
> And you did hit the nail on the head with traffic cops.. That's the big
> chunk of true async HDL.  Sync runs at the speed of the slowest device async
> goes as fast as possible. so traffic lights are on every corner.
> The other big chunk is the variable delay used set minimum times for signal
> transportation or for work to happen.  That's why FPGA's don't work.. no
> async delays. you would be forced to use constant delays and that breaks the
> async rules.
> 
> Also I believe that a flip flop that is clocked but does nothing, still
> consumes more power than a flip-flop doing nothing. (i.e. no clock)
> CMOS is all about changes not static conditions.  The 'average' for async
> systems doing the same task as sync systems is longer static periods.
> 
> then there aren't any clock buffers in an async system, no need, in large
> systems, they can form a significant chunk of power.

But this is apples and oranges, both have leaves and need to be peeled
before you make juice.  Async may not have clock trees and a clocked
idle FF may use more power than one with no clock, but an async circuit
has to propagate the clock through a delay circuit that is guaranteed to
take more time than the logic circuit.  That certainly will take power *
the number of circuits.  So which is more, apples or oranges? 


> Your right about different architectures too... As a sync designer I
> synchronise everything. its the mind set... but to design async you need to
> think async... and its not easy.. all the rules are thrown out for a new
> set.  Async is all about just in time delivery.

I am not clear.  I agree that the rules are very different.  But I am
not sure the rules have been discovered yet.  If all the circuits are in
a straight line, then each circuit is triggered by the one before it and
you have no timing problems.  If you have any parallel paths, you need a
way to align the data at the end.  Or you have to use a different sort
of structure.  Having all the different circuits idle except the one
being clocked is wasteful of the silicon.  You should be able to keep
all of the silicon busy if possible by the instruction being executed.  


> And, of course, there are some async designs that draw more power than sync
> designs... but as time goes by they will get better.  and you have a silicon
> overhead for all the extra 'timing' circuits 20% maybe .. and in reality,
> today, silicon is more expensive than power.  for the manufacturer that is.

But it is the chip user that pays for the silicon *and* the power.  So
they determine the relative importance.  

Are there any clear, concise guidelines written up anywhere for how to
design async circuits.  I wouldn't mind reading about that in my spare
time (if I can find any).  

-- 

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

I think the PSU does see the short spikes... just over a longer period.

I don't know if there's more than just PHd Thesis about at the moment.
Philips had something.. but it might be in house and I'm sure there's tons
of stuff if you ask the right person.  The stuff I have is getting old  to
old really.. but it is still relevant as the field doesn't seem to have
moved very far in the last 8 years.

When you talk about keeping all the silicon busy.. that's a fairy tail. When
did your last design use every bit of silicon for every clock?  I don't
believe they do.. any piece of complex silicon doesn't use itself 100% all
the time.
My own designs work in bursts... I even build a simple FIFO using shift
registers which swap out ever second cycle.. so they're not used all the
time .. even less than 50%.  Other parts only use one clock in 8.  quite in
efficient really.. but I only have one 16 MHz clock so that's the way it is.
I don't know how much async logic would help for designs like this.. mainly
because the input is sync and the output too.. but that's just one app.

"... but an async circuit has to propagate the clock ..."
You are thinking sync again.. Async circuits don't have a clock.. so nothing
to propagate they rely on hand shakes, delays and just in time.
Clocks are forbidden except in cross over designs (that the sync designer
hasn't got his head around yet!)

There are tricks to aligning parallel paths.. known by sorcerers and
magicians everywhere but not witch doctors.

And yes.. chip users do pay for power and silicon.   But as long as they
pay, the suppliers don't complain.  so they decide what's best for them..
and more chips per wafer is a big plus on the balance sheet.  Of course this
rule doesn't so much apply to Intel.  but they have a bonus of windows..
where you can never have too much power.

Simon


"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:41831590.A7F2D61@yahoo.com...
> Simon Peacock wrote:
> >
> > If current peaks are smaller.. than the PSU is smaller => smaller can be
> > more efficient.  Also if current doesn't die down instantaneously but
decays
> > due to L & C, then in theory, circuits which idle between clocks would
draw
> > more power than a circuit which gathers all the idles at the end and
just
> > sits there as there is no capacitors to charge and discharge on every
clock.
> > (Just a theory!)
>
> These currents spikes are never seen by the PSU.  They are so short that
> you have to have decoupling capacitors on your board (and very close to
> the chips) to smooth them out so they don't cause havoc with all the
> chips on the board.
>
>
> > All the rest valid points.. all made it the thesis too...
> > And you did hit the nail on the head with traffic cops.. That's the big
> > chunk of true async HDL.  Sync runs at the speed of the slowest device
async
> > goes as fast as possible. so traffic lights are on every corner.
> > The other big chunk is the variable delay used set minimum times for
signal
> > transportation or for work to happen.  That's why FPGA's don't work.. no
> > async delays. you would be forced to use constant delays and that breaks
the
> > async rules.
> >
> > Also I believe that a flip flop that is clocked but does nothing, still
> > consumes more power than a flip-flop doing nothing. (i.e. no clock)
> > CMOS is all about changes not static conditions.  The 'average' for
async
> > systems doing the same task as sync systems is longer static periods.
> >
> > then there aren't any clock buffers in an async system, no need, in
large
> > systems, they can form a significant chunk of power.
>
> But this is apples and oranges, both have leaves and need to be peeled
> before you make juice.  Async may not have clock trees and a clocked
> idle FF may use more power than one with no clock, but an async circuit
> has to propagate the clock through a delay circuit that is guaranteed to
> take more time than the logic circuit.  That certainly will take power *
> the number of circuits.  So which is more, apples or oranges?
>
> > Your right about different architectures too... As a sync designer I
> > synchronise everything. its the mind set... but to design async you need
to
> > think async... and its not easy.. all the rules are thrown out for a new
> > set.  Async is all about just in time delivery.
>
> I am not clear.  I agree that the rules are very different.  But I am
> not sure the rules have been discovered yet.  If all the circuits are in
> a straight line, then each circuit is triggered by the one before it and
> you have no timing problems.  If you have any parallel paths, you need a
> way to align the data at the end.  Or you have to use a different sort
> of structure.  Having all the different circuits idle except the one
> being clocked is wasteful of the silicon.  You should be able to keep
> all of the silicon busy if possible by the instruction being executed.
>
>
> > And, of course, there are some async designs that draw more power than
sync
> > designs... but as time goes by they will get better.  and you have a
silicon
> > overhead for all the extra 'timing' circuits 20% maybe .. and in
reality,
> > today, silicon is more expensive than power.  for the manufacturer that
is.
>
> But it is the chip user that pays for the silicon *and* the power.  So
> they determine the relative importance.
>
> Are there any clear, concise guidelines written up anywhere for how to
> design async circuits.  I wouldn't mind reading about that in my spare
> time (if I can find any).
>
> -- 
>
> 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 think the PSU does see the short spikes... just over a longer period.
> 
> I don't know if there's more than just PHd Thesis about at the moment.
> Philips had something.. but it might be in house and I'm sure there's tons
> of stuff if you ask the right person. 

Philips have released some devices over the years.

  Now obsolete, but quite impressive given the process/power results,
is an OTP Telephony 80C51 variant :
http://www.semiconductors.philips.com/cgi-bin/pldb/pip/P87CL888T

-jg

Simon Peacock wrote:
> 
> I think the PSU does see the short spikes... just over a longer period.

Context!  The point was that async logic spreads the spikes out while
sync logic lumps them together.  Actually that is not really true except
for the IO currents.  All the logic elements in a chip switch as the
inputs change.  With the different delays between FFs there are a lot of
individual switching currents.  Even sync logic uses async combinatorial
logic, but the FFs are slaved to a common clock.  

Regardless, whether you group all the switching current spikes together
or spread them out, the PSU sees them the same way due to their high
speed and the slowness of the PSU.  These switching currents run much
faster than the PSU switches or an LDO could possibly respond! 


> I don't know if there's more than just PHd Thesis about at the moment.
> Philips had something.. but it might be in house and I'm sure there's tons
> of stuff if you ask the right person.  The stuff I have is getting old  to
> old really.. but it is still relevant as the field doesn't seem to have
> moved very far in the last 8 years.
> 
> When you talk about keeping all the silicon busy.. that's a fairy tail. When
> did your last design use every bit of silicon for every clock?  I don't
> believe they do.. any piece of complex silicon doesn't use itself 100% all
> the time.

I didn't say 100%.  I just said you need to keep it as busy as
possible.  If an async circuit has five stages with different delays,
you have to wait for all five stages to complete before starting a new
data flow.  Although I guess if you used handshaking between each stage,
rather than just a self timed clock, you could then keep each stage
busy, but only at the rate of the slowest stage.  But doen't that sound
familiar?  


> My own designs work in bursts... I even build a simple FIFO using shift
> registers which swap out ever second cycle.. so they're not used all the
> time .. even less than 50%.  Other parts only use one clock in 8.  quite in
> efficient really.. but I only have one 16 MHz clock so that's the way it is.
> I don't know how much async logic would help for designs like this.. mainly
> because the input is sync and the output too.. but that's just one app.

Actually, I think FIFOs were among the earliest async logic components. 
Back in TTL days a FIFO was actually a series of registers with a
handshake circuit connecting adjacent registers.  If you wrote a word to
an empty FIFO you had to wait for the data to ripple through before you
could read it at the other end.  


> "... but an async circuit has to propagate the clock ..."
> You are thinking sync again.. Async circuits don't have a clock.. so nothing
> to propagate they rely on hand shakes, delays and just in time.
> Clocks are forbidden except in cross over designs (that the sync designer
> hasn't got his head around yet!)

Yes, both async and sync sequential circuits have a clock.  In async the
clock just passes between adjacent stages.  You are calling it a
handshake, but this is used as a clock on FFs somewhere.  Else how do
you trigger the FFs?  


> There are tricks to aligning parallel paths.. known by sorcerers and
> magicians everywhere but not witch doctors.
> 
> And yes.. chip users do pay for power and silicon.   But as long as they
> pay, the suppliers don't complain.  so they decide what's best for them..
> and more chips per wafer is a big plus on the balance sheet.  Of course this
> rule doesn't so much apply to Intel.  but they have a bonus of windows..
> where you can never have too much power.

Hmmmm...  well this could go on all day.  I still stand by my point that
most of the claims of how async circuits are better don't hold water. 
They may be different, but not necessarily better.  I'm not sure anyone
has given a single way in which async circuits are *clearly* better.  

-- 

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 just thought of one way async circuits are a PITA for the board
designer to use.  Sync circuits are typically designed to run correctly
over temp.  The chip builder provides a spec for temperature.  Then your
circuit speed is set by the clock.  

An async circuit is designed to work over a temp range, but is self
timed.  So the board designer has to test over temperature to make sure
the circuit speed will be fast enough.  I was just looking at the data
sheet for the P87CL888 and realized that it would be very hard to verify
the speed of the software vs. your system requirements.  The board
designer would have to verify the system at worst case temperature,
voltage *and* process...  again, the self timed clocking is not an
advantge when your system requirements have to be met at the slowest
speed.  

-- 

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

On Sat, 30 Oct 2004 12:16:40 -0400, rickman wrote:

> 
> Yes, both async and sync sequential circuits have a clock.  In async the
> clock just passes between adjacent stages.  You are calling it a
> handshake, but this is used as a clock on FFs somewhere.  Else how do
> you trigger the FFs?  
> 

The word clock implies a global clock, or at least a clock that goes
to every flip-flop (storage element) in a large section of the chip.  The
handshake signals in async design are local, rather than global in nature
(with, among other things, the benefit of greatly reduced EMI).

> 
> Hmmmm...  well this could go on all day.  I still stand by my point that
> most of the claims of how async circuits are better don't hold water.
> They may be different, but not necessarily better.  I'm not sure anyone
> has given a single way in which async circuits are *clearly* better.

Take a look at the book "Asynchronous Circuit Design" written by Chris J.
Meyers and published by Wiley in 2001. Chapter 9 gives some examples that
clearly contradict your comments.  One example (RAPPID at Intel) give a
simultaneous 3:1 improvement in speed, a 50% improvement in power, and a
much larger input voltage range over the synchronous design using the same
fab process, at the expense of 22% more chip area.  Other examples showed
similar results.

-- 

Phil

>An async circuit is designed to work over a temp range, but is self
>timed.  So the board designer has to test over temperature to make sure
>the circuit speed will be fast enough. ..

I'm missing something.  Why test the board as compared to
read the worst case numbers off the data sheet and see if
they are fast enough?

It's the same problems as checking setup/hold times.  Just
turned inside out.

Is the info not in the data sheet?

-- 
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.

>Take a look at the book "Asynchronous Circuit Design" written by Chris J.
>Meyers and published by Wiley in 2001. Chapter 9 gives some examples that
>clearly contradict your comments.  One example (RAPPID at Intel) give a
>simultaneous 3:1 improvement in speed, a 50% improvement in power, and a
>much larger input voltage range over the synchronous design using the same
>fab process, at the expense of 22% more chip area.  Other examples showed
>similar results.

So why hasn't async technology grabbed a bigger chunk of the market?

-- 
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.