Neat !<p>A good test for 'correctness' is to run the F-pentomino both in some known good program and your own.<p>It looks like this:<p><pre><code>    xx
   xx
    x
</code></pre>
I's a really interesting little pattern that will expand quite a bit before stabilizing, it also fires off a bunch of gliders.<p>edit: I've looked a bit more at your code, and it is <i>almost</i> correct for free-running instances of 'cell'.<p>The problem is with the generation counter, you only have 1 bit for the generation.<p>In a synchronous environment that would work, and because you propagate the 'update' signal from the first cell that is hit outward you will (probably) observe correct behaviour.<p>But that is not the same as having cells completely independent.<p>The connecting cells are all triggered from the first cell that gets hit. If multiple cells get triggered simultaneously (not possible in a single threaded program!) then as soon as there was a little bit of speed difference between any two cells things would go wrong.<p>I figure the absolute minimum number of bits in the generation counter is 2, because then you have one 'dead' state in between the 3 possibilities that are current.<p>A neighbour can be 'ahead', at the same generation or it can be 'behind' and what a cell does should be governed by the states of the neighbours.<p>In your program you can never get in to the 'behind' state, but in a free-running hardware solution that is a definite possibility.<p>I hope that's all clear :)<p>Think of it this way, effectively you've made your cells globally clocked again.<p>You also can't delete dead cells, two populations that were connected at some point in the past should stay connected or they will drift away from each other.<p>If a 'cell' is run by a completely independent thread which runs at some arbitrary speed the whole thing should still work.<p>Simulating asynchronous devices on synchronous devices is quite tricky!