Async Processors

Jim Granville wrote:
> rickman wrote:
> > BTW, how does the async processor stop to wait for IO?  The ARM
> > processor doesn't have a "wait for IO" instruction.
>
> Yes, that has to be one of the keys.
> Done properly, JNB  Flag,$ should spin only that opcode's logic, and
> activate only the small cache doing it.

No, it should not spin since that still requires clocking of the fetch,
decode, execute logic.  You can do better by just stopping until you
get an interrupt.

> > So it has to set
> > an interrupt on a IO pin change or register bit change and then stop
> > the CPU, just like the clocked processor.  No free lunch here!
>
> That's the coarse-grain way, the implementation above can drop to
> tiny power anywhere.

I disagree.  Stopping the CPU can drop the power to static levels.  How
can you get lower than that?

> > Yes, the async processor will run faster when conditions are good, but
> > what can you do with those extra instruction cycles?
>
> Nothing, the point is you save energy, by finishing earlier.

How did you save energy?  You are thinking of a clocked design where
the energy is a function of time because the cycles are fixed in
duration.  In the async design energy is not directly a function of
time but rather a fuction of the processing.  In this case the
processing takes the same amount of energy, it just gets done faster.
Then you wait until the next external trigger that you need to
synchronize to.  No processing or energy gain, just a longer wait time.



> >>Their gate count comparisons suggest this cost is not a great as one
> >>would first think.
> >
> >
> > But the gate count is higher in the async processor.
>
> Not in the 8051 example.
> In the ARM case, it is 89:88, pretty much even.
>
> The thing to do now, is wait for some real devices,
> and better data.

In the real world two equivalent designs will have to take more gates
for the async design.  You need all the same gates as in the clocked
design, you subtract the clock tree and add back in the async clocking.
 I expect this would be nearly a wash in any design.  The only way the
async design can be smaller is if they make other changes.

I say that clock management will be easier to use and implement and
give the same results as async clocking.  In a large sense, the "async"
clocking is just a way to gate the clock to each logic block on a cycle
by cycle basis.  It is really just a matter of what you claim to get
from this.  Speed is not one of these gains.

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

Again, depends on the application. If it's a packet routing/switching
engine
running below wire speed, then it means that the device will
route/switch
more packets per second without overrunning when not worst case.

> You can do the same thing with a clocked design.  Measure the
> temperature and run the clock faster when the temperature is cooler.
> It just is not worth the effort since you can't do anything useful with
> the extra instructions.

But that only allows derating for temp based on worst case assessment
of the process data. It doesn't allow for automatic adjustments for
process
variation or other device specific variances.

Sure you can take every device and characterize it across all the
environmental factors which impact performance, and write a custom
clock table per device ... but get realistic ...

it's all about tradeoff's ... designs and the target implementation
hardware.

> The glitching happens in any design.  Inputs change and create changes
> on the gate outputs which feed other gates, etc until you reach the
> outputs.  But the different paths will have different delays and the
> outputs as well as the signals in the path can jump multiple times
> before they settle.  The micro-glitching you are talking about will
> likely cause little additional glitching relative to what already
> happens.  Of course, YMMV.

Not true, as there have always been ways to design without glitches
using choices like gray coded counters for state machines, one hot
state machines, and covering the logic states to be glitch free by
design, which most good engineers will purposefully do when practical
and necessary, as should good tools. It's just a design decision to
ensure that every term is deterministic without static or dynamic
hazards. Maybe they don't teach this in school any more now that
everyone does vhdl/verilog.

    http://www.interfacebus.com/Design_Logic_Timing_Hazards.html
    http://findatlantis.com/absint_extended.pdf

In the best async designs, extremely fine grained dual rail, it
shouldn't happen at all with good gate design.

