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/pr...6HS/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:
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 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:
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.


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.


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

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

Have you contacted handshake solutions ?

-jg

rickman wrote:

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

On 11 Sep 2006 12:02:52 -0700, "rickman" <gnuarm@gmail.com> wrote:

If you have e.g. a simple multiple bit adder with ripple carry, there
is a specific number of gate delays between the lowest Carry_in to the
highest Carry_out. Add a similar chain of dummy gates (plus one or two
extra gate delays), send the strobe pulse to this dummy chain at the
same time as the actual values are loaded into the adder, the strobe
pulse will arrive to the other end of the dummy chain, when the adder
output has stabilised and thus, can be latched.

Since the dummy chain is operating at the same temperature and supply
voltage as the actual adder, any variation in the adder delay would
also affect the dummy gate delay chain in the same way.

This approach will require some extra gates and hence extra power
consumption, but on the other hand, the strobe needs to be sent to
only those units that are required for a specific operation.

With multiple units operating in parallel, you would have to perform a
logical AND operation on the strobe signals arriving through the dummy
chains of each corresponding unit.

Paul

Paul Keinanen wrote:
couldn't you accomplish the same running everything off an on-chip
oscillator
that also tracks supply and temperature.
And how much does logic speed actually change over temperature and
voltage?

gating the clock would do the same, though them clock tree would always

be using power

-Lasse

On 11 Sep 2006 15:01:13 -0700, langwadt@ieee.org wrote:

For instance for the original 4000 series CMOS gates, the propagation
delay with 50 pF load was about 100 ns at 5 V, but only 20 ns at 15 V.
I do not have the figures for the whole 3 .. 18 V operating supply
voltage range.

Paul

In article <1157838835.360150.20320@i42g2000cwa.googlegroups. com>,
gnuarm@gmail.com ("rickman") wrote:

I think there was a university project called Amulet.

Tim

--
Tim Partridge. Any opinions expressed are mine only and not those of my employer

Paul Keinanen wrote:
yes trippling the voltage should make a difference, but how much can
you expect
from a modern process? +/-10% before it either doesn't work or lets
out the smoke


-Lasse

langwadt@ieee.org wrote:
Not sure what you mean - modern process does not have an implicit narrow
voltage range, but they DO often restrict the Vcc in order to meet speed
targets, and to lower their testing costs.

eg uC are available today that cover 1.8-5.5V, and AUC (?) logic
covers 0.8V to 3.3V

Part of the appeal of Async design, is to remove that tight requirement
on Vcc.

-jg

Jim Granville wrote:
Last time I worked in something in 90nm, 1V was minimum to just retain
the state
of memory etc. nominal was 1.2V. How high do you think you could go
before it lets
out the smoke? Just getting 3.3V IOs is a problem

-Lasse