Low-power FPGAs?

rickman wrote:
> 
> Or maybe the tools are not being developed because there are no clear
> advantages to async circuits? 

.. But the tools ARE being developed = that's where this sub thread started.
  Sure, they are not what FPGA users would call mainstream yet
( and probably will not be for FPGA design ), but Philips are one of the 
more cautious companies, and they are also in a position of having made
real silicon.

> 
> Please explain to me in simple terms where the speed, size and power
> advantages come from?  I still have not seen it.  

  If you look at Figs 49 thru 52 in the Philips 87C888, you get some
idea.
  The MIPS/Watt values are very good, especially on what was a relatively
old process. See also how MIPS/Watt scales with Vcc.

  Async is not going to displace Sync designs in all areas, but it
does illuminate design pathways for lower power.
  One of those, is Vary of Vcc.

  Presently FPGA's spec only ONE Vcc, but a recent thread covered
an emerging potential for Wider variances on Vcc.
  This is somewhat innate in the silicon, it just needs the
mindset and specs change to use it.

-jg

On Sun, 31 Oct 2004 11:34:34 -0500, rickman wrote:

> Simon Peacock wrote:
>> 
>> If you have a few spare years it might be able to be explained.  The problem
>> is I don't believe there is anybody here who can explain it.  Maybe its like
>> RDRAM.  In theory great.. in practise its moved so slow that advances in
>> sync logic passed it by.
> 
> I have always held the idea that if a person can not explain something
> clearly, then they likely don't really understand it themselves.  At
> lease that was always my problem.  :)  Back in college I had a roommate
> who asked why the tides bulged on *both* sides of the earth and not just
> on the moon side.  I kept trying to explain it and finaly realized that
> I didn't really know how to explain it because I didn't understand what
> was pulling the tide on the opposite side.  Eventually I figured out
> that it was centrifugal force.  
> 
> I still believe there are *no* things that are hard to understand, only
> things that are not well understood.  And of course, in this case,
> things that are not really accurate...  
> 

It seems to me that you want something that is impossible.  On one hand,
you seem to want an explanation that is reduced to bite-sized slogans.  On
the other hand, you want to argue with the simplified explanation, picking
on details that are to complicated to fit into one sentence.  So which do
you want - a simple slogan, or a detailed, nuanced discussion?  You can't
have both.  You've had the first, and decided to argue with it.  So you
must really want the second, in which case you should really take the time
to read what much more qualified persons have written about at length in
books and formal papers.

> There are differences, such as the clocking method.  But they are apples
> and oranges and until you squeeze them a bit you won't get any juice. 
> What I mean is which one works better depends on how well the details
> can be optimized.  
> 

One obvious source of juice is the difference between the longest and
shortest combinatorial delays (i.e. flip-flop output delay plus routing
delays plus LUT delays plus flip-flop setupt time plus (perhaps) clock
skew). The clock period in a sync design is determined by the maximum
delay. However, the device still has to wait for an entire clock period
even during a cycle when all relevant combinatorial delays are much
less than the maximum. This would not be the case in an async design,
where the performance of a circuit over a period of time is more likely to
be a multiple of the average combinatorial delay rather than a multiple of
the maximum combinatorial delay.

EMI reduction due to spreading the switching current spikes over time
comes for free in an async design, rather than required special clock
chips.

-- 

Phil

>> 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?
>
>Because the data sheet won't tell you how fast your software will run. 
>Trying to measure the speed of software is very difficult considering
>all the permutations of paths that it can take.  In DSP work this become
>very critical since it often is very much real time.  But DSP algorithms
>are often are less complex to analyze than control programs or other
>tasks that embedded micros are running. ...

I'm assuming we have a good data sheet that lists the worst
case times for each instruction.  That's generally true for
simple sync CPUs.  It gets more complicated with high performance
CPUs.

If the program is simple, you can trace the flow.  For example,
with a DSP system you know how many times you go around the loop
in a filter or FFT.

