Final Project

ENGN 3213
REVERSE POLISH CALCULATOR

PROJECT REPORT
NAN ZHU
[U4342034]
VASANTA GAYATRI
CHAGANTI [U4238388]
Zhu, Chaganti ENGN 3213: Reverse Polish
Calculator Project Report
Abstract
The project involves the simulation, building and testing
of a Reverse Polish Calculator implementing a four –level
register stack with four basic arithmetic operations. The
Reverse Polish Calculator is built using a modular
approach and the project separately builds the Keyboard
interface, the RP Engine and the Display Unit. The
project has three levels of implementation, the first
level of integer addition and subtraction was coded and
tested using Xilinx ISE Webpack 9.2i, successfully and
the Keyboard Interface and Display Drive are
successfully implemented on hardware. Level 2 of the
project is designed to integrate multiplication and
division into the earlier modules, with input to the
calculator consisting of fixed point numbers. The
multiplication and division have been tested on the
Simulation Test benches developed and executed
successfully.
Page 2 of 39
TABLE OF CONTENTS
1 INTRODUCTION ...................................................6
1.1 REVERSE POLISH NOTATION..................................................................................................6
2 PROJECT DESIGN .........................................................................................8
2.1 DESIGN APPROACH............................................................................................................8
2.2 EQUIPMENT UTILISED..........................................................................................................9
2.3 VERILOG CODING STYLE....................................................................................................10
2.4 DESIGN TRADE-OFFS.......................................................................................................10
2.5 TEAM WORK DISTRIBUTION................................................................................................10
3 KEYBOARD INTERFACE...............................................................................11
3.1 THE KEYBOARD’S CONNECTOR.............................................................................................11
3.2 RECEIVING DATA ...........................................................................................................12
3.3 THE KEYBOARD SCAN-CODES...............................................................................................13
3.4 KEYBOARD IMPLEMENTATION................................................................................................14
3.4.1 Finite State Machine of the keyboard...............................................................14
..................................................................................................................................14
..................................................................................................................................14
3.5 SWITCH DE-BOUNCING......................................................................................................15
4. CONTROLLER............................................................................................15
5 ARITHEMATIC & LOGIC UNIT (ALU)..............................................................19
5.1 ALU INPUT..................................................................................................................19
5.2 ADDITION ....................................................................................................................19
5.2 SUBTRACTION ...............................................................................................................21
5.3 OPERATION CHOICE AND SIGN DECISION.................................................................................21
5.4 MULTIPLICATION .............................................................................................................23
7. STACK & KEY HOLDING REGISTER IMPLEMENTATION...................................26
8. DISPLAY...................................................................................................27
8.1 DISPLAY DRIVER.............................................................................................................27
9 SIMULATION RESULTS................................................................................29
9.1 SIMULATION TEST BENCH: KEYBOARD...............................................................................29
9.2 SIMULATION TEST BENCH: FSM CONTROL .........................................................................30
......................................................................................................................................30
......................................................................................................................................30
9.3 SIMULATION TEST BENCH: ALU..........................................................................................31
9.3.1 Simulation of addition......................................................................................31
......................................................................................................................................31
THEREFORE, THE ENABLE_ADD IS SET TO 0 AND THE ENABLE_SUB SET TO 1 (SHOWN BY THE SECOND ARROW). THE
FOLLOWING FOUR CALCULATIONS ARE TESTED “2 + 5 = 7”, WHICH TESTS POSITIVE NUMBERS ADDITION; “1234 +
9876 = 0B110, ALU_OVERFLOW = 1”, WHICH TESTS FOR POSITIVE NUMBER ADDITION OVERFLOWS; “(−5) +
(−2) = (−7)”, WHICH TESTS THE ADDITION OF TWO NEGATIVE NUMBERS; AND FINALLY THE “(−1234) +
(−9876) = (−B110), ALU_OVERFLOW = 1” WHICH TESTS NEGATIVE NUMBER OVERFLOWS. ALL THE RESULTS
WERE SENT TO ALU_OUT AT THE POSITIVE EDGE OF THE CLOCK...............................................................31
9.3.2 Simulation of subtraction.................................................................................31
.................................................................................................................................32
THESE RESULTS ARE REFLECTED IN THE TEST BENCH SHOWN ABOVE. AGAIN, THE RESULTS ARE UPDATES AT THE POSITIVE
EDGE OF THE CLOCK...............................................................................................................32
9.3.3 Simulation of multiplication..............................................................................32
THE MULTIPLICATIONS BETWEEN TWO POSITIVE NUMBERS, TWO NEGATIVE NUMBERS AND TWO OPPOSITE SIGN NUMBERS ARE
TESTED AS “2 * 3 = 6”, “(−5) *(−15) = 75” AND “(−15) * 15 = −225”. ONCE THE MULTIPLICATION
TRIGGED (WHERE THE FIRST ARROW POINTED), THE TESTS WERE OPERATED CONTINUOUSLY. A FOUR DIGIT NUMBER
MULTIPLICATION “1234 * 5 = 6170” AND AN OVERFLOW CASE “1234 * 15 = 8510, ALU_OUT = 1” WERE
Page 3 of 39
THEN TESTED TO SEE WHETHER THE HIGHER LEVEL REGISTERS WORK. AGAIN, THE RESULTS WERE SENT TO ALU_OUT AT
THE POSITIVE EDGE OF CLOCK AS SHOWN IN THE FIGURE BELOW..............................................................32
..................................................................................................................................32
9.4 SIMULATION TEST BENCH: KEY HOLDING REGISTER..........................................................32
......................................................................................................................................33
9.6 SIMULATION TEST BENCH: DISPLAY DRIVER.......................................................................33
10. PEGASUS BOARD IMPLEMENTATION.........................................................34
10.1 FPGA RESOURCE CONSUMPTION.......................................................................................34
10.1.1 Level1.............................................................................................................34
LOGIC UTILISATION................................................................................................................34
USED...............................................................................................................................34
AVAILABLE..........................................................................................................................34
UTILISATION........................................................................................................................34
NUMBER OF SLICES...............................................................................................................34
196................................................................................................................................34
768................................................................................................................................34
49%...............................................................................................................................34
NUMBER OF SLICE FLIP FLOPS...................................................................................................34
120................................................................................................................................34
1536..............................................................................................................................34
8%.................................................................................................................................34
NUMBER OF 4 UNIT LOOK UP TABLES (LUTS)..............................................................................34
455................................................................................................................................34
1536..............................................................................................................................34
29%...............................................................................................................................34
NUMBER OF BONDED IOBS......................................................................................................34
10..................................................................................................................................34
140................................................................................................................................34
7%.................................................................................................................................34
NUMBER OF GCLKS.............................................................................................................34
2....................................................................................................................................34
4....................................................................................................................................34
50%...............................................................................................................................34
10.1.2 Level 2............................................................................................................34
LOGIC UTILISATION................................................................................................................34
USED...............................................................................................................................34
AVAILABLE..........................................................................................................................34
UTILISATION........................................................................................................................34
NUMBER OF SLICES...............................................................................................................34
494................................................................................................................................34
768................................................................................................................................34
64%...............................................................................................................................34
NUMBER OF SLICE FLIP FLOPS...................................................................................................34
270................................................................................................................................34
1536..............................................................................................................................34
17%...............................................................................................................................34
NUMBER OF 4 UNIT LOOK UP TABLES (LUTS)..............................................................................34
894................................................................................................................................34
1536..............................................................................................................................34
58%...............................................................................................................................34
NUMBER OF BONDED IOBS......................................................................................................34
16..................................................................................................................................34
140................................................................................................................................34
11%...............................................................................................................................34
NUMBER OF GCLKS.............................................................................................................34
2....................................................................................................................................34
4....................................................................................................................................34
50%...............................................................................................................................34
......................................................................................................................................35
Page 4 of 39
10.2 WARNINGS.................................................................................................................35
WHEN THE TOP LEVEL MODULE IS SYNTHESIZED AND IMPLEMENTED XILINX GENERATES WARNINGS AS CAUTIONARY
COMMENTS ON THE USE OF ALWAYS BLOCKS AND SENSITIVITY PARAMETERS. THE USE_DSP48 CONSTRAINT ALLOWS THE
SPECIFICATION OF TECHNOLOGY RESOURCE FOR MACRO IMPLEMENTATION. ...................................................35
WARNING:XST:905 - "../TOPLEVEL.V" LINE 36: THE SIGNALS <KHR> ARE MISSING IN THE SENSITIVITY LIST OF
ALWAYS BLOCK. MODULE <TOPLEVEL> IS CORRECT FOR SYNTHESIS........................................................35
WARNING:XST:905 - "../SERIAL_RCVRWORKING.V" LINE 148: THE SIGNALS <PS2_DATA, NEXT_SCANCODE,
SCANCODE, READ, DIGIT> ARE MISSING IN THE SENSITIVITY LIST OF ALWAYS BLOCK. MODULE <SERIAL_RCVR2> IS
CORRECT FOR SYNTHESIS..........................................................................................................35
WARNING:XST:905 - "../DECODER1.V" LINE 40: THE SIGNALS <RCVR_OUT> ARE MISSING IN THE SENSITIVITY
LIST OF ALWAYS BLOCK. MODULE <DECODER1> IS CORRECT FOR SYNTHESIS..............................................35
WARNING:XST:905 - "../FSM3.V" LINE 81: THE SIGNALS <PRE, BCD> ARE MISSING IN THE SENSITIVITY LIST OF
ALWAYS BLOCK. MODULE <FSM3> IS CORRECT FOR SYNTHESIS.............................................................35
WARNING:XST:905 - "../MUX_DIS2.V" LINE 53: THE SIGNALS <IN1, IN2, IN3, IN4> ARE MISSING IN THE
SENSITIVITY LIST OF ALWAYS BLOCK...............................................................................................35
MODULE <MUX_DISPLAY2> IS CORRECT FOR SYNTHESIS....................................................................36
WARNING:XST:2734 - PROPERTY "USE_DSP48" IS NOT APPLICABLE FOR THIS TECHNOLOGY.......................36
10.3 FPGA SPEED.............................................................................................................36
11. CONCLUSION..........................................................................................36
REFERENCES................................................................................................37
APPENDIX....................................................................................................38
Page 5 of 39
1 INTRODUCTION
The aim of this design is to build a reverse polish calculator with four
significant decimal digits. Utilising a top down design approach the project
is segregated into four main blocks to implement the Finite State Machine,
Keyboard, ALU, and the State Registers. Each individual module is then
developed with its set of parameters and user defined constraints.
1.1 Reverse Polish Notation

