Department of Electronic Engineering
ELE00067M Digital Design Coursework Assessment 2021/22 SUMMARY DETAILS
This coursework (Final Project) contributes 40% of the assessment for this module.
Clearly indicate your Exam Number on every separate piece of work submitted.
Submission is via the VLE submission point. The deadline is 12:00 noon on 24 January 2022, Spring Term, Week 3, Monday. Please try and submit early as any late submissions will be penalised. Assessment information including on late penalties is given in the Statement of Assessment.
ACADEMIC INTEGRITY
It is your responsibility to ensure that you understand and comply with the University’s policy on academic integrity. If this is your first year of study at the University then you also need to complete the mandatory Academic Integrity Tutorial. Further information is available at http://www.york.ac.uk/integrity/.
In particular please note:
Unless the coursework specifies a group submission, you should assume that all submissions are individual and should therefore be your own work.
All assessment submissions are subject to the Department’s policy on plagiarism and,
wherever possible, will be checked by the Department using Turnitin software.
ELE00067M Digital Design Final project: Part I Design of a (parameterizable) ALU
THE PROJECT SHOULD BE DONE INDIVIDUALLY
Report formatting:
There is no formal report structure – you will be marked on the items listed within the script. The report will include code printout and simulation screenshots – see Lab 1 Appendices for guidelines.
Each part of the script must be handed in as a separate pdf file within a .zip archive, via the VLE by the deadline indicated on the front page of the script. In other words, 5 pdf files should be submitted in a single archive.
Your exam number should be printed on the first page of each pdf file.
The PDF files should be named Yxxxxxxx_DDMSc_PjP#.pdf, where the Yxxxxxxx is your exam number and the # is the part number (1 to 5).
In all cases, read carefully the instructions on the VLE submission page. Failure to follow the instructions could lead to your assignment not being marked and in any case to a mark penalty.
Submission weight on module mark: 40% Mark breakdown [100 marks]:
General issues (e.g. documentation, layout and comments, structural issues): 20 marks
Part 1 (e.g. VHDL code, testbench, simulation): 15 marks
Part 2 (e.g. VHDL code, testbench, simulation): 15 marks
Part 3 (e.g. VHDL code, testbench, simulation): 10 marks
Part 4 (e.g. VHDL code, testbench, simulation): 20 marks
Part 5 (e.g. VHDL code, testbench, simulation): 20 marks
Note 1: All scripts assume that you have access to version 2017.4 of the Vivado toolchain, available in the Departmental computer rooms. If you will be working remotely, instructions on how to install the free version on your own PC are available on the module website.
Note 2: You are absolutely free to exchange ideas and discuss the assessments with your fellow students. However, any instance of sharing code will be considered plagiarism and hence academic misconduct. As a “quick” rule, you can talk as much as you want (short of reading out the code you wrote), but you should never show your work to anyone else and much less exchange files. If you have any doubts as to what is allowed, do not hesitate to contact me.
A parameterizable ALU
The objective of this task is to design a parameterizable ALU capable of handling signed data (of a size defined by a generic value) and performing the following operations:
CATEGORY FUNCTION OPCODE
Identity: Bit-wise logic:
Arithmetic:
ALU_OUT <= A 0000 ALU_OUT <= A AND B 0100 ALU_OUT <= A OR B 0101 ALU_OUT <= A XOR B 0110 ALU_OUT <= NOT A 0111 ALU_OUT <= A + 1 1000 ALU_OUT <= A - 1 1001 ALU_OUT <= A + B 1010 ALU_OUT <= A - B 1011 ALU_OUT <= Arithmetic shift left A by X bits 1100 ALU_OUT <= Arithmetic shift right A by X bits 1101 ALU_OUT <= Rotate left A by X bits 1110 ALU_OUT <= Rotate right A by X bits 1111
Where A, B, and X are input vectors. Note that the shift unit is placed within the ALU. If you prefer to place it at the output of the ALU, as in the module slides, that is acceptable but keep in mind that the control signals (opcodes) to select the function realized by the ALU and by the shifter do not match those of the slides. Here, no operation can be carried out at the same time as a shift and therefore, unlike the slides, separate opcodes for the ALU and the shifter are not needed. Note also (and keep in mind) the application of the rule of “similar opcodes for similar operations”.
A size and a log2 functions are provided in the DigEng.vhd file, available for download from the course website. These non-synthesizable functions can be used to calculate the number of bits required to encode an integer (to be precise, of a natural), respectively the number of bits required to encode a range of values (it will be up to you to determine the most appropriate function to use). To use the functions, first copy the DigEng.vhd file in your working directory, then add the line
use work.DigEng.ALL;
at the top of your VHDL file. The expressions size(N) or log2(N) – where N is an integer or a
natural – will then return the desired value.
Note that the inputs and outputs of the ALU (for reasons that will become clear later) will have to be of type STD_LOGIC_VECTOR and will have to be cast to SIGNED for the arithmetic operations only. The shift operations should be arithmetic shifts implemented using the NUMERIC_STD shift and rotate functions (which will also require typecasting).
Further note that you will have to use standard VHDL operators for all operations (e.g., you should not define an adder using single-bit adders, but use the “+” operator).
In addition, the ALU must be able to generate the following flags (encoded in an 8-bit bus):
Flags(0): Flags(1): Flags(2): Flags(3): Flags(4): Flags(5): Flags(6): Flags(7):
OUT=0 OUT≠0 OUT=1 OUT<0 OUT>0 OUT≤0 OUT≥0 Overflow
Define a self-checking VHDL testbench that will verify every function of ALU for N=16. The testbench should be realized using a loop combined with a record statement to store the inputs and expected outputs and an assert/report/severity statement to stop the simulation in case of a mismatch between the expected and actual output. Include a confirmation message for each successfully passed test.
Make sure to test each function to an appropriate degree and do not forget to verify all possible flag conditions (including overflows). To verify the operation of the ALU, unused (don’t care) inputs should be set to value ‘0’.
The report for this task should include (in this order):
The commented VHDL code for the ALU and all its components (if any). Use comments to
illustrate your computation of the overflow flag. Note: screenshots are NOT accepted.
The commented VHDL testbench and an explanation of the test strategy (choice of input
vectors) adopted to verify the functionality of the ALU. Note: screenshots are NOT accepted.
A printout of the simulator results for the testbench – please comment the screenshots to
highlight the operations being performed. Introduce at least one erroneous set of input/outputs in your record to verify the assert clause and include a separate screenshot of the console displaying the report of the error and the confirmations that the other tests have been passed. Do not hesitate to use more than a single screenshot when needed!
The “RTL Component Statistics” and “RTL Hierarchical Component Statistics” parts of the synthesis report.
Screenshots of the schematics generated by the RTL analysis for the top level and each of the unique components (if you have used any, which you might not).