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 V Memory subsystem and full integration
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.
Memory subsystem, integration and verification
The processor sees the memory subsystem as two separate elements: a 256×32 read-only memory for the instructions and a 512×16 read/write memory for the data (both word-addressable). Your task in this step is to design a (very simple) memory management unit (MMU) that will allow the processor to work with a single 128×32 dual-port memory.
Specifically, the single-write/dual-read memory dual port memory is a RAM (identical to the ones seen in the VHDL portion of the module) with the addition of a secondary, read only port (address and data out). The memory will be word-addressable (i.e. each address matches a full 32-bit word).
The MMU will also allow the processor to interface with the external world using two memory- mapped I/O devices (a pushbutton and an array of LEDs).
Within the memory, addresses 0 to 63 will be used for the program (instruction memory), while addresses 64 to 127 will be used to store the data (data memory). Outputs should not be registered.
A few implementation details:
The I/O peripherals for the processor will be memory-mapped, that is, they can be accessed as if they were memory locations. The address range x’0100 to x’01FF are reserved for peripherals. In particular, the START button (which should NOT be debounced in this particular case – unless you feel like modifying the standard debouncer to produce a pulse longer than a single clock cycle) will be accessed at address x’01F0 and the register that will be connected to the LEDs at address x’01F8 in the program memory space. As only 8 LEDs are available, only the 8 most significant bits should be displayed.
You can assume that the program will not access memory locations outside the memory capacity (except the peripherals). In other words, not all the program memory space will be accessible (no page management).
Note that the data is 16 bits wide, whereas the memory is 32 bits wide. You should nevertheless make full use of the memory and take into account that the memory will return two data words (4 bytes) for each access. This should not cause any undue problems for reads (you will simply have to select either the most significant or the least significant half of the word depending on the least significant bit of the address), but will have to be handled when writing. To simplify this, keep in mind that when the location to be written to is addressed, the memory will automatically read the current value and present it at its output.
You can safely remove any logic (tri-state buffers or other) controlled by OEn in your datapath, if any. The OEn signal will become the write enable signal for your memories.
The pushbutton value will obviously be coded as a single STD_LOGIC line. Note that this will have to be converted to a 16-bit word before being sent to the processing unit.
The MMU is a purely combinational entity. The only sequential component involved is the output register (besides, of course, the memory).
Once the memory subsystem has been designed and integrated to the other components, the processor will be complete! To fully test the operation of the processor, the following program should be translated to machine language and loaded into the Instruction Memory (lower half of the dual-port memory) file. A very simple TB (which just provides a clock, a reset, and a start input) will be sufficient to test the processor.
MEM Label Instruction
This first instruction does nothing, but allows the same program to work for both single and multi-cycle CPUs.
loadi r15, h01F0
br r15,=0,-1
addi r31, r0, h001F add r1, r0, r0
inc r1, r1
br r31, <0, +5 (L2) storr r1, r31
inc r1, r1
dec r31, r31
jmp -4 (L1)
loadi r2, h0010
ori r30, r0, h0004 loadr r3, r30
loado r4, r30, 3 xori r29, r0, hFFFF move r7, r0
andi r5, r29, h0010 andi r6, r4, h0001 br r6, =0, +2 (L4) add r7, r3, r7
shr r4, r4, 1
shl r3, r3, 1
dec r5, r5
br r5, ≠0, -6 (L3) stori r7, 0
rol r7, r7, 9
ror r7, r7, 3
not r8, r7
xor r8, r29, r8
sub r9, r8, r7
subi r10, r9, h0001 br r10, >0, +9 (Lx) br r10, ≥0, +8 (Lx) addi r11, r10, h0002 br r11, ≤0, +6 (Lx) or r12, r7, r11 storo r12, r0, 1 and r12, r12, r11 br r12, =1, +3 (Lok) jmp +0
stori r7,h01F8
Do nothing until the user presses START
When the program gets to instruction 11, DMEM positions 0 to 31 should contain decimal values 32 to 1, r1 decimal value 33, and r31 decimal value -1 (65535).
When the program gets to instruction 25, r7 should contain decimal value 700 (result of the multiplication 25 x 28).
If the program has run correctly, execution should finish at instruction 43 and never move from there. Register and memory contents should be the following (decimal): r1=33; r2=16; r3=r4=r5=r6=r9=0; r7=r8=44800; r10=-1(65535); r11=r12=1; DMEM(0) = 700; DMEM(1) = 44801
The LEDs should display decimal 44800.
Note that finishing execution at instruction 43 is not by itself sufficient to verify the operation of the system: the contents of registers and memories are fundamental.
A RTF version of this code is provided in a separate file on the module website.
NOTE: The implementation on the boards will not be feasible due to the COVID lockdown and you are NOT expected to carry it out. I leave the following paragraph here in case you want to “have fun” and run your project on the boards once the labs re-open.
Once the simulation produces the expected results, the design should be implemented on the Xilinx boards to verify that it synthesizes correctly. The decimal value 44800 (1010111100000000 in binary) should be output and therefore bits 10101111 should be displayed on the board LEDs.
The report for this exercise should include:
The machine language equivalent of the test program in binary and hex format.
The commented VHDL code for the memory subsystem. Note: screenshots are NOT accepted.
The commented VHDL testbench. Note: screenshots are NOT accepted.
Screenshots of the simulation of the test program, showing, in readable size, the following
values for instruction sequences 6-11-12, 24-25-26, and 42-43:
o inputs and outputs of your top module (pushbutton, LEDs, reset, clock)
o the contents of IR in hexadecimal and PC in unsigned decimal notation
o the contents, in signed decimal notation, of the following registers: r1-r3, r7, r30 and r31 o all inputs and outputs of the memory management unit
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 new components (i.e., not the datapath or the control logic).
The XDC file connecting the processor to the clock, reset, and I/O pins (LEDs and pushbutton) on the FPGA board