2. Quite the contrary when you talk about complexity. You have to design for interfaces with different clock domains specifically. This is hard in Verilog, at t

2. Quite the contrary when you talk about complexity. You have to design for interfaces with different clock domains specifically. This is hard in Verilog, at the very least. I did it, I knew - Verilog, having no type system, cannot determine difference between various sizes of bit vectors, let alone prevent one to perform direct operation on the values from different clock domains. VHDL is no better (I can explain). The queues required for more-or-less error prone design are not cheap in any measurement - you have to alter your synchronous design for them, you have to add silicon for them and they introduce additional latency of several cycles when transmitting data. It is the queues between clock domains that prevents splitting sync design into smaller and smaller clock domains. Async design, on the other hand, adds single-clock "queues" between computation stages and that queues are clocked by the completeness of operation, not by some fixed clock rate whatever variable it is. And here some propaganda (which translates as "explanation", BTW). Ripple-carry adder in asynchronous design has average case complexity O(log(W)) (W being word size), just like worst case complexity of carry-lookahead adder. The worst case complexities are different, of course, O(W) and O(log(W)). But that worst-case complexity will occur with probability 1/2^W. What's more, if you dynamically add words of size W where one word has two parts H and L and H is either ones or zeroes, then complexity of asynchronous adder performance will be O(log(L size)) in average case. That may be a case when same adder used for addresses computation and general addition in generic CPU pipeline. Given that ARM has, I believe, immediate operand of size 12, you will have some nice speedup in address computation out of thin air. Without introducing any hacks and/or optimizations.