Does this mean that the chip isn't clocked? Doesn't that give you a complete metastability nightmare? How does it work?
A Case for Asynchronous Computer Architecture (2000) [pdf]
21–30 of 58 posts
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#22Does this mean that the chip isn't clocked? Doesn't that give you a complete metastability nightmare? How does it work?
No metastability nightmare.
One way to do this is to have each component have an output clock, which raises when it's output is known stable. If an adder has no carries, that takes 1ns. If it has each possible carry, it takes 2ns. You have a second clock propagating backwards to know when the next stage is ready for it's next input.
You still have timing. It's just set to when a component is ready with output, or ready to receive input.
Everything goes faster and uses less power.
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#23Having 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 in…
This is correct. It happens at multiple levels. Oversimplified:
* An async add operation takes variable time based on the number of carries, whereas a sync one is set to the worst-case.
* The clock for an ALU is set for the worst-case even when doing something faster (e.g. an ADD rather than a NAND)
* If you have multiple logic stages handled in one clock cycle, the problem is compounded. The clock is set by the slowest stage for all components in the system.
* If your system is doing nothing, you're still clocking it. Clocks are adjusted, but not at a nanosecond-by-nanosecond level.
All-in-all async gives a nice power boost and a nice performance boost (not enough of a boost to displace an entrenched ecosystem, mind you, but a nice boost nonetheless).
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#24Memory cells are the thing that uses the vast majority of power in a CPU. And they are used everywhere, cache, uOP cache, BTB, etc. Async CPU solved a problem that would have marginal benefit in a metric we care about Also, I imagine, they would need to be implemented assuming the worst timing delay from the processes. They can't be binned like modern CPUs.
That doesn't sound right? Dynamic power is consumed by toggling wires, and memory cells are going to be one of the places where toggling is rare because you can't access all memory all the time. Am I missing something?
Volatile memory consumes constant power to remember its value. Processing circuits only consume power when activated. And it's difficult to get the memory bandwidth saturated in a way that keeps all circuits busy. Computers do work in bursts; Then they wait for data. And practically all classical computer science data structures trash cache, like linked lists and OOP in general.
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#25This 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.
Has there been much progress? I remember hearing a lot about asynchronous logic circuits back in the 90s, but don't hear about much in the way of breakthroughs since then.
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#26I tried to do a clockless fully async bus interface in around 1988 in a chip I was designing at Masscomp for a fast data acquisition system. Never got built, but it was fun trying, and it would've been really fast. "Lower design complexity" though: hahaha! Nope.
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#27I 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 tha…
Do you mean domino logic?
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#28Mini-MIPS isn't that different from a conventional out-of-order superscalar microarchitecture. The article even says:
However, the MiniMIPS pipeline structure can execute instructions out-of-order with respect to each other because instructions that take different times to execute are not artificially synchronized by a clock signal.Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#29Earlier quoted context omitted.
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 in…
This is correct. It happens at multiple levels. Oversimplified: * An async add operation takes variable time based on the number of carries, whereas a sync one is set to the worst-case. * The clock for an ALU is set for the worst-case even when doing something faster (e.g. an ADD rather than a NAND) * If you have multiple logic stages handled in one clock cycle, the problem is compounded. The clock is set by the slow…
Yeah that's the theory, but reality is different and probably why we don't see any in production. (The last company that would admit to a tiny bit of clockless logic, Wave, folded).
The reality is that doing clockless logic introduces a lot of overhead at every state, both area and timing. There is different styles and the issue are different for them, but the bottom line is that nobody has been able to realize the theoretically wins in production (note1). And that's not even addressing the lack of tooling.
note1: the closet IMO is Ivan Sutherlands group which have some very impressive claims, but still nothing you can run out and buy.
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#30I 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 tha…
Do you mean domino logic?
Domino is _one_ version of asynchronous, but that's using a different notion of Asynchronous than the article. Because of the ambiguity, we talk today of clock-less logic, which comes in variants, most notably delay-insensitive and quasi-delay-insensitive. The latter is faster, but less immune to noise (has has terrible timing analysis issues).