Reverse Polish Notation was first developed by Jan Lukasiewicz in 1920,
when he introduced the concept of prefix notation that made arithmetic
operations faster, simpler and significantly easier to adapt to. Reverse
Polish Notation is implemented using a simple First-In-First-Out (FIFO)
stack. This method was utilised by HP in 1972, to build the first hand held
calculator with RPN Notation.
A simple example below demonstrates the working of an RPN Calculator,

 2 × (5 + 4) 
for the given algebraic expression:  
 The reverse polish
 3 × ( 2 +1) 
expression is: MI: 2 ENTER 5 ENTER 4 + *ENTER 3 ENTER 2 ENTER 1
+ * /. RPN notation has a number of advantages over the conventional
algebraic notation. With each operator entered, the user can check
intermediary results and verify the sum of all the actions before
calculating the final answer. This method also allows the user to define the
priority of the operators, without the need to remember ‘BODMAS’ rules.
Stack Stack A Reverse Polish calculator
Stack Stack
Entry KHR
Level 4
Level
Level 2
Level built on this notation is best
3 1
2 2 XX XX XX XX
implemented using a stack.
ENTE Each number entered is stored
2 02 XX XX XX
R onto a stack, while an operator
5 5 02 XX XX XX pops the stack and evaluates
ENTE
R
5 05 02 XX XX the expression. To achieve
4 4 05 02 XX XX this, a multilevel stack and a
+ 9 02 XX XX XX Key Holding Register are used
* 18 XX XX XX XX
ENTE
to design the calculator. A four
18 18 XX XX XX level stack is used as a project
R
3 3 18 XX XX XX guideline with which the above
ENTE
3 03 18 XX XX expression is evaluated as
R
2 2 03 18 XX XX follows:
ENTE
2 02 03 18 XX
R Even within RPN, there exist
1 1 02 03 18 XX
+ 3 03 18 XX XX different ways to express the
* 9 18 XX XX XX same equation. Considering
/ 0.5 XX XX XX XX M1 and M2 presented below:
MI: 2 ENTER 5 ENTER 4 + * 3 ENTER 2 ENTER 1 + *
/
M2: 2 ENTER 5 * 4 + 3 ENTER 2 * 1 +/
The result is the same for both operations but M2 saves ENTER Key
strokes. If this were to be implemented using a four level Stack, ENTER
Page 6 of 39
PUSHES the operand onto the stack and an operator POPS the operand. If
MI is used and the ENTER key is pressed too many times without an
operation in between the operands, then a four level stack would overflow.
M2 never allows the counter to progress to the fourth register (for this
example) showing a more efficient space utilization. This method is
preferred implementation of the calculator design detailed in the following
pages.
Page 7 of 39
2 PROJECT DESIGN
The goal of this project is to build a four function calculator with a four
level memory register.
The calculator is designed based on the reverse polish notation, and
performs signed decimal arithmetic.
Valid inputs to the calculator are numbers, operators and basic functions.
Number inputs are limited to four decimals with leading or trailing zeros.
Operations include addition, subtraction, multiplication and division. The
calculator’s functions are responsible for clearing its memory contents and
correcting its most recent entry. The calculator interprets the each entry
as either an operator or with the press of the ENTER key as a value to be
held in the 4-level stack register.
Illegal operations and operators including characters, leading zeros and

