This was a project that Jim Spoth and I made for our digital systems design course. The end product is a configurable Conway’s Game of Life implementation on an Altera DE2 FPGA board using a 64 x 32 bicolor LED matrix for the display. A PS/2 keyboard is used to create/modify/clear the current state of the board, as well as to pause and resume the simulation.
Jim was the primary architect of this project, as he had much more exposure to digital design than myself (he had done digital design work on his co-ops, whereas I only had basic academic experience). He was responsible for the high level design, system integration, PS/2 driver, and BIST (built-in self test) mechanism. I was responsible for the implementing the display driver and game of life logic. We used built-in RAM blocks for the display memory.
Truth be told, I don’t remember too many details about the project as a whole, but I do remember some miscellaneous details about the display driving and the game of life logic. The display that we used in this project was a Sure Electronics 6432 bicolor LED matrix. Although the display has all of the LED driver circuitry built in and provides a simple interface, it does not contain on-board memory for holding display data for the entire board. Instead, the display data for each row must be shifted in bit-by-bit (64 columns per row means 64 bits). This row data is stored in 74HC595 shift registers. Once the entire row has been clocked in, the shift register data is latched to the 74HC595 outputs, causing the row to be displayed on the matrix. This process is repeated in quick succession row-by-row (a process often known as scanning) to create the perception of a single image. This means that the display requires active driving to maintain a full image. In a microcontroller application, this would take significant computational resources. However, on an FPGA, this process can be performed in parallel with any other processing that must be done.
Although an FPGA implementation could conceivably update every cell in parallel, we did not require this level of performance, and opted for a sequential implementation. Thus, each cell is computed on a different clock edge. This still allowed us to update the cell state much faster than the maximum allowable refresh rate on the display, and obviously orders of magnitude faster than would ever be required for human viewing.
Below is a very quick video clip of running the simulation with a glider gun. Although it’s not clear from the video, the board is set up by using the arrow keys on the keyboard to move around a cursor. The cursor appears as a green cell. The space bar toggles the state of the currently highlighted cell (where living cells are red, dead cells are off, and the intersection between the cursor and a living cell is orange). The simulation can then be started and paused using the enter key. The board can continue to be edited both during simulation and when paused.