Ah, one of my hobby horses. I'd love for this to take off but so far I have not seen anything that convinced me that it will. I have a proof-of-concept of 'life' in clockless form, which was quite a bit of a headache, and since life is theoretically Turing complete that generalizes to the possibility of making clockless computers at scale. The one nasty little detail is that the computer implemented on the life substrate would have a clock simulated in life...<p>Pretty hard to get around that limitation.
The whole digital ASIC synthesis flow revolves around timing closure i.e. satisfying setup and hold at max possible clock speed.<p>I guess we may even have to invent a new HDL to pursue asynchronous paradigm efficiently.
This article takes me back to my college days ca. 2009, my senior design project was asynchronous cryptography circuits... I read this article and a few research papers more than a few times before I gained an entry level understanding of asynchronous circuits. Unfortunately the entire concept was very difficult for even senior computer engineering students to wrap their heads around when they had just been studying clocked circuits in-depth. Understanding the mueller-c element [0] in particular caused me significant difficulties.<p>Understanding the concept from a high-level isn't too bad however. As the article covers, if you visualize each piece of information moving along the pipeline as a hand-off, like a chain of people passing balls to each other, with the rule that they can't pass a new ball until they've passed the previous ball, you have a rough idea of how asynchronous processing circuits work. What's funny is that a natural "clock" begins to take shape at that point, although it's determined by the slowest component in your pipeline, rather than by an oscillator. The ball diagrams from the Rx libraries are actually also good visualizations for asynchronous circuits [1].<p>Those were some rough months attempting to achieve our advisor's goals, clearly the trauma still hasn't left me.<p>[0] <a href="https://en.wikipedia.org/wiki/C-element" rel="nofollow">https://en.wikipedia.org/wiki/C-element</a><p>[1] Example Ball Diagram from the Rx libraries: <a href="http://reactivex.io/documentation/operators/map.html" rel="nofollow">http://reactivex.io/documentation/operators/map.html</a>
Wow. Somehow this feels like an even more extreme version of Carl Hewitt's actor model in which individual actors themselves involve asynchronous components.
Archive.org has their old website, fleet.cs.berkeley.edu, which includes various publication and slides from talks [1]<p>[1] <a href="https://web.archive.org/web/20090423133512/http://fleet.cs.berkeley.edu/" rel="nofollow">https://web.archive.org/web/20090423133512/http://fleet.cs.b...</a>
I got to chat with Ivan after he gave a talk about Fleet at the University of Washington a bunch of years ago.<p>He strikes me as down to earth and intellectually honest in ways that most people are not.<p>A similar architecture at the software level is to have thread per core and queues to move data between threads as in Seastar, Glommio, etc.<p><a href="https://github.com/scylladb/seastar/blob/master/doc/tutorial.md" rel="nofollow">https://github.com/scylladb/seastar/blob/master/doc/tutorial...</a><p><a href="https://www.datadoghq.com/blog/engineering/introducing-glommio/" rel="nofollow">https://www.datadoghq.com/blog/engineering/introducing-glomm...</a>
I believe Chuck Moore took a stab at this with "Green Arrays"<p><a href="http://www.greenarraychips.com/" rel="nofollow">http://www.greenarraychips.com/</a>
I made a completely async. HTTP app. server and then added a distibuted async. JSON database on top:<p><a href="https://github.com/tinspin/rupy" rel="nofollow">https://github.com/tinspin/rupy</a><p>The problem with async. is that once you add one thing as async., you need to change everything to be async. for it to work well!<p>That said time is the hardest thing that humans have to deal with, we simply are not built to understand it.