other anomalies are considered as erroneous entries and discarded. As a
result of the operations performed, if the answer is smaller than the
display segment (too many leading zeros) or if the answer is bigger than
the display segment the result is considered either as an underflow or an
overflow condition, and the display defaults to an out of range value. For
this project these conditions are detected, and displayed on the Display
Driver as [-].
2.1 Design Approach

A finite state machine is used to model this system. Initially various
approaches were considered, and the team came up with the following
system design for the project. The top-down approach was taken to model
the different sub-systems. The main subsystems of this project are
detailed below.
The first RTL below is a description of the top level module, and shows the
Serial Receiver reading in the ps2_data, which is sent to the decoder
module to verify the scan codes generated. This is then sent to the RP
Engine, the output of which is sent to the four seven segment display
driver and the output of each display is refreshed at a rate set by the MUX.
The second RTL diagram describes the Reverse Polish Calculator Engine
showing the ALU, the Key Holding Register; FSM which gives the
parameters of (is operation).
Page 8 of 39
Following the top level design, each sub-system was considered in detail
to evaluate its requirements and constraints applying a bottom –up
approach at each subsequent level of design to meet the projects top level
requirements. Each module is then analysed through a dedicated test
bench, and the problems confronted at each level are discussed along with
the solution that the team came up with.
2.2 Equipment Utilised

Xilinx ISE Webpack 9.2i installed on the Lab computers was used to design
and simulate the modules to generate a working code. This code was
transferred over to the Xilinx Spartan 2 XC2S50 – PQ 208 Pegasus Board
from Digilent Technologies, Inc using a JTAG connection between the
console and the board. The code was also tested on the Xilinx Spartan 3E
-100 TQ 144, Basys Board. Input is transmitted to the board using an AT-
Keyboard with a PS/2 connector.
Page 9 of 39
2.3 Verilog Coding Style
Verilog coding followed in this project is aligned to that laid out in the
course textbook, Wakerly and to that of the Lecture Slides. The code is
broken down into modules as described above, and each module updates
at the active or falling edge of the clock, depending on whether data is
being written to the board or read from it. All the modules are synchronous
modules and are divided into atleast two blocks, following FSM coding
style. The first block is a sequential block that updates state values and
the outputs, and the second block is a combinational logic block, that
performs actions whenever the state variable is updated.
This coding aids in removing unnecessary glitches in the code and allows
each module to be debugged independently without worrying about
asynchronous updates from any of the previous blocks.
2.4 Design Trade-Offs

Speed, accuracy, memory constraints of the system had to be considered
when designing the RP Calculator. The memory was the most design
parameter, with a 50K-gate the Pegasus Board has limited amount of
space available for design. Complying with synchronized coding styles for
the report all outputs from the modules are updated at the active edge of
the clock. This style of coding is limits the speed at which the output is
generated, as the output value of each of the top level modules need to
wait for the inputs to get updated at the active clock edge. Accuracy level
of the results produced by the calculator is already set by the report
guidelines to four significant digits. Hence the programmed code needs to
be efficient in space utilisation, with each module updating at the rising or
falling clock edge. The final output design traded speed for clearer coding
practices.
2.5 Team Work Distribution

The work of the team was distributed evenly between the two project
partners. The project could not start out at the date the project guidelines
were set up, due to the unfortunate and unforseen quitting of one of the
project partners halfway through the course, throwing the entire project
onto a single person. The team then formed comprising of Vasanta and
Nan and the work flow was re-organised.
Vasanta was in charge of the top-level design of the FSM, display and
stack. Nan took over designing the keyboard interface and the addition
and subtraction modules. Both the team members designed the Arithmetic
and Logic Unit, and designed Level 2 implementation of the calculator.
Both the team members contributed to the report.
Page 10 of 39
3 KEYBOARD INTERFACE
The keyboard used for this project is the IBM PS/2 Keyboard developed in
1987. [1] This keyboard has 101 keys with a 6-pin mini-DIN connector.
The keyboard has bi-directional serial protocol including 17 host-to-
keyboard commands. The PS/2 interface is a bit serial interface with two
signals Data and Clock. Both signals are bi-directional and logic 1 is
electrically represented by 5 V and logic 0 is represented by 0 V (digital
ground). Whenever the Data and Clock lines are not used, i.e. when they
are idle, these lines are left floating, and both the host and device outputs
are set to a high impedance value. On the PCB, this is achieved with
resistors exceeding 5kΩ, used to pull the output high (HI).
The FPGA Pegasus/keyboard interface is shown in the figure below. When

the FPGA reads in Data or Clock inputs both PS2Data_out and PS2Clk_out
are kept low which puts the tri-state buffers in high impedance mode.
When the FPGA sends data out, the PS2Data and PS2Clk are set to logic
high.
Figure 3: FPGA/Keyboard Interface
3.1 The Keyboard’s Connector
Page 11 of 39
The PC's AT Keyboard is connected to all external equipment using four
wires. These wires are shown below for the 5 Pin DIN Male Plug & PS/2
Plug. For this project, the PS/2 pin connector is used, which allows
bidirectional communication between the host (Pegasus Board) and the
Keyboard Input.
Both the KBD Clock and KBD Data are Open Collector bi-directional I/O
Lines. While most of the data communication is directed from the
keyboard to the output, if desired, the Host can talk to the keyboard using
these lines.
3.2 Receiving Data

Data is received from the keyboard as illustrated in Figure below. A
transfer may be initiated by the keyboard if the Clock line is high. The host
(Pegasus Board in this case) may force the Clock low in order to prevent
the keyboard from sending data – the host may inhibit communication.
The PS2 clock used for communicating with the host is generated by the
keyboard. Data is valid at least 5 us (t in figure) before the falling edge of
the clock. The clock period is (T in figure) is 60 to 100 us.
Data from the keyboard comprises of 11bits for each

packet. This is sent from the keyboard serially bit by
bit. The first bit is always a start bit, logic 0. The
following 8 bits represent the scan code of the
corresponding key.
Figure: PS/2 timing
Figure: PS/2 Protocol
Page 12 of 39
The scan code is always sent with the least significant bit first. The data is
padded with an odd parity bit used for error detection. If the number of
logic 1’s in the scan code and the odd parity add up to an odd number,
then the scan code is considered to be sent without errors. When the 8 bits
of the scan code and the odd parity bit are sent, the data line is pulled with
a stop bit of logic 1 signaling the end of the data stream.
3.3 The Keyboard scan-codes

The keyboard sends scan codes to the host indicating which key has been
pressed. When a key is pressed or held down, one byte code-word is
transmitted. When the key is released a break code is transmitted. Every
key is assigned a unique code followed by a break code, indicating to the
host the duration and number of each key press.
The scan codes conveys to the Keyboard Bios, which keys have been
pressed or released. Take for example the '1' Key on the number pad. The
‘1' key sends a scan code of 69 (hex) down the serial line. If the key is held
for longer than a set delay known as the Typematic delay, the scan code is
resent. Once the key is released, the keyboard sends another scan code
(F0) to indicate the end of that key. Thus for each key pressed, the
keyboard sends in hexadecimal, the scan code, the break code followed by
the scan code again.
A handful of extended keys are represented with two hexadecimal scan
codes, and are identified by the starting ‘E’ of their hexadecimal value.
These keys will not be used in this project.
The project requires the numeric keys and the corresponding basic
operations set. These are assigned as shown in the table below. Aside
from this set, the enter key and two additional keys are chosen for their
scan code values and are assigned to clear the stack (CLR) and clear the
Key Holding Register (CLX).
SCAN CODE
KEY OPERATION
(HEX)
0 0 70
1 1 69
2 2 72
3 3 7A
4 4 6B
5 5 73
6 6 74
7 7 6C
8 8 75
9 9 7D
DECIMAL
. 71
POINT
+ ADD 79
- SUBTRACT 7B
* MULTIPLY 7C
Page 13 of 39
\ DIVIDE 5D
Backspa
CLEAR 66
ce
ESC CLX 76
3.4 Keyboard Implementation

The keyboard interface was designed using the code designed in the
hardware labs. The following shows the block diagram of the keyboard.
The keyboard is given the input of the
3.4.1 Finite State Machine of the keyboard
When keyboard sends signals to the receivers, there are 11 bits of binary
numbers that contained in each period. The first bit is the “start-checking
bit”. If it is “0”, the other bits that after the start-checking bit will be
continuously sent. The next 8 bits are the “scan code” of any signal button
on the ps/2 keyboard. A 1 bit parity checking code will follow the scan
code to send. The last bit is an “ending code”, whose value is usually 0,
standing for “one sending signal period is end”. As the cycle next-state
diagram shows, once the starting bit is confirmed, the rest 10 bits binary
numbers will be sent incessantly, until another start-checking bit with a
value of “1” is reached.
Scan codes transitions from one scancode to the next at a rate

synchronised to the ps2_clk which is usually set to 10 KHz. This clock
output can be skewed by the FPGA clock that runs at a speed 10 times
that of the PS2 Keyboard Clock. To limit the slew of the PS2 clock, a
Page 14 of 39
synchronised clock is used to transition between the high and low values
of the PS2 clock at the active edge of the FPGA clock.
3.5 Switch De-bouncing

Bouncing is a phenomenon that occurs when the the physical press of the
key against its mechanical spring results in the key ‘bouncing’ for a certain
period before it settles. This is usually a very negligible amount on present
day keyboards, however on the old AT keyboards this value can be more
pronounced. Bounce in the switch can cause the data to distort or be
incorrectly read. This can occur if the key’s mechanical spring is loose
enough to cause it for every press, or if the key is pressed repeatedly at a
rate faster than the settling time of the key.
The scan codes one byte of data, is composed of random number of ones
and zeros. The amount of time taken for the scan code to register all the
bits sent in by the ps2_data serial line is limited only by the synchronised
clock. When the scan code transitions to a new scan code, a sharp one can
be neglected and the output would result in a very different scan code.
This transition period is of the order of a few nano – micro seconds and is
too small to to offset the input. [4]
During testing, the keys produced correct output when the keys were
pressed at the rate of 4 keypresses-per-seconds. Bouncing can be tackled
both in hardware and software. Correcting the error is simpler using
software. As such the simplest way to deal with bouncing would be to write
a delay code before which the key is processed, ignoring values during
which the key settles. Since Verilog is a HDL language, a hardware circuit
could also be described like the SR-Latch presented in [4] to deal with
bouncing switches. Another de-bounce logic involves, applying an
exclusive OR to all the bits of the one byte scancode. Transitions from
zero to one are then only recorded when the switch is properly de-
bounced.
Since this was not an issue on our board, we decided not to implement a
de-bouncing code to accommodate the memory constraints imposed by
the Pegasus Board.
4. CONTROLLER
The representation of the input decides the coding style and the approach
used to build the not only the ALU, but also the decoding involved when
interfacing with the display driver.
The keyboard output is a five bit digit that stores the state of the scanned
key. Valid inputs include numbers, operators and the CLX, CLEAR and
ENTER keys. This output is decoded by the controller and valid input codes
are sent from the Key Holding Register and the Stack.
Page 15 of 39
The five bit hexadecimal code for each valid input is that comes from the
scancode and decoder module is shifted into a 16 bit register number by
number. The stack value of this implementation would result in:
2:  0010
1: 0001 0010
3: 0011 0001 0010
7: 0111 0011 0001 0010
While this representation in binary would translate to 29458, this value in

Binary Coded Decimal translates to 7312. Representing the input as a BCD
code word simplifies the operations performed within the ALU and the
shortens the case statements necessary to drive the display.
Using this representation of numbers, each number need only be

