Project 4/5

Battleship Game with

Communication System
EE 371 AC
March 10, 2016
NAME
Denny Ly
Minhhue H. Khuu
Ruchira Kulkarni

SIGNATURE

STUDENT ID

Table of Contents:
1.

ABSTRACT ............................................................................................................................................... 3

2.

INTRODUCTION ...................................................................................................................................... 3

3.

DISCUSSION OF THE PROJECT ............................................................................................................ 3

3.1 DESIGN SPECIFICATION .......................................................................................................................... 4
3.1.1
Communication System ................................................................................................................ 4
3.1.2
Battleship Game [1] ..................................................................................................................... 4
3.1.3
VGA Driver [2] [3] [4] [5] [6] .................................................................................................... 5
3.2 DESIGN PROCEDURE ............................................................................................................................... 6
3.2.1
Tools ............................................................................................................................................. 6
3.2.2
Communication System ................................................................................................................ 6
3.2.3
Battleship Game ........................................................................................................................... 7
3.2.4
VGA Driver .................................................................................................................................. 7
3.3 SYSTEM DESCRIPTION ............................................................................................................................ 8
3.3.1
Communication System ................................................................................................................ 8
3.3.2
Battleship Game ........................................................................................................................... 9
3.4 SOFTWARE IMPLEMENTATION ................................................................................................................ 9
3.4.1
Communication System ................................................................................................................ 9
3.4.2
Battleship Game ......................................................................................................................... 10
3.4.3
VGA Driver ................................................................................................................................ 13
3.5 HARDWARE IMPLEMENTATION ............................................................................................................. 14
3.5.1
Communication System .............................................................................................................. 14
3.5.2
Battleship Game ......................................................................................................................... 16
3.5.3
VGA Driver ................................................................................................................................ 18

4.

TESTING ................................................................................................................................................. 18
4.1 TEST PLAN............................................................................................................................................ 18
4.1.1
Eclipse ........................................................................................................................................ 18
4.1.2
Quartus II University Waveform Tool ........................................................................................ 19
4.1.3
Quartus II and Signal Tap .......................................................................................................... 19
4.2 TEST SPECIFICATION ............................................................................................................................ 19
4.2.1
Communication System .............................................................................................................. 19
4.2.2
Battleship Game ......................................................................................................................... 20
4.2.3
VGA Driver ................................................................................................................................ 20
4.3 TEST CASE ............................................................................................................................................ 20
4.3.1
Communication System .............................................................................................................. 20
4.3.2
Battleship Game ......................................................................................................................... 20
4.3.3
VGA Driver ................................................................................................................................ 21

5.

PRESENTATION, DISCUSSION, AND ANALYSIS OF THE RESULTS ........................................... 21

5.1 QUARTUS II UNIVERSITY WAVEFORM TOOL (COMMUNICATION SYSTEM) .......................................... 21
5.2 SIGNAL TAP AND CONSOLE OUTPUT (COMMUNICATION SYSTEM) ....................................................... 22
5.3 BATTLESHIP GAMEPLAY ANALYSIS ..................................................................................................... 23
5.4 FAILURE MODE ANALYSIS ................................................................................................................... 24
5.4.1
Communication System .............................................................................................................. 24
5.4.2
Battleship Game ......................................................................................................................... 25
5.5 ANALYSIS OF ANY ERRORS ................................................................................................................... 25
5.5.1
Communication System .............................................................................................................. 25
5.5.2
Battleship Game ......................................................................................................................... 26
5.6 ANALYSIS OF POSSIBLE ERRORS ........................................................................................................... 26
5.6.1
Communication System .............................................................................................................. 26
5.6.2
Battleship Game ......................................................................................................................... 26

6.

SUMMARY AND CONCLUSION ......................................................................................................... 26

7.

AUTHORS AND CONTRIBUTIONS..................................................................................................... 28

8.

APPENDIX .............................................................................................................................................. 29

9.

REFERENCES ......................................................................................................................................... 32

1. Abstract
The goal of our final labs (lab 4 and 5, which built on each other) was to understand how to
integrate the NIOS II microprocessor with our gate array to develop a game of Battleship between
two FPGA boards using the concept of serial communication. Our lab group solely did lab 4,
whereas lab 5 was a collaborative effort between our group and another group (Raymond, Eeshan
and Will). To achieve this, we followed the guidelines provided to us in the lab specifications and
incorporated the use of mealy state machines for reading and sending user signals through the
console on the eclipse IDE. By building on our FPGA functionality using the microprocessor, we
were able to add support for general purpose I/O to enable information exchange between the
processor and functionality both within and external to the FPGA. Our game utilized core
components of memory storage by using an SRAM to keep track of attacks made by both players
and their corresponding results. Our lab resulted in a successful implementation of our Battle Ship
game using not only a user-console but also on an interactive VGA monitor display

2. Introduction
In this project we specify and aim to design a serial network communication system between
two FPGA boards and to use these concepts to create a multi-player game of battleship. To develop
the communications capability for our game, we used Qsys tools and concepts. In Lab 4, we
extended a microprocessor on our FPGA to incorporate basic communications capability for the
bathysphere and ocean bottom habitat system which we designed in lab 3. We further built on
those asynchronous serial network concepts to apply them to a multiplayer game of Battleship in
Lab 5. We extended on our knowledge of serial communication in lab 5 by making use of hardware
interrupts and hardware interrupt handlers to receive signals from other players with a built in
library in Qsys called system.h in our implementation for the game. We also went further as to
display the game on not only a console output but also a VGA controlled monitor to make it user
friendly. Our game not only pertains to the regular set of rules specified by the game of battleship,
but extends to two other commands, namely the radar and the heal command. Radar allows a
player to get a 3 x 3 peek into the other players board display and heal allows a player to replenish
the recently sunken ship back. Both these plays require the player to use up one whole turn and
can get no attacks for that specific turn. As one of the goals of this lab was to build upon designs,
implementations, and fundamental I/O interface to the microprocessor from the previous labs, we
used the NIOS II microprocessor to aid us in sending various control signals through the user
console in the Eclipse IDE, which we used for the NIOS II microprocessor development. We used
the Qsys system and created instances for our NIOS in our top-level modules in Quartus. We also
built a modified version of the SRAM (containing 200 spots instead of 128 spots in previous lab)
to store our versions of boards in the game of battleship and associated software driver. To
implement this game, we needed to make use of another groups board. We partnered up with
another EE 371 group and designed our group (Raymond, Eeshan and Will) together.

3. Discussion of the Project

The overall project is designed with the intention of creating a system that allows two
DE1_SoC boards to communicate with one another and play a game of battle ship against each
other. The project is broken into two segments: (1) The Communication System, (2) The Battleship
Game, and (3) The VGA Driver. The creation of the Battleship Game was a collaborative work

