Image: Sam Byford / The Verge

Gameboy State Machine

Simulating Gameboy logic over an FPGA with Verilog

Created December 2020
Finite State Machine


This problem statement was introduced as the final project for Computer Engineering 270: Digital Design. The project highlights creating a state machine diagram and designing the FPGA logic with Verilog.


The general problem statement specifications are outlined below. The full project pdf can be found here.

Your player will have 3 different modes:
  1. Idle: In this mode your player is able to run using A or B or move to Fight mode or React mode by clicking their respective buttons.
  2. Fight: In this mode your player is able to kick using A or punch using B or move back into Idle mode by clicking the Fight button again.
  3. React: In this mode your player is able to jump using A or duck using B or move back into Idle mode by clicking the React button again.
Additional criteria:
  • The output is your players action, so there are five possibilities: Kick (0), Punch (1), Jump (2), Duck (3), Run (4). The corresponding numbers should be what your output is set to for each of the actions. In your diagram you may use the action names.
  • Your Game Boy has four different inputs: Fight (0), React (1), A (2), B (3). The corresponding numbers are the actual values of your input. In your diagram you may use the input names.
  • Depending on the input and state, you will either move to a new mode, or stay in your current mode and perform an action.
  • Whenever you are in Idle mode or move to Idle mode, your action should always be Run.
  • When transitioning from Idle mode to another mode, we don't care what your action is.
  • When Reset equals 1 your player should be in Idle mode.
  • Note: Your player cannot go from Fight mode to React mode and vice versa.


This logic design can be described as a mealy machine; a type of finite state machine. The states can be expressed as the three modes outlined above with their respective relationships.


The general approach contains two always blocks: one for state transition and another for the corresponding output.

Here the module is initialized with IO and the state register. Parameters were put in place to correlate state names to their respective values, in order to make the code more logical.

The state transition block must come before the output block. This always block triggers at the positive edge of the clock, but is also sensitive to the negative edge of the reset signal. The reset state is the first conditional because it has more priority. Following this is a switch statement with each mode (state) and a default of idle. Within each switch case is the given relationship between input and transition.

The output block is also triggered by the positive edge of the clock and will execute right after the state block. The logic is rather simple as layed out in the diagram, and can also be implemented as a switch. Under each mode (state) the input is checked with various conditions and the output z is assigned to the corresponding output.


This testbench module was written by the course's TAs. Here the module is initialized, the design is instantiated, and the same parameters are specified as in the design file.

The clock is established by inverting the signal every 10 nanoseconds.

This always block correlates each state with what is being displayed in the terminal.

This initial block runs once and simulates a Gameboy game-sequence.


Overall this was a fun final project. Finite state machines are commonly seen in simple real-world applications, making this project very useful. Being a design course, Computer Engineering 270 put a lot of emphasis on problem statement and delivering to the client as implied in this project.

You can find the interactive playground for this project here.

Here is the final Gameboy sequence: