Computer Systems & Organisation

Outline

If you have not completed the tasks in the above labs or do not understand the content, we strongly recommend that you first complete the labs and then start the assignment.

Background

You have been building the CPU from the ground up during the first six labs. The first part of this assignment will require you to submit the CPU that conforms to the QuAC ISA. The second part is more open-ended and will require you to extend the base ISA in an interesting way.

Part 1

For the first part of the assignment, your task is to deliver a CPU in Digital that implements the full QuAC ISA specification.

If you have already completed the first six labs that result in a CPU for the QuAC ISA, then congratulations! You have already completed the first part of the assignment.

Part 2

The QuAC ISA is quite limited in its capabilities compared to established ISAs, such as ARM and RISC-V. We cannot write very interesting assembly programs to solve real-world problems. The primary limitations of QuAC ISA include:

• Few logical and arithmetic operations
• Limited set of general-purpose registers
• ALU instructions cannot directly operate on immediate values
• Inability to conditionally execute on anything other than the zero flag
• Lack of a stack and dedicated push/pop instructions (this point relates to functions)

Your objective in this part of the assignment is to extend the QuAC ISA in a meaningful manner. To this end, you should note that the QuAC ISA deliberately has large gaps in the specification:

• Eight of the 16 possible operation codes (opcodes) are undefined. New instructions can thus use these opcodes and even define a new encoding format other than R-Mode or I-Mode.
• Bits [3] and [7] in the R-Mode encoding format are only defined if both are zero (allowing each R-Mode instruction to have three alternate meanings.)
• One of the register codes is unused (allowing for another special purpose register.)
• Bits [4:15] in the flag register are unused.
• The outcome/behaviour of writing to the flag register is undefined. This means that you could define writing to the flag register in the usual fashion (if you for some reason wanted to set/clear the flag bits directly) or you could add a write-only register that shares the same register code as FL (reading register code 101 reads from FL, writing to register code 101 writes to the new register.)

Your extension can broadly be whatever you like, but more challenging/interesting extensions are worth more marks. Here is a list of potential extensions that you might like to consider, though if you have your ideas, run them by your tutor first to check for suitability.

Your CPU with ISA extensions must be backwards compatible with the base QuAC ISA. Only change your CPUs behaviour with respect to the undefined instruction encodings and behaviour above.

Your assignment will also require the submission of a 2-page design report describing the design decisions you made to implement the base ISA and your extension. More specifically, we would like to read about your idea for extending the instruction set, the usefulness of the extension, the implementation details, such as the required changes to the microarchitecture. Note that while your idea could be simple, what is essential is that your implementation decisions are elegant and clean, and the design details are clearly explained in the report.

You will need to successfully implement a complex extension backed up by an excellent design report to get a mark in the HD range.

Your design report should precisely describe your extension and its behaviour and encoding in a format similar similar to the full ISA description.

Deliverables

We provide the file src/cpu.dig as a template that contains only the dual-port memory module. You should build the CPU in this file. For any other additional sub-circuits (e.g alu.dig, reg_file.dig, control_unit.dig), please place them in the src/ directory.

You are also required to submit the design document as report.pdf in the top level directory.

The assembler config that defines support for your extensions should be in the repo such that anyone can just start using it on your submitted CPU. Remember that the base ISA must still work, so you cannot change any existing instruction configs. You must also provide one or two assembly programs that demonstrate your extension.

We will take the following aspects into account during the marking of the assignment:

• Functional correctness
  • Your CPU must be able to run assembly programs written in the base QuAC ISA correctly.
  • You must demonstrate the correctness of your extended CPU with a carefully written assembly program that uses the new extension. We will verify.
• Succinctness and clarity and neatness of CPU design and organization
  • No spaghetti wiring
  • Wise use of diagonal wires (seldom)
  • Avoid easily preventable wire crossings
  • Avoid running wires under other components
  • Take care that the data flow in typical combinational circuits is left-to-right
• Sensible use of abstraction
  • We discussed abstraction for managing complexity a few times in this course. Your mindset should be that someday a computer systems architect would use your CPU circuit in a larger project. They will not be pleased if they require many days to understand and trust your design.
• Modularity
  • How easy would it be to modify your CPU and/or add other extensions?
• Avoiding wasteful duplication of hardware
  • An ALU that is not using the same full adder for addition and subtraction is wasteful
  • Adding an increment instruction should not use another adder
  • If an instruction can be synthesised from existing instruction(s) (namely pseudo-instruction), then adding new hardware for the instruction is wasteful. The one exception is that adding hardware for the new instruction results in a more efficient execution than utilizing existing instructions, i.e., the software-only approach.
• Gate minimisation
  • Your design does not need to be optimal, but large sprawling, easily minimizable circuits will be penalised.
• Testing
  • Modifications to the control unit and ALU should have corresponding additional tests added
  • New instructions should have some example code demonstrating how they work

Working on Your Assignment

Please follow the process below for working on your assignment submission.

1. One group member forks the assignment 1 template repository
2. On the forked project, go to ‘Members’ in the left side panel
3. Add the other group member
   1. Search for their UID
   2. Change role to ‘Maintainer’
   3. Click ‘Invite’
   4. Check they appear as a maintainer in the members list at the bottom. You will also see a marker bot account down here; leave this as it is.
4. Both members can now clone the forked project to their computer. I.e., the one with the forking group member’s UID in the URL. Do not clone the template repository.
5. Regularly commit and push your changes to the GitLab server
6. The last commit that you push to GitLab before the submission deadline will count as your submission. Please push your work regularly.

Group Work with Git

Git supports concurrent modification, but its conflict resolution support is not ideal for the circuit files. For your circuit files, try to only have a single member editing a given circuit file at a time. Push your work before the other member pulls and starts working on it.

Submission Checklist

1. Our CPU in src/cpu.dig implements at least the base QuAC instruction set.
2. Our statement.txt file includes all the necessary references/acknowledgements, and everything not mentioned in the statement is our groups original work.
3. We have pushed all our work to GitLab, and we can see all of our work on GitLab.
4. Our design document is at the top level of our project as a PDF called report.pdf.
5. We can read the contents of report.pdf using the GitLab file viewer interface (corrupted PDFs are not accepted).
6. quac.json contains the extra definitions for your instructions.
7. We have one or two assembly programs that can be run on our CPU to demonstrate our extension.
8. The CI is passing.

FAQ

Viewing feedback

To see your assignment feedback, go to your groups assignment project on GitLab and change the branch from master to master-feedback. A file feedback.md will be in here containing your feedback.

If you have not forked the assignment, or did not push anything before the deadline, you will not have a feedback branch.

If you have any questions, please reach out via a private Piazza post to instructors. We are happy to provide more feedback if you are unsure about the original feedback.