with another group. Those additional members include Eeshan Londhe, Raymond Mui, and
William Thing.

3.1 Design Specification

3.1.1 Communication System
The Communication System implemented in this project is an asynchronous UART
communication system that will send and receive 8-bits of information serially.
Asynchronous communication means and is used where there are irregular intervals between
the sending of data. In this project, well develop one such scheme.
Suppose that a serial communication line is set up to transmit ASCII characters as typed by a
person at a keyboard. The spacing between the transmission of each character will vary widely,
and there may be long periods when no characters are typed. In such situations, the receiving
device needs to know when a character is being sent so that it can receive the character then sort
out which part is data, which part is the error-checking field, and so on.
In our design, this is accomplished by a procedure known as framing. To signify the start of a
character, an initial state transition from the specified quiescent state occurs on the transmission
line before the first bit of the data character. After all of the bits of the character are received, the
state of the transmission line returns to the original quiescent state. These two specific states that
frame the character are designated the start bit and the stop bit. The start bit enables the receiving
device to temporarily synchronize with the transmitting device, while the stop bit allows the
receiving device time to get ready for the next frame.
In contrast, when blocks (usually large ones) of regularly spaced data are transferred over a
serial line, the transmitter and receiver can be synchronized, transferring characters at a much
higher rate. In this format, known as synchronous transmission, start and stop bits are no longer
needed, since the receiving device knows exactly where each character begins and ends.
3.1.2 Battleship Game [1]
The Battleship game is an extension of the communication system and purely adds a game
functionality using the communication system to allow a separate DE1_SoC to send character data
to perform game commands. The game assumes that the user will correctly place their ships and
contains no user input validation. This feature can be added in the future.
This implementation of the Battleship uses a 10x10 board that is labeled A-J for columns and
A-J for rows. The reasoning for this is it allows the board to be easily expanded to a larger size by
continuing on the alphabetical scale. The coordinates are viewed by first examining the columns
then the rows.
The game initially prompts the user to place three ships of length 5x1, 4x1, and 3x1. The ship
can be placed horizontally and vertically. The player to place their ships first will be the player
that will start their commands on the opponent.

The commands a player can conduct on their turn is attack given a coordinate, sensor scan a
3x3 grid given the coordinate of the top left position, and heal a part of a ship (once per game).
For each player, they will contain information of their misses and hits and their opponents
misses and hits on the SRAM. This means that each player has a unique copy of the game in their
SRAM that is a mirror imaged of their opponents.
The commands will be interpreted by mapping key inputs as ASCII characters sent through
the UART transmitter and receiver modules. The commands will be handled using interrupts to
create the interrupt signals and interrupt handlers to handle the interrupt signals.
In summary, the game contains the following features:
Prompts user to place three ships by giving the starting location and the direction
North, South, West, or East.
o 5x1 size ship.
o 4x1 size ship.
o 3x1 size ship.
Player who places ships first is the first player and gets to act first.
On a players turn, they player can do the following:
o Attack, given a coordinate.
o Scan the opponents grid in a 3x3 scan, given the upper left corner of the 3x3
grid scan.
o Heal a part of a ship (once per game).
Game information is stored locally on the SRAM of the players board.
Game commands are sent through the UART Transmission and Receiver modules.
Game commands are taken into effect using interrupt handlers.
Winner player is announced when the opponent loses all three ships.
Reset on key press.
No input validation, this can be added later.
3.1.3 VGA Driver [2] [3] [4] [5] [6]
The VGA driver was developed under heavy influence from Professor Scott Haucks tutorial,
Professor Bruce Lands Lecture from Cornell University, and additional research on websites from
the public domain that contained general information about VGA signals that include wiki pages
for general information, the information was only used for reference.
The VGA driver interface implemented only supports 640x480 resolution, so user specified
resolutions are emulated by creating large user pixels from several pixels in the native resolution.
The driver achieves this by selecting an integer that specifies both the width and height in native
resolution pixels of each user pixel. This integer is chosen such that the user pixels are as large as
possible without any of the display being cropped out. The region which the user draws in is
centered on the display and any margins to the top and bottom or left and right are colored black.
This scheme is optimal in that it provides the largest display with uniform pixels sizes and no
stretching or nonsquare pixels

3.2 Design Procedure

3.2.1 Tools
The lab uses Quartus II Qsys to generate the NIOS II processor and wire the processor to the
Cyclone V FPGA board as the platform for modeling. Also, Quartus II Signal Tap Logic Analyzer
was used to analyze the output waveforms from the various structures that were built in the lab.
The RTL Viewer will be used to examine the hardware gate level implementation of the high level
code that was written. Finally, to generate the Verilog and C code, Notepad++, and Eclipse was
used as the text editor. Eclipse was also used to compile the written C code into the proper machine
code for that NIOS II processor. The tools used in this lab is shown in Table 1.
Table 1. Table of Tools Used for this Lab
Tool
Quartus II Qsys
Quartus II Signal Tap
Quartus II University Waveform Tool
Quartus II RTL Viewer
Cyclone V FPGA (Model 5CSEMA5F31C6)
Eclipse
Notepad++

Purpose
Used to wire the NIOS II Processor to the
Cyclone V FPGA
Output waveform of hardware result
Analyze waveform of Verilog files.
Synthesizes a structural model of Verilog file
Platform to implement project design
Text editor and compiler for C code
Text editor

3.2.2 Communication System

The Communication System is broken up into two modules: (1) Transmit and (2) Receiver
modules. The purpose of the Transmit module is to take in parallel data and shift it out serially,
starting with a start bit, then preceding with the 8 bits of data, and ending with the end bit. The
purpose of the Receiver module is to receive serial data and output the serial data as an 8-bit
parallel data. The Receiver module will wait for the start bit the module will trigger and takes in 8
bits of the serial data and output is as parallel data.
Table 2. Inputs for the UART Transmit and Receiver Module
Input Signal
Serial In
Data In
Transmit
Load
Clock
Reset

Width
1 Bit
8 Bit
1 Bit
1 Bit
1 Bit
1 Bit

Description
Receiving serial signal (RX).
Transmitting parallel data (TX).
Signal the UART Communication System to send loaded data.
Signal to load the Data In data until transmission.
The clock signal. Ran at roughly 96000 Hz for 9600 bit/s transfer.
Active low reset.

Table 3. Output for the UART Transmit and Receiver Module

Input Signal Width Description
Serial Out
1 Bit
Transmitting serial signal (TX).

