Iowa State University

Electrical And Computer Engineering

CPRE 281

Final Project Report

Flight Schedule Board

December 8th, 2022

Baylor Clark
Eli Schaffer
 Table of Contents

Introduction - 2

Overall Design - 2

Finite State Machine Design - 7

Register Design - 11

Reach Goals - 15

Instructions - 16

Conclusion - 18

1
Introduction
For our final project, the group took the idea of a flight schedule board found in an airport
and attempted to implement a few features onto the FPGA. The overarching concept of the
project was to use the seven segment displays and switches to display an acronym of airline and
four digit flight number. The other goal of the project was to use the LEDs and rocker switches
on the FPGA to show the status of a flight. The status of flight would include whether the flight
is on time (indicated by green LED) or delayed (indicated by red LED). Furthermore, a certain
LED would indicate which of the four flights is being checked. The final status information
would be shown with a LED. Whether the flight had departed and was flying, the LED would be
lit up, and if the flight had arrived, the LED would turn off.

In terms of digital logic, the program begins with a 2-bit input. In order to make the
project challenging but not too complex, the group programmed and analyzed four different
“flights”. Therefore, a 4-to-1 MUX will be used. The project will require a finite state machine
dealing with the 4 different “flights”. The project will also need D Flip-Flops, and other common
logic gates. The information that will be determined by the finite state machine will include
destination and flight information, such as if the flight is flying or if the flight is delayed. This
information is shown through an LED to show the status of the “flight”. For information about
the airline and flight number, 24-bit registers are used. The airlines include Continental Airlines
(CA), Frontier Airlines (FA), American Airlines (AA), and Emirates Airlines (EA). A four digit
“flight number” was chosen by the group to be associated with the “flight”. The registers use an
input and VCC on the clear and preset of the D Flip-Flops to create and store the 24-bit binary
number. The four registers would go to a 4-to-1 bus mux that would then be controlled by two
switches on the FPGA board.

Overall Design

The process of design went through a few different states. The group decided to take a
top down approach to determine needed logic and functionality. To meet the requirements of the
project we had to include a register file, FSM, seven segment display/LED, and input from the
board. After some research, the group decided on the two letter and four digit number
signification. The register files would contain 24-bits to encode the proper information. The FSM
went through different interactions. To meet our specifications of having four locations, a flying
indication, delay, or on-time indication an 11-state FSM was made. More detailed information
about the design of the FSM will be provided below. The design of the project was fairly
straightforward besides a few issues with the FSM. Other than the main components, files from
previous labs were used such as clock stabilizer and seven-seg-decoder to save on time in the
design process.

2
 Figure 1
The combined design file above combines elements discussed previously in the project
report. The inputs correspond to the rocker switches and push button on the FPGA board. The
final register block is connected to three bus D Flip-Flops. Proceeding the D Flips-Flops are the
6 seven-seg-decoders that display the register information on the FPGA. The FSM is connected
to a 2-to-4 decoder and is connected to LED outputs. The design for this portion of the project
was straightforward because of all the design we had gone through before this. A problem
occurred when pin planning but was resolved quickly.

3
 Bus DFF

Figure 2

Very simply put, we needed to make a 24 bit DFF to ensure that when the finite state
machine was in the final state, we were still showing what flight we wanted the finite state
machine to be affecting. We hardcoded the preset and reset to VCC because we didn’t ever need
to reset or preset the bus DFF. If we would have, it would mess up the system of our project.

2-to-4 Decoder

Figure 3
This is a simple 2-to-4 decoder circuit. We used this to help the finite state machine
decide what destination it would be outputting.

4
 Clock Stabilizer

Figure 4
This is the same debouncing circuit we made in Lab 11. This helps the clock button we
use for our project to not bounce over states and keep it the same.

Figure 5

This is what our project looked like initially. We decided to throw everything onto one
design file and try to debug everything within it. After about an hour of this, we decided to
sub-component everything to make it easier on ourselves to understand and debug. We split
things up into the finite state machine, the register files, and all other logic needed to make things
work.

5
 Finite State Machine Design

Designing the finite state machine was a long process. We had a few different thoughts
about what needed to happen, and a few different iterations of design. The first thing we did was
make the state diagram for the machine, shown in figure 6. We then needed to make a state table
and state assigned table. We assigned the states as follows:

State A B C 1 2 3 4 5 6 7 8

Assignment 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010

Figure 6

