Async Processors

Paul Johnson wrote:
> On 9 Feb 2006 15:58:10 -0800, "rickman" <spamgoeshere4@yahoo.com>
> wrote:
>
> >You have ignored the real issue.  The issue is not whether the async
> >design can run faster under typical conditions; we all know it can.
> >The issue is how do you make use of that faster speed?  The system
> >design has to work in the worst case conditions, so you can only use
> >the available performance under worse case conditions.
>
> I think there's an issue here with the definition of "worst-case
> conditions". It's not just process/voltage/temperature corners, and
> tool would have to build in a safety margin even if it was. But, when
> you're designing a static timing analyser, you also have to take into
> account random localised on-die variations, and you have to build in
> more safety margin just in case. The end result is that when doing
> synchronous design your tool gives you a conservative estimate, and
> you're stuck with it. If you've got a bad process async design and a
> bad-process sync design sitting next to each other in a hot room with
> low voltages, then the async design should presumably run faster.

I had a chance to think about this further and I think the localized
variables in path delays actually hurt the async device more than it
does the sync device.

The idea behind the sync clocked design is to deal with all the issues
that make the logic delay time so variable.  Instead of trying to match
delays with the clocking, the entire issue is lumped into the clock
domain.  The clock period has to be larger than the worst case delay
through the logic plus an additional margin for the skewing of the
clock.  Minimizing clock skew is the purpose of the clock tree.  So
this is typically very small and only needs to be added to the logic
delay to get the minimum clock period.

The async processor must match the clock delay with the logic delay and
always keep the clock delay slightly larger.  There are always
variations in timing of similar components due to statistical factors.
Even if it is out at the 3 sigma point, by having a million transitors
on a die, you have to account for the few that are either fast or slow.
 The worst case would be a fast clock path and a slow logic path.  This
skewing must be considered at the logic and clock level.  In the end
you end up having to allow for the deviation in both directions which
means it is doubled.

So the async design likely must have larger margins added to the design
of the handshake path and the result is it will have a slower maximum
speed compared to a sync design.

rickman wrote:
> But the real issue is what do you do with the excess speed of the async
> design at room temp, etc?  Your design has to meet specific goals over
> all variables of temp, voltage and process.

You are too focused on the MHz - forget the MHz for a moment,
and look at the pJ and uV/m.
Many, many designers would be very happy to get those gains,
and still be in the same MHz ballpark.

The High end CPU you mentioned, quotes 15,000 gated clock elements.
At that count, it has to asympotpe to async performance anyway,
and it becomes a semantics exercise what you call a device
with that many gated/local/granular clocks...

-jg

fpga_toys@yahoo.com wrote:
> rickman wrote:
> > If your VOIP started dropping packets so that your phone calls were
> > garbled and the provider said, "of course, we had a hot day, do you
> > expect to see the same speeds all the time?", would you find that
> > acceptable?
>
> IT HAPPENS!!!  Reality Check ... IT HAPPENS EVERY DAY.

Packets are dropped, but for congestion reasons, not because the air
handling in the switch room set the temperature up a few degrees.

-a

Jim Granville wrote:
> rickman wrote:
> > But the real issue is what do you do with the excess speed of the async
> > design at room temp, etc?  Your design has to meet specific goals over
> > all variables of temp, voltage and process.
>
> You are too focused on the MHz - forget the MHz for a moment,
> and look at the pJ and uV/m.
> Many, many designers would be very happy to get those gains,
> and still be in the same MHz ballpark.

We are still not communicating.  You are assuming that the numbers from
the vendor are a valid comparison.  They don't say didly about what
software was running and what was done to save power in the sync
clocked version.  I don't accept that the chip is unique in its power
savings.  I consider this to be just one way to save that level of
power, and likely one of the more difficult ways.


> The High end CPU you mentioned, quotes 15,000 gated clock elements.
> At that count, it has to asympotpe to async performance anyway,
> and it becomes a semantics exercise what you call a device
> with that many gated/local/granular clocks...

But it *is* a sync clocked design.  My point is merely that an async
design does nothing that I can't do in a good sync clocked design if
power savings is my goal.  Further I expect that it is easier to do a
sync design because of the experience we have with it and the way it
easily maps to the system level requirements.

Consider testing.  I have to test my design against system level
requirements.  In a sync design, this just means you test a range of
code which may not even be the code the unit is shipped with.  This
testing can be done at any temperature and any voltage and any device.
Verification that the devices work at the clock speed is done
separately.  System testing just has to verify that the clock speed is
fast enough.

Wiith an async processor you need to test your full code for all paths
under worst case conditions (including process) to verify that you meet
the system timing requirements.  How the heck do you do that???  With
FPGAs you use static timing analysis to verify that you meet timing.
Do they have static timing analysis for software?

Andy Peters wrote:
> fpga_toys@yahoo.com wrote:
> > rickman wrote:
> > > If your VOIP started dropping packets so that your phone calls were
> > > garbled and the provider said, "of course, we had a hot day, do you
> > > expect to see the same speeds all the time?", would you find that
> > > acceptable?
> >
> > IT HAPPENS!!!  Reality Check ... IT HAPPENS EVERY DAY.
>
> Packets are dropped, but for congestion reasons, not because the air
> handling in the switch room set the temperature up a few degrees.

It happens when the router is unable to keep up with the traffic, aka
congestion.
Doesn't really matter why it's slower than the arrival rate.

If async can deliver a faster packet processing rate when the
environmentals
are better, then the cogestion point is moved higher for those periods,
unlike
being locked to worst case performance.

rickman wrote:
 > We are still not communicating.

you got that right.

> My point is merely that an async
> design does nothing that I can't do in a good sync clocked design if
> power savings is my goal.

Wrong. In EVERY case, for each instance a chip used, you need to
design/test for worst case parameters, and hope they do not change
over the chip's life due to migration and other effects, to run the
chip
against the wall with sync designs ... you have to leave margin, that
varies chip by chip.  With async, that problem simply is not a problem.


Again, just like the point about designing to be glitch free for power,
you
again have this wrong because you lack the understanding of current
async design methodologies, and continue to argue based on that lack
of understanding.

> Wiith an async processor you need to test your full code for all paths
> under worst case conditions (including process) to verify that you meet
> the system timing requirements.

Wrong, this is not necessary. The problem is addressed at design by
using
verifiably correct logic constructions to build the logic which are
safe and
hazzard free by design. After that, it doesn't matter what process or
environmental variations may impact the device.

Again, you completely lack the understanding of async design, and do
not even understand what you are claiming is false.

Learn about async design, before you just assume more false positions,
and continue to argue from baseless positions.

rickman wrote:
> My point is merely that an async
> design does nothing that I can't do in a good sync clocked design if
> power savings is my goal.

Now ... the point is, that the clock net will consume considerable
power and is pure overhead. On FPGAs the clock net is typically
responsible for 20-40% of total device power. With fast processors, 30%
of the power is in the clock distribution alone:

    http://www.tkt.cs.tut.fi/kurssit/8404941/S04/chapter5.pdf

This causes huge die heating, cooling, and thermal gradient problems,
and large clocked designs start out with this huge overhead in power
... that frankly pretty much just goes away with async. This is not a
new problem, it's been the core problem for about five years now. And
is getting very well understood. Consider:

   http://www.mwrf.com/Articles/Print.cfm?ArticleID=7278

where the author makes this point:

"Circuits with very high power consumption exhibit significant thermal
gradients across the chip. This is problematic because conventional
timing analysis assumes a single temperature for the entire device,
even though it is well known that timing is temperature dependent. The
usual response is simply to minimize overall chip temperature through
the use of more sophisticated, and expensive, packaging."

The application logic consumes power independent of the clock nets, and
is where the real work is done. Async adds additional logic but few
transistions, which may consume a very small static current (compared
to the total clock net power), to completely remove the clock net and
associated power. The power win for async in designs, is when the extra
power for the ack transistions is less than the clock net it replaces.
Since the ack routing is generally very short, it's frequently
considerably lower power than the globablly routed clocks. For async
ASIC designs, that frees up the clock net metalization and buffers, to
use for the application logic, which offsets the additional logic and
routing to help balance costs, or improve them.

So the point is, that the applicaion logic power costs are fixed, and
driven by the design. The clock net overhead is just that, and using a
careful async design the clock net power can be removed and replaced
with async logic that has lower power costs.