After creating the Transmitter and Receiver modules, a NIOS Processor was connected to the
input and output ports of the UART Transmit and Receiver Module. For the rest of the project, the
NIOS processor will be used to manipulate the control signals to send and receive characters.
3.2.3 Battleship Game
Interrupt handlers were designed using resources online (cited below). We designed an
interrupt handler only for the receiving signal, as we had to continuously listen to the signals sent
by the opponent for each player. Refer to section on software implementation for further detail.
The game commands we chose were to be the most user-friendly option for the user. We
continuously print the state of the game on the eclipse console so the user is aware of the state of
the game. Whenever some attack of move has to be made by the user, the user is notified on the
console by the program. - The coordinates for the board is done using A through J columns and
rows. - Attack is made by entering a, heal is made by entering H, radar is made by r. - p
prints out the current state of the board for the user.
The design process for the game rulings involved looking up resources online (especially the
Wikipedia page) to get the popularly defined set of rules for Battleship. In a nutshell, we
implemented the game functionality for placing ships on a given coordinate/proper orientation on
the game board, attacking an opponents ships and marking whether the result of an attack was a
hit or a miss. We also kept track of the score for each player. As soon as all of the ships for one of
the players ship sank, the game is over, and the other player wins. We also added two additional
rules to our game, the heal and the radar option. The heal option lets a user replenish a recently
sunk ship by the opponent without notifying the opponent and the radar options gives a 3 x 3 vision
of the opponents board starting from a given top-left coordinate. Both these moves waste an
attacking opportunity and are only to be used once.
Table 4. Console Input to Battleship Game Command.
Input Character
AA - JJ
a
s
h

Description
Coordinate.
Attack.
Scan.
Heal.

3.2.4 VGA Driver

The VGA Driver consists of a horizontal and vertical element. The horizontal and vertical
elements are controlled by a counter and the counter is determined based on the resolution and the
frequency in which the signal is sent. In this implementation, the resolution is set to be 640x480
at 25 MHz. The timing information can be found online in our references.
The purpose of the driver is to continuous drive a progressive scan through each pixel and
updating its color value by looking at what the set RGB values are at the current x and current y
pixel location that is being updated. Each pixel is updated at the rate of 25 MHz. The value of the
current x and current y value being scanned is outputted by the driver and the color value to be

changed for that current pixel is updated by inputting values in the VGA_R, VGA_G, and VGA_B
values to dictate the color at that current pixel location. If the RGB color value is not changed by
the time the driver moves on to the next pixel, the next pixel will also contain the same color as
the previous pixel until the RGB values change. When the driver reaches the end of the screen, the
driver will force the VGA color values to recalibrate back to 0 on all of the color spectrums to
conduct the Horizontal and Vertical sync. This repeats endlessly, and prevents a screen from being
driven from a singular instance. The screen can only display an output by constantly being driven
at the appropriate times.

3.3 System Description

3.3.1 Communication System
Figure 1 shows the overall top level of the communication system. The top level has two
counters for the receiver and the transmitter. There is also two shift registers and buffers on each
side. The NIOS II Microprocessor is the main part of the system. That piece hardware controls
most of the system depending on the character input from the console.

Figure 1. Block Diagram for Communication System

3.3.2 Battleship Game

Figure 2 shows the top level of the battleship game. Most of the components are the same as
the previous diagram, but it includes the SRAM and the battleship VGA hardware. The battleship
video output is the largest block because it has the most code in Verilog.

Figure 2. Block Diagram for Battle Ship Game

3.4 Software Implementation

The battleship game system was implemented using software through the use of NIOS II
Microprocessor (using C code in the Eclipse IDE) and Verilog. The code for this lab can be found
in the included zip file submitted on canvas. Table 5 shows the folder names that contain the
implemented code after extraction.
Table 5. Folder names that contains the code written for this lab
Folder name of Code
/communication_system/
/battle_ship/
/vga/
/sram/

Purpose
Folder contains code for the Communication System.
Folder contains code for the Battleship Game.
Folder contains code for the VGA Driver and output.
Folder contains code for the SRAM.

3.4.1 Communication System

In lab 4, the communication for the system was done using simple hardware components and
polling concepts (while loops till we received a control signal). We implemented functions of the
9

<altera_avalon_pio.regs.h> library which allowed us to send the data from and receive data to the
microprocessor whenever a simple character or string was inputted by a user on the console. When
the user typed a character in the Eclipse IDE console, the NIOS II microprocessor sent a signal to
our FPGA board. The board received the signal and in turn displayed the Ascii value in binary
form on the LED display.
After we got this basic set up working, we decided to then implement a hardware in our C
code an interrupt to make the system more flexible and able to receive at any moment. To
implement our interrupts for the receive end, we used functions part of the system.h library. We
had to implement a receive handler and the initial set-up for the receive interrupts (shown below).
This made it easier for us to handle any incoming attacking signals in our game of battleship from
the opponent board while playing. It also allowed us to implement features that were based on how
fast a certain player responded as compared to the other player in the game.
3.4.2

Battleship Game
These last two labs focused on C programming more than the previous labs. We wrote
our first C code, battleship.c, containing the main logic for our Battleship game starting from a
template called small hello world in Eclipse. The C code for the game was then built and run
onto the DE1_SoC board.

An SRAM containing 200 locations in memory was also implemented to determine the
board layouts of both the players in the game. Each location had the capacity of holding 8 bits (a
character value). The first 100 spots in memory in the SRAM are used for the current players
board layout whereas the next 100 spots in memory are used for the opponents board layout in
the current players perspective.
There are multiple stages where we read from and write to the SRAM. In the beginning
of the game, we choose to initialize our board (each players board) with the b to indicate
blank or that no ship placement/ movement has been made yet. The process to write to the
SRAM for setting up the board includes iterating through all the 200 memory locations and
overwriting the contents of that address with the given value.
After the blank board is set up in the SRAM, we allow the user based ship/
aircraft/submarine placement (basically different warfare vehicles of lengths 5, 4 and 3
respectively) input from the console to determine the layout of the SRAM so we can replicate their
placements on the board. For instance, if we are placing an Aircraft of length 4 on the board
starting from coordinate AA in the west direction, we will make the corresponding index in our
SRAM, through a specific formula, and use the fast access property with the use of indexes to
write to that index in our SRAM, the character 4. The same is done for all other ship types with
varying lengths.
When an opponent sends a particular coordinate over that they wish to attack, the address of
the location of the SRAM index corresponding to the requested coordinate is first read from and
then written to. If the character in that index has an existing ship (represented by 3, 4 or 5),
then it is considered a hit and the value at that address is overwritten with h. If the value at that
index is b (representing no ship), the value at that address is overwritten with m, indicating a

10

