University of Hull, Department of Engineering

Module 500659 – Electrical and Electronic Systems II

Digital Design Exercise – FPGA Implementation of a Matrix

Keyboard Encoder
I.M. Bell, 2021 v1

Contents
1 Introduction .................................................................................................................. 1
2 Background on Matrix Keyboard Encoders ................................................................... 1
3 Simulating the Keyboard Encoder ................................................................................. 2
4 Requirements for the Logic Primitives Version ............................................................. 2
5 Simulating the Primitives Version ................................................................................. 2
6 Requirements for the VHDL Version ............................................................................. 3
7 Simulating the VHD Version .......................................................................................... 4
8 Additional Points to Consider ........................................................................................ 4
9 Requirements for Signal Naming ................................................................................... 4
10 Approach to the Design Work ....................................................................................... 5
11 Software Tools and Tutorials ......................................................................................... 5
12 Guidance on Writing the Report ................................................................................... 6
13 Required Report Structure ............................................................................................ 7
14 Mark Scheme .............................................................................................................. 10

1 Introduction
You are required to design a fully digital, hardware-based keyboard encoder for a 16-key (4×4)
matrix keyboard. Your design is to be implemented using an FPGA and verified by simulation but
must be targeted at the specified development boards.
You will use two approaches to design development. First you are required to produce a
simple/minimal implementation using logic primitives (basic gates and flip flops). Secondly you are
to produce a (more) fully capable design using VHDL. Both designs are to be verified by simulation.
More detailed specifications and requirements are given later in this document.

2 Background on Matrix Keyboard Encoders

Background information on keyboard encoders, including outline circuit structures and operating
principles of typical matrix keyboard circuitry is provided in a separate document “Matrix Keyboard
Encoders – Background for the Digital Design Exercise”. It is strongly suggested that you read this
before reading the rest of this document as it will be easier to understand the detailed
requirements once you are familiar with the background.

1
3 Simulating the Keyboard Encoder
The matrix keyboard provides a challenge for simulating the keyboard encoder. The encoder will put
signals onto some wires of the keyboard matrix and receive input from others. When setting up a
simulation it may seem that should be possible to predict the response of the keyboard and
therefore manually setup the correct simulation input signals corresponding to the required key
presses. However, this approach is potentially flawed – if there are problems with driving signals due
to issues with the design the predicted signals will not match the actual behaviour of the circuit.
Furthermore, if the design involves feedback (the driving signals change in response to key presses)
trying to set up exactly the right simulation inputs may be difficult even for a functionally correct
design.
To overcome these issues a simulation model of the keyboard is provided for use in this exercise.
Full details are provided in the separate document “Simulating the Keyboard in the Keyboard
Encoder Design Exercise”. The keyboard model forms part of the VHDL test bench. The document
provides a walkthrough for using the keyboard model, and relevant code snippets are available for
download. The example will have to be adapted for your simulation, for example the timing and
sequence of keypresses in the example are unlikely to match what you require in your simulation.

4 Requirements for the Logic Primitives Version

The system is to be designed by you individually using primitive digital elements, that is, basic logic
gates (NAND, OR etc.) and flipflops (D-type etc.) entered as logic schematics. The schematics should
be arranged as a top level block diagram containing the main subsystems (scanner, decoder etc.)
shown as blocks, with the blocks implemented internally as gate/flipflop level schematics (further
layers of block hierarchy can be used if required). The only exceptions to the “primitives only” rule is
that you may use one or more on-chip Phase Locked Loops (PLLs) and/or a binary counter to create
clocks for your circuit. The counter, if used, may be an IP (Intellectual Property) block from Quartus
or taken from the example given in the software walkthrough.
The circuit itself must conform to the following requirements
1. Encode key presses on a standard 16-key, 4×4 matrix keypad by rows and detecting column
responses. The actively scanned row output must be at logic 1, and a logic 1 will be received
for a column when a key is pressed.
2. Provide a stable 4-bit binary output corresponding to the last key which was pressed. Each
key has a unique individual code which corresponds to a sensible numerical sequence on the
physical keyboard. The last key value remains on the output after the key has been released.
3. Have an output to indicate when a key is being pressed. When a new key is pressed this must
change to the active state after the key value output has updated.
4. The decoded output and key-pressed output must be constant between key press/release
events (e.g. not pulse with any scanning).
The system is expected to have one primary clock input (the 50 MHz FPGA clock input on the
development board) and possibly a master reset in addition to the I/O implied by the above
requirements.
The primitives-based design is not required to provide switch debounce and you can assume that only
key will be pressed at a time and that all keys will be released before the next key is pressed. These
assumptions are not realistic but will keep the design relatively simple. Do not attempt to design a
more sophisticated version for this part – the VHDL version will have an improved specification