represented by four bits including all the digits from 09 {0000  1001}
and the values from 1010 through to 1111 are unused. While this
technique does result in a certain amount of memory wastage, the
resulting code is simpler and much more efficient. Take converting 127 10
into binary and BCD as a simple example. In binary, this number evaluates
to:
12710 = 26 + 25 + 24 + 23 + 22 + 21 + 20 = 11111112. While In BCD each
digit has four bits of encoding and translates to:
110 = 00012, 210 = 00102 and 710 = 01112 ≡ 0001 0010 0111BCD.
In the controller, the only state that can start to read code is the “Idle”
state; therefore, every time when the input data is fully read into
controller, the next state should always become idle in order to keep
getting new inputs. The next state table is shown below:
Page 16 of 39
Page 17 of 39
Current Next State

State Input
Numbe Operat ENTER CLX CLR CHS
r or
Idle NUM CAL ENTER CLX CLR CHS
NUM Idle Idle Idle Idle Idle Idle
CAL Idle Idle Idle Idle Idle Idle
ENTER Idle Idle Idle Idle Idle Idle
CLX Idle Idle Idle Idle Idle Idle
CLR Idle Idle Idle Idle Idle Idle
Current next pushPo K_stac

BCD isOp
State state pS k
5'h0
Idle NUM 2'b00 2'bxx 2'b10
0
5'h0
1
5'h0
2
5'h0
3
5'h0
4
5'h0
5
5'h0
6
5'h0
7
5'h0
8
5'h0
9
5'h0
Idle ENTER 2'b01 2'bxx 2'b01
A
5'h1
Idle CAL 2'b00 2'bxx 2'b00
A
5'h0
Idle CLX 2'b00 2'bxx 2'b00
B
5'h1
Idle CLR 2'b11 2'bxx 2'b00
B
5'h0
Idle CAL 2'b10 2'b00 2'b11
C
5'h1
Idle CAL 2'b10 2'b01 2'b11
C
Page 18 of 39
5 ARITHEMATIC & LOGIC UNIT (ALU)

The Arithmetic and Logic Unit (ALU) is the central part of the project and
all the arithmetic and logical operations are performed in here. The ALU is
implemented as a combinational circuit that performs micro-operations on
the BCD operands from the Stack and KHR. The operations performed by
the ALU are determined by the controller, and the Change Sign Logic
Control implemented within the ALU.
5.1 ALU Input

The ALU input comes in from the Stack Module which stores the four levels
of stacks, and the Key Holding register. This input is sent to the ALU, which
then performs calculations on each digit of the BCD code word. When
performing calculations it is possible for the resulting number to have a
value larger than 9, say 11. This in binary is represented as 1011, however
this is not a valid BCD output. To convert the output into a valid BCD code-
word, a ‘carry-out’ is performed, wherein 10 is subtracted from the digit at
hand, and a carry value of one is then parsed to the next digit in the code
word. This process is described in the table below.
SUM S ≡ {4’b Carry Correction

BCD1 , BCD2}
0 ≤ S≤9 N N
10 ≤ S ≤ 15 Y (implement Correction) Y, add 6
16 ≤ S ≤ 18 Y(implement Correction Y, add 6
again)
5.2 Addition
Addition in the ALU was initially performed in the control module using
binary input. Each updated binary value added onto its previous value.
This approach suffered severe drawbacks as it could not cope with
overflow, in that it was not distinguishable from two’s compliment. Since
binary addition did not seem very feasible, the team switched over to
Binary Coded Decimal [BCD] addition.
To implement this, the team developed a full adder module from two half
adder blocks and passed four bit BCD value to the full adder. The full
adder calculation returned at most a 5 bit output. This output was very
often out of range, and the adder module was then redefined, to
accommodate four temporary variables that added each digit in parallel.
Each digit was then adjusted, and the carry over from each digit added on
to the subsequent BCD value.
The four bit full adder is then designed along the following schematic.
Page 19 of 39
Figure 1 Half Adder & Full Adder

In the schematic, a half adder takes in two BCD values and produces the
sum of these values along with a Carry-Out Value. Combining the two half
adders to store the carry in and carry out values produce the full adder
sum of the inputs A and B.
Using the full adder, addition of two four bit BCD numbers, results in a five
bit BCD output. Thus similar signed inputs would result in an overflow
condition. The overflow (fifth) bit is discarded if the number exceeds four
significant decimal places.
Once implemented, the full adder code, took the same time to implement
as the inbuilt addition (+) and subtraction (-) operators for bit vectors in
Verilog. The full adder code needs to be instantiated every time the adder
is called for the 4 BCD values, in addition to being called to add the carry-
in values. In contrast, the in-built Verilog (+) and (-) operators are
synthesized by the compiler to just one adder and and it then uses a
multiplexer to selects its inputs.
Addition is performed by aligning inputs along the decimal point, and

adding each column of input. When BCD addition is performed this way,
the resultant value of two four bit binary numbers can result in a value
greater than {1001} BCD representation of decimal number 9. When this
occurs, the binary number is no longer a valid BCD code. To display the
correct output a simple correction algorithm detailed in the following table
is implemented.
Operation Term 1 [BCD] Term 2 [BCD] Result

Binary Input 0000 0000 10110
If input ≥ 10,
subtract 10, and +0000 +10110
store it in term 2 +0001 −01010 0001 1100
and incr. term 1 +0001 +01100
by one.
Term 2 is still ≥
10, subtract 10, +0001 +01100
and store it in +0001 −01010 0010 0010
term 2 and incr. +0010 +00010
term 1 by one.
Term 2 is <10, & 0010 0010 0010 0010
Page 20 of 39
Term 1 is <10.
The BCD output
is generated.
Decimal Code
2 2 22
Word
As an example, the addition between 10012 and 10002 can lead to an

