6 ms·

Heyo, I'm a PhD student in the field. I figured I can talk about its current status. First, here are various search terms: clockless, self-timed, delay-insensi

Heyo, I'm a PhD student in the field. I figured I can talk about its current status. First, here are various search terms: clockless, self-timed, delay-insensitive, latency-insensitive, quasi delay-insensitive (QDI), speed independent, asynchronous, bundled-data There are a wide variety of clockless circuits that each make their own timing assumptions. QDI is the most paranoid, making the fewest timing assumptions. Bundled-data is the least paranoid (its effectively clock-gating). A clockless pipeline is always going to be slower than a clocked one and requires about 2x the area. However, clockless logic is way more flexible, letting you avoid unnecessary computation. Overall, this can mean significantly higher throughput and lower energy, but getting those benefits requires very careful design and completely different computer architectures. Most of the VLSI industry is woefully uneducated in clockless circuit design and the tools are terribly lacking. I've seen many projects go by that make a synchronous architecture clockless, and they have always resulted in worse performance. What this means is that it would take billions of dollars for current VLSI companies to retool, and doing so would only give them a one-time benefit. So, you probably won't see clockless processors from any of the big-name companies any time soon. What they seem to be doing right now is buying asynchronous start-ups and shutting them down. As of the 90nm technology node, its not possible to be switching all of the transistors on chip without lighting a fire. This mean that the 2x area requirement is not much of a problem since a well-designed clockless circuit only needs to switch 25-50% of them at any given time. Also since 90nm, switching frequencies seem to have plateaued with a max of around 10 GHz and typical at around 3 GHz. When minimally sized, simple clockless pipelines (WCHB) can get at most 4 GHz and more complex logic tends to get around 2 GHz (for 28nm technology). Leakage current has become more of a problem, but it's a problem for everyone. There is a horribly dense wikipedia page on QDI, but it has links to a bunch of other resources if you are curious.

Symmetry 7y ago
If we're looking at a post-Moore's Law interregnum in process improvements before we find some new substrate then that might be a good opportunity to explore things like clockless designs when efforts can take longer to pay out.
- nbingham 7y ago
  And the truth is that we are. Here is a bunch of data on Intel's processes that I've pulled together from various public domain sources. The yield curves are a very rough estimate, so take them with a grain of salt. https://www.nedbingham.com/intel_max_transistor.png https://www.nedbingham.com/intel_max_transistor.png https://www.nedbingham.com/intel_switching_frequency.png https://www.nedbingham.com/intel_switching_frequency.png https://www.nedbingham.com/intel_tdp.png https://www.nedbingham.com/intel_tdp.png https://www.nedbingham.com/intel_gate_delay.png https://www.nedbingham.com/intel_gate_delay.png
jacquesm 7y ago
> What they seem to be doing right now is buying asynchronous start-ups and shutting them down. There's a plan!
- tachyonbeam 7y ago
  Investment Program for Embracing Innovation (IPEI) is best-spent capex.
kurthr 7y ago
Yours matches the commentary of a friend in the field from about 2000. I do hope that the end of Moore sees improvement in this sort of design, and the tools required. I do see some high speed low power networking hardware moving this way: Router Using Quasi-Delay-Insensitive Asynchronous Design https://dl.acm.org/citation.cfm?id=2634996&preflayout=flat https://dl.acm.org/citation.cfm?id=2634996&preflayout=flat
- nbingham 7y ago
  Yep, I saw that go by, and a lot of my work is heavily influenced by Andrew Lines. But what I've been seeing is that QDI is really bad at arithmetic because the acknowledgement requirements turn XORs into a nightmare hairball of signal dependencies. But QDI is really good at complex control.
  - kurthr 7y ago
    Interesting analysis... I wonder if "locally clocked" ALUs could help with that sort of thing. Clockless shouldn't have to be a purity test :^)
    - nbingham 7y ago
      Hence my thesis :)
    - deepnotderp 7y ago
      That's more or less GALS ("globally asynchronous locally synchronous ")
  - deepnotderp 7y ago
    That's not true for all ways of doing things, for example, with bundled data, dual rail domino QDI and various commercial groups like wave computing and ETA computing which have their own asynchronous flavors, often optimized for arithmetic operations.
    - 7y ago
