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

51–58 of 58 posts

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

#51

Post by Taniwha »

jacquesm wrote: post #49
Taniwha wrote: post #34

Earlier quoted context omitted.

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.

yup, but I'm using it as an example to make a point here (hence my use of the word 'naive') - also the whole point of doing async stuff is that you don't have to worry about 'ticks'

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

#52

Post by jacquesm »

Taniwha wrote: post #51
jacquesm wrote: post #49

Earlier quoted context omitted.

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

yup, but I'm using it as an example to make a point here (hence my use of the word 'naive') - also the whole point of doing async stuff is that you don't have to worry about 'ticks'

Even in async you have to worry about ticks, it's just that the ticks aren't global.

Think of the extent to which a clock can propagate as a lightcone, within that domain everything is synchronized, but it need not be synchronized with things on the outside. The smaller the domains the more asynchronous a design gets. But you'll never be async all the way down, at some point you will have to worry about stabilizing your outputs and passing them on to the next stage in that stable situation.

Compare synchronous serial lines with an asynchronous interface such as a centronics printer interface. The former will happily send zeros + clocks all day long absent a signal, the latter will strobe it's 'ready' output only when there actually is data, but it will still have to output that pulse, which serves as a very local clock.

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

#53

Post by boibombeiro »

IshKebab wrote: post #20
boibombeiro wrote: post #14

Memory 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?

The comparison of power usage is often done in the context of external memory. When talking about in-chip memory it becames an apples to orange comparison.

For start, it doesn't make sense to power gate a SRAM. So they are always leaking power. And despite writes not being common, reads are. Most application with SRAM reads all the metadata in parallel looking for a match (and often the data too due timing constraints and increased size of control logic because the extra complexity). And reading uses power.

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

#54

Post by FullyFunctional »

blagie wrote: post #40
FullyFunctional wrote: post #29

Earlier quoted context omitted.

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

I don't think that's right. 1) I think an architecture change -- any architecture change -- is expensive. Intel and AMD dumped many billions of dollars into R&D around existing architectures, and an asynchronous one starts without a lot of that benefit. 2) There's a ton of stuff -- chipsets, RAM, software, etc. -- built up around synchronous. The engineering cost go up astronomically. 3) That's not to mention baselin…

There is no 10% boost - it's fiction

ADDED:

With the millions spent on getting just a minor single digit improvement, you think the big players wouldn't jump on clock-less immediately if they could? Note, Intel did use (does?) use domino logic in the ALU and FPU. The benefit just isn't there for clock-less. I personally know of companies that tried and gave up on it.

To your other points, you wouldn't boil the ocean; you keep everything else clocked as usual and bridge between them.

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

#55

Post by hypertele-Xii »

Taniwha wrote: post #33
hypertele-Xii wrote: post #24

Earlier quoted context omitted.

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.

You're confusing DRAM and CPUs - CPUs almost only use static SRAM cells internally which don't require refresh

Wikipedia says "SRAM is volatile memory; data is lost when power is removed."

So it must consume power to retain its value.

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

#56

Post by Const-me »

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…

> imagine you have a 64-bit adder

Integer addition is too easy. On all modern computers, add instructions take at most 1 cycle. Even vector ones like vpaddq AVX2 which adds four 64-bit numbers to another four numbers.

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

#57

Post by blagie »

FullyFunctional wrote: post #54
blagie wrote: post #40

Earlier quoted context omitted.

I don't think that's right. 1) I think an architecture change -- any architecture change -- is expensive. Intel and AMD dumped many billions of dollars into R&D around existing architectures, and an asynchronous one starts without a lot of that benefit. 2) There's a ton of stuff -- chipsets, RAM, software, etc. -- built up around synchronous. The engineering cost go up astronomically. 3) That's not to mention baselin…

There is no 10% boost - it's fiction ADDED: With the millions spent on getting just a minor single digit improvement, you think the big players wouldn't jump on clock-less immediately if they could? Note, Intel did use (does?) use domino logic in the ALU and FPU. The benefit just isn't there for clock-less. I personally know of companies that tried and gave up on it. To your other points, you wouldn't boil the ocean;…

I think there's a long graveyard of conceptually better architectures which died because people underestimated costs, from Transmeta, to all sorts of SIMD and MIMD systems, to VLIW.

I agree it's not too expensive to prototype, but it's super-expensive to do *right*.

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

#58

Post by achronix »

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.

Achronix is still an independent FPGA company No longer focused on asynchronous FPGA technology Currently shipping high performance synchronous FPGA technology on 7nm Learn more about the Speedster7t FPGA: https://www.achronix.com/product/speedster7t-fpgas
Post reply on HN