overflow case and give the wrong output value. Again, if we follow the
basic binary addition algorithm, the answer will be 100012. The value of
100012 is 17, which is the correct answer to the addition 9 + 8, and is
segregated according to the table presented above.
However, if the addition of the two numbers has a precision greater than
four decimal places, the output is not displayed, and the overflow
condition is triggered. Error-handling code within the module displays the
overflow as a ‘[-]’.
5.2 Subtraction
Subtraction leads numbers of transitions between the input digits and their
two’s complement in binary and 10’s complement. Again, same as the
addition, for convenience, the pre-programmed symbol “−” is used in this
project, and BCD is used to represent the input output numbers in the
calculator.
The subtraction has the same invalid output error as addition, but the
algorithm involved is slightly different from that of the addition. No
overflow errors are detected in the subtraction module simply because
only the absolute values are sent to the subtraction module. The change
sign logic implemented for all four operations are detailed in section 5.5.
To avoid the invalid output error, the following simple steps will be
undertaken. Starting from the rightmost 4-bit binary code, each BCD value
of the first input is subtracted from its counterpart and stored in four
temporary variables. If the result is less than 00002 or greater than or
equal to 10012, the first value will have to borrow ‘1’ from the next digit
and the add 10102, (10) to the 4 bit binary result in the second digit. This
process ripples through to the fourth BCD. If the fourth digit is found
lacking in carry-in value, a Change Sign is appended to the resulting
output and sent to the Key Holding Register.
This concludes LEVEL 1 implementation for the RPN calculator. The

addition and subtraction modules have been rigorously tested using test
benches developed in Xilinx and the output thus generated is shown in
Section 9. All the output values were accounted for, and both overflow and
negative sign conditions tested.
5.3 Operation Choice and Sign Decision
Page 21 of 39
Operation choice, based on the two inputs to the ALU and its Change Sign
Value are described. Since the multiplication and division modules sign
logic is not that different, their values are also included. Inputs to the ALU
upon which the above operations are performed fall into the following
categories:
 Input 1 = Positive; Input 2 = Positive
 Input 1 = Positive; Input 2 = Negative
 Input 1 = Negative; Input 2 = Positive
 Input 1 = Negative; Input 2 = Negative
When calculating, addition of numbers with opposite signs (negative and

positive) is treated as a subtraction, while subtraction of like signs is
treated as an addition.
In this project, due to the 4 7-segments limitation, the largest acceptable

input to the calculator will be four digits, which translates to 16 bits of BCD
code. To make the inputs more convenient to use, we add a 17 th bit for
each of the input to define whether it is a positive number (if the extra bit
is 0) or a negative number (if the extra bit is 1).
The output sign of multiplication and division is fairly straightforward. If

the two inputs have same sign, the output will be positive, and if the two
inputs have opposing signs, the output will be negative. The output sign of
addition and subtraction is also obvious, the same as the input which has a
greater absolute value.
In summary, the following table has been derived with all possible cases of
operators and operands. The calculation to be performed and its
interpretation are also specified.
Input 1 Input 2 Input Operation Output

operator Performed
Positive Positive + + Positive
Positive Negative + − Follow the
larger
number’s
Negative Positive + − Follow the
larger
number’s
Negative Negative + + Negative
Positive Positive − − Follow the
larger
number’s
Positive Negative − + Positive
Negative Positive − + Negative
Negative Negative − − Follow the
larger
number’s
Positive Positive * * Positive
Page 22 of 39
Positive Negative * * Negative
Negative Positive * * Negative
Negative Negative * * Positive
Positive Positive / / Positive
Positive Negative / / Negative
Negative Positive / / Negative
Negative Negative / / Positive
5.4 Multiplication
Level 2 of the project requires signed multiplication and division to be
performed on fixed point decimal numbers. The team developed the logic
for multiplication as well as division, however was only able to implement
the multiplication module on the FPGA.
The BCD multiplication requires the use of binary multiplication as basic

operation. The algorithm of multiplying two binary numbers is shown
below:
Figure 1 Binary Multiplication [5]
First the partial product for each digit is worked out. Because each nibble
is a binary code word, partial products are calculated for each digit of the
two terms in parallel. From the above figure, the pipelined partial products
are calculated as {B0A0, AOB1-A1BO, A2B1 - A1B1 ….and so on}. These
partial products are combined taking care of the carry-ins involved. The
multiplicand of each combinational term of multiplier is checked for its
product and 6 is recursively added to the result, if the number exceeds the
maximum BCD word - 1001.
Page 23 of 39
Figure 2 Multiplication Block Diagram
This is a form of carry and save addition is used to speed up the

processing of the multiplication of the ALU. For an n digit multiplication the
code requires (2*n-1) BCD multiplications and (n-1) BCD additions. Each of
the (2*n -1) multiplications that produce partial terms, recursively add
using a full adder described in section 5.1.
For the multiplication coding, four temporary parameters are used to store
the multiplications of individual digits. Following this the code dealt with
numbers was more complicated than addition. Addition would only occur
carry out with value of 1, while in multiplication, the carry out was varying
from 1 to 8 (i.e. 9 * 9 = 81, carry out = 8).
There were two methods to find out the carry out. First one was to create a
loop. If the temp value was greater than 9, it was then subtracted by 1. By
recursively checking the temp value and taking “1” each time from, the
carry out value could be found as the times of repeating the procedures.
The output values generated for multiplication are shown in the test bench
developed for the ALU, all the output values were accounted for, and the
overflow conditions tested.
Page 24 of 39
Page 25 of 39
7. STACK & KEY HOLDING REGISTER IMPLEMENTATION

The stack implemented in the project has a depth of four and is used to
store all the numbers entered from the keyboard followed by an ENTER
key (refer table in INTRO). The stack is implemented as a four stage shift
register. The stack can be cleared of all its contents using the CLEAR
command.
Each level of the stack can accommodate a four digit BCD value, and
hence functions as a 16bit shift register. The stack gets updated either
with a ‘push’ or ‘pop’ command. The ‘push’ command, pushes all the
values of the stack by one level, while a ‘pop’ raises the the stack and the
outermost value of the stack is discarded. A CLEAR command clears the
entire stack of its values.
The stack has four modes of operation, selected from a 2-bit input. At each
clock cycle the stack will function in one of
these modes. The stack is very similar to a
bidirectional shift register, and one level
stack output is as shown in the figure.
This is executed in the stack module as follows:
The Key Holding Register updates similarly, The stack updates when the
variable strobing its output to push or pop is called. A push value, pushes
each stack value a level lower and a ‘pop’ command
Page 26 of 39
8. DISPLAY
The display utilizes the four seven-segment displays on the output, and
assigns each value of the 15 bit register to the output. The working of the
seven segment display is shown below:
From [3]
Since each of the seven-segment displays shares the same cathode
values, assigning the cathode values to each of the four seven segment
displays, shows the same digit on all four displays. From the figure above
obtained from the Pegasus manual, we find that each display is assigned
an anode {a1, a2, a3 & a4}. Thus to show different digits on each of these
outputs, the anode values are toggled, displaying one digit at a time. If
this switching is done at the right speed, it is imperceptible to the human
eye, and each digit appears distinct. To accomplish this, a switcher is used
to take in the BCD input and pass just one digit and the corresponding
anode value, to be displayed.
The anode values toggle at a rate faster than the flicker rate that the
human eye can perceive in order for the display to show two different
digits simultaneously. This is achieved by using a refresh rate of 50Hz the
same frequency that drives the Pegasus FPGA.
8.1 Display Driver

