i would have thought an asynchronous finite state machine type of system could be used to create a computer?
A Case for Asynchronous Computer Architecture (2000) [pdf]
31–40 of 58 posts
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#32This 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 )
Nor this one:
https://authors.library.caltech.edu/43698/1/25YearsAgo.pdf
It was the original paper for this that got me interested in building silicon tools
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#33Earlier quoted context omitted.
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.
You're confusing DRAM and CPUs - CPUs almost only use static SRAM cells internally which don't require refresh
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#34Modern 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.
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 take 64 adder delays - an async circuit can have simple additions run faster than the worst case ones (which will still work). While a synchronous circuit would have a clock that could only go as fast as the slowest case (or pipeline things so that the output appears multiple clocks later)
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#35Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#36It'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.
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#37Earlier quoted context omitted.
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 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.
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#38I 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 power use for their circuits, but that is a huge uphill climb.
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#39I 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.
Re: A Case for Asynchronous Computer Architecture (2000) [pdf]
#40Earlier quoted context omitted.
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 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 baseline engineering costs.
Async won't give a 2x boost to performance. I would guess it'd be 10%, maybe even 30%. That's not nearly enough to justify the investment.
Ivan Sutherlands' work certainly won't compete with teams 10+x times that size and investment.