Cellular automata can span physical FPGA chains while preserving fast local reaction. Brian Greenforest’s 2021 estimate assigned 0.113 milliseconds of cell-to-cell travel across one hundred FPGAs and three meters of fabric, equivalent to roughly 95,000 kilometers per hour.
That scale makes mesh topology a compelling alternative to long span-N wires and fat-tree supercomputers.
Local Pipelines Turn Distance Into Throughput
At an 891-megahertz operating point, every device can advance local state while links carry prior results to the next cell. The fabric does not need a global answer before useful work continues.
A mesh keeps communication near the computation that uses it. It can trade a small propagation delay for regular placement, local timing, and a machine that grows through repetition.
Bring Real Workloads Back to the Mesh
The architectural question now shifts from whether signals can cross the array to which algorithms benefit from local propagation. Simulation, search, vision, physical control, and evolving spatial models all offer candidates.
FPGA researchers can map a demanding cellular workload, measure its reaction time, and help redesign reconfigurable devices around scalable local communication.
Execute Cellular Automata Across FPGA Chains Through Cartilage Runtime Instantiation
Cartilage Runtime-Instantiation Architecture carries this system into nested modules that enter and connect inside a live spatial machine.
LinkedIn status when archived: Visible to anyone on or off LinkedIn.
I made a simple estimate: it seems we're not doing cellular automata for a wrong reason. A fully pipelined FPGA chain, even at 16 nm node at 891 MHz has cell-to-cell latency over an array of 100 FPGAs (spanning over 3 meters) of just 0.113 milliseconds! Clocked pipelined signal travels at 95,000 kilometers per hour, which is more than enough for fast reaction time complex compute! So what a big deal supporting all these "span-N" wires and "fat tree" supercompute architectures?! Let's get back to mesh again?.. Please, let me know in the comments below \/ \/ \/ if I got it wrong. Seems that Intel 4 melting core with full pipeline has stopped the trend. Let's get it back on track, and redesign all our FPGAs, never worrying about timing closure ever again?
#networktopology #supercomputing #latency #fpgas
Comments added by Brian Greenforest on LinkedIn
These 3 comments were also preserved verbatim from Brian Greenforest’s LinkedIn data export or the public post page.
Comment 1 · (2021-06-04 04:52:21 UTC)
I agree, but I am not sure (simply never ran a successful Muller element stuff) that these are as fast and energy efficient for high-performance computing (not for energy-saving eventing/spiking).
I love the idea of async, and experimented with it a lot, but it always ends up demanding so many transistors and package pads!
Tanj, may I ask you for a specific "any to any" algorithm as a pilot for experiments with mesh architecture vs. fat tree? I feel it's heuristic and based on assumptions rather than on a proven math—simply due to the fact that mathematicians assume either existing ordinary fixed mesh circuits (not self-reconfigurable FPGAs), or von Neumann nodes...
I badly need to try that proof on innovative parallel architectures, but I HAVE NO IDEA WHAT TO RUN 😹
Any algorithm suggestions ARE VERY WELCOME! 😍👍🥳
Tanj Bennett I need a specific customer-problem related algorithm, not at the stage HOW we solve their problem (applying randomization is a way to solve the problem, there might be a better way).
I don't know ANYTHING about computational problems in the field. If you have good friends who use computations to solve real problems, please, share my anxiety with them—I'll listen them for hours!
Comments added by Brian Greenforest on LinkedIn
These 3 comments were also preserved verbatim from Brian Greenforest’s LinkedIn data export or the public post page.
Comment 1 · (2021-06-04 04:52:21 UTC)
View the LinkedIn post
Comment 2 · (2021-06-04 14:51:34 UTC)
View the LinkedIn post
Comment 3 · (2021-06-04 16:27:23 UTC)
View the LinkedIn post