For a sync system, you can count cycles.  For an async system,
you could probably write some software do do the equivalent
sort of bookkeeping.

What do people do for complicated systems?  I'd probably toss
a counter into the wait loop and figure out what fraction of
the CPU was idle.  Maybe make a histogram and see how far out
the tail goes.  Round up more if the cost of failure is higher.

With an async system, I'd expect you could do the same sort
of thing.  Maybe use timers rather than a spin/poll loop to
keep with the low-power philosophy.  But now the problem is
that you have to correct for temp, voltage, and process.
Temp and voltage you can measure.  You can probably measure
process by running some calibration code.  But you still have
to add a fudge factor for the software.  How important is the
software uncertantity relative to the hardware uncertantity?

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

On Sun, 31 Oct 2004 14:49:44 -0600, Hal Murray wrote:

 
> With an async system, I'd expect you could do the same sort
> of thing.  Maybe use timers rather than a spin/poll loop to
> keep with the low-power philosophy.  But now the problem is
> that you have to correct for temp, voltage, and process.
> Temp and voltage you can measure.  You can probably measure
> process by running some calibration code.  But you still have
> to add a fudge factor for the software.  How important is the
> software uncertantity relative to the hardware uncertantity?

It strikes me that the hardware vendor would characterize and bin the
devices in some way that would be meaningful, and provide design tools
that would aid in this manner.  For a fixed-function device (e.g. UART or
fifo) the binning process at the semiconductor vendor would take care of
the speed issue in just the same manner as is done today (from the
viewpoint of someone incorporating the part in their design). For an
instruction-programmable part (i.e. CPU) this would also be the same as
for today (parts speed-graded by the manufacturor, user doesn't have any
meaningful way to compare parts).  And who knows if there will ever be
async programmable logic parts, but if there is, again the manufacturor
speed-grades the parts and has to provide layout and (worst-case) static
timing tools to the designer (no more 'magic' than the current FPGA/CPLD
situation).

-- 

Phil

Hi Phil,
Comments added:-
"Phil Short" <pjs@switchingpost.nospam.com> wrote in message 
news:pan.2004.10.31.19.38.29.636872@switchingpost.nospam.com...
> On Sun, 31 Oct 2004 09:42:06 -0800, Symon wrote:
>
> Performance of a sync device depends on the clock rate, which depends on
> the worst case delays through combinatorial logic and routing delays.  For
> example, if the clock period of a design is determined by the delay
> through a multiplier array, the time between the completion of a simple
> addition and the next clock edge could be quite long. Performance of an
> async device depends, in some sense, on average (rather than maximum)
> delays, and so the result can be available quite sooner.
>
However, sync circuits cope with this by just waiting more cycles for the 
result to appear. The async circuit maybe squeezes the last little bit of 
performance out, but at the expense of a whole load of handshaking stuff.
>
> Not very damning at all.  There are many examples in which superior
> technologies have failed in the market place, with VHS versus Beta being
> the standard example, and GAs vs Si another example, and BeOS yet another.
> Lack of success can be due to a lot of factures unrelated to the
> technology or product itself.  Bad marketing, bad timing, network effect,
> etc.  Factors other than technological merit are quite often the reason
> that products, technologies, and companies succeed or fail, and using
> failure as evidence of a lack of technological merit is totally fallacious
> logic.
>
Well, that's your opinion. My opinion is that the market is rarely wrong, 
especially when the technology has been around for decades, and it's a error 
of judgement to cherry pick one or two examples in the past where marginally 
better technology failed to disprove this. The exception proving the rule 
and all that. If async stuff was really 3 times faster and used 50% of the 
power, as you quoted in a previous post, we'd most likely see a whole lot 
more of it. Just my opinion!
Best, Syms.

