Calculator

Sander Babby, Alin Stan, Dustin Hoskins

Electrical and Computer Engineering Department
School of Engineering and Computer Science
Oakland University, Rochester, MI
[email protected], [email protected], [email protected]

Abstract from the decoder was less than 10, then zN would be high and
The purpose of the project was to build a simple calculator zO would be low. Likewise, if the value from the decoder was
greater than 9, then zO would be high and zN would be low.
using a keypad, LCD, and FPGA (Nexys 4). The calculator
This would help the ALU determine if numbers or if operators
would be able to add, subtract, multiple, and divide 4 bit were being pressed. The LCD did not need this data since it
numbers. The project was a great learning experience for displays what is pressed and not running background
digital logic and VHDL. An example is interfacing multiple computations.
components and performing computations on the FPGA. The The keypad was switched to the switches halfway
project was able to perform properly in simulation, but it did throughout the project. This was done to remove any variation
not perform correctly in real life because of a timing issue coming from the keypad. The original keypad had a bend in
with the outputting the result to the LCD. A recommendation the ribbon cable, which was causing bouncing between rows.
would be to keep the signal high long enough for the LCD to The decoder stayed the same in what it was inputting and
print the result. outputting. Later in the project, a new keypad was received
and tested. This newer keypad was able to work well with
I. INTRODUCTION minimal bouncing. The newer keypad was not connected to
The scope of the project was building a 4-bit calculator the project at the end because the team did not want the
using a keypad, LCD, and FPGA (Nexys 4). The team minimal bouncing to hinder test to allow for quicker debug
time. The decoder code did account for bouncing inside of the
wanted a project that would involve many topics covered in
code. This is what took care of most of the bouncing in the
ECE 378 and challenge the team to complete the project.
keypad.
This was a good project to do because it incorporates many
different digital logic principals such as external interfaces B. Arithmetic Logic Unit
and architecturally based with arithmetic operations. Some The ALU represented the brain of the project. Its job was
of the topics that were covered in class were decoders, to be able to receive the numbers that the user inputs and
Arithmetic Logic Unit (ALU) design, and Finite State output the result. The use would input numbers in decimal and
Machines (FSMs). Topics that had to be researched outside would expect to see a decimal output. This was the first
of class were interfacing a keypad and LCD to the Nexys 4. obstacle that we faced. The numbers would be coming in and
This project has many applications such as being used as a it was up to the ALU to figure out what the input was, and
traditional calculator, app on a smartphone, or a part of a what the operand was. If a user enter a 1, 2, and then 3. The
larger project that would need calculations performed. Many ALU had to take those 3 separate inputs and make it the
modern electrical and software applications depend on decimal number 123. This was done by using a state machine.
calculations to be performed in real time in the background In the first state the machine would receive the first number,
using a calculator such as the one in this project. store it in a variable, and then go to the next state. This state
would multiple the first number by 10 and then add the second
II. METHODOLOGY input to this number before going to state three. In each state
it would take the previous states result and multiple it by 10,
A. Keypad then add the new input. If at any time the ALU received an
A decoder in the project represented the keypad. The operator (+ - * %) the state machine would stop and hold its
decoder would receive a signal from the ALU to determine to current value. There were two of these state machines used.
clear or not. It would also receive an input from the keypad. One to capture the first number, and one to capture the second.
The way this works is if a key is being pressed it determines There was a parent State machine which controlled all aspects
it by matching the row being pressed with what column in that of the ALU’s functions. In state 1 of the ALU state machine it
row is being pressed. That is how the keypad determines would enable to first number catcher. It would only change
which key is inputted. The keypad in addition to the value states when an operator was received. Then in state 2 it would
being sent that is being pressed, it would send two additional disable the first number catcher and enable the second. It
signals to the ALU. These signals were a zO and a ZN. These would stay in state 2 until it received the input for equals. It
would be high or low depending if a number was pressed or if would then transition to state 3. This state performed the
an operator was pressed. If the value of output from the value calculations using a series of if statements and would then
output the result to the LCD’s divider. The FSM is outlined in from the input and saves it into input2, if it is between 100
below in figure 1. and 199 then the first output is a 1 subtracts 100 from the
input and saves it into input2, if it is less than 100 then output
one is blank and saves input to input2. Then the divider
checks for the numbers by 10’s outputs the number to output2
and subtracts the largest multiple of 10 from it and saves the
remainder into input3. It then finally outputs input3 to
output3 and send a finished signal to the result catch.
The 3 outputs are now inputted into result catch,
which is another state machine. This state machine is
designed to slow down the writing process and output each
number one at a time to the LCD. The LCD was receiving the
numbers to fast so we tried to slow down the output. This is
where things started going wrong. We were never able to
output the final result to the LCD. We believe this is due to
the timing required by the LCD. We also had to implement
an enable signal for the LCD, which also came from this
result catch. We were able to show that the calculator does
actually work through a simulation; however we are not able
to show the actual result on the LCD. Based on the timing
diagram show below we believe that we were sending the
signal out at the wrong time and the LCD was not ready to be
written to, and was not correctly enabled at the right time and
for the right amount of time. We should have seen the rs as
high and e as high in order for us to write to the LCD, which
in our case did not happen as it should have as represented in
figure 2 below [3].

Figure 1. FSM of project ALU.