rickman wrote:
>>>Yes, the async processor will run faster when conditions are good, but
>>>what can you do with those extra instruction cycles?
>>
>>Nothing, the point is you save energy, by finishing earlier.
> 
> 
> How did you save energy?  You are thinking of a clocked design where
> the energy is a function of time because the cycles are fixed in
> duration.  In the async design energy is not directly a function of
> time but rather a fuction of the processing.  In this case the
> processing takes the same amount of energy, it just gets done faster.
> Then you wait until the next external trigger that you need to
> synchronize to.  No processing or energy gain, just a longer wait time.

Well, it depends what you take from their published infos.

To me, it makes sense, and I look forward to seeing real devices :)

The ultimate proof, is not what someone thinks may, or may not matter,
but how the actual chip performs.

-jg

fpga_t...@yahoo.com wrote:
> rickman 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.
>
> Again, depends on the application. If it's a packet routing/switching
> engine
> running below wire speed, then it means that the device will
> route/switch
> more packets per second without overrunning when not worst case.

Do they design the equipment to drop packets when it gets hot or when
the PSU is near the low margin or when the chip was just not the
fastest of the lot?  That is my point.  You design equipment to a level
of acceptable performance.  The equipment spec does not typically
derate for uncontrolled variables such as temperature, voltage and
process.

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?


> > You can do the same thing with a clocked design.  Measure the
> > temperature and run the clock faster when the temperature is cooler.
> > It just is not worth the effort since you can't do anything useful with
> > the extra instructions.
>
> But that only allows derating for temp based on worst case assessment
> of the process data. It doesn't allow for automatic adjustments for
> process
> variation or other device specific variances.

Actually they do.  That is called speed grading and nearly all makers
of expensive CPU chips do it.  You could do that with any chip if you
wanted to.  But there is no point unless you want to run your Palm 10%
faster because it is a toy to you.


> Sure you can take every device and characterize it across all the
> environmental factors which impact performance, and write a custom
> clock table per device ... but get realistic ...
>
> it's all about tradeoff's ... designs and the target implementation
> hardware.

Yes, I agree, you have to be realistic.  There is no significant
advantage to having a processor run at different speeds based on
uncontrolled variables.


> > The glitching happens in any design.  Inputs change and create changes
> > on the gate outputs which feed other gates, etc until you reach the
> > outputs.  But the different paths will have different delays and the
> > outputs as well as the signals in the path can jump multiple times
> > before they settle.  The micro-glitching you are talking about will
> > likely cause little additional glitching relative to what already
> > happens.  Of course, YMMV.
>
> Not true, as there have always been ways to design without glitches
> using choices like gray coded counters for state machines, one hot
> state machines, and covering the logic states to be glitch free by
> design, which most good engineers will purposefully do when practical
> and necessary, as should good tools. It's just a design decision to
> ensure that every term is deterministic without static or dynamic
> hazards. Maybe they don't teach this in school any more now that
> everyone does vhdl/verilog.

You are talking about stuff that no one uses because there is very
little advantage and it does not outweight the cost.  My point is that
none of this is justified at this time.

Besides, for the most part, the things you mention do not prevent the
glitches.  One hot state machines use random logic with many input
variables.  Only one FF is a 1 at a time, but that means two FFs change
state at each transition and potentially feed into the logic for many
state FFs.  This means each rank of logic can have transitions from the
two FFs that change and potentially significant power is used even in
the ranks that do not change their output.


>     http://www.interfacebus.com/Design_Logic_Timing_Hazards.html
>     http://findatlantis.com/absint_extended.pdf

I have never heard anyone suggest that you should design to avoid the
intermediate transients of logic.  Of course you can, but there are
very few designs indeed that need to be concerned about the last few %
of power consumption this would save.


> In the best async designs, extremely fine grained dual rail, it
> shouldn't happen at all with good gate design.

