Digital Computers I: Organization and Logical Design

Lab 4: Adventure Game Synthesized

Due: Wednesday, April 8, 2015 in class

Introduction
In this lab may you will design a Finite State Machine (FSM) that implements the
adventure game from Lab 3, but this time in VDHL (not a schematic) and ultimately
synthesized on an FPGA. You should follow the instructions from Lab 2, which shows
you how to create a project that targets the Spartan-3E Starter Board and shows you how
to simulate using ISim.
As always, dont forget to read the entire lab and refer to the What to Turn In section at
the end of this lab before you begin. There is also a set of hints of common tool mistakes
on the last page of the lab.

Refer to the FSM you designed in Lab 3. If you were not successful creating the FSM in
lab 3, be sure to get help with a TA to make sure you are on the right track. Use the
design steps listed in Figure 2. Parts of these steps will be given, while others will be
entirely up to you.
This lab is divided into four parts: design, VHDL entry, simulation, and implementation.
If you follow the steps of FSM design carefully and ask questions at the beginning if a
part is confusing, you will save yourself a great deal of time. As always, dont forget to
refer to the What to Turn In section at the end of this lab before you begin.

Page 1 of 6

1. Design
The adventure game that you will be designing is from Lab 3. Please see that assignment
to remind yourself of the rooms and objects. Your state transition diagrams (or at least the
sketch of them in the Lab 3 handout) will be an important resource here.
Youve already designed one state machine in which you wrote out a set of next state and
output equations. This time, you will design it in VHDL and let the synthesis tool choose
the gate-level implementation.
Once again, you must implement your game using two separate state machines (in two
separate source files) that communicate with each other. One state machine keeps track
of which room you are in, while the other keeps track of whether you currently have the
cloak. The interfaces for these modules are given to you in the top.vhd file that ultimately
seams them together for you:
http://students.cec.wustl.edu/~bracy/cse260/lab4/top.vhd

2. VHDL Entry
Create a new project named lab4_xx, where xx are your initials. Choose HDL for the
to-level source type, and choose the settings shown in the picture below.

Page 2 of 6

Create a new source of type VHDL Module, by right clicking the project name in the
Design window, and selecting New Source. Call this module room_fsm. Provide
inputs clk, reset, N, S, E, W, V, and outputs room, cloak, dead, and win. The room output
is an 8-bit 1-hot encoding that can be directly connected to the 8-bit LED signals on the
FPGA board.
Complete the VHDL module with your own code to define your state machine. Look at
examples in the book or the Everything you ever wanted to know tutorial on Piazza.
You should have a process that responds to the reset signal and connects the next state to
the state signals. You should have another process that is in charge of the state transitions
that is triggered when inputs to the module from the user or the room fsm change. You
should have combinational logic at the bottom of the module (not in a process) that
assigns the output signals. This is the only place you should assign values to the output
signals in your module. Look over section 4.2 (see HDL Examples 4.2-4.7) in the book
for the various ways of assigning signals.
Repeat this process for a second module called cloak_fsm. This module will be much
simpler. It should have inputs clk, reset, and cloak, and a single output V.

3. Simulation
Now Simulate your FSM. Click on the Simulation button in the Design window. Then
right click State_Machine and create a VHDL test bench. Call it lab4__xx_test. You
may be asked to specific which module you are testing. Begin by testing the room_fsm.
Ignore the cloak_fsm entirely. A test bench skeleton will be generated for you, but you
will have to create the stimulus to test your state machine. Create two test cases for a
winning and a losing game, using the test benches you created for Lab 3 as a guide. At
first, if the cloak_fsm is not included in the test bench, you will lose on both test cases
because the V signal will not go high. This is okay. Convince yourself that your
room_fsm works, then add in the cloak_fsm into the test bench. Look through the test
bench and see how the room_fsm was invoked. Create code for cloak_fsm by following
the example created for you with the room_fsm. Now you should have a single test bench
that tests both FSMs. Your simulation should show a winning and a losing game.

4) Hardware Implementation
I cannot state this strongly enough: the easiest way for you to complete this assignment is
to get the simulation working before you even begin the hardware implementation.
Now you will map your design to the Spartan 3E FPGA as you did in Lab 2. First, you
will need 5 new files that will associate the inputs and outputs of the schematic you drew
to the switches, LED lights, and the LCD screen on the board. Go to the following URL
and download the files you find there:
http://students.cec.wustl.edu/~bracy/cse260/lab4
The files are:

CommonDefs.vhd:

defines operationMode & a bunch of other stuff you can

probably ignore

Lcd.vhd:

necessary for using the LCD. Ignore for now.

Page 3 of 6

Support.vhd:

adventure.ucf:

top.vhd

has the debouncer I mentioned in class and also the

UpdateLCD module which you will need to modify
maps the FPGA pins to the signals in the top module
youll need to look in here to figure out which buttons
should be mapped to the NSEW signals
the vhd code that holds it all together. Youll need to
modify this code to correct the button NSEW mappings.

