1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Asynchronous ARM

Discussion in 'Embedded' started by rickman, Sep 9, 2006.

  1. rickman

    rickman Guest

    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


    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

    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.
    rickman, Sep 9, 2006
    1. Advertisements

  2. rickman

    Paul Gotch Guest

    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

    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.

    Paul Gotch, Sep 9, 2006
    1. Advertisements

  3. rickman

    rickman Guest

    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, Sep 9, 2006
  4. 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

    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 ?

    Jim Granville, Sep 9, 2006
  5. rickman

    rickman Guest

    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, Sep 9, 2006
  6. I think that philips one has been EOL'd, as it's quite old now.

    Have you contacted handshake solutions ?

    Jim Granville, Sep 9, 2006
  7. 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.
    Jim Granville, Sep 10, 2006
  8. rickman

    rickman Guest

    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, Sep 10, 2006
  9. 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.

    Jim Granville, Sep 10, 2006
  10. rickman

    rickman Guest

    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.
    rickman, Sep 11, 2006
  11. 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 Keinanen, Sep 11, 2006
  12. rickman

    langwadt Guest

    couldn't you accomplish the same running everything off an on-chip
    that also tracks supply and temperature.
    And how much does logic speed actually change over temperature and
    gating the clock would do the same, though them clock tree would always

    be using power
    langwadt, Sep 11, 2006
  13. 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 Keinanen, Sep 12, 2006
  14. I think there was a university project called Amulet.

    Timothy Partridge, Sep 15, 2006
  15. rickman

    langwadt Guest

    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

    langwadt, Sep 15, 2006
  16. 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.

    Jim Granville, Sep 16, 2006
  17. rickman

    langwadt Guest

    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

    langwadt, Sep 16, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.