5 Simulating the Primitives Version

You are required to perform simulations which clearly verify that you design conforms to all of the
above specifications. Your simulation should use the keyboard model provided.
2
Your VHDL test bench for the primitives version should contain two components; firstly your circuit,
which will have already been included (as i1) by the Quartus testbench writer; and secondly the
keyboard model. You will have to add the keyboard model as described in the “Simulating the
Keyboard in the Keyboard Encoder Design Exercise” document. The model is available for download,
as are the additional code snippets required.
Your testbench will also need to include modelling of the pull-down resistors connected to the
keyboard on the input side of your circuit (columns). Typically, these will be of the form
ColumnSensePD(1) <= '0' when ColumnSense(1) = 'Z' else ColumnSense(1);

although you may use different signal names. You will need to define an additional 4-bit signal for this.
Again this is detailed in the “Simulating the Keyboard in the Keyboard Encoder Design Exercise”
document.
As in the example, your testbench will need to include keypress signals, for which you will need a
signal definition, again as shown in the example. The keypresses simulated will need to be different
from those in the example – the timing of the example may be different, and you should only activate
one key at a time, whereas the example includes simultaneous keypresses.

6 Requirements for the VHDL Version

The system is to be designed individually by you using synthesisable behavioural VHDL code written
for set of separate, well-defined system building blocks (scanner, decoder, controller etc.) The code
is to be linked to a top-level block diagram of the system structure (further layers of block hierarchy
can be used if required). The only exception to the requirement that you code all the functionality in
VHDL directly is that you may use one or more on-chip Phase Locked Loops (PLLs) and/or a binary
counter to create clocks for your circuit. The counter, if used, may be an IP block from Quartus or
taken from the example given in the software walkthrough.
This version is to be created as a new project in the design tool, separate from the logic primitives
version.
This version must be designed to be implemented on the development board and additional hardware
(keyboard test box). It must therefore be compatible with that hardware. Details of operation of the
test box are provided in the document “Matrix Keyboard Encoder Test Unit User Guide”. An important
feature of external hardware, which you must take into account in your VHDL design and simulation,
is that the interface requires a logic 0 row drive (logic 0 for active drive of a row to 1, and logic 1 for
high impedance to keyboard).
The circuit itself must conform to the following requirements.
1. Encode key presses on a standard 16-key, 4×4 matrix keypad by scanning rows and detecting
column responses. The actively scanned row output must be at logic 1 on the physical
keyboard. However, the external interface circuit (tristate buffer) inverts the row signal, so
the output from the FPGA must be 0 for the active row, with other rows at 1.
2. Provide a stable 4-bit binary output corresponding to the last single key which was pressed
(also see requirements 7 and 8). Each key has a unique individual code which corresponds to
a sensible numerical sequence on the physical keyboard. The last key value remains on the
output after the key(s) has been released.
3. Have an output to indicate when a key is being pressed. When a new key is pressed this must
change to the active state after the key value output has updated.
4. The decoded output and key-pressed output must be constant between key press/release
(e.g. not pulse with an scanning).
5. The outputs must respond within 1 ms of a key press.

3
 6. The encoder must cope with key bounce of up to 10 ms without giving false outputs.