miss on the opponent. These hit or miss values are also recorded in the opponents (attackers)
version of the other players board on their SRAM. This way, both players can easily identify if
they had already made a particular move before and if they were successful or not at that time.
Furthermore, our program does not allow a particular player to choose the same coordinate to
attack more than twice and will print out an error message indicating so.
The control signals for the battleship are implemented through the C code. The control
signals involve (1) ready signal - indicating which player is ready first, which determines which
player makes the first attack in the game (2) win signal - when all the ships for a player have
sunk, that player loses and the other player wins (3) heal signal - whether or not a player has
requested a heal to replenish the ship that was just attacked. (4) radar signal - whether the player
has requested the radar view option (5) current player - indicates which player is currently
attacking and which one is receiving (player == 1 means attacking and player == 2 means
defending).
Interrupts where used to continuously receive signals from each players opponent. Each
time data was received, our interrupt handler would determine a series of things. These included
determining who the first player to attack is, whether a player had sunk as ship, whether a player
had hit a ship or whether a player had miss an attack, whether a player had used an action such as
heal or radar that will cost them a turn and keeping track of the scores.
void init_receive_irq() {
/* volatile variable to avoid optimization */
void* edge_capture_ptr = (void*) &edge_capture;
/* Enable first button interrupts. */
IOWR_ALTERA_AVALON_PIO_IRQ_MASK(RECEIVED_BASE, 0x1);
/* Reset the edge capture register. */
IOWR_ALTERA_AVALON_PIO_EDGE_CAP(RECEIVED_BASE, 0x0);
/* Sets the interrupt handler */
alt_ic_isr_register(RECEIVED_IRQ_INTERRUPT_CONTROLLER_ID, RECEIVED_IRQ,
receive_handler, edge_capture_ptr, 0x0);
}

Figure 3. C Code, Initialize the Interrupt function.

void receive_handler(void* context) {
char other_player_signal = IORD_ALTERA_AVALON_PIO_DATA(data_in);
if (player == 0 && other_player_signal == 'R') {
if (signal) {
player = 1;
} else {
player = 2;
}
} else if (wait_radar) {
r_block[index_radar] = other_player_signal;
index_radar++;
} else if (wait_heal) {
type_heal = other_player_signal;
} else if (other_player_signal == 'n' || other_player_signal == 'o' ||
other_player_signal == 'p') {
offense = other_player_signal;
} else if (other_player_signal == 'h' || other_player_signal == 'm') {
hit = other_player_signal;
} else if (other_player_signal == 'u' || other_player_signal == 'v' ||
other_player_signal == 'w' || other_player_signal == 'z') {

11

sink = other_player_signal;
} else {
s_index = (int) other_player_signal;
}
volatile int* edge_capture_ptr = (volatile int*) context; // volatile variable
to avoid optimization...
*edge_capture_ptr = IORD_ALTERA_AVALON_PIO_EDGE_CAP(RECEIVED_BASE);
// Store
edge capture register in *context.
IOWR_ALTERA_AVALON_PIO_EDGE_CAP(RECEIVED_BASE, 0x0);
// Reset edge capture
register
}

Figure 4. C Code, Interrupt Handler.

void init_sram() {
int i;
*addr = 0x0;
*w_data = 'b';
*w_enable = 0x1;
*addr = 0x0 + DEFAULT_SIZE;
for (i = 1; i < DEFAULT_SIZE; i++){
*addr = i;
*addr = i + DEFAULT_SIZE;
}
*w_enable = 0x0;
}

Figure 5. C Code, Initialize SRAM.

int convert_coord(char* coord) {
int ones = *(coord + 1) - 'A';
int tens = (*coord - 'A') * 10;
return (tens + ones);
}

Figure 6. C Code, Convert Coordinate.

void update_SRAM(int index1, char direction, char type) {
int i, length;
*addr = index1;
*w_data = type;
*w_enable = 0x1;
length = (int) (type - '0');
if (direction == 'N') {
for (i = 1; i < length; i++) {
*addr -= 10;
}
} else if (direction == 'S') {
for (i = 1; i < length; i++) {
*addr += 10;
}
} else if (direction == 'W') {
for (i = 1; i < length; i++) {
(*addr)--;

12

}
} else if (direction == 'E') {
for (i = 1; i < length; i++) {
(*addr)++;
}
}
*w_enable = 0x0;
}

Figure 7. C Code, Update SRAM.

void send_signal(char send_value){
/* reinitialize the string index count and transmission/load signals */
IOWR_ALTERA_AVALON_PIO_DATA(transmit, 0);
IOWR_ALTERA_AVALON_PIO_DATA(load, 0);
/* load char for transmission */
IOWR_ALTERA_AVALON_PIO_DATA(data_out, send_value);
int receiving = 0;
/* wait until a character has been received */
while (!receiving) {
IOWR_ALTERA_AVALON_PIO_DATA(load, 1);
IOWR_ALTERA_AVALON_PIO_DATA(transmit, 1);
receiving = IORD_ALTERA_AVALON_PIO_DATA(sent);
}
/* done transmission, turn off signals */
IOWR_ALTERA_AVALON_PIO_DATA(transmit, 0);
IOWR_ALTERA_AVALON_PIO_DATA(load, 0);
}

Figure 8. C Code, Send Signal.

3.4.3 VGA Driver
In order to draw any shape, a task was used to draw a square at any given x and y coordinate
within the 640x480 resolution and a width and height parameter to determine how large the square
to be. The (0, 0) x and y coordinate is located at the upper left screen, and increasing the x values
goes towards the right of the screen and increasing the y values goes towards the bottom of the
screen. Likewise, the width is directed towards the right and the height is directed towards the
bottom of the screen.
The draw_squre task uses the wires declared at the top level of the module named current_x
and current_y which are the current grid location the driver is updating. The output value is a
Boolean value which determines whether or not to update the VGA values based if the driver is
current scanning over the desired region indicated by the input parameters. The code is shown in
Figure 9.
task draw_square;
output drawSquare;
input [9:0] x;
input [9:0] y;

13

input [9:0] w;
input [9:0] h;
if((x < current_x )
&&
(y < current_y)
&&
(x + w > current_x) &&
(y + h > current_y)) begin
drawSquare = 1'b1;
end
else begin
drawSquare = 1'b0;
end
endtask

Figure 9. Verilog Task for Drawing a Square.

3.5 Hardware Implementation

3.5.1 Communication System
The main part of the lab was to be a able to communicate through a serial connection from
one DE1-SoC board to another board. The main parts in this lab were the hardware subsystem and
to build a software application to utilize the hardware.

3.5.1.1 Serial-Parallel-Serial Network Interface

