Paul A. Clayton (paaronclayton.delete@this.gmail.com) on May 12, 2020 2:13 pm wrote:
> dmcq (dmcq.delete@this.fano.co.uk) on May 12, 2020 1:05 pm wrote:
> [snip]
> > There doesn't seem to be much said about asynchronus CPU's lately. I'd have thought they would solve a lot
> > of these problems. Any idea what it is that's the big problem stopping that sort of design being used?
>
> [I am not an expert in this! Keep salt handy.]
>
> I received the impression that design validation and part testing were significant barriers for asynchronous
> design. Part of that is presumably just immaturity. While presumably some of the work for supporting non-synchronous
> design translates to new processes, I suspect some work has to be redone or at least retuned. (The slowdown
> in process development and the increasing importance of energy efficiency may increase the attention given
> to asynchronous design. Such might also work well with approximate computation.)
>
> While using a clock signal for control has significant overheads and routing issues, per
> bit-signal "ready" seems to be too expensive (perhaps especially with increasing wire
> density constraints?). Per operation/stage control seems more practical and attractive,
> but such would still seem to require more buffering than a synchronous design.
>
> Synchronous design seems a bit like lock-based multithreaded software design; one trades some potential parallelism
> for easier conceptualization and validation. (Presumably there is some hardware design equivalent to transactional
> memory/optimistic concurrency as an intermediate point between synchronous and asynchronous.)

This old EE Times article

https://www.eetimes.com/does-asynchronous-logic-design-really-have-a-future/#

provides some explanation for why asynchronous design is less common than one might hope.

Short version: Validation and debugging are harder and the win is not as obvious as one would like.