Jim Granville wrote:
> 
> rickman wrote:
> >
> > Or maybe the tools are not being developed because there are no clear
> > advantages to async circuits?
> 
> .. But the tools ARE being developed = that's where this sub thread started.
>   Sure, they are not what FPGA users would call mainstream yet
> ( and probably will not be for FPGA design ), but Philips are one of the
> more cautious companies, and they are also in a position of having made
> real silicon.

"Not ... mainstream" is putting it mildly... 


> > Please explain to me in simple terms where the speed, size and power
> > advantages come from?  I still have not seen it.
> 
>   If you look at Figs 49 thru 52 in the Philips 87C888, you get some
> idea.
>   The MIPS/Watt values are very good, especially on what was a relatively
> old process. See also how MIPS/Watt scales with Vcc.

What are you comparing it to?  My copy of the data sheet is dated 2002
and says superceeds the 2000 version.  Most of the chips I would say run
with about the same MIPs/W are also 4 years old.  MSP430, PIC16, AVR...


>   Async is not going to displace Sync designs in all areas, but it
> does illuminate design pathways for lower power.
>   One of those, is Vary of Vcc.

Varying Vcc reduces power for *ALL* chips.  I know for a fact that most
of the PIC MCUs are designed for a range of Vcc, often 2.7 to 5.5
volts.  In fact the power varies with the square of the voltage since
both the current and the voltage change.  


>   Presently FPGA's spec only ONE Vcc, but a recent thread covered
> an emerging potential for Wider variances on Vcc.
>   This is somewhat innate in the silicon, it just needs the
> mindset and specs change to use it.

This is not at all "innate" in silicon.  The chips just need to be
designed for a range of Vcc rather than optimized for the best Vcc as
FPGAs are.  

-- 

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

Symon wrote:
> 
> However, sync circuits cope with this by just waiting more cycles for the
> result to appear. The async circuit maybe squeezes the last little bit of
> performance out, but at the expense of a whole load of handshaking stuff.

Actually async circuits also have to leave margin.  The "handshake" is
timed by delays in the silicon which must be given some margin over the
slowest path through that section of the combinatorial logic.  So just
like you would set your system clock speed a bit slower than the worst
case combinatorial delay path, they must do the same, just on a lower
level.  

When the external system has real time requirements, then the async chip
must meet that speed requirement at its slowest.  Then running faster is
of no benefit.  You just end up in your idle loop running more cycles
and burning more power.  


> > Not very damning at all.  There are many examples in which superior
> > technologies have failed in the market place, with VHS versus Beta being
> > the standard example, and GAs vs Si another example, and BeOS yet another.
> > Lack of success can be due to a lot of factures unrelated to the
> > technology or product itself.  Bad marketing, bad timing, network effect,
> > etc.  Factors other than technological merit are quite often the reason
> > that products, technologies, and companies succeed or fail, and using
> > failure as evidence of a lack of technological merit is totally fallacious
> > logic.
> >
> Well, that's your opinion. My opinion is that the market is rarely wrong,
> especially when the technology has been around for decades, and it's a error
> of judgement to cherry pick one or two examples in the past where marginally
> better technology failed to disprove this. The exception proving the rule
> and all that. If async stuff was really 3 times faster and used 50% of the
> power, as you quoted in a previous post, we'd most likely see a whole lot
> more of it. Just my opinion!
> Best, Syms.

Actually his examples don't really show anything.  Beta vs. VHS was a
marketing issue because Sony wanted unreasonable licensing fees and I
don't think there *IS* any marketing on async logic.  GAs vs. Si is not
an issue of one being better, each has their advantages and each is used
when appropriate.  

This whole discussion is getting too long.  If there are any facts I
would like to hear them.  

-- 

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

Phil Short wrote:
> 
> It seems to me that you want something that is impossible.  On one hand,
> you seem to want an explanation that is reduced to bite-sized slogans.  On
> the other hand, you want to argue with the simplified explanation, picking
> on details that are to complicated to fit into one sentence.  So which do
> you want - a simple slogan, or a detailed, nuanced discussion?  You can't
> have both.  You've had the first, and decided to argue with it.  So you
> must really want the second, in which case you should really take the time
> to read what much more qualified persons have written about at length in
> books and formal papers.