The network utilizes a couple of counters, parallel-serial buffer and shift register, serialparallel buffer and shift register, and a NIOS II processor.
3.5.1.2 Counters
The clock used in the counters are around 16x the data rate of 9600 bits per second, but the
clock used in the microprocessor is the standard 50 MHz. The counter ultimately controls the shift
registers on both of the send and receive sides. The transmitters counter is enabled by the transmit
signal from the microprocessor and the receiver's counter is enabled by the start bit coming in
through the data in line. The counter on the transmitter side has 10 clock cycles to go send out the
ten total bits for every transmission. The counter on the receiver side has 8 clock cycles that saves
the 8 data bits in the middle. Once the transmitter and the receiver completes sending or receiving,
the counters will also output a send or receive bit into the microprocessor.
3.5.1.3 Bits in Transition
The bits will consist of one start bit, 7 data bits representing the character, 1 even-parity bit,
and the end bit. The start bit is just a low bit value that tells the receiver that the system is ready
some data bits. Since the normal ASCII values consists of values between 0 to 127, the next 7 bits
will represent that character value. The transmitter sends out the binary value starting with the
lowest significant bit. The next bit will be the even parity bit. If there is an even number of high
binary data bits in the character, the even parity will be true. The other system will check this to
determine if the data is corrupted or not. The last bit in the transmission is the end bit that is just
high and will stay high until the next start bit.

14

3.5.1.4 Parallel-Serial Buffer and Shift Register

The shift register is driven by the counter and sees ten clock cycles every time there is data
that needs to be sent. When the shift register is not sending out bits, it is filled with all ones in the
registers and is outputting one continuously to the serial line. Once the shift register sees a load
signal, the hardware will load the values set in the microprocessor into the registers and wait for
the transmit signal to start shifting the bits out one by one until the clock stops driving the shift
register.
3.5.1.5 Serial-Parallel Buffer and Shift Register
This shift register is also driven by its on counter, but only sees 8 total clock cycles per data
bus. The initial start bit will begin the counter so that the shift register will begin shifting when the
least significant bit starts coming in. The shift register will store the values in the registers and the
registers will simultaneously output into the microprocessor. The registers will continuously
output those values until the next data bus comes in and shifts into those spots.
3.5.1.6 NIOS II Microprocessor
The microprocessor is similar to the ones built in the previous labs. The microprocessor
consists of multiple PIO ports. First, there are the SRAM data inputs and outputs to control data
storage. There is also a transmit, load, and 8-bit parallel data bus outputting from the
microprocessor to control sending characters to the other user. A character sent and receive is
going into the microprocessor to help our software applications know when to look at the data bus
to coming in or to send the next character out. There is an output that is wired up directly to the
LEDs to display the current character received from the serial in side of the network.

Figure 10. RTL Viewer of the Communication System

15

3.5.2

Battleship Game

Figure 11. RTL Viewer of the Battleship Game with VGA Output

16

The Battleship Game with VGA output has a lot of wires because the output display driver is
hardwired to the SRAM and accesses the SRAM to render the images.

Figure 12. RTL Viewer of the Battleship Game with VGA Output, Zoomed In
The pin assignment for the Battleship game can be found in the Appendix in Section 8.

17

3.5.3

VGA Driver

Figure 13. RTL Viewer of the VGA Driver

4. Testing
The testing of the design was broken up into three segments, all of which contributed to the
testing process: (1) Test Plan, (2) Test Specifications, and (3) Test Cases. The test cases are
developed based on the specifications of the test for the general test plan for each testing tool. The
results of the test are shown in Section 3.

4.1 Test Plan

In this lab, the followings tools were used to test the interlock system and the differential and
limit error signals.
Eclipse
Quartus II and Signal Tap
4.1.1 Eclipse
The process of testing the C programs in eclipse consists of the following steps:
1) Load the NIOS II processor into the DE1_SoC board.
18

2) Properly wire any hardware switch, wire, or Verilog modules to the NIOS II processor.
3) Create a project under a workspace using the tutorial.
4) Write the code.
5) Generate the BSP file.
6) Compile the code using the NIOS II Processor on the DE1_SoC board as the platform.
7) Fix any compiler errors.
8) Run
9) Fix any output or input errors.
10) Repeat
4.1.2 Quartus II University Waveform Tool
The process of testing in University Waveform Tool consists of the following steps:
1)
2)
3)
4)
5)
6)
7)
8)

Set the Verilog code as the top level module.

Run Analysis and Synthesize.
Create a University Waveform Tool (.vwf file)
Add all output ports.
Add all input ports.
Set waveforms for input ports.
Run analysis of waveform.
Examine the output waveform and see if the waveform matches with the expected
results.
9) Use result to re-evaluate Verilog code until perfection.
10) Repeat
4.1.3 Quartus II and Signal Tap
The process of testing in signal tap consists of the following steps:
1) Design a top level module in Verilog under the Quartus II IDE.
2) Assign the output described in System Description on the DE1-SoC board to display
the output for a given present state.
3) Assign the input to the inputs described in System Description on the DE1-SoC board.
4) Synthesize and open up Signal Tap and set input, output, and clock ports for testing.
5) Set the trigger conditions for test condition.
6) Set clock and sample depth to CLOCK_50 and 32K samples, respectively.
7) Load the .sof file into the DE1-SoC board.
8) Run the Signal Tap and utilize the input signal to activate the trigger condition.
9) Analyze the waveform to see if the waveform has any similarities or irregularities from
predicted results from the test specifications.

4.2 Test Specification

4.2.1 Communication System
To test the Communication System, before loading the software into the DE1_SoC board,
extensive tests on the Quartus II University Waveform Tool will be used to examine each
individual module to see if the modules are behaving as expected. After testing each module

19

individually, tests will be conducted on the transmitter and the receiver modules which are built
directly from the smaller modules. Finally, after the transmitter and the receiver modules are tested,
both modules will be combined together to create one single communication module.
After doing the ideal test cases, the system will now be loaded onto a DE1_SoC board as the
platform and signal tap will be used to examine the results of the Communication System.
Additionally, the Communication System will be tested by checking the console output on the
Eclipse console.
4.2.2 Battleship Game
To test the Battleship game, we will test if the game behaves as described in Section 3. If the
game follows the behaviors as mentioned, then the Battleship behaves as expected. To examine
the game even further, we will examine the SRAM to see the state of the game. Additionally, we
will test to see if the interrupt handlers are operating correctly.
The Battleship game will be tested in the Eclipse by analyzing the console outputs.
4.2.3 VGA Driver
To test the VGA driver, we want to see if the monitor displays color at the correctly specified
locations. The tests for the VGA driver is done concurrently with the Battleship Game.

4.3 Test Case

