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 II
Design of a (parameterizable) register bank
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 register bank
The objective of this task is to design a register bank containing a parameterizable number of registers of parameterizable size (number of bits).
The register bank should be dual-read (i.e., allow two different registers to be read at the same time) but single-write (i.e. allow only one single register to be written at every clock edge).
The implementation should be parameterizable both for the data size and the number of registers (i.e. the entity will receive two generics). To help with parameterization, the size and log2 functions are provided in the DigEng.vhd file, available for download from the course website. The library contains a description of these non-synthesizable functions. To use the functions, you should first download it, then use the “Add sources” command to add it to your project, and finally write the line
use work.DigEng.ALL;
at the top of your VHDL file. The expressions size(N) and log2(N) – where N is a natural – will then return values (e.g. std_logic_vector(size(N-1)-1 downto 0)). Note that these functions are slightly different and you should choose carefully the one that is best suited for each case.
The read operation should be implemented using shared output busses and tri-state buffers (remember that only one set of buffers should be activated at any one time!). The syntax for a tri- state buffer is the following:
DATA_OUT <= DATA_IN when (En = '1')
else (others => ‘Z’); — Z = high-impedance
A couple of additional hints/specifications:
The registers are simple synchronous-reset D-type registers with enable (note that clock and
reset are not shown in the figure)
R0 should simply be a source for the constant 0 and therefore should not be implemented by
a register.
The registers should be realized with a single for-generate loop (except for R0 which should
be defined separately).
You will need to generate very large internal signals for the outputs of the registers. Note that, while this can be done with a single vector, it is much more appropriate (and useful for simulation!) to use a two-dimensional array.
The decoders in the figure are simple logic systems that will output a 1 on a single line, corresponding to the value of the input. However, note that you do not need to implement decoders: think of the operation of the register bank and specifically of the condition for each of the tri-state buffers (read) and the register enable (write)!
Design a testbench to verify the operation of the register bank. The testbench will not have to be self-checking (but of course do so if you want!) and there should be no need for a record. You should think about a structured testbench using for loops. When designing the test-bench, make sure to consider all that can go wrong, while minimising the number of test patterns (avoid, for example, writing the same value into all the registers and always reading from the same register on both outputs). The testbench should be applied to a register bank with 32 registers of 16 bits (but you should verify other combinations as well to test your for-generate loops!)
The report for this exercise should include (in this order):
The commented VHDL code for the register bank and all its components (if any). Note:
screenshots are NOT accepted.
The commented VHDL testbench. Note: screenshots are NOT accepted.
A printout of the simulator results for the testbench – make sure that the values are clearly
readable. Display the contents of all the registers. Keep in mind that the simulation screenshots
will be quite “tall”, and do not hesitate to use more than a single screenshot!
The “RTL Component Statistics” and “RTL Hierarchical Component Statistics” parts of the
synthesis report. Note how the tri-state buffers have been converted to multiplexers by the
synthesis process!
Screenshots of the schematics generated by the RTL analysis for the top level and each of the
unique components (i.e., only one register).