Would it be fair to say that the next challenge would be to develop a new kind of programming language architecture/concept that would take advantage of a t2-tile system? Otherwise, what is the strictest bottleneck?
We've got the ulam programming language custom tailored for the MFM, and the SPLAT spatial programming language built on top of ulam. I expect we'll want more languages or language features as we scale up, but we need to earn our way to them with design experience. I'd love to build a T3 tile, probably FPGA-based, using lessons learned, that could provide perhaps 10x or 100x the average event rate of the T2s. And get them out into researchers and hackers in quantity.
Maybe! One main challenge is the (at least) six-way local intertile communications. The T2s use BeagleBone Greens, which have two PRUs that I slice three ways each to do packet transfers. The RP2040 anyway has two 'PIO' instances that seem similar.
But I'm unsure that any redo at that scale would improve delivered performance that much.
If I had it to do over I think I'd've tried to put an ethernet router chip on each tile and basically do backplane ethernet between tiles.
But I dream of LVDS serdes between tiles with low-level packet stuff handled in FPGA fabric..