7. If one or more additional keys are pressed after the first key has been pressed, but while it is
still being held, then they are ignored, even if the first key is released before the others.
8. If one or more additional keys are pressed simultaneously (that is within a time shorter than
that in which the encoder can distinguish the order in which they were pressed) then a single
“key-pressed” indication should be given and the output code may relate to any of the keys
which have been pressed.
The system is expected to have one primary clock input (the 50 MHz FPGA clock input on the
development board) and possibly a master reset in addition to the I/O implied by the above
requirements.
Your design should comply with design guidelines provided by the FPGA manufacturer.

7 Simulating the VHD Version

You are required to perform simulations which clearly verify that you design conforms to all of the
above specifications. Your simulation should use the keyboard model provided, with the approach to
setting up the test bench being similar to that used for the primitives version.
In addition to the keyboard model, your simulation (testbench) needs to include the test box interface
hardware (tristate buffers and pull-down resistors). Full details of how to this are given in the
document “Matrix Keyboard Encoder Test Unit to DE0-Nano – SoC Interface User Manual”. In addition
to the four lines of code to model the pull-down resistors, as used in the primitives version, a further
four lines of testnech code, of the form
KeyRow(0) <= '1' when RowDrive(0) = '0' else 'Z';
are required to model the buffers.
Again the keypresses in the example may not match the requirements for you simulations.
For this version you need to consider more complex simulation scenarios than for the primitives
version. You need to simulate bouncing keys and system behaviour with multiple key presses (to prove
multi-key lock out). A potential difficulty is the large number of simulation cycles which may be
required for the debounce timer. A possible approach is to use a shorter debounce interval for (some)
simulation.

8 Additional Points to Consider

Think about the aim of the work as being to deliver a general-purpose IP block (Intellectual Property)
that is potentially useful in a wide range of designs (both in in industrial/machine and user interface
contexts). This means, reusability, configurability and flexibility are desirable properties.
The inputs and outputs should be designed with realistic usage in mind. Initially you will probably want
to test the system with the inputs and outputs (other than the quadrature signals) connected to LEDs
and switches. However, this is not a real usage scenario. In real use, your design is more likely to be
interfaced to a microprocessor (for example in a System on Chip FPGA design or as a separate chip
with standard interfacing, such as SPI) and you should take this into account, but you are not expected
to design the additional interfacing (SPI, AXI etc.)

9 Requirements for Signal Naming

You must name you quadrature signal inputs using your student number in the following way
S1_nnnnn and S2_nnnnn

4
Where nnnnn are the last five digits of your student number. For example, if your student number
was 201712345 you would name your signals
S1_12345 and S2_12345
All other significant blocks/subsystems must have at least one input or output “tagged” with your
student number in a similar way.
This is important – If you fail to follow this naming requirement in all relevant schematics, block
diagrams, code, and simulation waveform you will lose significant marks. This applies to both the
primitives and VHDL versions. Make sure that any code listings or screenshots you include have all
relevant signal names clearly visible and readable (e.g. not hidden or blurry).

10 Approach to the Design Work

You should develop your design in a methodical and well-structured manner aiming for a modular
design with functionally verified sub-systems.
If you are unable to implement all of the functionality detailed in Section 6 in time you should aim to
deliver a verified version of as much of the functionality as you can manage.

11 Software Tools and Tutorials

