Asynchronous ARM

I remember discussions a while back about an async MCU which I don't
think was an ARM.  Here is a clockless ARM CPU core that seems to be
ready for use.  Anyone know if there are chips out there with this
design?

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

Personally, I don't get the advantages of clockless processing.  If you
are doing embedded, real time work, then a processor with a variable
speed is not an advantage.  You have to synchronize at different
levels, but you still have to synchronize.  So when the processor is
running at max rate (low temp, high Vcc...) you have to stop it to
synchronize with the outside world that you are controlling or
measuring.

I think a lot of the data showing lower power and lower EMI is not
accurate.  It is not that the measurments were faked, but rather that
the measurments are not the ones you should care about.

In comp.sys.arm rickman <gnuarm@gmail.com> wrote:
> Personally, I don't get the advantages of clockless processing.  If you
> are doing embedded, real time work, then a processor with a variable
> speed is not an advantage.

The processor does not have a "variable speed", that's not how asynchronous
logic works. In a traditional synchronous design everything has to happen on
the clock pulse. At a very high level the clock interval must be long enough
for the signals to propagate and for outputs to stabilise. The processor must
also be clocked all the time even if it is not doing anything, this takes
power.

Obviously you can dynamically scale the clock frequency or gate the clock
all together. However the crux of the matter is at any moment in time the
processor, or a subsection of it, is either on or off and is being clocked at
a constant rate.

In an asynchronous circuit you present the input then sometime later the
circuit tells you that the output is valid and should be passed on. A
major problem in asynchronous design is managing when information is valid
and should be passed on. This problem doesn't exist in a synchronous design
as the information is built into the design in the form of assumptions about
the number of clock ticks a particular part of the design will take to
produce a result.

> You have to synchronise at different levels, but you still have to
> synchronise.

You do have to interface your asynchronous core to external synchronous
logic. Doing this efficiently is one of the things Handshake seem to have
worked out how to do and is why it has become possible to commercialise an
asynchronous design.

-p
-- 
"Unix is user friendly, it's just picky about who its friends are."
 - Anonymous
--------------------------------------------------------------------

Paul Gotch wrote:
> In comp.sys.arm rickman <gnuarm@gmail.com> wrote:
> > Personally, I don't get the advantages of clockless processing.  If you
> > are doing embedded, real time work, then a processor with a variable
> > speed is not an advantage.
>
> The processor does not have a "variable speed", that's not how asynchronous
> logic works. In a traditional synchronous design everything has to happen on
> the clock pulse. At a very high level the clock interval must be long enough
> for the signals to propagate and for outputs to stabilise. The processor must
> also be clocked all the time even if it is not doing anything, this takes
> power.

I have already had this discussion in the newsgroups before and I am
not interested in  a long debate on the pros and cons of an
asynchronous clocked system.

The first misconception many people have is that async systems do not
have a clock.  All systems with registers have clocks.  If there is no
clock, there is no register.  Even the set and reset strobes of an RS
FF are clocks.  The fact that the clocks in an async system are gated
through logic and delays does not mean that they are not clocks.

The speed of async systems definitely *do* vary with processing
variations, temperature and power supply voltage.  One of the claimed
advantages is that you get *extra* speed when you keep the temperature
down and you don't have to maintain margin for processing variations.
This is also true in any synchronous system if you really want to
optimize; this is not typically done since it only results in a small
improvement in speed which would then vary between systems.  Since each
system has a minimum speed to maintain, this has virtually no advantage
in the huge majority of applications.

A synchronous system does not need to be clocked when it is "not doing
anything".  There are any number of MCUs that have a mode where the
clock is stopped and the MCU waits for an event to start it up.  This
"sleep" mode is one of the lowest power modes the MCU has, just like
the async processor.


> Obviously you can dynamically scale the clock frequency or gate the clock
> all together. However the crux of the matter is at any moment in time the
> processor, or a subsection of it, is either on or off and is being clocked at
> a constant rate.

Yes, this is correct that you can do the same clock management in a
sync system as in an async system.  Only the parts of either design
that need to be running, are running.


> In an asynchronous circuit you present the input then sometime later the
> circuit tells you that the output is valid and should be passed on. A
> major problem in asynchronous design is managing when information is valid
> and should be passed on. This problem doesn't exist in a synchronous design
> as the information is built into the design in the form of assumptions about
> the number of clock ticks a particular part of the design will take to
> produce a result.

Async logic is not magic.  The part of the circuit that passes the
clock through to the output has to delay the clock more than the
signals are delayed in the logic.  So on each transaction you have many
of the same timing issues to deal with that are done at the clock
domain level in sync logic.


> > You have to synchronise at different levels, but you still have to
> > synchronise.
>
> You do have to interface your asynchronous core to external synchronous
> logic. Doing this efficiently is one of the things Handshake seem to have
> worked out how to do and is why it has become possible to commercialise an
> asynchronous design.