Great, you have identified an advantage of async designs.  They can be
done with extremely fine grained dual rail logic that can avoid
transients in intermediate logic.  But then you can do that in sync
designs if you decide you want to, right?

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:43ebe95e$1@clear.net.nz...
> rickman wrote:
> >>>Yes, the async processor will run faster when conditions are good, but
> >>>what can you do with those extra instruction cycles?
> >>
> >>Nothing, the point is you save energy, by finishing earlier.
> >
> >
> > How did you save energy?  You are thinking of a clocked design where
> > the energy is a function of time because the cycles are fixed in
> > duration.  In the async design energy is not directly a function of
> > time but rather a fuction of the processing.  In this case the
> > processing takes the same amount of energy, it just gets done faster.
> > Then you wait until the next external trigger that you need to
> > synchronize to.  No processing or energy gain, just a longer wait time.
>
The gain is very simple.. every time a sync circuit clocks.. a zillion
transistors switch.. less if the circuit is partitioned correctly.  But by
definition, in an async circuit, only the one path actually does something.
The clock distribution in an advanced processor is a significant proportion
of the overall clock budget.  There is also the capacitive effect.. charge
and discharge.. if the current never falls to zero, then the minimum power
is slightly above zero also.  Static cmos fets, of course, draw no current.

Simon

Simon Peacock wrote:
> "Jim Granville" <no.spam@designtools.co.nz> wrote in message
> news:43ebe95e$1@clear.net.nz...
> > rickman wrote:
> > >>>Yes, the async processor will run faster when conditions are good, but
> > >>>what can you do with those extra instruction cycles?
> > >>
> > >>Nothing, the point is you save energy, by finishing earlier.
> > >
> > >
> > > How did you save energy?  You are thinking of a clocked design where
> > > the energy is a function of time because the cycles are fixed in
> > > duration.  In the async design energy is not directly a function of
> > > time but rather a fuction of the processing.  In this case the
> > > processing takes the same amount of energy, it just gets done faster.
> > > Then you wait until the next external trigger that you need to
> > > synchronize to.  No processing or energy gain, just a longer wait time.
> >
> The gain is very simple.. every time a sync circuit clocks.. a zillion
> transistors switch.. less if the circuit is partitioned correctly.  But by
> definition, in an async circuit, only the one path actually does something.
> The clock distribution in an advanced processor is a significant proportion
> of the overall clock budget.  There is also the capacitive effect.. charge
> and discharge.. if the current never falls to zero, then the minimum power
> is slightly above zero also.  Static cmos fets, of course, draw no current.

You are talking about a circuit with NO clock gating.  A sync clocked
circuit can have the clocks dynamically switched on and off to save
power.  I already posted an example of a high end CPU which is doing
that and getting a 3x power savings, just like the async chip compared
to the sync chip listed earlier in the thread.

Actually power dissipation is more complex than just saying "this path
is not used".  If the inputs to a block of logic change, it does not
matter if the outputs are used or not.  The inputs must be held
constant or the combinatorial logic switches drawing current.

Clock distribution is not a significant issue in the timing budget.
The delays in the clock tree are balanced.  If you need to minimize the
effective delay to match IO clocking the delay can be compensated by a
DLL.  The clock tree does use some power, but so does the handshaking
used in async logic.

Everyone seems to minimize their analysis of the situation rather than
to think it through.  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?

rickman wrote:
> > Again, depends on the application. If it's a packet routing/switching
> > engine
> > running below wire speed, then it means that the device will
> > route/switch
> > more packets per second without overrunning when not worst case.
>
> Do they design the equipment to drop packets when it gets hot or when
> the PSU is near the low margin or when the chip was just not the
> fastest of the lot?  That is my point.  You design equipment to a level
> of acceptable performance.  The equipment spec does not typically
> derate for uncontrolled variables such as temperature, voltage and
> process.

Yes, nearly every communications device with a fast pipe, will discard
packets when over run. Cisco Routers of all sizes, DSL modems,
wireless radios, .... it's just everyday fact of life.

Faster cpu's cost more money ... if you want to by a Cisco router that
drops packets at higher loads, spend more money. The primary difference
between whole families, is simply processor speed.

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