This software is available on CSE image university computers (including by remote access using
Horizon), but you may also want to use free versions of Quartus and Modelsim-Altera on your own
machines – it is strongly suggested that you use exactly the same version of the software as in the lab
(downloads of all versions are available from the Quartus website). Note that a free version of
Questasim is not available, but on the University machines it will provide much faster simulation (for
longer simulations). It is straightforward to switch which simulator is used by Quartus in its settings.
Students who completed module 400463 will be familiar with these tools through the “Quickstart
Guide to Using Intel/Altera Quartus II - Walkthrough 1” tutorial and the RGB LED Driver design study
assignment.
Students who completed module 500660 will be familiar with the use of Questasim/Modelsim-Altera
for VHDL code entry and simulation through the “VHDL Simulation Example using QuestaSim”
(QuickStartQuestaSim) tutorial class example, and any private coding practice from that module using
the examples from that module.
This work introduces the use of VHDL-based design within Quartus – a tutorial covering this is provided
the “Quickstart Guide to Using Intel/Altera Quartus II - Walkthrough 2”. This should be completed
before starting your own design work. Depending on your current confidence with basic use of these
tools (from the earlier modules) you may wish to first review the previous tutorials.
When developing VHDL code you may find that it faster to work just using Questasim/Modelsim-Altera
during initial coding and debug. The cycle of edit > compile > simulate tends to be much faster when
using just the simulator. Once the code is in a good state then it is easily added to/updated in a Quartus
project. Note that Questasim/Modelsim-Altera will simulate any valid VHDL, but Quartus requires the
code to be synthesisable. This means that some constructs cannot be used, for example using a “wait
for” statement to create a delay can be simulated but cannot be synthesised. When working with
Quartus code in the testbench does not have to be synthesisable as this is only used for simulation
purposes.

5
12 Guidance on Writing the Report
Marks will the strongly dependent on the degree to which you conform to these guidelines. That is,
even if you produced a good working design you will receive poor marks if it is poorly documented.
This work is not an experiment, it is a piece of design work. It must not be written up as if it were an
experiment. The purpose of the report should be to document the final, correct design and prove that
it meets the requirements specified.
You do not need to repeat large sections of the material from the background document “Matrix
Keyboard Encoders – Background for the Digital Design Exercise” as background in your report. You
can assume the reader of your report is familiar with this material. If necessary, you can specifically
reference this document in your report to support your discussion. If you use additional background
material from other sources this should be described in more detail and correctly referenced.
You can assume the reader of your report is familiar with, digital electronics, VHDL and the design
tools. Do not include basic background/theory material on these topics. Do not describe how to use
the design tools. This is already well documented. You can assume the reader of your report is familiar
with the design tools.
You should repeat the specifications from the sections 4 and 6 of this document, so that you report is
self-contained in terms of specification details. The specification numbers be used to identify
specifications where appropriate in your explanations and discussion. However, do not copy other
text from the handouts.
Report the final correct design as it is at the end of your development work. Do not describe early
versions or mistakes you made during development. Do not describe the development as a step-by-
step process. Your designs should be described with explicit reference to the requirements specified
in sections 4 and 6 – explain how your design achieves the requirements.
Provide top-down explanation of the operation of your designs with reference to block diagrams
before describing them in more detail. For this purpose, block diagrams should ideally be drawn in
simplified format which makes them clear (e.g. like figures 8 and 9 in the background document),
rather than using the top-level schematic from the design tool. However, you should also include the
top-level schematic. Explanations of circuit operation may also benefit from simplified waveform
diagrams (not simulation output) (e.g. figure 3 in the background document). You should highlight
features which relate to the specifications with explicit reference to the requirements. If your design
did not cover all requirements you should make it clear which requirements you have covered.
Your schematics and block diagrams should be placed in the main body of the report close to where
they are discussed in the text. Make sure that all labelling text on these diagrams (block and signal
names etc.) would be clearly and easily readable in a printed version of your report. That is, you should
screen-snip schematics etc. but make sure the zoom level used delivers an image with readable text.
You should include fragments of code in your report where these are required to assist your
description, but do not include every line in the main body of the report. All your code should be
available in appendices of your report and these should be referred to when the relevant part of the
design is discussed. Your code is expected to contain an appropriate level of comments. All code must
be presented in the report as text (not screenshots) a non-proportional font such as Courier New and
must be well laid-out in terms of indentation, line-spacing etc. It is suggested that you the
Programmer’s Notepad app which can export code as RFT with syntax colouring, which you can then
import into a Word document.
You report text must provide explanation and justification, not just description and figure references.
For example, it is not sufficient to simply state “figure x shows the schematic for y” without any
explanation of circuit y. Furthermore, do not just describe the structure or form of a circuit or

6
waveform – this is covered by the graphic. For example the following is very poor text to accompany
a schematic
“The circuit in figure x is some logic which uses an AND gate, two OR gates and an inverter
to convert from the 4-bits used by the keyboard to the 2-bits required for the output value.”
The following is much better because it explains exactly what the circuit is and why it is used, rather
than just describing the wiring or look of the schematic. There is an implication that the method used
(priority encoder) has already been justified in the top-level system overview. Also note the use of
references [] and the relating of the design to specific specification requirements.
“The row decoder has four row inputs (RI<4:1>), which will be active-1 during a keypress.
Its two outputs (RV<1:0>) contribute to the binary key value. As discussed in section v the
active row can be mapped to the upper two bits of the key value using a priority encoder.
The schematic, shown in figure w, is a widely available (e.g. [x] and [y]) implementation of
a 4-to-2 priority encoder. The circuit’s truth table is given in figure z [x]. It can be seen that
row-to-value encoding matches that in figure q and thus this circuit provides partial
implementation of specification requirement 2.”
Describe your verification strategy with explicit reference to the requirements specified in sections 4
and 6. Present simulation results which efficiently prove that the requirements are met. Highlight how
the results prove that you design has met the requirements specified in sections 4 and 6. Annotated
you waveforms (e.g. with arrows, circles etc. highlighting specific features) to make it as easy as
possible for the reader to assimilate the key results without wading through large amounts of detail.
Do not present large numbers of waveforms which do not add any useful additional insights. Include
waveforms in the main body of the report close to where they are discussed. If necessary, further, less
important, simulation results may be included in appendices.
Make sure that all text on simulation waveforms would be clearly and easily readable in a printed
version of your report. Make sure that all waveforms have timescales and signal names clearly visible.
Do include large areas of black space in your waveform screenshots. You may need to adjust the
window layout in the design tool prior to snipping the screen to achieve these requirements.
Your report must have a conclusion in which you summarise the work presented and discuss the
capabilities and performance of your design, indicating where there might be room for improvement
in future work. You should also reflect briefly on the differences between schematic-based and HDL-
based design. This, like the whole, report must be written in a formal and professional style. Do not
include direct descriptions of personal experience or reflections on your learning in this report.
All diagrams, simulation waveforms, code fragments etc. must be given figure numbers, explicitly
referred to by figure number and properly discussed in the text. Sections with section titles and
figures, but no body text are not acceptable. If you simply place a lot of waveforms etc. in the report
without referring to them or discussion them they may be discounted (not regarded as present in the
report).
All appendices containing code etc. must be referred to in the main body of the text when the relevant
section of the design is discussed.

13 Required Report Structure

The main body of the report should be structured as follows. Sensible variants of the structure, to
fit the work actually done, are acceptable, but poorly structured reports which clearly ignore these
guidelines are likely to receive poor marks.

7
1. Introduction Overview of the project with very brief introduction to
keyboard encoders but reference the handout rather
than repeating large chunks.
2. Specification Statement of specifications (copy specification from
handout, numbered for easy reference). Comment on
specifications if required (e.g. if any ambiguities were
resolved, or if it was decided not to implement particular
requirements prior to starting the design work).
2.1 Primitives Version Overview Top level description with reference to a simplified block
diagram (ideally not the top-level schematic) and also
simplified waveforms if needed. Explain system
operation and how the specification is achieved.
2.2 Primitives Version Detailed Design For each block
Present the schematic, define its inputs and outputs and
explain how it works, referencing the top-level
description where appropriate. Where appropriate,
explain how the design enables a particular specification
to be met. If appropriate provide design information
such as logic equations, truth tables, state diagrams.
Reference sources (e.g. of schematics) if you used
circuits from elsewhere.
2.3 Primitives Version Block If you deemed it appropriate to simulate (and present)
Verification particular blocks on their own describe the results for
each such block here.
In each case
Describe the simulation set up (e.g. what inputs were
provided and why?). Give details of any special code
required in the test bench (i.e. other than to just
generate the input waveforms)
Present the simulation results and explain how they
prove the circuit is operating correctly. Annotate the
waveform if required to assist with the explanation.
2.4 Primitives Version System You may need to perform more than one simulation to
Verification cover all requirements in the specification. Present these
in a logical order (most basic operations first).
For each simulation
Describe the simulation set up (e.g. what inputs were
provided and why?). Give details of any special code
required in the test bench (i.e. other than to just
generate the input waveforms). Note that any common
set-up information (relevant to all simulations) should be
covered once, before the individual sections.
Present the simulation results and explain how they
prove the system meets one or more of the
specifications. Be specific in referring to the

8
 specifications. Annotate the waveform if required to
assist with the explanation.
3.1 VHDL Version Overview Top level description with reference to a simplified block
diagram (ideally not the top-level schematic) and also
simplified waveforms if needed. Explain system
operation and how the specification is achieved.
3.2 VHDL Version Detailed Design For each block
Define its inputs and outputs (ports). Present code
snippets and explain how it works, referencing the top-
level description where appropriate. Where appropriate,
explain how the implementation enables a particular
specification to be met. If appropriate provide design
information such as logic equations, truth tables, state
diagrams. Reference sources if you used code from
elsewhere.
3.3 VHDL Version Block Verification If you deemed it appropriate to simulate (and present)
particular blocks on their own describe the results for
each such block here.
In each case
Describe the simulation set up (e.g. what inputs were
provided and why?). Give details of any special code
required in the test bench (i.e. other than to just
generate the input waveforms)
Present the simulation results and explain how they
prove the circuit is operating correctly. Annotate the
waveform if required to assist with the explanation.
3.4 VHDL Version System Verification You may need to perform more than one simulation to
cover all requirements in the specification. Present these
in a logical order (most basic operations first).
For each simulation
Describe the simulation set up (e.g. what inputs were
provided and why?). Give details of any special code
required in the test bench (i.e. other than to just
generate the input waveforms). Note that any common
set-up information (relevant to all simulations) should be
covered once, before the individual sections.
Present the simulation results and explain how they
prove the system meets one or more of the
specifications. Be specific in referring to the
specifications. Annotate the waveform if required to
assist with the explanation.
Discussion Summarise the outcome of the design process. Did the
designs meet all the specifications, if not what is lacking?
Are there any other highlights or issues with the design

9
 should be discussed? Are there any problems inherent in
the specifications (there may not be)?
Discuss the relative merits of the approaching a design
using schematics built from primitive logic elements
versus use of hardware description languages.
Conclusion Summarise the key outcomes of the work and if
necessary state what future work would still be required.

14 Mark Scheme
The report will be marked according to the following scheme. There is strong dependence on the
degree to which the specifications have and been correctly met, and shown to be met. Marks for
design and simulation elements may be significantly reduced if the presented schematics and
waveforms do not conform the naming convention described in section 9.
Report presentation (max 20%)
Overall quality of language, structure and organisation of the report. Quality of diagrams. Level of
conformance with format and presentational (figure numbering and figure referencing etc.).
Primitives System Design (max 15%)
Clarity and correctness of top level overview. Clarity and correctness of detailed design description.
Degree to which requirements are met.
Primitives System Simulation (max 15%)
Clarity and correctness of verification description and discussion. Degree to which requirements are
correctly verified.
VHDL System Design (max 20%)
Clarity and correctness of top level overview. Clarity and correctness of detailed design description.
Degree to which requirements are met.
VHDL System Simulation (max 20%)
Clarity and correctness of verification description and discussion. Degree to which requirements are
correctly verified.
Discussion/conclusions/evaluation (max 10%)
Quality of the discussion on design capabilities/limitations with respect to the specification and
possible applications. Quality of brief reflection on schematic vs HDL design. Quality of discussion on
possible improvements/further work.

10