No Phil, am not asking for "bite-sized slogans".  I am asking for a
simple explanation of how this technology works better.  Is it really
that complex that it can't be explained?  


> One obvious source of juice is the difference between the longest and
> shortest combinatorial delays (i.e. flip-flop output delay plus routing
> delays plus LUT delays plus flip-flop setupt time plus (perhaps) clock
> skew). The clock period in a sync design is determined by the maximum
> delay. However, the device still has to wait for an entire clock period
> even during a cycle when all relevant combinatorial delays are much
> less than the maximum. This would not be the case in an async design,
> where the performance of a circuit over a period of time is more likely to
> be a multiple of the average combinatorial delay rather than a multiple of
> the maximum combinatorial delay.

Yes, but I explained how in a real time system, this only moves the
problem from the clock domain to the system domain.  Your chip can run
at faster speeds when it is cooler or just a faster chip (process) but
that won't be of any value since you have to design your system to the
worst case chip delay.  

If you are talking about the different paths within the chip, I still
don't agree that there is a significant difference.   Sync logic is
balanced so that the different circuits have about the same delay so
that the clock speed can be optimized.  So there is not much waste
between the separate circuits.  Within a given circuit the async logic
still has to wait for the logest delay since it has no way of knowing
what speed the logic will run.  Remember the async handshake is really a
delayed clock and must be delayed more than the worst path through the
combinatorial logic.  


> EMI reduction due to spreading the switching current spikes over time
> comes for free in an async design, rather than required special clock
> chips.

Yes, this is one advantage that async circuits have.  But it is
certainly not enough to warrant the efforts required for async design.  

-- 

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

>This is not at all "innate" in silicon.  The chips just need to be
>designed for a range of Vcc rather than optimized for the best Vcc as
>FPGAs are.

They don't have to be designed for multiple voltages.  You can design
them for the primary target and then characterize them (aka fill in the
blanks in the data sheet) at other voltages.

Might be an interesting market opportunity.  Similar to what Xilinx
is doing with only testing to meet a specific design.  Just run the
tests at a different voltage.  (after figuring out how fast the chip
should go so and making another set of speed files for the tools and
...) 

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

Phil Short wrote:
> 
> On Sun, 31 Oct 2004 14:49:44 -0600, Hal Murray wrote:
> 
> 
> > With an async system, I'd expect you could do the same sort
> > of thing.  Maybe use timers rather than a spin/poll loop to
> > keep with the low-power philosophy.  But now the problem is
> > that you have to correct for temp, voltage, and process.
> > Temp and voltage you can measure.  You can probably measure
> > process by running some calibration code.  But you still have
> > to add a fudge factor for the software.  How important is the
> > software uncertantity relative to the hardware uncertantity?
> 
> It strikes me that the hardware vendor would characterize and bin the
> devices in some way that would be meaningful, and provide design tools
> that would aid in this manner.  For a fixed-function device (e.g. UART or
> fifo) the binning process at the semiconductor vendor would take care of
> the speed issue in just the same manner as is done today (from the
> viewpoint of someone incorporating the part in their design). For an
> instruction-programmable part (i.e. CPU) this would also be the same as
> for today (parts speed-graded by the manufacturor, user doesn't have any
> meaningful way to compare parts).  And who knows if there will ever be
> async programmable logic parts, but if there is, again the manufacturor
> speed-grades the parts and has to provide layout and (worst-case) static
> timing tools to the designer (no more 'magic' than the current FPGA/CPLD
> situation).

Ok, I think we are closing the loop here.  Doesn't this make it clear
that when designing with an async part, you still have to allow for the
worst case timing in your system design?  Doesn't that eliminate any
speed advantage async parts might have by running faster when they can?  

-- 

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