Async Processors

I see a link to my web site referenced here concerning logic glitches;
http://www.interfacebus.com/Design_Logic_Timing_Hazards.html

However; because the post is so large, I need to look at it tomorrow
for a proper reply.

I do see many references to power dispassion. Power dispassion is not
an issue, as one gate with a transient, dissipates very little power.
An FPGA design always has a 'near-by' flip flop.

I need to read the full post.

The main site is:
http://www.interfacebus.com/

Jim Granville wrote:
>   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.

I did not see ANY data that was "orders of magnitude".  I saw that they
were about three times less power at an equivalent speed.

I'm not saying that the technology can't save power.  I am saying that
you don't have to toss out the baby with the bath water.  They are
comparing a power optimized design to a non-power optimized one.  We
also know nothing about the program they used which may favor the async
processor because it does not try to save power in the sync processor.


Hey, if there is real data out there showing me how this works and that
it is clearly better, fine.  I'm just saying this is not that sort of
data.


> or its EMC improvement ?

The EMC is significant, but again, is it being compared to an EMC
optimized sync processor... no.  I have seen standard clocked designs
that were optimized for EMC.


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

I'm not doubting the data, I'm doubting the comparison.  Do you see the
difference?


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

Yes, I am sure it was a lot of work and that is part of my concern with
it.  But as long as it is *their* work, if they start making chips that
solve my system problems better than other chips, then I'll use them.
But this chip actually runs slower max speed in the same process.  Did
you notice that?  The clocked processor runs up to 100 MHz, IIRC while
the async processor was only 77 MHz room temp!

Interfacebus.Engineer@gmail.com wrote:
> I see a link to my web site referenced here concerning logic glitches;
> http://www.interfacebus.com/Design_Logic_Timing_Hazards.html

Nice job presenting the material on that page :)

rickman wrote:
> 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.

Simply not true for all async designs, especially those that generate
the ack function from the outputs of the local gates -- in those cases
there are no "margins" added at all, as it is implictly not necessary
by the design of the logic. This works well for fast routing and low
fanout, where gate delays are small and routing delays are small. For
larger designs, where the global clock skew rapidly exceeds these
timings, there is significant gain. 10 year old Phased Logic (ack
encoded as phase), and other async designs with ack based on logic
outputs (rather than a separate timing path) are a good example:

   http://www.erc.msstate.edu/mpl/projects/phased_logic

These designs compete well where global clock skew and environmental
margins greately exceed the typical timing of a logic element and short
route delay.

rickman wrote:

> Hey, if there is real data out there showing me how this works and that
> it is clearly better, fine.  I'm just saying this is not that sort of
> data.
> 
> 
<snip>
> 
> I'm not doubting the data, I'm doubting the comparison.  Do you see the
> difference?

( but above ) : "I'm just saying this is not that sort of data."

I'll leave others to decode that, I'm lost..

>>  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.
> 
> 
> Yes, I am sure it was a lot of work and that is part of my concern with
> it.  But as long as it is *their* work, if they start making chips that
> solve my system problems better than other chips, then I'll use them.
> But this chip actually runs slower max speed in the same process.  Did
> you notice that?  The clocked processor runs up to 100 MHz, IIRC while
> the async processor was only 77 MHz room temp!

There is another, perhaps clearer press release here :

http://www.eet.com/news/design/showArticle.jhtml;jsessionid=RZAVAFCAIVCMGQSNDBECKHSCJUMEKJVN?articleID=179103395

Here, the key comparison is
"at equivalent performance the ARM996HS consumed a factor of 2.8 less 
power than the ARM968E-S, or 36 percent, according to simulation 
benchmark data from Handshake Solutions"

as I have said before, many designers will grab that with both hands.
If this is offered as FAB ready, those designers will not actually care 
about the details.

and they also say

"the ARM996HS is being promoted for its low electromagnetic footprint, 
another benefit of clockless performance which would make the processor 
core suitable for  automotive and mixed-signal applications."

Better EMC is also not to be sneezed at...

but I liked this comment too - Seemed very relevent...

