3 ms·

Anyone here working on async chips these days?

pjc50 10y ago
I used to work at a startup ( https://www.linkedin.com/company/azuro https://www.linkedin.com/company/azuro ) that was commercialising the founders' work on asynchronous design. They eventually sold to Cadence. Asynchronous design is a huge sell; we scaled it back to just applying some async techniques to the clock tree of synchronous designs for moderate performance/power improvements. There are three problems we found: - the existing toolchain is synchronous-orientated, so you'd have to replace all of it and retrain your staff. - the chip developers and their managers tend to be older and more conservative than the software world. They're also potentially large teams (Intel are obviously huge). So the retraining is going to be difficult and expensive. - it's risky. New toolchain and newly trained staff? There's going to be bugs in the tools and errors in the design. Worse, there will be new types of bug that people aren't good at diagnosing. These will take weeks to resolve and a couple of wafer sets. That's a very expensive proposition! If async is to get a foothold it would be, like ARM, starting at the low end. Low power consumption is an obvious pitch for microcontrollers, and the simpler designs will be less risky.
- bensummers 10y ago
  ARM tried it in the 90s with the AMULET. https://en.wikipedia.org/wiki/AMULET_microprocessor https://en.wikipedia.org/wiki/AMULET_microprocessor
  - david-given 10y ago
    I knew someone who was (tangentially) involved with that; apparently one of the biggest problems was that it came out during the height of the Megahertz Wars, and pretty much the first thing anyone asked about the AMULET was how fast it was, expecting a clock speed as the answer. Given that the answer to that question for the AMULET was 'Errm...', they'd then just abandon it as a processor candidate as being conceptually too difficult to think about. I wonder if the design could be reworked into Verilog or VHDL and used as an FPGA soft core?
    - slededit 10y ago
      If that was really what did it in then it shows a real lack of creativity. Synthetic Mhz would have been the way to go - just like how the EPA still gives an MPG rating to electric cars.
- phkahler 10y ago
  I'm starting to feel like a broken record but... A perfect opportunity with risc-v.
  - mynameislegion1 10y ago
    Folks are already working on a clockless RISC-V CPU: https://www.youtube.com/watch?v=b3rbWdhnP54 https://www.youtube.com/watch?v=b3rbWdhnP54
  - thowaway60 10y ago
    Folks are already working on a clockless RISC-V CPU: https://www.youtube.com/watch?v=b3rbWdhnP54 https://www.youtube.com/watch?v=b3rbWdhnP54
  - personofpelican 10y ago
    Folks are already working on a clockless RISC-V CPU: https://www.youtube.com/watch?v=b3rbWdhnP54 https://www.youtube.com/watch?v=b3rbWdhnP54
  - pjc50 10y ago
    Why do you say that? I can't see anything about RISC-V (or any ISA!) that makes a difference to those four points.
    - phkahler 10y ago
      It's a very simple instruction set. Whatever the challenges are with asyc design and verification, the task will be simplified with a smaller/simpler processor design. The open source nature of it also means any company or researcher is free to do what they want with it. Design tool companies for example could create that alternative workflow for async and promote it by saying "look at the results we got on RISC-V" and make all the comparisons they want. They could also release the design if they wanted. It's hard to see any of that happening with something like ARM or x86.
      - pjc50 10y ago
audiofish 10y ago
I've done some work with Octasic's Opus DSP system [http://www.octasic.com/technology/opus-dsp-architecture http://www.octasic.com/technology/opus-dsp-architecture] The cores themselves are asynchronous, with all of the benefits of lower power. The memories sitting outside of the cores are clocked, however. I remember being a little bit disturbed by the temperature dependence of the chip on wall-clock execution time but it didn't affect our applications. It was interesting to find this stuff as a product-ready platform.

pjc50 10y ago

I used to work at a startup ( https://www.linkedin.com/company/azuro https://www.linkedin.com/company/azuro ) that was commercialising the founders' work on asynchronous design. They eventually sold to Cadence. Asynchronous design is a huge sell; we scaled it back to just applying some async techniques to the clock tree of synchronous designs for moderate performance/power improvements. There are three problems we found: - the existing toolchain is synchronous-orientated, so you'd have to replace all of it and retrain your staff. - the chip developers and their managers tend to be older and more conservative than the software world. They're also potentially large teams (Intel are obviously huge). So the retraining is going to be difficult and expensive. - it's risky. New toolchain and newly trained staff? There's going to be bugs in the tools and errors in the design. Worse, there will be new types of bug that people aren't good at diagnosing. These will take weeks to resolve and a couple of wafer sets. That's a very expensive proposition! If async is to get a foothold it would be, like ARM, starting at the low end. Low power consumption is an obvious pitch for microcontrollers, and the simpler designs will be less risky.

bensummers 10y ago
ARM tried it in the 90s with the AMULET. https://en.wikipedia.org/wiki/AMULET_microprocessor https://en.wikipedia.org/wiki/AMULET_microprocessor
- david-given 10y ago
  I knew someone who was (tangentially) involved with that; apparently one of the biggest problems was that it came out during the height of the Megahertz Wars, and pretty much the first thing anyone asked about the AMULET was how fast it was, expecting a clock speed as the answer. Given that the answer to that question for the AMULET was 'Errm...', they'd then just abandon it as a processor candidate as being conceptually too difficult to think about. I wonder if the design could be reworked into Verilog or VHDL and used as an FPGA soft core?
  - slededit 10y ago
    If that was really what did it in then it shows a real lack of creativity. Synthetic Mhz would have been the way to go - just like how the EPA still gives an MPG rating to electric cars.
phkahler 10y ago
I'm starting to feel like a broken record but... A perfect opportunity with risc-v.
- mynameislegion1 10y ago
  Folks are already working on a clockless RISC-V CPU: https://www.youtube.com/watch?v=b3rbWdhnP54 https://www.youtube.com/watch?v=b3rbWdhnP54
- thowaway60 10y ago
  Folks are already working on a clockless RISC-V CPU: https://www.youtube.com/watch?v=b3rbWdhnP54 https://www.youtube.com/watch?v=b3rbWdhnP54
- personofpelican 10y ago
  Folks are already working on a clockless RISC-V CPU: https://www.youtube.com/watch?v=b3rbWdhnP54 https://www.youtube.com/watch?v=b3rbWdhnP54
- pjc50 10y ago
  Why do you say that? I can't see anything about RISC-V (or any ISA!) that makes a difference to those four points.
  - phkahler 10y ago
    It's a very simple instruction set. Whatever the challenges are with asyc design and verification, the task will be simplified with a smaller/simpler processor design. The open source nature of it also means any company or researcher is free to do what they want with it. Design tool companies for example could create that alternative workflow for async and promote it by saying "look at the results we got on RISC-V" and make all the comparisons they want. They could also release the design if they wanted. It's hard to see any of that happening with something like ARM or x86.
    - pjc50 10y ago

audiofish 10y ago

I've done some work with Octasic's Opus DSP system [http://www.octasic.com/technology/opus-dsp-architecture http://www.octasic.com/technology/opus-dsp-architecture] The cores themselves are asynchronous, with all of the benefits of lower power. The memories sitting outside of the cores are clocked, however. I remember being a little bit disturbed by the temperature dependence of the chip on wall-clock execution time but it didn't affect our applications. It was interesting to find this stuff as a product-ready platform.