We also decided to make the finite state machine a moore machine, meaning the outputs
were assigned based on the current state only. State A is the reset state and “idle” state, state B is
virtually the same as state A but it differs in the outputs so when we were debugging it, we knew
if the states had changed. This is also the on-time “hub” for all of our flights. This design choice
can also be seen in our final presentation when different LEDs light up for the different states.
State C is the delayed state “hub”, and is close to states A and B, but it also has different outputs.
States 1 and 5 are the states for location 1, 1 being on-time, and 5 being delayed. This also
follows through all other state pairs. The “pairs” are 2 and 6, 3 and 7, and 4 and 8. Given that we
have more than 8 states, we needed to use 4 bits to describe each individual state without
repeating bits. We also decided to use 2 inputs for ease of designing because we have 4 different
locations. By doing this, we could go directly from B or C to the final destination. Designing it
this way resulted in a 6 input truth table, meaning that we couldn’t use K-maps to derive
expressions for the next-state logic. The final logic that we got for the next-state variables was
relatively simple, considering we had 6 different inputs. The logic we got is shown in figure 7 .

6
Also by designing a moore machine, we were able to use a 4 variable K-map for the output logic.
We also used a truth table to help show us what logic created specific outputs. This truth table is
shown in figure 8.

Figure 7

Figure 8

The don’t cares at the end of the truth table were there because the last 5 states in the
truth table should in theory never occur. We tested the output and input logic using Questa
ModelSim during our Thanksgiving break when we didn’t have access to the boards. This made
our lives a lot easier because we didn’t need to pin plan all of the pins we needed to test the
design. While testing with Questa, we noticed that some of the output arguments weren’t lining
up as we thought they would have. We then noticed that we could make the output logic much
simpler if we made the “hexadecimal” number equal to E, which stands for Error. After doing
this, we re-tested our output logic, and our final design file for the output logic can be seen in
figure 9. We also had some errors when testing the input logic. We had so many arguments that it
was hard to keep straight the current and next states. To accommodate this, we made multiple
outputs for the current and next states when we exported it to Questa. We had some iterations

7
when designing it because we noticed that some of the states gave the wrong next state. After we
finished debugging this, we made a symbol of it and used it in our finite state machine file. Our
final input logic and design file can be seen in figure 10.

Figure 9

Figure 10
After we made symbols and connected all of the input and output logic, we then tested
the finite state machine in Questa. When we verified that it worked, we made a final finite state

8
machine block to use in our final design file. The last design of our finite state machine can be
seen in figure 11.

Figure 11

9
 Register Design

24-bit Register

Figure 12
The design file shown above is the 24-bit register discussed in the introduction. The
design process began with determining what information was going to be shown. The group
determined a two-letter acronym and a four-digit number would be shown on the seven-segment
displays to signify one of four flights. The two-letter acronyms would stand for real airlines:
Frontier Airlines (FA), Continental Airlines (CA), American Airlines (AA), and Emirates
Airlines (EA). The group would pre-determined the four-digit numbers since we wanted the
numbers to be the same throughout the project. Initially, the group looked into various airlines
and real flight numbers; however, the seven-segment display limited possible letters and
numbers. Luckily, the group was able to determine airlines that contained hexadecimal letters.
The letters and numbers were then converted to a binary that could be encoded in the design file.

10
Flight Information
1. FA(Frontier Airlines)-4222 (00)
a. Binary Number- 1111 1010 0100 0010 0010 0010

2. AA(American airlines)-9838 (01)

a. Binary Number - 1010 1010 1001 1000 0011 1000

3. CA(continental airlines)-4579 (10)

a. Binary Number - 1100 1010 0100 0101 0111 1001

4. EA(Emirates airlines)-5270 (11)

a. Binary Number- 1110 1010 0101 0010 0111 0000

In terms of making the design file, the block schematic contains 24 D Flip-Flops to
encode the information. During design, arranging the D Flip-Flops in 6 rows of 4 to encode each
4-bit binary number seemed the most logical. The inputs to all the D Flip-Flops are set to the
Vcc. The group considered different ways of encoding the bits. However, the most effective way
found was to use a low preset system. If the bit was 1, set the preset to the reset input and the
clear to Vcc. Inversely, if the bit was 0, set the preset to Vcc and the clear to the reset input. A
bus line was used to connect all the D Flip-Flops into one [23..0] output. The same process was
done three more times to encode the information for each “flight” listed above.

11
4-to-1 Mux Verilog

Figure 13
The Verilog code shown above was used from a previous lab with some modifications.
For the Mux to transfer the correct information, bus specifications were added to the Verilog. On
the first attempt, [23..0] was added to the input and output, but when a block file was created, the
output was not a bus line. The group discovered that the reg also needed the same bus
specification. A block file was made from the Verilog and was used in the combined register
design file down below.

12
Combined Registers

Figure 14
The combined register design file above combines the previous register design files. The
four register blocks contain the information about each of the four “flights.” All four of the
registers are connected to bus inputs of the 4-to-1 mux. The design of this circuit was
straightforward and no problems were encountered during the design process. The output of the
mux is the determined flight by the user.

13
 Reach Goals