You seem to understand most of the real issues.  In the end async logic
does not have significant advantages.  I can't tell if async logic has
EMI advantages because I have not seen the details of how the test
results I've seen were measured.  This may be one area where there may
be some good to async.  

Thanks for the reply.

rickman wrote:
> The speed of async systems definitely *do* vary with processing
> variations, temperature and power supply voltage.  One of the claimed
> advantages is that you get *extra* speed when you keep the temperature
> down and you don't have to maintain margin for processing variations.
> This is also true in any synchronous system if you really want to
> optimize; this is not typically done since it only results in a small
> improvement in speed which would then vary between systems.  Since each
> system has a minimum speed to maintain, this has virtually no advantage
> in the huge majority of applications.

  There are many tasks that are very loose on their minimum speed,
and where minimum energy is much more important. Anything looking
for battery life, and with a human operator probably has most code
in that category.
  Asyncs are harder to engineer, so tend to target the energy-vital
markets.

  Async and Sync designs DO use the same process, so there are no
huge jumps either way. Async is implicitly voltage tolerant, which
can help in battery systems.
  That said, Sync systems are getting ever-more-complex Vcc/Clock/Temp 
sense controls, and with enough effort in varying and tracking
all 3 params, and complex clock gating, you can get a Sync design to 
approach Async.

  The Clock drive and distribution currents and spectrums will be
fundamentally different, with Async having a more inbuilt spread
spectrum (which you can add externally to a Sync system), but that also 
raises interesting test questions :
  How would you guarantee a Async system would pass, under all operating 
conditions ?

-jg

Jim Granville wrote:
>   There are many tasks that are very loose on their minimum speed,
> and where minimum energy is much more important. Anything looking
> for battery life, and with a human operator probably has most code
> in that category.
>   Asyncs are harder to engineer, so tend to target the energy-vital
> markets.
>
>   How would you guarantee a Async system would pass, under all operating
> conditions ?

This is interesting.  I personally don't believe there are significant
advantages to async systems, but I would be willing to consider using
such a chip, especially if it is an ARM chip.  My current applications
require low EMI as well as efficient power usage.  I would be more than
willing to evaluate a real product for my current application where I
am planning to use an ARM7 with a power consumption of 100 - 300 mW at
full speed.  To meet our deisgn goals power managment will need to be
used.  If I can use an async part and meet our power goals with no
added software burden, that would be a significant advantage.

Wasn't there a real ARM (or other) MCU designed using async clocking?
Anyone remember which company this was? I found the async 8051 from
Philips which might just be useful.  It is not overly fast, but I'm not
sure we really need an ARM CPU in this design.  Unfortunatly it uses
OTP memory which would not work for us.  Obvously designed for the
consumer device market.  

Any other async MCUs that are real chips?

rickman wrote:

> Jim Granville wrote:
> 
>>  There are many tasks that are very loose on their minimum speed,
>>and where minimum energy is much more important. Anything looking
>>for battery life, and with a human operator probably has most code
>>in that category.
>>  Asyncs are harder to engineer, so tend to target the energy-vital
>>markets.
>>
>>  How would you guarantee a Async system would pass, under all operating
>>conditions ?
> 
> 
> This is interesting.  I personally don't believe there are significant
> advantages to async systems, but I would be willing to consider using
> such a chip, especially if it is an ARM chip.  My current applications
> require low EMI as well as efficient power usage.  I would be more than
> willing to evaluate a real product for my current application where I
> am planning to use an ARM7 with a power consumption of 100 - 300 mW at
> full speed.  To meet our deisgn goals power managment will need to be
> used.  If I can use an async part and meet our power goals with no
> added software burden, that would be a significant advantage.
> 
> Wasn't there a real ARM (or other) MCU designed using async clocking?
> Anyone remember which company this was? I found the async 8051 from
> Philips which might just be useful.  It is not overly fast, but I'm not
> sure we really need an ARM CPU in this design.  Unfortunatly it uses
> OTP memory which would not work for us.  Obvously designed for the
> consumer device market.  
> 
> Any other async MCUs that are real chips?

I think that philips one has been EOL'd, as it's quite old now.

Have you contacted handshake solutions ?

-jg

rickman wrote:

> This is interesting.  I personally don't believe there are significant
> advantages to async systems, but I would be willing to consider using
> such a chip, especially if it is an ARM chip.  My current applications
> require low EMI as well as efficient power usage.  I would be more than
> willing to evaluate a real product for my current application where I
> am planning to use an ARM7 with a power consumption of 100 - 300 mW at
> full speed.  To meet our deisgn goals power managment will need to be
> used.  If I can use an async part and meet our power goals with no
> added software burden, that would be a significant advantage.
> 
> Wasn't there a real ARM (or other) MCU designed using async clocking?
> Anyone remember which company this was? I found the async 8051 from
> Philips which might just be useful.  It is not overly fast, but I'm not
> sure we really need an ARM CPU in this design.  Unfortunatly it uses
> OTP memory which would not work for us.  Obvously designed for the
> consumer device market.  

  If you need low power, and are in the middle ground between vanilla 
