Low-power FPGAs?

On Sat, 30 Oct 2004 17:14:43 -0500, Hal Murray wrote:

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

I would assume that async technology is being held back, in part, because
of the lack of widespread availability of design tools, designers familiar
with the techniques involved, and of good production test and
characterization tools, and so forth.  A chicken and egg situation is how
I would put it.

-- 

Phil

Phil Short wrote:
> On Sat, 30 Oct 2004 17:14:43 -0500, Hal Murray wrote:
> 
> 
>>>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?
> 
> 
> I would assume that async technology is being held back, in part, because
> of the lack of widespread availability of design tools, designers familiar
> with the techniques involved, and of good production test and
> characterization tools, and so forth.  A chicken and egg situation is how
> I would put it.

  A good summary, and it also has to do with 'path of least resistance'
- it was easier/cheaper to simply shrink to gain speed.
  That is starting to no longer be true, and at the same time ASYNC 
tools are getting better [hence the Philips/ARM announcement, which is 
really
a Tool Chain one].

-jg

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:6sVgd.24109$mZ2.911799@news02.tsnz.net...
> Phil Short wrote:
> > On Sat, 30 Oct 2004 17:14:43 -0500, Hal Murray wrote:
> >
> >
> >>>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?
> >
> >
> > I would assume that async technology is being held back, in part,
because
> > of the lack of widespread availability of design tools, designers
familiar
> > with the techniques involved, and of good production test and
> > characterization tools, and so forth.  A chicken and egg situation is
how
> > I would put it.
>
>   A good summary, and it also has to do with 'path of least resistance'
> - it was easier/cheaper to simply shrink to gain speed.
>   That is starting to no longer be true, and at the same time ASYNC
> tools are getting better [hence the Philips/ARM announcement, which is
> really
> a Tool Chain one].
>

I believe this is the perfect answer to the problem.. why ?? because no one
demands it!  If enough people wanted, and more important, laid cash out ..
Xilinx would build a self timed, fully async FPGA.  But I pity the support
staff, and of course Mentor and Symplicity tools get thrown out... for
another set of course. so there's another $50k to spend, and the extra pity
for their support staff..

So reality is.. its probably too expensive to change, until the current sync
technology has reached its limit, the tools and design know how is already
paid for.  Of course there can always be another Microsoft.. who comes up
with the perfect 'toy' that everyone wants (and think they need) that uses
async technology and completely flips the industry over in a matter of
years. :-)
From that point.. its most likely to be an ultra fast, ultra big, ultra low
power 'something' for computers or a play station.  Maybe a graphics chip
that draws almost no power and does a billion polygon's a millisecond.


Simon

Hal Murray wrote:
> 
> >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?

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 have never seen anyone try to
count clock cycles (or ns for async circuits) for each instruction and
analyze a program of any complexity.  The best they normally do is
measure it in a simulator or on the bench.  A sync circuit would have
the advantage of always having the same timing regarless of temp,
voltage and process.  The async circuit will vary with those parameters
and will need to be verified.  

Perhaps a prorating figure will be provided to say that if you meet
timing with a 20% margin at 25C and worse case Vdd, then at 70C it will
run ok with the worse process.  But my understanding is that process
variations can be even wider than 20%.  I seem to recall a conversation
with Xilinx suggesting that you provide 50% or more between max and min
delays.  

Async circuits don't remove the issues of meeting a "clock" timing. 
They just push the problem to the system level when you have to meet
real time requirements.  


> It's the same problems as checking setup/hold times.  Just
> turned inside out.
> 
> Is the info not in the data sheet?

What info would you like them to spec?  


-- 

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

I never said "global" and I don't see why you would infer that when we
were talking about the async circuits.  


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

I don't have a copy of that book.  Those sound like great results.  But
there are a lot of other variables and only a handful of examples don't
prove the method.  The Philips async 8051 (which is discontinued after
only a couple of years) doesn't seem to have any special advantages.  It
is (was) not cheaper than sync chips, it was not lower power (2-5 mA at
4 MIPs) and the lack of predictable speed would be a major issue in my
book.  

