The mouse cursor is outputted from the NIOS to the VGA controller. These inputs control which column, row, and value to input (first three respectively), and the "override_clk" allows the NIOS to pulse the control module, notifying that data is ready.Ī mouse would give input to the system via the NIOS. After the controller has stopped running, the NIOS can input data via "override_x", "override_y", "override_data", and "override_clk". This allows the controller to complete the current frame and stop gracefully. It first has to stop the controller by pulling the "run" input low, then wait for the "running" output to go low. The NIOS II would interact with the data though the controller. If external input was to be added, it would be though a NIOS II processor. All of these states are shown in videos at the end of this document. These are chosen using SW: Fully Random (initializes the screen with random bits), Half Random (initializes half the screen with random bits), Middle Random (initializes the center of the screen with random bits), and Pre-set (a small pre-set pattern in the center of the screen). Even with this aspect removed, there remains interactivity by choosing one of four initial states. However, Due to limited time and lack of up-to-date documentation, the Interactive aspect was removed from the project, but much of the interface has already been implemented. The most intuitive control is using a mouse and cursor, and I insisted on implementing any interactivity using a mouse and cursor. Overall, Figure 1 is a great demonstration of the speed and logic behind the parallelization. The animation does not account for memory pipelining. Instead, the previous row is contained in a buffer of registers.Ģ. Memory is not read from calculated cells (as this will screw up the automata). The above Animation is not completely accurate due to two missing details:ġ. The goal of synchronizing the updates to the VGA scan is to remove any flickering and distortion.įigure 1: An animation to explain the basics of the parallelization scheme. I wouldn't be surprised if this system could handle much higher frequencies (200+Hz). As you can see, all columns finish updating the row with plenty of time to spare. Here is an animation of how the grid is updated in parallel. There is a lot of time where the columns are not dong any calculation, so the system itself is capable of much faster speeds, if we were to decouple the calculation from the VGA scanning. The number of frames to skip is chosen using SW. 60Hz (0 frames skipped), 30Hz (1 frame skipped per frame calculated), 20Hz (2 frames skipped), 15Hz (3 frames skipped), and so on. The control Module allows the rate of calculation to be controlled. This keeps the calculation and VGA in sync. The control module triggers all of the columns to calculate a row in parallel the moment the VGA module finishes rendering a row. The control module is the only module the columns directly interact with. I also have a larger control module that controls and synchronizes these columns. I picked 8 because it uses the M4K blocks efficiently (one per column), and the X grid location can be easily split into a column reference and location within the column (highest bits and lowest 3 bits, respectively).Įach column contains the logic to do calculations, and a state machine that will calculate a given row when triggered. I split the grid up into columns, 8 cells wide. They can also be made highly parallel using one block per parallel unit: Parallelization High Level Design Memoryĭue to the speed requirements, I choose to use M4K blocks, as they are dual ported (both the VGA and my Hardware can read/write) and fast. The game of life is much more interesting if it is interactive. More on this in the next section.Īlso, user interactivity was a major consideration, but ultimately didn't get implemented due to technical difficulties. My design uses massive parallelization to achieve the required speeds, and is more than capable of faster. Given that each cell requires 9 values to calculate it's next value, even with extreme pipelining serial updating would not be possible (without over-clocking). However, this poses the first and largest design hurdle: Updating that resolution at that rate requires over 18 million updates per second! This leaves just a few clock cycles per cell for updating. This would be full VGA, and updated as fast as the monitor can display the grid. The main goal of this project was to implement Conway's game of life on a grid of 640x480 cells, running at 60Hz. This project implements Conway's game of life on an Altera Cyclone II FPGA using a DE2 development board, at full VGA resolution. Conway's game of life is a 2D cellular automaton.
0 Comments
Leave a Reply. |