Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Case for Asynchronous Computer Architecture (2000) [pdf]

avlsi.csl.yale.edu

Post reply on HN
Print view View original

41–50 of 58 posts

Re: A Case for Asynchronous Computer Architecture (2000) [pdf]

#41

Post by blagie »

astrange wrote: post #37
blagie wrote: post #5

Earlier quoted context omitted.

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 o…

> * some kind of architecture where a single bad expansion card (USB, PCIe, etc.) can't crash a whole computer If you mean IOMMU, we do have that. It doesn't seem completely doable because someone could still plug an etherkiller into the card.

I don't care much about hostile attacks. I just lost a few weeks until I debugged my computer was crashing due to a failing wifi card. I care about that sort of thing. That's totally fixable.

Re: A Case for Asynchronous Computer Architecture (2000) [pdf]

#42

Post by pclmulqdq »

ajb wrote: post #39
pclmulqdq wrote: post #38

I worked with Alain Martin at Caltech, and I always loved the idea of asynchronous circuits. When I became an FPGA engineer, I realized the big problem with both FPGAs and asynchronous logic: the tooling doesn't generalize well to other domains, so you have to be a narrow specialist to make progress. If someone could convert synchronous verilog to async circuits under the hood, they may see huge gains in speed and po…

There is an FPGA company, Achronix, that claimed to do this. Their FPGA architecture was apparently asynchronous, and they had tools that compiled synchronous designs onto it. Don't know how good their tech was, but they got bought by Intel and are still making it AFAIR.

Their async tech worked fine, but FPGAs likely don't get the same benefit as ASICs from async logic. Not to mention debugging is hard, so if you're not committed to a design, you may not want to put in the effort.

The Achronix folks are going strong today (still independent), but with a much more conventional FPGA. The on-chip network may be async, but they hide it well. I hope they have lots of success in the future.

Re: A Case for Asynchronous Computer Architecture (2000) [pdf]

#44

Post by Taniwha »

IshKebab wrote: post #21

Does this mean that the chip isn't clocked? Doesn't that give you a complete metastability nightmare? How does it work?

Well to some extent metastability is a result of having a clock (and the tiny feedback loops that we embed in synchronous flops to create storage) - instead you use logic structures that are designed to be asynchronous and that can adjust their timing to not have these issues

Re: A Case for Asynchronous Computer Architecture (2000) [pdf]

#45

Post by bullen »

I don't think async can make things faster but it can make them more energy efficient and the incentives for that is still close to none as our economic models reward waste until all EROEI is depleted.

But you need to add the ability to switch things off dynamically, meaning cores on CPU/GPU; so far the industry has solved this with little.big but that requires all software to change, it's going to take time that we unfortunately do not have as hardware is closing the ownership model.

Re: A Case for Asynchronous Computer Architecture (2000) [pdf]

#46

Post by astrange »

blagie wrote: post #41
astrange wrote: post #37

Earlier quoted context omitted.

> * some kind of architecture where a single bad expansion card (USB, PCIe, etc.) can't crash a whole computer If you mean IOMMU, we do have that. It doesn't seem completely doable because someone could still plug an etherkiller into the card.

I don't care much about hostile attacks. I just lost a few weeks until I debugged my computer was crashing due to a failing wifi card. I care about that sort of thing. That's totally fixable.

Eh, you probably already have the OS architecture for that. The vendor just isn't using it.

Re: A Case for Asynchronous Computer Architecture (2000) [pdf]

#47

Post by jacquesm »

Animats wrote: post #36

It's a classic idea. There were some early asynchronous mainframes built from discrite logic. It might come back. It's an idea that comes around when you can't make the clock speed any higher. It's one of those things from the department of "we can make it a little faster at the cost of much greater complexity, higher cost, and lower reliability". That's appropriate to weapons systems and auto racing.

I think the long term driver won't be speed but power consumption, something that Asynchronous Computing has the potential to materially improve.

Re: A Case for Asynchronous Computer Architecture (2000) [pdf]

#48

Post by jacquesm »

blagie wrote: post #22
IshKebab wrote: post #21

Does 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 rea…

And there are no unnecessary state changes, like you get with a clocked circuit that changes state with the rhythm of the clock, whether or not it is useful. At high frequencies that equates to a lot of power lost.

Re: A Case for Asynchronous Computer Architecture (2000) [pdf]

#49

Post by jacquesm »

Taniwha wrote: post #34
twoodfin wrote: post #12

Earlier quoted context omitted.

Can you write more about this or provide some examples? Of course, memory access has had variable timing “forever”, but the idea that other functional units can vary their timings for instructions is new to me.

Well for example imagine you have a 64-bit adder - and you add two numbers together - let's assume that on e of the in puts is '1' - how long does it take until the output is stable? it depends on the second value an d more importantly how long it takes for all the carries to propagate to the MSB - for a naive circuit and input of 0 the output will stabilise very quickly, for an input of 0xffff_ffff_ffff_ffff it will…

That's a pretty naive adder implementation. A more efficient version would stabilize after two ticks.

Re: A Case for Asynchronous Computer Architecture (2000) [pdf]

#50

Post by adrian_b »

baybal2 wrote: post #11
bob1029 wrote: post #9

Having 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…

Clock distribution eats a lot of power at gigahertz frequencies, and a lot of gates. > If you have to poll or await some other component arbitrarily, there will necessarily be extra overhead and delays in these areas. You don't poll. You have a lot of small input-clocked domains which work at a speed with which data comes.

True, but asynchronous circuits need a lot of extra gates and signals for detecting when an operation is completed and notifying the next stage that it can proceed.

It is very difficult to estimate which of the 2 approaches will need less area and power for some given requirements.

It is likely that for a sufficiently complex device an asynchronous implementation will use less power, but the effort to design bug-free complex asynchronous logic is much higher than for synchronous designs, which is probably the main reason why very few commercial asynchronous devices have existed.

Post reply on HN