Game of Life on FPGA | Lolézio Viora Marquet

The brief for Imperial’s second-year Electronics Design Project was an educational tool that visualises a mathematical function, with hardware acceleration that beats a CPU-only version. Our team of six (Benjamin De Vos, Anderson Lo, Ajay Samaranayake, Ching Bon Tang, Joshua To and me) chose Conway’s Game of Life on a PYNQ-Z1, which pairs an ARM processor with FPGA fabric. The system shows a 1280 by 720 grid over HDMI, one cell per pixel, and users draw the starting pattern in the air with hand gestures.

A large TV showing 'Imperial JABBAL presents GAME OF LIFE' in orange pixel lettering, with the red PYNQ-Z1 board on the table beneath it. — The finished system: the PYNQ-Z1 on the table, driving the display over HDMI.

Sizing the problem on a CPU

I wrote the Python implementations we used as a baseline. The first tracks only live cells, so its cost scales with the number of live cells rather than the size of the grid. I then parallelised it across 16 threads, first by splitting the grid into bands of rows and then into square blocks. At 1920 by 1200 the block split was more than twice as fast as the row split, because each thread’s neighbour lookups stay within a small region of memory.

The best software result was still far off our target. Our C++ version computed about 8 generations per second at 1280 by 720, so a 60 Hz display needed a speedup of at least eight times, which set the case for custom hardware.

Next-state logic

I wrote the core of the hardware: a module that applies the Game of Life rule to one cell from its eight neighbours, and a Verilog generate loop that instantiates 1280 of them side by side, so a whole row’s next state is computed at once. Around it, Ajay built the row counter and the line buffer that feeds each row with the rows above and below it, and Ching Bon built the logic that swaps the two block RAMs between “current” and “next” each generation, which avoids copying the grid. With one row per clock cycle, a full generation takes 722 cycles. At the fabric’s clock of roughly 150 MHz that is about 200,000 generations per second, although the display itself refreshes at 60 Hz.

Block diagram: initialise logic and two block RAMs feeding a multiplexer, a row counter and line buffer feeding the parallel next-state unit, which writes results back to memory, and a pixel generator driving HDMI. — The hardware pipeline: a row counter and line buffer feed the parallel next-state unit, which writes each new row into the other block RAM.

Loading the starting grid

I wrote the logic that loads a user’s pattern into memory. The processor passes data to the fabric through 32-bit registers, so each 1280-cell row is split into forty 32-bit words, written into forty registers, and concatenated in hardware into one 1280-bit word that fills a whole row of block RAM in a single cycle. The full grid loads in 720 cycles, after which a flag starts the evolution.

Diagram showing a 1280-element boolean row converted to 0s and 1s, then a 1280-character string, then split into forty 32-bit register values regfile[0] to regfile[39]. — How one row of the drawn grid is packed into forty 32-bit registers before being written to memory as a single 1280-bit word.

Hand-gesture interface

I built most of the gesture interface, which runs on a laptop. It tracks hand landmarks with MediaPipe through OpenCV: with the drawing gesture, each point the user traces sets a 3 by 3 block of cells, and a thumbs-up sends the finished grid to the board. An open hand pauses the simulation on the current generation, and closing it resumes. The grid is sent to the board row by row over a TCP socket, and I wrote the Jupyter notebook on the board that receives each row, writes it into the registers and steps the generations. In user testing the interface responded in about 30 ms on average.