A Case for Asynchronous Computer Architecture (2000) [pdf]
avlsi.csl.yale.edu
A Case for Asynchronous Computer Architecture (2000) [pdf]
1–10 of 58 posts
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#2This seems to be from 20 years ago, the most recent citation was from 2000 and it describes a MIPS chip built on a 1998 process.
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#3This seems to be from 20 years ago, the most recent citation was from 2000 and it describes a MIPS chip built on a 1998 process.
And not even a mention of AMULET (https://en.wikipedia.org/wiki/AMULET_microprocessor)
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#4This seems to be from 20 years ago, the most recent citation was from 2000 and it describes a MIPS chip built on a 1998 process.
Yes, but I thought that it could be interesting to look at research on the topic from 20 years ago to compare it with present progress.
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#5This seems to be from 20 years ago, the most recent citation was from 2000 and it describes a MIPS chip built on a 1998 process.
Yes, but I thought that it could be interesting to look at research on the topic from 20 years ago to compare it with present progress.
Asynchronous would work better, but we're unlikely to get there -- too big a change.
It's like:
* having ECC everywhere
* having a single display standard (as opposed to HDMI/DisplayPort/USB-C/DVI/VGA/...)
* some kind of architecture where a single bad expansion card (USB, PCIe, etc.) can't crash a whole computer
... and so on
On one hand, no brainer. On the other hand, it hasn't happened.
NVidia is breaking ground on the move to SIMD/MIMD-style architectures, as predicted at the same time, and only because it gives a 30x boost in performance. Async will probably net us a 50% performance boost or something.
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#6Modern clocked processors don't account for worst-case timings. Instead, instructions take variable count of clock cycles to complete.
In some sense they're already asynchronous, despite clocked.
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#7This seems to be from 20 years ago, the most recent citation was from 2000 and it describes a MIPS chip built on a 1998 process.
Yes, but I thought that it could be interesting to look at research on the topic from 20 years ago to compare it with present progress.
Could you add the publication year in the title of your submission?
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#8I will raise an import distinction: asynchronous logic != dynamic logic.
There can be dynamic synchronous logic, and vice versa.
Dynamic vs. static determines whether the circuit as such needs to be driven by any constant pacing input, whether embedded clock, or external clock, vs. not needing it to arrive to a settled state (to latch.)
If you are to speak strictly, asynchronous vs. synchronous determines whether that pacing input is external, or recovered from input.
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#9Having a common clock reference (per core) is essential for reducing latency between components. If you have to poll or await some other component arbitrarily, there will necessarily be extra overhead and delays in these areas. There will also need to be extra logic area dedicated to these activities. Make no mistake, just because there's no central clock, doesnt mean you are magically off the hook. You still need to logically serialize the instruction stream(s).
Even for low power applications, you would probably use less battery getting the work done quickly in a clocked CPU and then falling back to a lower power state ASAP. Allowing the pipeline effects to take hold in a modern clocked CPU should quickly offset any relative overhead. Heterogenous compute architecture is also an excellent and proven approach.
Certainly, there are many things that happen in a CPU that should not necessarily be bound by a synchronous clock domain (e.g. ripple adder). But, for these areas where async cpu a clear win, would we actually see any gains in practice using real software? Feels like there's a lot of other strategic factors that wash out any specific wins.
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#10Having a common clock reference (per core) is essential for reducing latency between components. If you have to poll or await some other component arbitrarily, there will necessarily be extra overhead and delays in these areas. There will also need to be extra logic area dedicated to these activities. Make no mistake, just because there's no central clock, doesnt mean you are magically off the hook. You still need to…
My understanding--which seems to coincide with this article and which Wikipedia seems to agree with (not that that necessarily means much for this)--is that in an asynchronous circuit latency would be lower, not higher, as the clock is required to wait for the worst-case performance while a clock-less system can proceed immediately once only the required inputs have arrived (or even attempt to speculate on partial inputs, something which would offer no value if you would have to end up waiting for the next tick anyway).