For our CPE 133 final project, Chase and I decided to create a ‘Minesweeper’ game that utilized button and switch input from a Basys-3 board as well as VHDL code. A better name for the game could very well be ‘Russian Roulette’, however we wanted to go with a more family friendly name. The game involves the user to press the middle button on the Basys board to randomly assign one of the 16 switches to be ‘active’ with a bomb. Two players then take turns flipping up switches, one at a time, until one of the players flips the switch with the ‘bomb’. When that happens, the seven segment display alerts the players that that player has just lost the game.

Step 1: Overview

The project utilized many of the VHDL modules that we have utilized over the course of this quarter. A four bit counter was used in conjunction with the clock edge in order to simulate a random four bit number to activate one of the switches. A state diagram was also used in order to output different words to the seven segment display, ranging from ‘PLAY’ when the players are in the middle of their game, to ‘LOSE’ when one of the players has flipped the active switch.

Step 2: Materials

Basys3 Development Board from Digilent, Inc.
Vivado Design Suite BC_DEC.vhd (This file was provided to us on Polylearn and was written by Bryan Mealy)
A 4 bit counter made of T flip flops
A FSM

Step 3: Making the Game

The first step towards making this game was drawing a circuit diagram with all the components that we will be using. Inputs for this system were button 1, the 16 switches, and the Clock. Outputs were the seven segment display and the anodes. After drawing the circuit diagram, we wrote individual source files for each component in Vivado and put them together using port maps under the main source file.

The entire basis of the game revolves around randomly assigning one of the 16 switches to be active with a bomb, and for the players to not know which switch is active until that active switch is flipped on. We looked into random and pseudorandom number generators online, but we eventually decided that using a 4-bit counter and assigning the corresponding switch to be active is sufficiently random for what we were looking for. We were able to repurpose our 4-Bit counter that we created in a previous project to be able to work for this assignment. We used the counter to create a random number between 0-15; then in the main1 component, we assigned the decimal equivalent of the random number to its corresponding switch on the board. As seen in the schematic, both the output X (‘active bomb’) from main1 component and the switches the players turn on go to FSM1. The state machine outputs a one bit Z value which is then read by BC_DEC1. The Finite State Machine we used has two different states: in state A, the seven segment display outputs ‘PLAY’ and the machine stays in that state until it recognizes that the activated switch is flipped. Once that happens, the FSM goes to state B where it outputs ‘LOSE’ to the seven segment display and stays in that state until all 16 switches are flipped to ‘0’. When that condition is met, the FSM then once again goes to state A and awaits the players to start another game. A Moore diagram to help understand this FSM is shown above.

Step 4: Future Modifications

A few modifications we were considering about making to our game include adding more bombs to the field (possibly increasing from one to three), adding a score counter and multiple rounds. We ultimately decided against these improvements, as we found that playing a longer, extended game typically was more tense and in the end more fun than a game that typically ended after three or four switch flips.

Step 5: Conclusion

We were very happy with the final result of this project; not only because the final version of the game was fun to play, but also because creating and programing the project required us to utilize most, if not all that we learned this quarter. We utilized Flip Flops, counters, FSMs, the clock, user input from the board, and output to the seven segment display.

We also learned how a few syntax errors could completely break the program (even if they would be considered fine in other programming languages such as Python or Java) and that only after multiple simulations and multiple iterations of the code being uploaded to and tested on the board, will you finally be able to work all the bugs out of your code.