4.3.1 Communication System
The test cases include:
Sends Correct Characters.
Receives Correct Characters.
Signals Stops at the correct time.
Signals Begin at the correct time.
Able to send strings.
Able to receive strings.
4.3.2 Battleship Game
The test cases include:
Initialize game
Reset
Send signals using interrupt handlers
Receive signals using interrupt handlers
Do appropriate actions when sending
Do appropriate actions when receiving
Check SRAM for game status
Check for both players

20

4.3.3 VGA Driver

The test cases include:
Displays what is on SRAM
Correct colors
Updates on actions

5. Presentation, Discussion, and Analysis of the Results

In this section, we will discuss the testing and results shown in the two systems created within
these two labs (1) The Communication System and (2) the Battleship game.
The network hardware and the software application were used successfully to communicate
to other DE1-SoC boards. First, simulations will be looked at of the systems. The signal-tap and
the console will be looked at next and compared with the simulations.
A battleship game was implemented onto the DE1 board the utilized the serial communication
system built in the previous lab. Communicating between two boards allowed users to play a twoplayer game without being too close together. The game used the console to take in input from the
user, the SRAM to store the current map of the players, and the VGA cable to output the map onto
a monitor. An interrupt was also implemented to make the system more flexible and able to receive
at any moment. Once the receive signal is seen in the microprocessor, the interrupt will occur and
record the value that the opponent is sending. This value will then be used to compute the players
turn.

5.1 Quartus II University Waveform Tool (Communication System)

There are two main subsystems to the network. The first part subsystem is the transmitter. The
transmitter consists of a counter and the parallel-serial buffer and shift register. Figure 14 shows
the entire sequence that the transmitter goes through every time there is a transmit signal from the
microprocessor. There is a total of ten clock cycles before the entire bus is sent. The counter
outputs a character is sent signal when the last data bit is sent so another character can be sent.

Figure 14. Quartus II University Waveform Tool, Transmitter Control Waveform

The other subsystem in the hardware system is the receiver. The receiver consists of a counter
and a serial-parallel buffer and shift register. Figure 15 shows when the character received is

21

outputted from the subsystem into the microprocessor. There is a total of 8 clock cycles because
there is a total of 8 data bits coming from the system. Once all eight bits have come in to the
receiver, the counter will output the character received signal so the program can know that the 8bit data bus going into the microprocessor is ready to be read.

Figure 15. Quartus II University Waveform Tool, Receiver Control Waveform

Figure 16 shows how the two subsystems will work together if the receiver is getting a serial
in from the transmitter. The transmitter will begin to shift out bits starting with the initial low bit.
Once all the bits are out of the shift registers, the sent signal will be transmitted to the
microprocessor. The receiver will begin to receive a bit after the start bit is sent on the transmitter
side. After seeing that bit, the counter for the receiver will begin and shift in values from serial in
until all of the 8 bits are received. After the eight bits are in, the character received will be sent to
the microprocessor.

Figure 16. Quartus II University Waveform Tool, Transmitter and Receiver

Waveform

5.2 Signal Tap and Console Output (Communication System)

Figure 17 shows the output on the DE1-SoC board. The serial in is changing every time the
counter for the transmitter hits a positive edge and eventually shifts out all of the values into the
serial line. The transmitters clock will then output a sent signal to the microprocessor. The receiver
sees the bits one by one until all 8 bits are received and then stops shifting in values. Once the
shifting is done, the received signal will be sent to the microprocessor to indicate that the sequence
is complete.

22

Figure 17. Signal Tap, Transmission and Receiving Character

The Signal-Tap displays only one-character transmission through serial communication. The
console, however, can display multiple characters being sent through serial communication and
can show that long strings can be sent through to the other board. As you can see in Figure (Console
output), the entire string could be sent and received through serial communication.
In the lab, the board could communicate with itself and to other boards. When the board is
communicating with itself, the data is sent via the transmit signal and then the system will wait for
the receive signal before the next character is sent. The sequence continues until all of the
characters in the queue is sent. If the board is communicating to another board, the DE1 board will
need to choose to either send or receive by initially choosing a mode to start out in. In Lab 5,
interrupts were implemented in the system so the board could receive and send at the same time.
The DE1-SoC board was able to communicate with others and the results were showed in
Signal-Tap and the console. This shows that our design of the serial communication network
interface was successful.

5.3 Battleship Gameplay Analysis

At the end of the lab, the battleship game executed as expected. The original gameplay with
ships being sank, players taking turns, game starting over, and extra features all followed the
original design.
The game begins and the players would set their game boards by entering the starting
coordinate value they want and the direction they want the boat to extend in on the board. The
player that finished first is the first player to attack first in the game and the other player will be
the defender in the first turn. After all the ships were placed on the board, the SRAM printed out
all of the correct placements of the ships and the first person that finished placing the ships started
out first.

23

When the player is in attack, the user is asked to choose between three different actions they
can do. The three options include using a radar, healing one of your ships, and attacking normally.
The radar lets the user choose a coordinate (top-left) and the attacker will see a 3x3 block of the
opponents board starting from the given coordinate. The 3x3 block is printed on the console and
then the players turn ends. Another option is to heal one of the ships that are currently broken.
The heal can only be used on any ship that has been previously hit, but have not sunk yet. This
gives the user time to think about their next move and might cause the other player to figure their
future plans. Once the player heals, the board will display that the coordinate has not been hit yet.
The last action that the user can do during their attack phase is to just shoot at the opponents map.
If the user hits, then the opponents ship will either be damaged or sunk depending on the condition
of the rest of the ship. The console will be updated with a hit or miss on the attackers copy of the
opponents map and it will then be the next players turn. Using the radar and heal can only be
used once a game. Once the player has used this skill, the player will not be prompted about this
option for the rest of the game.
When the player is in defense, the player must wait for the other player to choose one of the
offensive actions and act accordingly to it. If the attacker shot a missile normally, the defensive
players board will be updated with either a hit or miss. If the attacker uses a radar, the defensive
player will look at the given value and send over the 3x3 block starting at the given coordinate. If
the attacker uses heal, the defender will update that spot from a hit to a blank on their board.
Once a ship dies, both of the players will be told which ship fell and that ship will be fallen
forever. Once all of the ships have been sunk, the players will be told if they won or not and then
prompted to start another game by placing their ships on the board again.
Along with having the boards of both players display on the console, the game boards are also
shown on computer monitors using the VGA cable. The hardware uses the data inside the SRAM
as control logic to determine what to display on the monitor. Initially, the screen shows two empty
boards (grids with blue squares). As the players place their ships on the game board, squares will
begin to light up. The color of the square will be determined by the length of the boat. Length 5
boats are green, length 4 boats are cyan, and length 3 boats are purple. If something is hit in the
middle of the game, the square will turn red. If a player misses, the square will be yellow. Once
the game ends, the board will turn back to its initial state.
The serial communication used between the two boards worked seeming less together and the
interrupts helped program the game a lot easier. We can just set values inside of the interrupt
handler and use them when it is needed. The turned based game didnt use the full capabilities of
interrupts, but it still made the game run more smoothly.