8051 and small ARM, you could look at the C8051F41x series from Silabs ?
  These have an on chip 2V regulator, and low and ~200uA/MHz to 50MHz.
-jg

Jim Granville wrote:
> rickman wrote:
>
> > This is interesting.  I personally don't believe there are significant
> > advantages to async systems, but I would be willing to consider using
> > such a chip, especially if it is an ARM chip.  My current applications
> > require low EMI as well as efficient power usage.  I would be more than
> > willing to evaluate a real product for my current application where I
> > am planning to use an ARM7 with a power consumption of 100 - 300 mW at
> > full speed.  To meet our deisgn goals power managment will need to be
> > used.  If I can use an async part and meet our power goals with no
> > added software burden, that would be a significant advantage.
> >
> > Wasn't there a real ARM (or other) MCU designed using async clocking?
> > Anyone remember which company this was? I found the async 8051 from
> > Philips which might just be useful.  It is not overly fast, but I'm not
> > sure we really need an ARM CPU in this design.  Unfortunatly it uses
> > OTP memory which would not work for us.  Obvously designed for the
> > consumer device market.
>
>   If you need low power, and are in the middle ground between vanilla
> 8051 and small ARM, you could look at the C8051F41x series from Silabs ?
>   These have an on chip 2V regulator, and low and ~200uA/MHz to 50MHz.

Thanks for the info, but I wanted to explore the low EMI aspects as
well.  I actually have two apps for an MCU.  One is fairly conventional
where it does some simple control of hardware.  The other is much
simpler where it has two slave SPI ports and controls a handful of
relay drivers.  This app is on an RF board and it would be nice to not
have *any* clocks running.

rickman wrote:
> Jim Granville wrote:
> 
>>rickman wrote:
>>
>>
>>>This is interesting.  I personally don't believe there are significant
>>>advantages to async systems, but I would be willing to consider using
>>>such a chip, especially if it is an ARM chip.  My current applications
>>>require low EMI as well as efficient power usage.  I would be more than
>>>willing to evaluate a real product for my current application where I
>>>am planning to use an ARM7 with a power consumption of 100 - 300 mW at
>>>full speed.  To meet our deisgn goals power managment will need to be
>>>used.  If I can use an async part and meet our power goals with no
>>>added software burden, that would be a significant advantage.
>>>
>>>Wasn't there a real ARM (or other) MCU designed using async clocking?
>>>Anyone remember which company this was? I found the async 8051 from
>>>Philips which might just be useful.  It is not overly fast, but I'm not
>>>sure we really need an ARM CPU in this design.  Unfortunatly it uses
>>>OTP memory which would not work for us.  Obvously designed for the
>>>consumer device market.
>>
>>  If you need low power, and are in the middle ground between vanilla
>>8051 and small ARM, you could look at the C8051F41x series from Silabs ?
>>  These have an on chip 2V regulator, and low and ~200uA/MHz to 50MHz.
> 
> 
> Thanks for the info, but I wanted to explore the low EMI aspects as
> well.  I actually have two apps for an MCU.  One is fairly conventional
> where it does some simple control of hardware.  The other is much
> simpler where it has two slave SPI ports and controls a handful of
> relay drivers.  This app is on an RF board and it would be nice to not
> have *any* clocks running.

  These parts have on-chip Osc, and we've found the C8051F series to be 
low EMI,(but have not tested the F410 yet), I'd expect the lower Vcc and
on chip regulator, to make it even better. mA/MHz is less :)
  If the SPI App is too complex for HCMOS Shift registers,
(or even a HEF4094 is you want it really quiet) you could wake up the uC 
on the SPL_SS and shut the clock right down in other cases.
  Just needs a lead-in time allowance after the SPI_SS to re-start the 
on chip osc.

-jg

A coworker suggested that async parts would be harder to produce to
work over a wide temperature range.  I had commented that the only
parts I could find any reference to were commercial temp.  He
attributed this to the difficulty of making them work correctly over
temperature.  I am assuming it is a market issue.  The applications
that require very low power and don't have demanding real time
requirements are typically commercial, battery operated things like key
fobs and pager displays.  The industrial apps likely have more
stringent real time requirements.

Or maybe it is just a question of risk.  If you are making key fobs, do
you care if 1 in 1000 times you have to hit the button again?  But if
you are making the engine control computer I would expect you don't
want predetonation even once in 1000 spark plug fires.