Make sure you add all 5 files or you will have mysterious bugs that will cost you sleep
and tears.
If you have forgotten how to load your program on the FPGA, please refer to Lab 2.
After you have successfully loaded your FSM onto the FPGA, you can play the game,
although at first it will not be very easy to play (see Task #1). Resetting the FSM (by
toggling the far right switch) should allow you to play the game multiple times.
Tasks
Task #1: Fix the mapping of the NSEW signals which have been assigned incorrectly
in top.vdh. Look at the names given to the buttons in adventure.ucf. They are names like
M25. Now look at the buttons on the actual FPGA board to determine which should be
NSE and W (the names are written on the board itself). Then fix the mapping in top.vhd.
Until you fix this, you cant really test the game b/c you dont know which buttons move
you in which direction.
Task #2: Have the cloak? no text change mid-game when you find the cloak. To do
this, you will need to go into Support.vdh and look at the UpdateLCD module. See where
the cloak? no text is assigned to the LCD screen. (Each box on the LCD is part of an
array of about 60 characters total. Each character is the hex encoding of the ASCII
character. Google hex ascii encoding for a lookup table reference if you need it.) Figure
out how to get the game to say cloak? yes as soon as the cloak has been found. The
player should see no until she gets the cloak, and then she should see yes for the rest
of the game. You will probably need to change the interface to the UpdateLCD module
in order to accomplish this, which will require changes to UpdateLCD in the top module,
too. Be sure to check every instance of the word update and youll see all the places
that need changing.
Note: Once again there is a constant called operationMode. When you synthesize
your design, make sure operationMode is set to 1. Ideally, you should only simulate
using room_fsm.vhd, cloak_fsm.vhd, and your testbench. So you should not need to keep
changing the operation mode back and forth.
After you have finished entering your code, check your VHDL code for errors by
synthesizing your code. Synthesis will convert your VHDL code into gates and flipflops. Making sure your VHDL module is highlighted in the Design window, choose the
Synthesize XST option in the Processes window. Synthesis will find syntactical and
certain other errors.

Page 4 of 6

In the Design Summary (usually a tab in the biggest window of the project navigator)
Expand the Detailed Reports option and choose Synthesis Report. Reading this will
often warn you of troubles that otherwise could take a long time to track down. If
synthesis did not complete successfully, the report will explain why. If it did complete
successfully, you can see what a normal successful report looks like, which will be handy
when you have to debug more complicated digital systems in the future. In particular,
pay attention to whether the synthesis tool chose to change your state encodings; this will
help to understand the schematics. The report will be long because of all the LCD code.
Fix the errors in your VHDL and perform Synthesis again. Repeat until Synthesis
completes successfully and there is a green check mark next to the Synthesize option in
the Processes for Source window.
Try to find the part that refers to the synthesis of your units: cloak_fsm and room_fsm.
Look at the entries for those state machines. Do the results surprise you?
Think about the hardware that you expect your FSM to imply. You can view your
synthesized gates by selecting View RTL Schematic and View Technology Schematic
under the expanded Synthesize XST option (bottom left window where you invoked the
synthesis in the first place). Select Start with a schematic of the top-level block, and
click ok. Print the RTL schematic in a readable way to turn in with your lab write-up.
The RTL Schematic is the Register-Transfer-Level schematic and shows gates and
registers. Study the schematic carefully. Does it match what you expect? It should
have a state machine block with a clock, reset, inputs, and outputs, along with some
output logic. You can right click the room state machine and choose View FSM to see a
state transition diagram. Does the diagram match your intent? If the schematic
contains anything you didnt want, such as latches, think about your VHDL code and
figure out how it was incorrectly written to imply the unwanted hardware. Take a look at
the Technology Schematic and guess why we dont want you to print out that one.
We will discuss the details of how FPGAs work shortly. For now, take a look, and get a
general idea of how the synthesis tool changes your code into hardware. You will see a
number of flip-flops; check that the number makes sense.
You will notice that the synthesis tool might have implemented your design in hardware
differently than you did in the Lab 3. In your write-up include a few sentences on any
differences you noticed and why they might have happened.
Remember that even when your module synthesizes without errors, it does not
necessarily mean that it performs the functions you expect it to. You still need to
simulate your code to verify its functionality.

Page 5 of 6

What to Turn In
Please provide a hard copy of each of the following (in the correct order, and each part
clearly labeled).
1.

A printout of your room_fsm.vhd and cloak_fsm.vhd and top.vhd.

2.

Two annotated printouts of your simulation waveforms: one that shows you
playing the game and winning (entering Victory Vault), and another that shows
an example of losing the game (entering the Grievous Graveyard). Your
signals must be printed in the following order: CLK, R, N, S, E, W, V,
room7:0, cloak, dead, win. (The notes on the next page describe how to format a
test bench waveform output file if youve forgotten how to do so.) Please select
Landscape under Print Setup before printing these so that they fit better on the
page. Find 3-4 events to annotate on each simulation that identify it as a winning
or losing game. Make sure you zoom out such that the entire win or loss fits on a
single page.

3.

A 1-page printout of the RTL schematic.

4.

Write a few sentences about the Synthesis Report, the RTL schematic, and the
technology schematic and if and how they differ from your expected hardware.
The questions you should answer are in bold on the previous page. One meaty
paragraph should suffice.

5.

Briefly describe how you tested the system on the Spartan 3E board and whether
it worked according to the specifications. 2-3 sentences should suffice.

Youve now implemented your first design in VHDL and your first state machine in
hardware!

Demo your code

Print out a Lab 4 coversheet (on Piazza) and bring it with you to your demo.
In addition to turning in your code, you will be asked to demo your code to a TA. Attend
one of the TA lab hours
(http://www.cse.wustl.edu/~bracy/class/cse260/Lab_Hours.html). Show them your
working simulation, and they will complete an online form (they have the link)
indicating whether your demo was successful or not.
Your lab must be demoed before you turn it in.

Electronic Submission
In addition to turning in your code via hard copy, you will be asked to submit your main
vhdl files on blackboard: room_fsm, cloak_fsm, and top.vhd. Upload them to the same
Lab4Files assignment. These are the only three files that need to be submitted
electronically.

Page 6 of 6