" Richard York, ARM&#4294967295;s ARM996HS product manager, said ARM would not rush 
to introduce clockless versions of other cores. &#4294967295;It [asynchronous logic] 
will take some time to become widely accepted because it is very 
different,&#4294967295; he told EE Times. " and
" &#4294967295;A self-timed Cortex M3 would be a fascinating product but we want to 
see how this product goes in the market first.&#4294967295; "

I look forward to the silicon, both ARM and 80C51 versions.

-jg

rickman wrote:
"This reminds me a bit of the way fuzzy logic was claimed to be such an
advance, but when you looked at it hard you would find little or no
real advantage.  Do you see many fuzzy logic projects around anymore?"

Yes, quite a few.  Bruno Di Stefano posted these 10 recently:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
GPS car navigation from German company NAVIGON comes to USA
(http://msmobiles.com/news.php/4766.html )
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Emerson Wins $13 Million Contract to Digitally Automate Korea's
Largest
Coal-Fired Power Plant
(http://www.automation.com/store/pdetails16264.php )
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Socket Communications Unveils Industry First Cordless Ring Scanner for
Bluetooth Enabled Mobile Computers
(http://home.businesswire.com/portal/site/google/index.jsp?ndmViewId=n...
)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Fujitec eases bottlenecks
(http://news.enquirer.com/apps/pbcs.dll/article?AID=/20060116/BIZ01/60...
)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
WCC Announces ELISE for Linux
(http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/stor...
  )
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Bluetooth "ring scanner" works with Windows Mobile handhelds
(http://www.windowsfordevices.com/news/NS9845751870.html )
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Online Marketing: Google Enhances Filters Once Again - How will it
affect you?
(http://rismedia.com/index.php/article/articleview/13227/1/1/)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Handwriting recognizer supports square screens, VGA
(http://www.windowsfordevices.com/news/NS2550969623.html )
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CalliGrapher 8.2 for Mobile Devices
(http://www.digitalhomecanada.com/content/view/1007/60/ )
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The Weather Wizards
(http://www.avweb.com/news/airman/191492-1.html )
"With the Forecast Icing Potential (FIP) tool, pilots can make
themselves aware of expected icing hazards along their route up to 12
hours in advance. FIP provides a high-tech, color, weather map and a
flight-route display of icing potential at flight levels from 3,000 to
18,000 feet.
The algorithm analyzes weather data from a vertical column perspective.
It determines the cloud top and base heights, checks for embedded cloud
layers, and identifies precipitation types. Once the likely locations
of
clouds and precipitation are found, the physical icing situation is
determined, and a fuzzy logic method is used to determine the icing
potential. Every three hours the model generates forecasts out to 12
hours. The user can select forecast times from three-, six-, nine-, and
12-hour intervals to plan safe routes of travel."
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Predictor wrote:
> rickman wrote:
> "This reminds me a bit of the way fuzzy logic was claimed to be such an
> advance, but when you looked at it hard you would find little or no
> real advantage.  Do you see many fuzzy logic projects around anymore?"
>
> Yes, quite a few.  Bruno Di Stefano posted these 10 recently:
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> GPS car navigation from German company NAVIGON comes to USA
> (http://msmobiles.com/news.php/4766.html )
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Emerson Wins $13 Million Contract to Digitally Automate Korea's
> Largest
> Coal-Fired Power Plant
> (http://www.automation.com/store/pdetails16264.php )
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Socket Communications Unveils Industry First Cordless Ring Scanner for
> Bluetooth Enabled Mobile Computers
> (http://home.businesswire.com/portal/site/google/index.jsp?ndmViewId=n...
> )
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Fujitec eases bottlenecks
> (http://news.enquirer.com/apps/pbcs.dll/article?AID=/20060116/BIZ01/60...
> )
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> WCC Announces ELISE for Linux
> (http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/stor...
>   )
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Bluetooth "ring scanner" works with Windows Mobile handhelds
> (http://www.windowsfordevices.com/news/NS9845751870.html )
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Online Marketing: Google Enhances Filters Once Again - How will it
> affect you?
> (http://rismedia.com/index.php/article/articleview/13227/1/1/)
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Handwriting recognizer supports square screens, VGA
> (http://www.windowsfordevices.com/news/NS2550969623.html )
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> CalliGrapher 8.2 for Mobile Devices
> (http://www.digitalhomecanada.com/content/view/1007/60/ )
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> The Weather Wizards
> (http://www.avweb.com/news/airman/191492-1.html )
> "With the Forecast Icing Potential (FIP) tool, pilots can make
> themselves aware of expected icing hazards along their route up to 12
> hours in advance. FIP provides a high-tech, color, weather map and a
> flight-route display of icing potential at flight levels from 3,000 to
> 18,000 feet.
> The algorithm analyzes weather data from a vertical column perspective.
> It determines the cloud top and base heights, checks for embedded cloud
> layers, and identifies precipitation types. Once the likely locations
> of
> clouds and precipitation are found, the physical icing situation is
> determined, and a fuzzy logic method is used to determine the icing
> potential. Every three hours the model generates forecasts out to 12
> hours. The user can select forecast times from three-, six-, nine-, and
> 12-hour intervals to plan safe routes of travel."
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

So that is what, perhaps 1000 to 1 ratio of fuzzy logic projects to
hard logic projects?

I have never explored fuzzy logic myself, but Bob Pease has and I read
what he had discovered about it.  There were a lot of claims that were
not supported.  Of course the lack of evidence of a positive does not
prove a negative.  But I have seen little reason to consider fuzzy
logic a perferable alternative to any other type of design and
implementation.

Likewise, I don't see any reason to belive that async clocked logic
design has significant advantages over standard sync clocked logic
design for most applications.

There has been a lot of speculation here, a little evidence from
vendors was presented (which may or may not have been biased, we don't
have sufficient info to judge) and a lot of links of largely irrelevant
stuff was given.  I stand my my analysis of the logic that was
described to me.

The main issues are two; async logic is claimed to provide more speed
and/or run with lower power consumption.  Other than some very unusual
applications where it is ok to not meet deadlines and drop data, no one
has presented a way that the added speed can be used.  Likewise, I have
not seen any convincing evidence of lower power than you can achieve
using sync designs if your goal is to reduce power consumption.

Consider that the example that started all this compared an async
processor that is *slower* than the sync processor they are comparing
it to.  The sync processor also has little designed into it to save
power, it just runs full tilt unless you put it in a low power mode
directly when you have nothing to do.  But this is not the only way to
use sync logic.  You can be smart about managing clock gating.  I think
there are other ways to save power in both sync and async designs, but
I won't go into that here.  I want to explore that myself in an FPGA
design I am doing.

rickman wrote:
> So that is what, perhaps 1000 to 1 ratio of fuzzy logic projects to
> hard logic projects?

Absolutely a BS logical deduction. By that same reasoning, air planes
are totally useless because they are not used as frequently as bicyles,
motorcycles, and cars. That earth movers and excavators are useless
because their are not as many of those as there are shovels, power
drills or screwdrivers. That ocean going oil tankers are not useful
because they are a minority in oil transportation designs compared to
rail tankers and semi-tankers.

If it's the right tool, device, design ... use it ... even if
relatively rare in use globally.

The experts basically agree that Fuzzy logic, especially when used for
control systems, is a different mathmatical frame work for representing
probabliity based inputs into a system, and that it takes some pretty
serious math to prove that the resulting system is stable -- not unlike
a traditional control system design which has probability based control
functions and inputs which are not continuous. There are also a number
of trivial FL designs, which clearly can be implemented other ways, and
in many cases probably should be for real world applications. There are
also designs where traditional mathmatical models of the system simply
are not practical to develop, where researchers find that FL systems
combined with other AI approaches yeild usable solutions, which may or
may not be as optimal as if you spent the time to actually discover a
more formal description of the problem (if at all possible) and use
traditional approaches.

> I have never explored fuzzy logic myself, but Bob Pease has and I read
> what he had discovered about it.  There were a lot of claims that were
> not supported.  Of course the lack of evidence of a positive does not
> prove a negative.  But I have seen little reason to consider fuzzy
> logic a perferable alternative to any other type of design and
> implementation.

I also read that series a couple years ago, and the nut of it was that
he insulted a lot of people and expected them then to argue with him to
debate the merits of the technology, and when they didn't used that as
proof in the final article that he was right.

> Likewise, I don't see any reason to belive that async clocked logic
> design has significant advantages over standard sync clocked logic
> design for most applications.

Which may well be partially true today, given the lack of tools and
huge bias left over from 25 years of teaching people that async is bad.
I did my VLSI class 20+ years ago using Carver Mead and Lynn Conway's
book which also discussed async designs with the instructor absolutely
bashing async design, as probably a few hundred thousand other students
have been subjected to the sync only mantra.  I did a self clocked high
speed data separator for my project, which didn't go over well, but was
also impossible as a clocked design for the techology of the day.

But you seem to argue more than just the point of fuzzy or async being
unreasonable for many projects, you seem to also argue that they aren't
reasonable for ANY project. Frequenty by dismissing the results of
actual projects with conjecture that you somehow could do the same with
sync design.  And that really is asserting that you some how know
better than those other researchers and engineers, even when you also
state you do not have experience designing with these technologies.

> The main issues are two; async logic is claimed to provide more speed
> and/or run with lower power consumption.  Other than some very unusual
> applications where it is ok to not meet deadlines and drop data, no one
> has presented a way that the added speed can be used.  Likewise, I have
> not seen any convincing evidence of lower power than you can achieve
> using sync designs if your goal is to reduce power consumption.

BS.

You were given references which directly refute this ... which if you
actually read, you are then implicitly claiming those references are
somehow fraudulent, or otherwise incorrect, without providing proof in
your unfounded claim above. If you did not read, and analyze, then you
do not have the right to make this claim before doing so, and
sucessfully refuting their work.

You were provided references for the arm project, which clearly state
the operating power of the async design was 1/3 that of the clocked
reference design in units of W/MHz, which you promptly ignore because
the resulting target design was slower. This IS a valid measurement
when power scales linearly with clock rate.

You were provided references, and more are available, where PL async
tools where applied to existing sync designs, and significant power
reduction resulted.

> Consider that the example that started all this compared an async
> processor that is *slower* than the sync processor they are comparing
> it to.

The sync reference design was the ARM968E-S described as "Smallest,
lowest power ARM9E Family CPU to date (gate count = 80% of ARM966E-S)"
by the developers, who obviously are very proud that they got the size
and power down again on this iteration of their product. You are
effectively stating that you can take their optimized sync design, and
reduce it's power per megahertz by 65+% as the folks at Handshake
Solutions did -- which implies that you consider the ARM.com team that
did the ARM968E-S core design pretty close to clueless and incompetent
NO? I would guess that the ARM.com team is far from incompetent when it
comes to optimizing their design.

    http://www.arm.com/products/CPUs/ARM968E-S.html

The handshake solutions team then takes that netlist, and applies async
design tools to it, and manages to reduce it's power significantly ...


http://www.handshakesolutions.com/Products_Services/ARM996HS/Index.html

>From 130nW/MHz to 45nW/MHz ... a 65+% reduction in power. Which you
then dismiss with "Likewise, I have not seen any convincing evidence of
lower power than you can achieve using sync designs if your goal is to
reduce power consumption."

It seems, that you refuse to accept the evidence, and refuse to refute
it, offering only the assertion that you can do better, and fail to
even justify that with proof.

fpga_t...@yahoo.com wrote:
 >From 130nW/MHz to 45nW/MHz ... a 65+% reduction in power. Which you

ops ... 130uW/MHz to 45uW/Mhz ...

fpga_toys@yahoo.com wrote:
> The handshake solutions team then takes that netlist, and applies async
> design tools to it, and manages to reduce it's power significantly ...

hmmm ... need to slow down ... it was not stated they started with this
netlist,
just that they have an equiv design.