Article: Power Delivery in a Modern Processor
By: Paul A. Clayton (paaronclayton.delete@this.gmail.com), May 12, 2020 2:13 pm
Room: Moderated Discussions
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.)
[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.)
