UCCE2053 Computer Organisation and Architecture Assignment 1, 2026 | UTAR

– jalr

Instruction Group 2

– srav

– sllv

Instruction Group 3

– Exercise 5.11 (l_inc)

Add a variant of the lw (load word) instruction, which increments the index register after loading word from memory. This instruction (l_inc) corresponds to the following two instructions:

lw  $rt, Address($rs)

addi  $rs, $rs, 4

– Exercise 5.22 (lw variant)

Add a variant of the lw (load word) instruction, which sums two registers to obtain the address of the data to be loaded and uses the R-format.

Synthesize the part of SV code written by you as RTL view using Xilinx tool and compare the synthesis result with the schematic that you have drawn. Check the synthesized RTL to make sure the circuit makes sense.

Issues that require fixing:

1. How to load an external program or instructions into the MIPS processor?
2. When developing the processor, make sure the basic instruction can successfully run first. Then proceed to include the extra instructions. Develop a few sets of test programs: for example, one for verifying the basic instruction set and the extra instructions, one for building blocks, and one for function calls. Make sure your test program include verifying corner cases and also handling hazards. Summarize the verification result in a table apart from showing the waveforms. Mention which one is working, which is not and why not working.
3. When developing short programs to verify the chip level, make sure all instructions are verified!
4. Don’t forget to verify the following:
   a) Register $zero
   b) The SV model and the schematic that you have drawn must tally. How do you check whether they are tally?
   c) Status signals.
   d) The positive and negative values for arithmetic instructions
   e) In particular, slt instruction family will get wrong result if overflow is not included. Make sure you test this.
   f) The use of nops at the right places.

The detail of the design tasks, design flow and report are shown in “assignment guideline.doc”. Marks will be given according to “assignment guideline.doc”.

3-0 Assessment Criteria

The assessment comprises of 3 parts:

• Assignment 1 (Group): Initial Specification Development (10%).
• Practical Assignment 1 (Individual): Chip, Unit and Block Specification, Modelling and Verification (20%).
• Practical Assignment 2: Demo and Result Discussion (10%).

Deliverables:

You are required to hand in two formal reports (each report in .pdf and .docx files, use the team leader name as the file name) and your SV codes for testing. Email all the files to mokkm@utar.edu.my.

• Assignment 1 report: Deadline: Week 10, Monday (before 5 pm) – Student withdrawal on week 12 Friday.
• Practical Assignment 1 report: Deadline: Week 12, Monday (before 5 pm).

You are required to do a demonstration.

• Practical Assignment 2: technical discussion. Deadline: week 14 lab venue.
• Use Vivado to start presenting with the top level verification.
• Then followed by the block level simulation results.
• Basic idea of this demo: show me that you are technically competent!

4-0 Report Requirements

Each group will hand two formal reports (softcopy in word document): one for Assignment 1 and the other for Practical Assignment 1. Indicate the part of work that each group member has worked on as marks will be given accordingly to individual. A good report can be written in many ways – use the following as a guide to construct your report.

1. 2 marks per day will be deducted for late submission. For example. For assignment 1, maximum marks is 10. Let’s say your group gets 7. If late one day, 7 – 2 = 5. Maximum delay: 2 days. Otherwise fail.
2. Line spacing: 1 (do not use 1.5 line spacing or more)
3. Table of content, references/citations, appendixes etc. The documentation flow must follow the design flow as discussed in the assignment guideline file given to you.
4. Use SystemVerilog. Cannot use Verilog. Codes should contain good naming conventions, useful and concise comments at appropriate places, good organization of codes, good file naming conventions etc. Font for the codes: Verdana 9.
5. Micro-architectural level design – modelling, verification and synthesis. Explain the test cases you have constructed with supporting simulation results. For results in the form of waveform, do not simply print out the entire waveform to be included in your report. Indicate the portion of the waveform that is significance in relation to the test case that you have run. The same applies to the System level design.
6. Correct facts: marks are given to correct facts. If your report contains wrong facts, marks will be deducted. Irrelevant facts are considered as wrong facts too. If you include irrelevant facts, it shows that you don’t know what you are doing – marks will be deducted. Otherwise, if irrelevant facts are included without marks deduction, then you would have dump the entire internet into your report and let me discern the right from wrong facts, then this has become I am “answering the question for you”. Many students lose their marks this way.
7. Concise facts: no grandfather story. What you mentioned in the report, you must build.
8. The documentation flow must follow the design flow (from “assignment guideline.doc” file). Marks are deducted if fail to follow this instruction.

5-0 Reference