The display driver used to light up the seven segments is shown below:
Page 27 of 39
The seven segment display driver has a multiplexer that chooses the bits
that get updated, and converts the 16 bit register into a four bit BCD
value.
The SSD or the Seven Segment Display block then converts the BCD
value into its corresponding seven segment value. The Modulo State
Machine slows down the Clock timer to 50 Hz, and sends the clock input
along with the corresponding BCD digit to be displayed to the 2:4
Decoder. The 2:4 Decoder employs a 2 bit delay value that toggles
constantly between four states. Depending on the delay state four bits are
assigned to the anode of the display driver.
Page 28 of 39
9 SIMULATION RESULTS
9.1 Simulation Test Bench: KEYBOARD

The Verilog code for this module was simulated in ISE using a test bench.
The Verilog test module simulates an 11 bit code word for each key
pressed. Each key press is detected at the falling edge of the clock. Once
the key press is detected, the keyboard interface cycles through the states
in its finite state machine from {s0 – ss}. The state is synchronously
updated also at the falling edge of the clock and each bit of the 8-bit
scancode is updated sequentially as shown above.
The simulation test bench was quite tricky to implement as the output
from the scancode gets updated at different values, and takes an arbitrary
time to do so. Also all the ps2_values had to be synchronised almost
exactly to the clock input and were sent in reverse to simulate actual data.
The first arrow in the simulation figure 1 shows the hexadecimal scancode
for the number 1- h’69. This scancode value can be seen to be updated at
the falling edge of the clock, and the corresponding number value is stored
in digit. The following scancode h’F0 is the ‘key released’ scancode, and
once this scancode is detected, the value of digit, is updated to ‘out’ which
stores the output BCD value.
Page 29 of 39
9.2 Simulation Test Bench: FSM CONTROL
The next state logic toggles between the states given as input (number,
operator, function) and the idle state. Every time the BCD value gets
updated, so does the output as shown by the arrows.
Page 30 of 39
The output logic of the pushPop stack and the K_stack values only get
updated at the press of the ENTER key denoted by the 5’h0A key press as
shown above
9.3 Simulation Test Bench: ALU
9.3.1 Simulation of addition

The figure demonstrates the theoretical results of different combinations
of input numbers. For the operator depicted by the first arrow, the input
operator was stays at “+” (2’b00) during the simulation. The first
calculation was “(−5) + 2”. In our project, when a negative input, a
positive input and a “+” operator are detected by ALU, the actual
operation performed is subtraction.
Therefore, the enable_add is set to 0 and the enable_sub set to 1 (shown

by the second arrow). The following four calculations are tested “2 + 5 =
7”, which tests positive numbers addition; “1234 + 9876 = 0B110,
alu_overflow = 1”, which tests for positive number addition overflows;
“(−5) + (−2) = (−7)”, which tests the addition of two negative numbers;
and finally the “(−1234) + (−9876) = (−B110), alu_overflow = 1” which
tests negative number overflows. All the results were sent to alu_out at the
positive edge of the clock.
9.3.2 Simulation of subtraction

Subtraction is performed on the following inputs “(−5) − (−2) = −3”, “2 −
(−5) = 7”, and “1234 − 9876 = −8642” testing the cases of negative,
opposing polarities and positive number subtractions respectively. In this
project, if subtraction needs to be performed on two numbers with
different polarities the performed operation is an “addition”.
Page 31 of 39
These results are reflected in the test bench shown above. Again, the
results are updates at the positive edge of the clock.
9.3.3 Simulation of multiplication
The multiplications between two positive numbers, two negative numbers

and two opposite sign numbers are tested as “2 * 3 = 6”, “(−5) *(−15) =
75” and “(−15) * 15 = −225”. Once the multiplication trigged (where the
first arrow pointed), the tests were operated continuously. A four digit
number multiplication “1234 * 5 = 6170” and an overflow case “1234 * 15
= 8510, alu_out = 1” were then tested to see whether the higher level
registers work. Again, the results were sent to alu_out at the positive edge
of clock as shown in the figure below.
9.4 Simulation Test Bench: KEY HOLDING REGISTER

The key holding register updates the value at the change of input, retains
the same value when the enter key is pressed, and clears its value when
CLX function is used.
Page 32 of 39
9.6 Simulation Test Bench: DISPLAY DRIVER

The display driver has a constant refresh rate, and the simulation results
are best shown with a working example of the code. As can be seen from
the figure, the digits display distinct numbers and the display driver
refreshes at the rate of an assigned ‘slow clock’ value.
Page 33 of 39
10. PEGASUS BOARD IMPLEMENTATION
10.1 FPGA Resource Consumption

10.1.1 Level1
The number of slices used to generate level 1 is 49% of the total slices.
This resource utilisation of the Slice Flip Flops and bonded IOBs is low
compared to that of the Level 2 utilization.
Logic Utilisation Used Availabl Utilisatio

e n
Number of Slices 196 768 49%
Number of Slice Flip Flops 120 1536 8%
Number of 4 Unit Look Up 455 1536 29%

Tables (LUTs)
Number of bonded IOBs 10 140 7%
Number of GCLKs 2 4 50%
10.1.2 Level 2
The resource utilisation for level 2 is fairly intensive due to the
multiplication algorithm. This can be seen in the large number of slices
utilised and the number of slice flip flops.
Logic Utilisation Used Availabl Utilisatio

e n
Number of Slices 494 768 64%
Number of Slice Flip Flops 270 1536 17%
Number of 4 Unit Look Up 894 1536 58%

Tables (LUTs)
Number of bonded IOBs 16 140 11%
Number of GCLKs 2 4 50%
The following table shows the advanced resource consumption of the

module. The module shows an exceptionally high number of latches,
however these latches are resolved when the generate programming file is
implemented. This could be because the values parsed from the keyboard
are not set until the bit file is generated.
10.2 Warnings
When the Top Level Module is synthesized and Implemented Xilinx