The idea of a flight schedule board allowed us to set further reaching goals. One further
reaching goal the group has in mind is to use the LCD screen. The 7 segment display restricts the
type and amount of information that can be displayed. However, using the LCD would have
allowed us to implement more information that would traditionally be on a flight schedule board.
A few ideas for the LCD could include “flights” and information about them scroll across the
LCD display board. Furthermore, we could show if a “flight” is delayed and what destination it
will be going to. We never got far enough along in the project to really start and attempt the LCD
screen. This and along with the fact that we never had a chance to deal with it before now is why
we decided to make it a reach goal. Another reach goal we had was to make the flight numbers
and airlines accurate with the real-world. As explained above, we were restricted to a few
airlines, so we weren’t able to design the correct information. We wanted the locations shown
below, as well as a few flights that went from each location to the next. This was hard to do with
restricted airlines. We gave this up because we were spending too much time on the little things
instead of designing the main project. We needed 5 different locations and destinations because
we had 4 flights, and only one flight can be at one location at a time.

Reach Goal Info

Seattle - SEA
Denver - DEN
New York (La Guardia) - LGA
Los Angeles - LAX
St. Louis - STL

14
 Instructions
1. Turn on the FPGA and open Quartus Prime on your computer.
2. Open the “ProjFin.qpf” file, and then open the “Final.bdf” file, and compile it to your
computer.
3. Next, use the “Tools” tab and program the file to the FPGA board.
4. The board will light up with a preset arrangement of lights and code on the seven
segment displays, we found them to be (8A 0020), as well as some switches . We used a
low-hot reset system, meaning that if the first rocker switch (SW3_DB, also known as the
reset switch) was down, the system would not work.
5. Using the third rocker switch (SW1_DB, also known as S1) and fourth rocker switch
(SW0_DB, also known as S0), you can decide which flight you want to display. Press the
second push-button (KEY0_DB, also known as the clock button) three times to see the
flight selection you wanted. They will be displayed on the last six seven segment displays
(HEX5-HEX0).
a. 00 is flight FA 4222
b. 01 is flight AA 9383
c. 10 is flight CA 4579
d. 11 is flight EA 5270
6. After you have the flight selected, it is important to note that not every press of the clock
button will show you the results you want. If you follow the instructions properly, you
should have no problem seeing your results. If at any point you lose count of what clock
press you’re on, you can reset the system using the reset switch, and go back to Step 5.
7. Once you have this done, you can then use the same two rocker switches to decide what
other flight information you need. The system won’t become active until the S1 switch is
turned on.
8. While you have the S1 switch on, you can then decide if you want the flight to be on-time
or delayed using the S0 switch. Setting S0 to 1 delays the flight, and S0 to 0 keeps the
flight on-time. When you decide which time you want the flight to be, you can then press
the clock button.
9. Using the same two switches, you can then decide what destination you want the flight to
go to. After you select which destination you want, you can press the clock button and
see the results on the LEDs. The LED to show you if it is on-time is LEDG7, the delayed
LED is LEDR0, and the LED that shows if it is completed or not is LEDG5.
a. 00 is destination 1.
b. 01 is destination 2.
c. 10 is destination 3.
d. 11 is destination 4.
10. After you press the clock button and see that the LEDG5 is not lit up, this is the final state
of our project. This state shows the flight number, determines if it is on-time or delayed,

15
 and also lights up one of four specific locations. After this, you can reset the system with
the low-hot reset switch, and go back to step 5 to start over.
11. For example, you can have flight CA 4579 to go to the first destination with a delayed
departure. To do this, you need to select flight CA 4579 with a 10 on the select switches
and press the clock button three times. Then make sure that the reset switch is up, and set
the select switches to 11. After this, press the clock button, then set the select switches to
00 and press the clock button. The seven segment displays should read “CA 4579” and
the delayed flight light as well as the location zero light should be on. If the incomplete
light is on, either the system is one clock cycle behind, or you didn’t follow instructions
correctly.
12. Here is an example where we have flight FA 4222 delayed to location 3.

a.

16
 Conclusion
In conclusion, the functionality of the project works to the group’s and TA’s liking. The
design process was very fun to go through and solve problems in our design. The group was able
to incorporate all the needed design elements into the project. The FSM was the most difficult
design aspect of the project. One area that could have been improved was the register file. Since
the encoded information was already pre-determined we decided to hard code the information
directly into the registers. In order to get full points, we should have included write, enable, and
mux to bring in the information and encode it in the registers. The only problem when
programming the design to the FPGA was a couple incorrect pin plans. Another change that
would have been made if there was more time was to change the location of a couple LEDs and
include information on the LCD. Our goal for the project was to print information about the
flight and airport location on the LCD; however, with time constraints that was not possible. The
group thought the idea was unique and tried to implement as many features from an actual flight
board as we could. Overall, the design process helped the group learn valuable information about
the content learned in the course and incorporate new ideas as well. With more resources and
time we could have incorporated more but are happy with the final product.

17