avmich 7y ago
> A clockless pipeline is always going to be slower than a clocked one How come? In a clocked design, you have to have clocks slow enough so all possible logic paths would finish. In a clockless one the propagation only takes as much as needed, and in a case of shorter path can take less time, doesn't it?
- nbingham 7y ago
  Synchronous design tools are very good at making all of the pipeline stages have about the same logic depth, which is generally 6-8 transitions/cycle but can be much less. The fastest possible QDI circuit is a very simple, very small WCHB buffer which has 6 transitions/cycle. Most QDI logic will have 10-14 transitions/cycle. Also, the speed of a linear pipeline is limited to the slowest stage in the pipeline whether or not you use clockless. Clockless only helps pipeline speed when you have a complex network.
  - deepnotderp 7y ago
    I don't think it's really fair to condemn all of asynchronous due to the slowness of QDI. There are faster ways of doing things like GaSP, dual rail domino done detection, bundled data, one sided handshaking, etc.
    - nbingham 7y ago
      I think there's been a misunderstanding. You're right, and I don't intend to condemn all of async, or even QDI for that matter :) I am doing my PhD on it, so I do think there is promise. I just think that arithmetic is better handled by Bundled-data specifically. Let QDI do the control leg-work and tack high-performance arithmetic to it. Also, Gasp is certainly faster, but is limited to simple pipelines. That's why I like QDI, it lets me make weird circuits. EDIT: Sorry, I got mixed up between the conversation threads... dislexia is a thing. I'm not saying condemn async or QDI, but we must recognize what it is good at and what it is not. A QDI pipeline stage may be slower, yes. So don't use it if you just want to implement a linear pipeline. But do use it if you have a complex network because of the previously mentioned benefits. Gasp and other async pipeline topologies don't have the flexibility of QDI, and there isn't really a good framework to mix them with QDI techniques at the moment (maybe relative timing?). The power of async comes from this flexibility and the ability to avoid unnecessary computation.
naasking 7y ago
> Overall, this can mean significantly higher throughput and lower energy, but getting those benefits requires very careful design and completely different computer architectures. What effect will this have on our programming languages and programming idioms? To some extent, our low-level programming languages have influenced CPU design, and vice versa, but it's not clear what effect an architectural change like this would have.
- nbingham 7y ago
  Ideally, none. We're leaning toward FPGAs and CGRAs to accelerate tight inner loops. This means that it will have a huge effect on compilers. They will have to compile from a control flow behavioral description like C to a data-flow description to map onto the array. This compilation process is honestly not solved. This is why you have verilog instead of just compiling C to circuitry. I've taken a crack at it (in the form of QDI circuit synthesis from CHP) and every sub-problem is either NP-hard or NP-complete. Though all of this is assuming we solve the memory bottleneck... which... might come about with upcoming work on 3D integration and memristors? who knows.
  - naasking 7y ago
    So this is mostly challenging for imperative languages? So a dataflow heavy language, like functional programming, might be easier to compile?
    - jcranmer 7y ago
      The challenge isn't in extracting a dataflow graph from an imperative control flow format. Compilers are already capable of doing this, and every major compiler has an expression DAG at some point. The challenge is in mapping from a generic dataflow graph to the actual dataflow hardware primitives, which have different requirements whose constraints may require non-trivial mappings.
      - naasking 7y ago
        Register allocation is also NP complete, but we have plenty of efficient approximations that work well enough in practice, like linear scan for fast compilation, or by graph coloring or puzzle solving for slower but more efficient compilation. Is there a comparable tradeoff available in this case?

Symmetry 7y ago

If we're looking at a post-Moore's Law interregnum in process improvements before we find some new substrate then that might be a good opportunity to explore things like clockless designs when efforts can take longer to pay out.

nbingham 7y ago
And the truth is that we are. Here is a bunch of data on Intel's processes that I've pulled together from various public domain sources. The yield curves are a very rough estimate, so take them with a grain of salt. https://www.nedbingham.com/intel_max_transistor.png https://www.nedbingham.com/intel_max_transistor.png https://www.nedbingham.com/intel_switching_frequency.png https://www.nedbingham.com/intel_switching_frequency.png https://www.nedbingham.com/intel_tdp.png https://www.nedbingham.com/intel_tdp.png https://www.nedbingham.com/intel_gate_delay.png https://www.nedbingham.com/intel_gate_delay.png

jacquesm 7y ago

> What they seem to be doing right now is buying asynchronous start-ups and shutting them down. There's a plan!

tachyonbeam 7y ago
Investment Program for Embracing Innovation (IPEI) is best-spent capex.

kurthr 7y ago

Yours matches the commentary of a friend in the field from about 2000. I do hope that the end of Moore sees improvement in this sort of design, and the tools required. I do see some high speed low power networking hardware moving this way: Router Using Quasi-Delay-Insensitive Asynchronous Design https://dl.acm.org/citation.cfm?id=2634996&preflayout=flat https://dl.acm.org/citation.cfm?id=2634996&preflayout=flat