The benefits are that the clock skew in the designs no longer limits
performance, nor does worst case environmentals, which are growing
worse due to unbalanced heating of the die.  Async avoids these
problems by design, at modest costs which are offset by removing the
clock net resources.

fpga_toys@yahoo.com wrote:
> rickman wrote:
>  > We are still not communicating.
>
> you got that right.
>
> > My point is merely that an async
> > design does nothing that I can't do in a good sync clocked design if
> > power savings is my goal.
>
> Wrong. In EVERY case, for each instance a chip used, you need to
> design/test for worst case parameters, and hope they do not change
> over the chip's life due to migration and other effects, to run the
> chip
> against the wall with sync designs ... you have to leave margin, that
> varies chip by chip.  With async, that problem simply is not a problem.
>
>
> Again, just like the point about designing to be glitch free for power,
> you
> again have this wrong because you lack the understanding of current
> async design methodologies, and continue to argue based on that lack
> of understanding.
>
> > Wiith an async processor you need to test your full code for all paths
> > under worst case conditions (including process) to verify that you meet
> > the system timing requirements.
>
> Wrong, this is not necessary. The problem is addressed at design by
> using
> verifiably correct logic constructions to build the logic which are
> safe and
> hazzard free by design. After that, it doesn't matter what process or
> environmental variations may impact the device.
>
> Again, you completely lack the understanding of async design, and do
> not even understand what you are claiming is false.
>
> Learn about async design, before you just assume more false positions,
> and continue to argue from baseless positions.

I was going to ignore your posts because you seem to insist on being
rude.  But I will say this before dropping this discussion with you.

I am not talking about testing the chip as you indicate above.  I am
talking about the system level design issues.  When I write code on a
sync clocked CPU, the execution time is deterministic, even if it is
too complex for me to analyze 100%.  I will see the same results all
the time.  So the chip must be tested over temperature,etc, but I only
need to test my software at room temperature.  In the async clocked
CPU, the system level timing varies with all the things I can't
control.  So I have no way to test my system to be sure it will work,
except to test at room temp and then derate for the three big factors,
temp, voltage and process.  Then we are back to where we started, but
now we have to leave slack in the hardware between the clock and data
path and we also have to leave slack again at the system level.

This has nothing to do with how you design or build the CPU chip.  This
is an artifact of a non-deterministicly timed CPU.  In the end there
are very few apps where an async clocked processor has any real
benefit.

So please don't be rude and tell me I don't understand the design when
you don't understand my statements.

rickman wrote:
> So please don't be rude and tell me I don't understand the design when
> you don't understand my statements.

I rather feel the same way, when you strongly dismiss points with the
assertion that you know best, and everyone else has to be wrong.

rickman wrote:

> Jim Granville wrote:
> 
>>rickman wrote:
>>
>>>But the real issue is what do you do with the excess speed of the async
>>>design at room temp, etc?  Your design has to meet specific goals over
>>>all variables of temp, voltage and process.
>>
>>You are too focused on the MHz - forget the MHz for a moment,
>>and look at the pJ and uV/m.
>>Many, many designers would be very happy to get those gains,
>>and still be in the same MHz ballpark.
> 
> 
> We are still not communicating.  You are assuming that the numbers from
> the vendor are a valid comparison.  

  Shouldn't the engineer in you say 'show me the silicon?', rather than 
sweeping dismissal of all things async, including published info.

  Of course, it is their own comparison, but normally such comparisons 
try to talk up what are actually small differences [just look at Xilinx 
vs Altera marketing noise ...].
  The data they show, for EMC and pJ/Opcode, is orders of magnitude stuff.

> They don't say didly about what
> software was running and what was done to save power in the sync
> clocked version.  I don't accept that the chip is unique in its power
> savings.  

or its EMC improvement ?

> I consider this to be just one way to save that level of
> power, and likely one of the more difficult ways.

  Strange, then, that you believed the other device's specs,
(also pre-silicon) with the 15,000 gated clocks, straight off ?

  Who claimed this was easy ? It's what they must have done
in the tools area, that impresses me as much as the
(claimed) silicon results.

-jg