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 IV Instruction coding and control logic design
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.
Instruction coding and control signals
The next step in the design of the processor is the definition of the instruction set and of the value of the control signals for all the instructions in the instruction set.
You will design a 16/32 bit microprocessor, that is, a processor with 32-bit instructions and 16-bit data. The processor specifications are:
A dual-read, single-write bank of 32 registers of 16 bits each.
For the computation of the (minimal) size of the offsets, you should assume that the offsets
should be able to fully cover:
o a word-addressable data address space of 512 16-bit words.
o a word-addressable instruction address space of 256 instructions (i.e. an 8-bit PC).
An ALU/shifter capable of implementing:
o 1 identity operation (no operation on input A);
o 4 logic operations (AND, OR, XOR, NOT);
o 4 arithmetic operations (add, subtract, increment, decrement);
o 4 (logical) shift by n bits operations (shift left, shift right, rotate left, rotate right); o all flags (7) required for the control instructions (no overflow).
An instruction set containing the instructions specified below in Table 1.
Note that the register bank and ALU are the ones you designed in parts I and II, and integrated in the datapath in part III. Also note that the overflow flag will be unconnected in the final design (since you will not implement an interrupt subsystem).
The instruction set for the processor is the following:
No-operation Arithmetic
Instruction
rt <= ra + immediate value rt <= ra – immediate value rt<=ra+1
00 0000 00 0100 00 0101 00 0110 00 0111 00 1000 00 1001 01 0000 01 0001 01 0010 01 0011 01 0100 01 0101 01 0110 01 1000 01 1001 01 1010 01 1011 10 0000 10 0001 10 0010 10 0011 10 0101 10 0110 10 0111 11 0111
add rt, ra, rb
sub rt, ra, rb
addi rt, ra, imm
subi rt, ra, imm
inc rt, ra
dec rt, ra
not rt, ra
and rt, ra, rb
or rt, ra, rb
xor rt, ra, rb
andi rt, ra, imm
ori rt, ra, imm
xori rt, ra, imm
shl rt, ra, n
shr rt, ra, n
rol rt, ra, n
ror rt, ra, n
move rt, ra
loadi rt, imm
loadr rt, ra
loado rt, ra,
stori rb, imm
storr rb, ra
storo rb, ra,
rt <= DMEM[imm] {direct addressing}
rt <= DMEM[ra] {register indirect addressing}
rt <= DMEM[ra+off] {base plus offset addressing} DMEM[imm] <= rb {direct addressing} DMEM[ra] <= rb {register indirect addressing} DMEM[ra+off] <= rb {base plus offset addressing} Jump to IMEM[PC+off]
AND immediate value OR immediate value XOR immediate value shifted left by n bits shifted right by n bits rotated left by n bits rotated right by n bits
brc ra, cond, off
If condition is true, then jump to IMEM[PC+off], else continue.
Conditions: ra=0
ra ≠ 0 ra = 1 ra < 0 ra > 0 ra ≤ 0 ra ≥ 0
11 0000 11 0001 11 0010 11 0011 11 0100 11 0101 11 0110
The instruction coding for the set, i.e. the placement of the fields within the 32 bits of the instruction, is the following:
3130292827262524232221201918171615141312111009080706050403020100
add rt, ra, rb; sub rt, ra, rb; and rt, ra, rb; or rt, ra, rb; xor rt, ra, rt
inc rt, ra; dec rt, ra; not rt, ra; move rt, ra; loadr rt, ra; storr rb, ra
addi rt, ra, imm; subi rt, ra, imm; andi rt, ra, imm; ori rt, ra, imm; xori rt, ra, imm
OPCODE IMMEDIATE[15:0]
shl rt, ra, n; shr rt, ra, n; rol rt, ra, n; ror rt, ra, n
loadi rt, imm; stori rb, imm
Ra Rt Ra Rt/b Ra Rt Ra Rt
OPCODE IMMEDIATE[15:0] Rt/b
loado rt, ra, off; storo rb, ra, off
brc ra, cond, off
0 0 0 0 0 0
OFFSET[9:0]
OFFSET[8:0] Ra
OFFSET[8:0]
Questions for the report (answer using your own words):
Q1: What determines the size (number of bits) of the opcode?
Q2: What determines the size (number of bits) of the register fields (ra, rb, rt)?
Q3: What determines the size (number of bits) of the immediate field?
Q4: What determines the size (number of bits) of the n field in the shift/rotate instructions?
Q5: Why is the size of the offset in the loado/storo instructions different from the one in the brc/jmp instructions?
Q6: The offsets and immediate values are right-aligned (LSB in bit 10). Is there any advantage in doing this?
You now need to determine the values of the control signals for the architecture. Note that not all control signals will have to be defined in this step, but only those that depend on the instruction itself (and not on the operands). Also, keep in mind that some of the control signals (specifically, for the ALU and shifter) will depend on your specific implementation of those components.
For the final report, the control signals will have to be printed in the form of a table.
S[1,3,4] AL OEN WEN
add rx, ry, rz ……………
??? ??? ? ?
Note that “don’t care” values should not be resolved in the table (by convention, set to value ‘Φ’) as they can lead to significant simplifications in the design of the control logic.
Implementation of the control logic
Once the control signals have been defined, the next step is the design of the decode logic. This subsystem consists of:
A 32-bit Instruction Register (identical in all implementations).
A sequencer to generate the address of the next instruction, built around an 8-bit PC.
Logic for the generation of the control signals.
Parameterization is not required (indeed, it would be impossible to implement parameterization of control logic in any meaningful way).
A possible architecture for the sequencer is the following (see lectures for details), where the Program Counter (PC) is a simple register and the remainder of the logic is combinational:
To control the single-cycle datapath, two sets of control signals need to be generated:
opcode-dependent signals (defined in step 1 above);
operand-dependent signals, which have to be extracted from the instruction (e.g., RA).
The decode logic should be entirely combinational (and thus contain no VHDL processes). The syntax to use will probably consist mostly of with/select or when/else constructs. It is worth noting that the Xilinx tools usually automatically implement all large multiplexers with constant inputs as ROMs. In other words, using the VHDL syntax for the description of multiplexers to define the control signals should automatically generate the most efficient implementation (you can check the synthesis report to verify this).
The second set of control signals (operand-dependent) depends on the operand fields of the instruction. This is where a proper coding of the instructions (and of the opcode) can really simplify the design!
Keep in mind that, where for the register bank the use of a reset signal is “just” good design practice, for the decode logic (and particularly for the sequencer) it is absolutely essential.
To (partially) verify the operation of the control logic (once again, the full verification will only occur in part V after the processor has been fully integrated), create a top level entity that contains the control logic and the datapath as components. Then, create a record to verify the same 5 instructions that you used in part III to check the operation of the control logic. Of course, this time the input will simply be the 32-bit vector that matches the instruction coding you have selected.
You should be able to verify that the control bits sent by the control logic to the datapath match the ones you entered in the testbench for part III (and make sure to display them in your simulation screenshots!)
The report for this exercise should include (in this order):
The answers to the questions following the instruction coding
The table of control signals
The commented VHDL code for the top level and all new components (i.e. do not include the
datapath). Note: screenshots are NOT accepted.
The commented VHDL testbench. Note: screenshots are NOT accepted.
A printout of the simulator results for the testbench, illustrating the operation of the instructions
(register contents) and displaying all the control signals generated by the control logic. 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).