>
> > > You can do the same thing with a clocked design.  Measure the
> > > temperature and run the clock faster when the temperature is cooler.
> > > It just is not worth the effort since you can't do anything useful with
> > > the extra instructions.
> >
> > But that only allows derating for temp based on worst case assessment
> > of the process data. It doesn't allow for automatic adjustments for
> > process
> > variation or other device specific variances.
>
> Actually they do.  That is called speed grading and nearly all makers
> of expensive CPU chips do it.  You could do that with any chip if you
> wanted to.  But there is no point unless you want to run your Palm 10%
> faster because it is a toy to you.

No, that is a completely different issue ... not dynamic fit of
processing
power to current on chip delays.

> Yes, I agree, you have to be realistic.  There is no significant
> advantage to having a processor run at different speeds based on
> uncontrolled variables.

No ... wrong.

Sorry ... that is true only in your mind for your designs. It does not
apply
broadly to all designs for all real world problems. Real engineers do
this because it really does matter for THEIR designs.

So, I've already stated clearly one every day application where the
customer
benifits by having routers only drop packets when the hardware isn't
capable
of going faster, rather than derating the whole design to reduced worst
case
performance levels.

> > Not true, as there have always been ways to design without glitches
> > using choices like gray coded counters for state machines, one hot
> > state machines, and covering the logic states to be glitch free by
> > design, which most good engineers will purposefully do when practical
> > and necessary, as should good tools. It's just a design decision to
> > ensure that every term is deterministic without static or dynamic
> > hazards. Maybe they don't teach this in school any more now that
> > everyone does vhdl/verilog.
>
> You are talking about stuff that no one uses because there is very
> little advantage and it does not outweight the cost.  My point is that
> none of this is justified at this time.

"no one uses because" ... sorry, but clearly you haven't been keeping
up with your reading and professional skills training as you certainly
don't know everyone.

You really need to read a lot more the C.A.F. to get a better grounding
on what people actually do these days. ... For starters read starting
at the end of page 3 about Data path reordering and glitch power
reduction:

  http://www.sequencedesign.com/downloads/90300-368.pdf

Get the point ... people concerned about low power, do actually design
to remove glitching by design ... by serious engineering design. Keep
on reading about what "no one uses because" to get a real understanding
about real no body engineering for power in section 5 Architecture
Optimization:

      http://www.mrtc.mdh.se/publications/0914.pdf

Note the lead in to the topic ... glitches can consume a large amount
of power. Now clearly some engineers have never had to worry about
battery life or waste heat from excess power. But for the real power
sensitive engineers, the truth is that nobody can ignore these factors.

The reality is that the faster the logic gets, the more you have to
worry about these timing miss match effects. Three generations back, a
1ns glitch was obsorbed into the switching times. At 90nm glitches as
short as a few dozen ps will cause two unwanted transistions and power
loss. The whole problem with glitches is this extra double state flip
when there should have been zero that robs power ... and that is
amplified by all the logic behind the glitch also flipping once or
twice as well ... greatly amplifing the cost of the initial failure to
avoid glitches by design. At 90nm there are a whole lot more sources of
glitches that require attention to design details that didn't even
matter two or three generations back. So while you may think that no
one actually attempts glitch free design practices, by using formal
logic tools to stop them dead, you clearly do not know everyone to make
that statement so firmly.

If you still think that no one decides to design formally correct
glitch free circuits, keep
reading what leading engineers from Actel, Xilinx, say:


http://klabs.org/mapld04/tutorials/vhdl/presentations/low_power_techniques.ppt
    http://www.ece.queensu.ca/hpages/faculty/shang/papers/fpga02.pdf

Note the end of section 5.2 where it discusses the power consumed in
several of the designs sections due to glitches was 9-18%. Note also
that agressively pipelining with the additional "free" registers in
FPGA's is a clear win. Other ASIC studies by Shen on CMOS combinatorial
logic have stated that as much as 20-70% of a devices power can be
consumed by glitches, which is a strong reminder to use the FPGA
registers and pipeline wisely.