5.4 Failure Mode Analysis

5.4.1 Communication System
The inputs to the system is the clock, reset, serial data in and the character from the console.
If the clock was stuck on high or low, the system would not work entirely because there will not
be any positive edges on the signal to drive the system. If reset is stuck on high, the system will be
stuck in its initial state. If the reset is stuck on low, the system will work normally, but will have

24

no way of resetting itself if there any bugs that occur. If serial data in is stuck on high, the system
will never receive anything because it will never see a start bit. If the serial data in is stuck on low,
the system will continuously receive characters, but all of the characters will have the ASCII value
zero. If the character is stuck on any character, the system will not run normally and might be
frozen since the characters determine the control path for the system.
The outputs from the system is the LEDs and the serial data out. If any of the LEDs are stuck
on high, the LED will always be on. If the LEDs are stuck on low, the LED will not shine. Both
of these cases will confuse the user and misrepresent the ASCII value that came in on the receiving
side of the network. If serial data out is stuck on high, the transmitter will never send out a character
because no start bit occurs. If serial data out is stuck on low, the transmitter will always output a
null terminator to the board receiving the serial data.
5.4.2 Battleship Game
The inputs to the system is the clock, reset, serial data in and the character from the console.
If the clock was stuck on high or low, the system would not work entirely because there will not
be any positive edges on the signal to drive the system. If reset is stuck on high, the system will be
stuck in its initial state. If the reset is stuck on low, the system will work normally, but will have
no way of resetting itself if there any bugs that occur. If serial data in is stuck on high, the system
will never receive anything because it will never see a start bit. If the serial data in is stuck on low,
the system will continuously receive characters, but all of the characters will have the ASCII value
zero. If the character is stuck on any character, the system will not run normally and might be
frozen since the characters determine the control path for the system.
The outputs from the system is the serial data out and the VGA output. If serial data out is
stuck on high, the transmitter will never send out a character because no start bit occurs. If serial
data out is stuck on low, the transmitter will always output a null terminator to the board receiving
the serial data. If the VGA output gets stuck at high, the screen will continuously output white. If
the VGA output gets stuck at low, the screen will continuously output black.

5.5 Analysis of any errors

5.5.1 Communication System
An error that occurred is thinking both of the shift register clocks would be the same. Both of
the subsystems did something different so they deserve their own clock. Sending out ten bits is
important in the transmitter, but only eight bits were really needed on the receiving side. Once the
counters were built specifically for each system, the entire system became more synched together
and fixed another possible future problem.
The last and largest error we encountered was because of the compiler settings. There were
problems when the Quartus project was moved from one computer to the other even if no changes
were made to the code. The code would work and then completely not work if the code was
compiled in a different setting. Signal-Tap and simulations all outputted the correct results, but
would fail once the code was compiled elsewhere. The solution was to switch the compiler to an
aggressive approach where it didnt modify or optimize our original design. Learning to check the
compiler settings every time became an important part of successfully finishing the project.

25

5.5.2 Battleship Game

One initial problem we encountered was interrupt handlers. When accessing the interrupt
handlers, the code would get stuck in there and continuously loop forever. The problem occurred
because the edge capture register was not cleared after going into the interrupt. This made the
handler think that another interrupt was happening and would continuously access the handler.
Another error was indexing the arrays in Verilog. The way C indexes the array and Verilog
indexes the array is different. This was a problem when data was trying to be extracted from the
SRAM. We were indexing the wrong places and sometimes skipping some of the memory spaces.
The compiler didnt play nicely in this lab as well. The serial communication was working
seamlessly, but everything stopped working once the code was compiled on a different computer.
This time, the compiler settings didnt solve the problem. The solution was to revert back to a
backup file and move back to the original computer that the project was initially started on.

5.6 Analysis of possible errors

5.6.1 Communication System
A possible error is mixing up the transmit and receive GPIO pins when trying to communicate
between another group. This could stop a group for a while because it is a very subtle mistake. A
solution to this is to choose pins farther apart from each other so there is less of a chance that a
mix up could occur. Another possible error is the difference in clock speeds between two different
systems. If the clock speeds are too far off from each other, then the receive side will always see
garbage values and not the actual characters being sent over. One final possible error is having a
delay after every character when trying to send a string. The receiving side cant receive data too
fast or it will miss some receive signals and get stuck in the code.
5.6.2 Battleship Game
One possible error is not assigning the base addresses in the C program correctly based on the
values in Qsys. This is a major problem because the user will not be changing the PIO values when
it is needed. This is hard to see as well because there are no warnings from the compiler that tells
the user if the addresses are not aligned correctly. Another possible error is pulling the incorrect
values from the SRAM to control what prints to the VGA. This will cause the screen to display
the incorrect colors and sometimes not display anything at all. This is hard to debug because
Signal-Tap only has a limited number of nodes the user can look at to debug.

6. Summary and Conclusion

Overall, the lab covered many things that have previously been covered and new things that
are just being introduced. The most important thing we learned was how to incorporate
asynchronous serial communication in NIOS II microprocessor onto our DE1_SoC FPGA board
to communication with other FPGA boards. We did this by starting at a base design, which we
implemented for Lab 4. We first got different components (shift registers, counters, parallel to
serial registers, etc) of our hardware design ready by following the diagrams that were given to us
in the Lab 4 specification. Then, we introduced the microprocessor component for serial
communication using transmit and receive signals and while loops for polling. Once we got
comfortable with that, we moved on to more complicated concepts such as Interrupts and did
26

research on how and when to use them to receive signals. We also added extra features in our game
such as the VGA display component in which we ended up furthering our knowledge into the
specifics of the VGA display, including, but not limited to, the frequency at which the screen
refreshes itself, the layering technique to output various colored pixels on the monitor, etc. We
also learned the importance of design process when creating a specification all by ourselves as we
were solely responsible for the implementation design for the game of Battleship. It was a trial and
error process to make the maximum use of our SRAM to store the board for the game correctly.
We kept making revisions of the initial implementation plans we had for our game to make it
compatible for both boards. Additionally, we also learned important collaboration techniques. As
the three of us have been working together for the last ten weeks, we had gotten used to working
with each other. Once another group was thrown in the mix, both groups had to reach a medium
where we could all split up the work fairly. As a result, we successfully implemented our game of
Battleship with extra features functionality using the microprocessor and the FPGA through the
tasks mentioned in the paragraph above. We were also able to add support for general purpose I/O
to enable information exchange between the processor and functionality both within and external
to the FPGA.
The biggest takeaway of this lab was learning how to how to incorporate a NIOS II
microprocessor onto our DE1_SoC FPGA board and develop a success asynchronous network
communication system that could be use to make a multi-player game of Battleship. Another
takeaway was to learn how to reiterate and improve the design and usability of an existing model
based on new requirements. In the process of working with the microprocessor, we got introduced
to a variety of new tools such as eclipse and Qsys, such as the interrupt handler and the console
interface of the eclipse IDE and incorporating this whole system onto a monitor using a VGA
display system. Learning new tools will be essential in the industry since not all places will have
familiar tools or some places will have a superior tool. In conclusion, we used the new tools we
were introduced to to make a successful applications using the NIOS II microprocessor. In this
process, we also learned how to make a working model for not only our board, but also design
meaningful software for our microprocessor that is compatible with other group FPGA system and
hardware designs.