C. LCD
We attached an LCD Unit to our Nexys 4 Board. The main
code came from Dr. Llamocca [1][2]. The rest of the code we
created ourselves. For the first portion of the equation, which
we consider as the first number input, the operator, the second
number input and the equals input is a direct link to the LCD.
When you select an input on the switches, or if using the
keypad, pushing a button, the LCD automatically write the Figure 2. Timing required to write to LCD.
character received. There is a component called a divider,
which is really just a state machine, which takes in a 4-bit III. EXPERIMENTAL SETUP
number and converts that to an ASCII character and then that To verify the functionality of the calculator different
gets sent to the LCD. The divider stay in the same state and hardware and software test methods were used. For the
keeps writing to the LCD until the equals sign is pushed. software, Xilinx to code, debug, and simulate the project.
When the equals sign is pushed the divider moves into state Each individual component was simulated in Xilinx’s ISim to
two. In state two the divider no longer receives an input from verify it was working correctly. After this was accomplished,
the switches; it now receives an 8 bit input from the ALU, it the components were combined into a top level and simulated
also sends an enable to the next component called result to verify the functionality of the top level.
catch. The number from the ALU can be anywhere from zero For the hardware, the components were tested individually
to 225 in decimal. The divider then starts ripping the number to verify functionality. An example of this is connecting the
apart in order to try and get the characters. It has 3 outputs. keypad to the Nexys 4, pressing a button, and outputting the
All of them are zero at first and the outputs are in ASCII 8 bit result to the seven-segment display of the Nexys 4. This was
notation. First the divider checks if the number is greater than also done with the ALU by inputting values from the switches
200, if it is then the first output will be a 2 and subtracts 200 and outputting the result to the seven-segment display. For the
LCD, values were inputted using the switches and then sent to
the LCD by pressing a pushbutton on the Nexys 4. The value results in the projected were explainable. For example,
was being displayed in ASCII on the LCD. switching keypads removed the bouncing for the most part
After components were individually tested, they were because the connection was not bent as such in the original
combined together to verify the functionality of the system. keypad. Although the result did not display on the LCD, this
This was accomplished by connecting the keypad and LCD to was explainable because the signal was not being sent long
the Nexys 4. On the keypad, entering a number followed by a enough to the LCD for it to write the result.
arithmetic operator then another number and the equals
operator will send the necessary signal to the ALU and LCD. V. CONCLUSIONS
As buttons are being pressed on the keypad, the LCD is
This project was an exceptional learning experience for
displaying what is being entered. The ALU is performing the
necessary calculations as buttons are pressed so that once the implementing the topics covered in ECE 378 in a real world
equal operator is pressed, the result is sent to the LCD to project. The team was able to gain experience with important
display it. The LCD should then display the result next to topics such as FSMs, ALU, decoders, computer arithmetic,
commands that were entered. Also, to rule out any bouncing and VHDL programming. Another important take away from
by the original keypad, switches were used to send the signal this project was working as a team to integrate individual
to the ALU and LCD in testing. This should display the components that work separately on its own but require work
numbers entered, the arithmetic operator, equal operator, and to implement correctly together. This will provide as
the result on the LCD. excellent experience when moving into industry and working
with teams in large corporations.
IV. RESULTS As discussed, the project did not perform 100% as
The project produced results as expected for the most part. expected. The main issue remaining was the result not being
In simulation, the project was able to send the signals displayed on the LCD and connecting the keypad to the final
correctly to and from components then send the final result to system. Displaying the result to the LCD could be improved
the LCD. In implementation, the calculator performed by determining the proper timing when displaying a result
similarly to the simulation except with not displaying the from the ALU instead of the keypad. Once the correct timing
calculated result. The LCD would receive the result but delay is found, then the result could be displayed on the LCD.
would not show the result being displayed. Besides the LCD Another alternative would be to displaying the result to the
not displaying the result, the rest of the projected would seven-segment display. This could have been done either for
worked properly. For example, the signals being sent to the demonstration purposes in class or as a permanent solution to
ALU and the LCD from the keypad were correct. The ALU the LCD not displaying the result. Furthermore, the keypad
would then take the signals, properly perform the necessary could have been improved by improving the minimal bounce
calculations, and then send the result to the LCD. The LCD that was left in the keypad.
would take the result as an input, but a timing delay issue The project was able to enhance the team’s understanding
would cause the LCD not have enough time to write the result of digital logic and provide lessons learned for moving
on the display. Besides the result, the LCD would show the forward in school and industry.
numbers being entered into the system, the arithmetic
operator, and the equal operator on the display. REFERENCES
The project was able to perform correctly because of topics [1] Llamocca, Daniel. “[ECE378] Final Project.” Message to the
authors. 2 Apr. 2015. E-mail.
covered in ECE 378. FSMs were able to work as a control for
[2] Llamocca, Daniel. “Re: ece 378 Final project.” Message to the
the calculator within the ALU to send, receive, and calculate authors. 20 Mar. 2015. E-mail.
signals as needed for the project. The LCD was also [3] Hitachi. HD44780U (LCD-II). Tokyo, Japan: Hitachi, 1998.
implemented using a FSM. The keypad was able to work by PDF.
using a decoder. Besides the LCD not displaying the [4] Haskell, Richard E., and Darrin M. Hanna. Digital Design
calculated result, the calculator performed as expected. The Using Digilent FPGA Boards. Rochester Hills, MI: LBE
Books, 2009. Print.