generates warnings as cautionary comments on the use of always blocks
and sensitivity parameters. The use_dsp48 constraint allows the
specification of technology resource for macro implementation.
WARNING:Xst:905 - "../TopLevel.v" line 36: The signals <KHR> are missing in

the sensitivity list of always block. Module <Toplevel> is correct for synthesis.
WARNING:Xst:905 - "../serial_rcvrWorking.v" line 148: The signals <ps2_data,

next_scancode, scancode, read, digit> are missing in the sensitivity list of
always block. Module <serial_rcvr2> is correct for synthesis.
WARNING:Xst:905 - "../decoder1.v" line 40: The signals <rcvr_out> are missing

in the sensitivity list of always block. Module <decoder1> is correct for
synthesis.
WARNING:Xst:905 - "../fsm3.v" line 81: The signals <pre, BCD> are missing in
the sensitivity list of always block. Module <fsm3> is correct for synthesis.
WARNING:Xst:905 - "../mux_dis2.v" line 53: The signals <in1, in2, in3, in4> are
missing in the sensitivity list of always block.
Page 35 of 39
Module <mux_Display2> is correct for synthesis.
WARNING:Xst:2734 - Property "use_dsp48" is not applicable for this technology
10.3 FPGA Speed

The speed or the maximum frequency of a digital system is largely
determined by the system delay. System delay is influenced by several
factors other than the circuit logic alone: The propagation delay due to the
internal structure of the gates, the loading of the output buffers (assigning
net delays) and the circuit logic.
Propagation delay is the time difference between the issue of an input and
the reflection of that input value in an output signal. These delays are a
product of the physical gates in the system and the time it takes for them
to respond to an output. These delays can be caused due to parasitic
capacitances inside the gates, speed of light limitations of the circuit, and
net delays (caused by wiring between the gates on the board).
The delay of the circuit can be measured using the Post Place and Route
Simulation. This simulation helps determine the delay of the internal nodes
of the circuit and a Critical Path can be determined from the timing
diagram to show the path that limits the circuit speed.
11. CONCLUSION
The reverse polish calculator was developed and implemented as shown in
the report. The report showed the fsm coding style taught in the course
and emphasized on the need for efficient design. With more time, more
operators can be implemented and a floating point digit added.
Page 36 of 39
REFERENCES
1. http://www.computer-engineering.org/ps2keyboard/
2. Digilent Basys Board Reference Manual. Xilinx Spartan 3E -100 TQ
144.
3. Digilent Pegasus Board Reference Manual. Xilinx Spartan 2 XC2S50 –
PQ 208
4. http://research.microsoft.com/enus/um/people/gbell/designing_comp
uters_and_digital _systems/00000194.htm
5. http://www.willamette.edu/~fruehr/cs130/lab2.html
6. http://www.vocw.edu.vn/content/m10781/latest/
7. http://www.eportfolio.lagcc.cuny.edu/scholars/doc_sp07/eP_sp07/suo
ng.nguyen/CIS295.html
8. Digital Design, Principles and Practices. Fourth Edition. John F
Wakerly
Page 37 of 39
APPENDIX
Flow Chart describing the working of a reverse polish notation:
Start
Read Input
Data
ENT YES
ER Store in
KEY Stack
POP
Pop Stack,
Operate on
OPE YES the number
RAT and KHR, store
OR in KHR
NUM
ERIC YES Store in
DAT KHR
A
Page 38 of 39
Flow Chart describing the working of the Keyboard:
Page 39 of 39

Final Project

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final Project

Uploaded by

Copyright:

Available Formats

ENGN 3213

REVERSE POLISH CALCULATOR

1.1 Reverse Polish Notation

A simple example below demonstrates the working of an RPN Calculator,

Illegal operations and operators including characters, leading zeros and

2.1 Design Approach

2.2 Equipment Utilised

2.4 Design Trade-Offs

2.5 Team Work Distribution

The FPGA Pegasus/keyboard interface is shown in the figure below. When

Figure 3: FPGA/Keyboard Interface

3.1 The Keyboard’s Connector

3.2 Receiving Data

Data from the keyboard comprises of 11bits for each

Figure: PS/2 timing

Figure: PS/2 Protocol

3.3 The Keyboard scan-codes

3.4 Keyboard Implementation

Scan codes transitions from one scancode to the next at a rate

3.5 Switch De-bouncing

While this representation in binary would translate to 29458, this value in

Using this representation of numbers, each number need only be

Current Next State

Current next pushPo K_stac

5 ARITHEMATIC & LOGIC UNIT (ALU)

5.1 ALU Input

SUM S ≡ {4’b Carry Correction

Figure 1 Half Adder & Full Adder

Addition is performed by aligning inputs along the decimal point, and

Operation Term 1 [BCD] Term 2 [BCD] Result

As an example, the addition between 10012 and 10002 can lead to an

This concludes LEVEL 1 implementation for the RPN calculator. The

5.3 Operation Choice and Sign Decision

When calculating, addition of numbers with opposite signs (negative and

In this project, due to the 4 7-segments limitation, the largest acceptable

The output sign of multiplication and division is fairly straightforward. If

Input 1 Input 2 Input Operation Output

The BCD multiplication requires the use of binary multiplication as basic

Figure 1 Binary Multiplication [5]

Figure 2 Multiplication Block Diagram

This is a form of carry and save addition is used to speed up the

7. STACK & KEY HOLDING REGISTER IMPLEMENTATION

This is executed in the stack module as follows:

8.1 Display Driver

9.1 Simulation Test Bench: KEYBOARD

9.2 Simulation Test Bench: FSM CONTROL

9.3 Simulation Test Bench: ALU

9.3.1 Simulation of addition

Therefore, the enable_add is set to 0 and the enable_sub set to 1 (shown

9.3.2 Simulation of subtraction

9.3.3 Simulation of multiplication

The multiplications between two positive numbers, two negative numbers

9.4 Simulation Test Bench: KEY HOLDING REGISTER

9.6 Simulation Test Bench: DISPLAY DRIVER

10.1 FPGA Resource Consumption

Logic Utilisation Used Availabl Utilisatio

Number of Slices 196 768 49%

Number of Slice Flip Flops 120 1536 8%

Number of 4 Unit Look Up 455 1536 29%

Number of bonded IOBs 10 140 7%

Number of GCLKs 2 4 50%

Logic Utilisation Used Availabl Utilisatio