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
- 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.
- 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.
- Have an output to indicate when a key is being pressed. When a new key is pressed this must change to the active state afterthe key value output has updated.
- 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.
- 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.
- 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.
- Have an output to indicate when a key is being pressed. When a new key is pressed this must change to the active state afterthe key value output has updated.
- The decoded output and key-pressed output mst be constant between key press/release (e.g. not pulse with an scanning).
- The outputs must respond within 1 ms of a key press.
3
- The encoder must cope with key bounce of up to 10 ms without giving false outputs.
- If one or more additional keys are pressed afterthe 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.
- 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
my student id
14631
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