27

7. Authors and Contributions

NAME

CONTRIBUTIONS

Denny Ly

Communication System, C Program, Battle Ship

Game, Battle Ship Extra Features, Interrupt Handler,
Testing, Lab Report

Minhhue H. Khuu

Communication System, C Program, VGA Driver,

VGA Output, Testing, Lab Report

Ruchira Kulkarni

Communication System, C Program, Battle Ship

Game, Lab Report

Raymond Mui

Helped with Battle Ship Game and Interrupt Handler

Eeshan Londhe

Helped with Communication System, C game

William Thing

Absolutely Nothing

28

8. Appendix
I/OPORT
HEX4[1]
HEX4[2]
HEX4[3]
HEX4[4]
HEX4[5]
HEX4[6]
HEX5[0]
HEX5[1]
HEX5[2]
HEX5[3]
HEX5[4]
HEX5[5]
HEX5[6]
IRDA_RXD
IRDA_TXD
KEY[0]
KEY[1]
KEY[2]
KEY[3]
LEDR[0]
LEDR[1]
LEDR[2]
LEDR[3]
LEDR[4]
LEDR[5]
LEDR[6]
LEDR[7]
LEDR[8]
LEDR[9]
PS2_CLK
PS2_DAT
PS2_CLK2
PS2_DAT2
SW[0]
SW[1]
SW[2]
SW[3]

ASSIGNEDPIN
PIN_Y23
PIN_Y24
PIN_W22
PIN_W24
PIN_V23
PIN_W25
PIN_V25
PIN_AA28
PIN_Y27
PIN_AB27
PIN_AB26
PIN_AA26
PIN_AA25
PIN_AA30
PIN_AB30
PIN_AA14
PIN_AA15
PIN_W15
PIN_Y16
PIN_V16
PIN_W16
PIN_V17
PIN_V18
PIN_W17
PIN_W19
PIN_Y19
PIN_W20
PIN_W21
PIN_Y21
PIN_AD7
PIN_AE7
PIN_AD9
PIN_AE9
PIN_AB12
PIN_AC12
PIN_AF9
PIN_AF10

29

SW[4]
SW[5]
SW[6]
SW[7]
SW[8]
SW[9]
TD_CLK27
TD_DATA[0]
TD_DATA[1]
TD_DATA[2]
TD_DATA[3]
TD_DATA[4]
TD_DATA[5]
TD_DATA[6]
TD_DATA[7]
TD_HS
TD_RESET_N
TD_VS
USB_B2_CLK
USB_B2_DATA[0]
USB_B2_DATA[1]
USB_B2_DATA[2]
USB_B2_DATA[3]
USB_B2_DATA[4]
USB_B2_DATA[5]
USB_B2_DATA[6]
USB_B2_DATA[7]
USB_EMPTY
USB_FULL
USB_OE_N
USB_RD_N
USB_RESET_N
USB_SCL
USB_SDA
USB_WR_N
VGA_B[0]
VGA_B[1]
VGA_B[2]
VGA_B[3]
VGA_B[4]
VGA_B[5]

PIN_AD11
PIN_AD12
PIN_AE11
PIN_AC9
PIN_AD10
PIN_AE12
PIN_H15
PIN_D2
PIN_B1
PIN_E2
PIN_B2
PIN_D1
PIN_E1
PIN_C2
PIN_B3
PIN_A5
PIN_F6
PIN_A3
PIN_AF4
PIN_AH4
PIN_AH3
PIN_AJ2
PIN_AJ1
PIN_AH2
PIN_AG3
PIN_AG2
PIN_AG1
PIN_AF5
PIN_AG5
PIN_AF6
PIN_AG6
PIN_AG7
PIN_AG8
PIN_AF8
PIN_AH5
PIN_B13
PIN_G13
PIN_H13
PIN_F14
PIN_H14
PIN_F15

30

VGA_B[6]
VGA_B[7]
VGA_BLANK_N
VGA_CLK
VGA_G[0]
VGA_G[1]
VGA_G[2]
VGA_G[3]
VGA_G[4]
VGA_G[5]
VGA_G[6]
VGA_G[7]
VGA_HS
VGA_R[0]
VGA_R[1]
VGA_R[2]
VGA_R[3]
VGA_R[4]
VGA_R[5]
VGA_R[6]
VGA_R[7]
VGA_SYNC_N
VGA_VS
serialIn
serialOut

PIN_G15
PIN_J14
PIN_F10
PIN_A11
PIN_J9
PIN_J10
PIN_H12
PIN_G10
PIN_G11
PIN_G12
PIN_F11
PIN_E11
PIN_B11
PIN_A13
PIN_C13
PIN_E13
PIN_B12
PIN_C12
PIN_D12
PIN_E12
PIN_F13
PIN_C10
PIN_D11
PIN_Y18
PIN_Y17

31

9. References
[1]

"Battleship
(Game),"
[Online].
Available:
https://en.wikipedia.org/wiki/Battleship_(game).
[2]
B. Land, "Bruce Land - Cornell ECE Professor," [Online]. Available:
https://www.youtube.com/watch?v=F9J9qwTSZcY.
[3]
B. Land, "DE2 VGA Examples - ECE 576 Cornell University," Cornell University,
[Online].
Available:
http://people.ece.cornell.edu/land/courses/ece5760/DE2/indexVGA.html.
[4]
S. Hauck, "EE 271 Peripherals," UW EE, [Online]. Available:
https://www.ee.washington.edu/class/271/hauck2/de1/video/Video_Tutorial.pdf.
[5]
S. Hauck, "EE 271 - Peripherals," UW EE, [Online]. Available:
https://www.ee.washington.edu/class/271/hauck2/de1/index.html.
[6]
"VGA
Controller
(VHDL),"
[Online].
Available:
https://eewiki.net/pages/viewpage.action?pageId=15925278.

32