The performance comparisons to other players is a brilliant feature, though.
Once I found myself trying to implement a mutex in it... I've just spent all day at work doing stuff like this, and then I come home from work and keep doing it there as well.
Great game, but it's like catnip for programmers.
Why Do We Play Video Games That Feel Like Work? - https://news.ycombinator.com/item?id=9495141
The only real challenge that I see would be the I/O. That's quite a few pins for most FPGA parts I've worked with. Maybe things have gotten easier in 15 years? The architecture design of the chip doesn't seem all that complicated, but clock cycles would not match the game.
For programming, add an instruction PROGRAM <val>. This writes <val> to program slot BAK and adds one to BAK. Each node starts with its program memory full of PROGRAM ANY and starts with BAK=0. To program a node, simply send the program to it, one word at a time. When the program counter wraps round, your program runs.
To initialise the network, have a serial EPROM connected to a fake I/O node. After startup, the contents of the ROM gets sent, one word at a time, on the I/O node's port. This programs the node it's attached to, which starts running; this then forwards messages on to the next node, which gets initialised and starts running, etc. That way you'd fill the network with message-forwarding programs. Once done, each node starting at the most remote would be overwritten with your real program, and once the root node gets overwritten initialisation is complete.
Admittedly, a TIS-100 built like this "simulation" would be hard to program without some way of addressing each node.
Hmm... writing a TAS-100 simulator would be trivial. Maybe I could --- NO! I've got too many stupid projects on the go as it is!
It's a puzzle game, though, and probably aims less at being a practical teaching tool than a set of novel and obscure problems. If it teaches anything it'd be approaching odd problems in general, just like spacechem did.