Steven Lewis, Andrey Martchovsky, Chengcheng Xu Asynchronous Systems Steven Lewis, Andrey Martchovsky, Chengcheng Xu

What are they? A digital designer's worst nightmare Difficult to verify correctly Require venturing out of the 101001 comfort zone and into analog land A fact of life in every modern SoC Even synchronous systems encounter many of the same challenges when circuit size > c / (300 fclk) or when dealing with multiple clock domains Another technique to lower power and noise Asynchronous systems are in fact quite common in many mixed signal applications, where, their relatively simple aspects allow for AMS verification. It is only at the larger integration levels where their nondeterministic nature can be seen as a burden and a difficulty in verification. That often requires system and circuit designers to employ custom simulators and verification flows in order validate proper functionality in the asynchronous system.

The status quo Event relationship and timing is known and predictable Deterministic In a synchronous system, events occur in a certain predictable relation to one another, with sufficient timing margin to guarantee proper operation at the circuit level. Having this determinism enables the verification environment (i.e. simulator) to statically schedule and evaluate the computation operations.

Asyncland Event relationship and timing is not always known nor predictable Non-Deterministic Contention

Buridan's Ass!! A hungry ass, an equal distance from two equal piles of hay will starve to death while pondering on which pile to choose It is impossible for a real analog system to get stuck in such an indecisive state for an infinite amount of time. There is always enough entropy/noise in any real system to tip the scales either way, and the analog gain in the system will bring the output to a decision. Such a unique situation is possible only in two circumstances: In a simulator with the absence of quantum noise. When there is no gain the system, at which point the system would not work. .. and hence the difficulty with contention

Dealing with Contention Must have a way of handling concurrent events or state transitions in a robust way Handshaking Resource arbitration

Types of Async Systems Truly asynchronous systems [Obridko & Ginosar, "Low Energy Asynchronous Adders", 2004] Globally Async Locally Sync (GALS) [Grass, Gurkaynak & Vivet, "Globally Asynchronous, Locally Synchronous Circuits: Overview and Outlook", 2007]

Applications Mixed Signal SoCs and Crypto ICs Without a fixed clock, supply bounce is spread out in the frequency domain [Gurkaynak et al., 2005]

Applications State Machines - delay insensitivity, UML design With a clever use of mutexes, each state can be standardized and the design of a hardware state machine can be done graphically. J. Audy, 2012

Applications Network on Chip (NoC) Hybrid system, with partitioned design process [http://techventures.columbia.edu/news/columbias-dr-nowick-wins-nsf-grant-funding-his-research-chip-networks]

Why go through the trouble with asynchronicity? High-speed clock distribution can be difficult and is an electron guzzler. Clocking everything at the same rate can introduce signal integrity issues, async allows to spread out the system power noise in the frequency domain. Partitioning of a complex design and IP reuse. You are very confident in your design abilities and want debugging to be difficult/impossible (i.e. crypto modules). Robustness.

...and the catch? Design verification is very difficult to do right and really easy to do wrong. Can introduce performance hits unless addressed properly. No industry standard design flow, async design relies heavily on methodology. Debugging?

Key Points Async systems are enabled with same techniques for power optimization as in sync systems. System performance is sensitive to design methodology. Tools for verification are key to bring about a paradigm shift.

Questions?