Asynchronous ARM

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

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.

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

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

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

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.

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.

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

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

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