-- 

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:
> 
> On Sat, 30 Oct 2004 17:14:43 -0500, Hal Murray wrote:
> 
> >>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?
> 
> I would assume that async technology is being held back, in part, because
> of the lack of widespread availability of design tools, designers familiar
> with the techniques involved, and of good production test and
> characterization tools, and so forth.  A chicken and egg situation is how
> I would put it.

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

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

-- 

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

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.

The part I've read is "for the same function, async circuits draw less
power, consume 20% more silicon, and run 15% faster."  The key here is "for
the same function".  I've said before, that a piece of silicon with the same
geometry and same number of transistors running at the same clock rate draws
the same power.  It doesn't really matter what its doing.  So if you have
90% of the silicon working for a sync circuit, and 90% working for an async
circuit, there is no saving.  The saving is async doesn't run all the time,
no clocks, no nothing.  This is where async gets its gains.  I'm sorry I
don't have formulas or detailed numbers, but I don't usually design async
logic :-)

Simon.


"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:41846C13.9E7D6027@yahoo.com...
> Phil Short wrote:
> >
> > On Sat, 30 Oct 2004 17:14:43 -0500, Hal Murray wrote:
> >
> > >>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?
> >
> > I would assume that async technology is being held back, in part,
because
> > of the lack of widespread availability of design tools, designers
familiar
> > with the techniques involved, and of good production test and
> > characterization tools, and so forth.  A chicken and egg situation is
how
> > I would put it.
>
> Or maybe the tools are not being developed because there are no clear
> advantages to async circuits?
>
> Please explain to me in simple terms where the speed, size and power
> advantages come from?  I still have not seen it.
>
> -- 
>
> 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 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...  


> The part I've read is "for the same function, async circuits draw less
> power, consume 20% more silicon, and run 15% faster."  The key here is "for
> the same function".  I've said before, that a piece of silicon with the same
> geometry and same number of transistors running at the same clock rate draws
> the same power.  It doesn't really matter what its doing.  So if you have
> 90% of the silicon working for a sync circuit, and 90% working for an async
> circuit, there is no saving.  The saving is async doesn't run all the time,
> no clocks, no nothing.  This is where async gets its gains.  I'm sorry I
> don't have formulas or detailed numbers, but I don't usually design async
> logic :-)

I understand what you are saying, but in a real world circuit, async
devices don't just stop running of their own accord to save power. 
Consider what is initiating the async circuit.  Either it is running in
a feedback mode triggering itself when it completes each pass, like a
CPU; or it is triggered from an external event, like a clock!  In both
cases the async circuit runs all the time, in fact an async CPU won't be
executing NOPs (and even NOPs require circuits to draw power), it will
be running code in a loop if nothing else.  It can shut down by
executing code to go into a low power state waiting for an external or
timer interrupt, but so can a sync CPU.  

I'm not trying to be a PITA, but no one here has really given this much
thought.  I keep reading a lot of stuff that is very generalized and
does not really describe async vs. sync circuits once you dig a bit. 

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.  


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 agree with you on this whole ASYNC thing. No-one in this thread has 
offered any explanation as to why ASYNC should out-perform SYNC circuits, or 
addressed your concerns. They just offer quotes from academics whose 
research grants depend on it, or suggest that it's too complex to explain. 
As you say, after many years of research, the dearth of commercial 
applications is pretty damning.
On the other hand, 4 billion years of natural selection can't be wrong, I'm 
pretty sure the logic circuit in my head is asynchronous. At least that's 
what it's telling me now! Brains run on about 20 Watts.
Cheers, Syms.

"rickman" <spamgoeshere4@yahoo.com> wrote in message 
news:4185141A.E4005C39@yahoo.com...
>
> I'm not trying to be a PITA, but no one here has really given this much
> thought.  I keep reading a lot of stuff that is very generalized and
> does not really describe async vs. sync circuits once you dig a bit.
>

On Sun, 31 Oct 2004 09:42:06 -0800, Symon wrote:

> Rick,
> I agree with you on this whole ASYNC thing. No-one in this thread has 
> offered any explanation as to why ASYNC should out-perform SYNC circuits, or 

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.

> addressed your concerns. They just offer quotes from academics whose
> research grants depend on it, or suggest that it's too complex to
> explain. As you say, after many years of research, the dearth of
> commercial applications is pretty damning.

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.

-- 

Phil