So, from my perspective "no one" concerned about power can possibly be
doing their job if they are unware of glitching power issues ... a
stark contrast from your enlightening broad statements to the contrary.

> >     http://www.interfacebus.com/Design_Logic_Timing_Hazards.html
> >     http://findatlantis.com/absint_extended.pdf
>
> I have never heard anyone suggest that you should design to avoid the
> intermediate transients of logic.  Of course you can, but there are
> very few designs indeed that need to be concerned about the last few %
> of power consumption this would save.

I think you have now, and it's a lot more than a few percent for some
designs.

> Great, you have identified an advantage of async designs.  They can be
> done with extremely fine grained dual rail logic that can avoid
> transients in intermediate logic.  But then you can do that in sync
> designs if you decide you want to, right?

yep ... with worst case limited performance too.

On 9 Feb 2006 16:08:35 -0800, "rickman" <spamgoeshere4@yahoo.com>
wrote:

>Jim Granville wrote:
>> rickman wrote:
>> > BTW, how does the async processor stop to wait for IO?  The ARM
>> > processor doesn't have a "wait for IO" instruction.
>>
>> Yes, that has to be one of the keys.
>> Done properly, JNB  Flag,$ should spin only that opcode's logic, and
>> activate only the small cache doing it.
>
>No, it should not spin since that still requires clocking of the fetch,
>decode, execute logic.  You can do better by just stopping until you
>get an interrupt.
>
>> > So it has to set
>> > an interrupt on a IO pin change or register bit change and then stop
>> > the CPU, just like the clocked processor.  No free lunch here!
>>
>> That's the coarse-grain way, the implementation above can drop to
>> tiny power anywhere.
>
>I disagree.  Stopping the CPU can drop the power to static levels.  How
>can you get lower than that?

There's overhead and delays associated with starting the clock up
again; not significant for power, but may make it impractical for
high-rate I/O.

The other option is to memory-map and use a wait. The clocked
processor will stall, and power consumption will drop, since the
output of the clocked elements aren't changing. However, the clock
nets are still charging and discharging.

For the async processor, though, you should be able to get down to
leakage currents.

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.

>You can do the same thing with a clocked design.  Measure the
>temperature and run the clock faster when the temperature is cooler.

You can't do that because, I think, you can't get the tools to give
you a graph of max frequency vs. temperature for worst-case process
and voltage. You just get the corner cases. With an async design it
doesn't matter - it just runs as fast as it can. Brings to mind the
gingerbread man.

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.

"Local" variations can also affect the async processor.  That is why
the delta between the data and control path delays must be larger than
zero.

In the end all these effects must be accounted for whether at the chip
level or at the system level.


> >You can do the same thing with a clocked design.  Measure the
> >temperature and run the clock faster when the temperature is cooler.
>
> You can't do that because, I think, you can't get the tools to give
> you a graph of max frequency vs. temperature for worst-case process
> and voltage. You just get the corner cases. With an async design it
> doesn't matter - it just runs as fast as it can. Brings to mind the
> gingerbread man.

I don't need tools, silicon speed vs. temp and voltage is a well known
quantity.  Besides, there are little or no tools commercially available
for doing async design.  I assumed we were not talking about the
practicality with today's tools, but were extrapolating to a "perfect"
world.

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.

Ok, FPGA identified one application where it might be acceptable to not
meet your timing goals as the box warms up.  Personally I don't believe
that, since even Cisco designs using requirements and I seriously doubt
there is room for uncontrolled variables limiting the performance of
their equipment.  "Yes, our product will operate at XXX packets per
second (as long as you keep it very cool and the voltage regulator is
at the high end of its spec and the chip is at the fast end of its
spec)."  Do they spec equipment that way?

Doesn't this make sense?  What do you do with the extra MIPs you get
*sometimes*.