nbingham 7y ago
Yep, I saw that go by, and a lot of my work is heavily influenced by Andrew Lines. But what I've been seeing is that QDI is really bad at arithmetic because the acknowledgement requirements turn XORs into a nightmare hairball of signal dependencies. But QDI is really good at complex control.
- kurthr 7y ago
  Interesting analysis... I wonder if "locally clocked" ALUs could help with that sort of thing. Clockless shouldn't have to be a purity test :^)
  - nbingham 7y ago
    Hence my thesis :)
  - deepnotderp 7y ago
    That's more or less GALS ("globally asynchronous locally synchronous ")
- deepnotderp 7y ago
  That's not true for all ways of doing things, for example, with bundled data, dual rail domino QDI and various commercial groups like wave computing and ETA computing which have their own asynchronous flavors, often optimized for arithmetic operations.
  - 7y ago

avmich 7y ago

> A clockless pipeline is always going to be slower than a clocked one How come? In a clocked design, you have to have clocks slow enough so all possible logic paths would finish. In a clockless one the propagation only takes as much as needed, and in a case of shorter path can take less time, doesn't it?

nbingham 7y ago
Synchronous design tools are very good at making all of the pipeline stages have about the same logic depth, which is generally 6-8 transitions/cycle but can be much less. The fastest possible QDI circuit is a very simple, very small WCHB buffer which has 6 transitions/cycle. Most QDI logic will have 10-14 transitions/cycle. Also, the speed of a linear pipeline is limited to the slowest stage in the pipeline whether or not you use clockless. Clockless only helps pipeline speed when you have a complex network.
- deepnotderp 7y ago
  I don't think it's really fair to condemn all of asynchronous due to the slowness of QDI. There are faster ways of doing things like GaSP, dual rail domino done detection, bundled data, one sided handshaking, etc.
  - nbingham 7y ago
    I think there's been a misunderstanding. You're right, and I don't intend to condemn all of async, or even QDI for that matter :) I am doing my PhD on it, so I do think there is promise. I just think that arithmetic is better handled by Bundled-data specifically. Let QDI do the control leg-work and tack high-performance arithmetic to it. Also, Gasp is certainly faster, but is limited to simple pipelines. That's why I like QDI, it lets me make weird circuits. EDIT: Sorry, I got mixed up between the conversation threads... dislexia is a thing. I'm not saying condemn async or QDI, but we must recognize what it is good at and what it is not. A QDI pipeline stage may be slower, yes. So don't use it if you just want to implement a linear pipeline. But do use it if you have a complex network because of the previously mentioned benefits. Gasp and other async pipeline topologies don't have the flexibility of QDI, and there isn't really a good framework to mix them with QDI techniques at the moment (maybe relative timing?). The power of async comes from this flexibility and the ability to avoid unnecessary computation.

naasking 7y ago

> Overall, this can mean significantly higher throughput and lower energy, but getting those benefits requires very careful design and completely different computer architectures. What effect will this have on our programming languages and programming idioms? To some extent, our low-level programming languages have influenced CPU design, and vice versa, but it's not clear what effect an architectural change like this would have.

nbingham 7y ago
Ideally, none. We're leaning toward FPGAs and CGRAs to accelerate tight inner loops. This means that it will have a huge effect on compilers. They will have to compile from a control flow behavioral description like C to a data-flow description to map onto the array. This compilation process is honestly not solved. This is why you have verilog instead of just compiling C to circuitry. I've taken a crack at it (in the form of QDI circuit synthesis from CHP) and every sub-problem is either NP-hard or NP-complete. Though all of this is assuming we solve the memory bottleneck... which... might come about with upcoming work on 3D integration and memristors? who knows.
- naasking 7y ago
  So this is mostly challenging for imperative languages? So a dataflow heavy language, like functional programming, might be easier to compile?
  - jcranmer 7y ago
    The challenge isn't in extracting a dataflow graph from an imperative control flow format. Compilers are already capable of doing this, and every major compiler has an expression DAG at some point. The challenge is in mapping from a generic dataflow graph to the actual dataflow hardware primitives, which have different requirements whose constraints may require non-trivial mappings.
    - naasking 7y ago
      Register allocation is also NP complete, but we have plenty of efficient approximations that work well enough in practice, like linear scan for fast compilation, or by graph coloring or puzzle solving for slower but more efficient compilation. Is there a comparable tradeoff available in this case?