Department of Computing and Mathematics
ASSESSMENT COVER SHEET 2023/24
Unit Code and Title: 6G4Z0031 Computer Architecture
Assessment Set By: Elaine Duffin and Elysia Barker
Assessment ID: 1CWK100
Assessment Weighting: 100%
Assessment Title: Computer Architecture Report
Type: Individual
Hand-In Deadline: Tuesday 16th January 2024 9pm (See Moodle for your
personal deadline).
Hand-In Format and Mechanism: All practical and written work will be incorporated into a single
report to be uploaded to Moodle.
Learning outcomes being assessed:
LO1 Develop a sequential, digital electronic circuit using emulation software to a strict specification and
document that development.
LO2 Build a structured assembly language program that uses both system calls and a range of memory
locations in a microprocessor to invoke higher order sequential operation from a microprocessor and
reflectively document that operation and contrast it to LO1.
Note: it is your responsibility to make sure that your work is complete and available for marking by the
deadline. Make sure that you have followed the submission instructions carefully, and your work is
submitted in the correct format, using the correct hand-in mechanism (e.g., Moodle upload). If
submitting via Moodle, you are advised to check your work after upload, to make sure it has uploaded
properly. If submitting via OneDrive, ensure that your tutors have access to the work. Do not alter your
work after the deadline. You should make at least one full backup copy of your work.
Penalties for late submission
The timeliness of submissions is strictly monitored and enforced.
All coursework has a late submission window of 7 calendar days, but any work submitted within the late
window will be capped at 40%, unless you have an agreed extension. Work submitted after the 7-day late
window will be capped at zero unless you have an agreed extension. See ‘Assessment Mitigation’ below
for further information on extensions.
Please note that individual tutors are unable to grant extensions to assessments.
2
Assessment Mitigation
If there is a valid reason why you are unable to submit your assessment by the deadline you may
apply for assessment mitigation. There are two types of mitigation you can apply for via the unit area on
Moodle (in the ‘Assessments’ block on the right-hand side of the page):
- Self-certification: does not require you to submit evidence. It allows you to add a short extension to
a deadline. This is not available for event-based assessments such as in-class tests, presentations,
interviews, etc. You can apply for this extension during the assessment weeks, and the request must
be made before the submission deadline. - Evidenced extensions: requires you to provide independent evidence of a situation which has
impacted you. Allows you to apply for a longer extension and is available for event-based assessment
such as in-class test, presentations, interviews, etc. For event-based assessments, the normal
outcome is that the assessment will be deferred to the Summer resit period.
Further information about Assessment Mitigation is available on the dedicated Assessments page:
https://www.mmu.ac.uk/student-life/course/assessments#ai-69991-0
Plagiarism
Plagiarism is the unacknowledged representation of another person’s work, or use of their ideas, as one’s
own. Manchester Metropolitan University takes care to detect plagiarism, employs plagiarism detection
software, and imposes severe penalties, as outlined in the Student Code of Conduct and Regulations for
Undergraduate Programmes. Poor referencing or submitting the wrong assignment may still be treated as
plagiarism. If in doubt, seek advice from your tutor.
As part of a plagiarism check, you may be asked to attend a meeting with the Unit Leader, or another
member of the unit delivery team, where you will be asked to explain your work (e.g., explain the code
in a programming assignment). If you are called to one of these meetings, it is very important that you
attend.
If you are unable to upload your work to Moodle
If you have problems submitting your work through Moodle, you can email it to the Assessment Team’s
Contingency Submission Inbox using the email address submit@mmu.ac.uk. You should say in your email
which unit the work is for, and provide the name of the Unit Leader. The Assessment team will then
forward your work to the appropriate person. If you use this submission method, your work must be
emailed before the published deadline, or it will be logged as a late submission. Alternatively, you can
save your work into a single zip folder then upload the zip folder to your university OneDrive and submit a
Word document to Moodle which includes a link to the folder. It is your responsibility to make sure you
share the OneDrive folder with the Unit Leader, or it will not be possible to mark your work.
Assessment Regulations
For further information see Assessment Regulations for Undergraduate/Postgraduate Programmes of
Study on the Student Life web pages.
Formative Feedback: Verbal feedback on your coursework will be given in labs in weeks 7
and 11 and the weekly optional timetabled drop-in session.
Summative Feedback: Individual and general written feedback will be given through
Moodle within 4 weeks after the submission deadline.
3
- Introduction
1.1 Overview
This Computer Architecture coursework requires you to develop a CPU simulation using Logisim Evolution
and amend and develop RISC-V assembly language programs using RARS/RISC-V Assembly language
simulator. All work will be presented in a written report which must be based on the report structure
document from Moodle. All practical tasks must be demonstrated using images and accompanying
written explanations with the final code added to your report as described in the sections below.
On Moodle you will find starter code for the CPU simulation and assembly language tasks. You must use
Logisim Evolution digital logic circuit simulator and RARS/RISC-V Assembly language simulator. These are
available on the lab computers and or downloaded from https://github.com/logisim-evolution/logisimevolution and https://github.com/TheThirdOne/rars respectively. You must make sure that you can
access working software for this coursework, whether using university computers or your own.
To gain high marks you must complete the practical tasks and produce a high-quality report with images
and written explanations (expected to be 80-100 words for most tasks). The first practical tasks have very
detailed instructions, but later tasks are designed to be more complex with multiple possible approaches
and expect you to apply problem solving, logical thinking and understanding to complete them. The final
task for each aspect is designed to be much more advanced and may require additional research beyond
the course materials and a longer written explanation (about 250 words).
1.2 Support
The Coursework Additional Hints and Advice document available on Moodle contains further details for
how to complete some tasks including reminders as to how to use the software. Any time you are unsure,
you should look at the relevant section of the that document before asking for help.
Video support for this coursework is available on Moodle including “The Road to 40” videos for both the
CPU simulation and RISC-V assembly language tasks which includes adding the evidence and written
descriptions to the report structure document for several tasks.
There is an optional weekly drop-in on your timetable on Mondays where you can ask questions about
any part of the unit including your work towards this coursework. The Programme Support Tutor, Susan
Lomax, also has drop-in support times advertised on Moodle. Coursework support will also be available in
your lab session in weeks 7 and 11 of the unit when you should bring your work towards the coursework
for individual face-to-face feedback or to ask questions. You can discuss harder tasks the tutors can get
hints but not direct help towards the highest marks.
You should use the Unit Leader’s office hours which are shown on Moodle. You may send questions to
the tutors by email or using MS Teams. The tutors will try to answer quickly, but you should allow up to
two working days for a response. Note that the deadline is in January and there will be a block of time
over the winter break when the unit tutors are on leave and not available for any support.
1.3 Employability
You are expected to show professional standards in your work. Especially early in your career, you might
be given very detailed specifications which you are expected to follow systematically. This needs a
careful, thorough approach with attention to details. In industry, you are expected to follow the style of
the original when making changes and make it easy for someone to understand and amend in future.
Carefully documenting testing (in this case using images) when amending an existing product is based on
industry experience.
4 - CPU Simulation
Download the following resources from the coursework materials on Moodle and store them together in
a folder, ideally on your university OneDrive. If you download them as a zip file, you will need to unzip
(extract) them to use them.
- CPU circuit (CPU_simulation_starter.circ)
- Starter program(s) (program1.dat, program2.dat)
- Sample data (data.dat)
The first tasks have further detailed hints for all the steps needed in the Additional Hints and Advice
document and are covered in the Road to 40 video available on Moodle, including adding to the report.
Adding the Logisim Evolution file to your report
You must include the full Logisim Evolution code containing all the parts you have attempted of the CPU
in an appendix to your report. To do this, open your Logisim Evolution .circ file in Notepad++ (or another
plain text editor) highlight and copy all the code and paste into your appendix. The code should then be
changed to a fixed width font (e.g., Consolas).
2.1 Calculating the sum of data stored in data memory
2.1.1 Overview
In this task, you will store the last four digits of your student ID in the data memory of the CPU simulation
and run a program to calculate the sum of those digits and write the resulting total to the data memory.
2.1.2 Detailed instructions
Open the circuit provided (CPU_simulation_starter.circ) in Logisim Evolution. Change the student ID
shown in the text in the circuit to your own student ID. Save the circuit.
Open the data.dat file in a text editor (e.g., notepad++). Change the values to be the last four digits of
your MMU student ID, each separated by a space. Save the file and paste its contents under the heading
Test Data in the section for this task in your report and change to a fixed-width font.
Add up the digits yourself before running the simulation. Under Expected Result in your report, give the
sum of those digits in decimal and converted to hexadecimal.
Load the program file program1.dat to the instruction memory and your amended data.dat to the data
memory. Add an image to your report under Circuit with data loaded showing the CPU with the data and
program loaded making sure that your individual data is visible.
The program (program1.dat) should add up the four digits that you have placed in the data memory and
put the result at address 4 in the data memory. Run the program and stop clicking the clock when the
instruction f000 is highlighted in the instruction memory. Take an image at this point and add to your
report under the heading Circuit at end of program.
Check the result of the simulation and add text under the heading Result to state how the circuit at the
end relates to your expected results. Under the heading Explanation, explain the purpose of the ACC and
program counter (PC) registers in the simulation. Relate the PC to pressing the clock and what you see in
the instruction memory and explain where the input to the ACC comes from and where the output goes
to in terms of the changing values you see when running the simulation.
5
2.2 Calculating the sum of Immediate values
2.2.1 Overview
In the first task, you loaded the last four digits of your student ID into the data memory, and the program
read each one from memory in turn to add to a total. For this task, you are going to amend a program so
that the last four digits of your id are given as immediate values in the program instructions. The program
will again calculate the sum of those digits but will write the totals as it goes along to the data memory.
2.2.2 Detailed instructions
Open the program2.dat file in a text editor. The file provided appears as follows.
v2.0 raw
1004 3000 1103 3001 1102 3002 1101 3003 f000
The program provided would be for a student with the last four digits 4321 (in the positions highlighted).
Change the highlighted immediate values to be the last four digits of your student ID. Save the file and
add to your report under the heading Test Program.
Create a table in the Expected Result to show the running total at each step for the last four digits of your
student ID in both decimal and hexadecimal.
Load your amended program file program2.dat to the program memory, clear the data memory and
make sure that the PC is set to 0. Run the program until the instruction f000 is highlighted in the
instruction memory. Take an image at this point and add to your report under the heading Circuit at end
of program.
Look at the values you see in the data memory and compare to the hexadecimal values from your table of
expected results. If they don’t match you should try to work out why. Write a statement under the
heading Result that compares the expected results to the actual results.
Under the heading Explanation, explain in your own words how the CPU simulation caters for the
difference between a 1 or a 2 as the first digit of the instruction. Your explanation should refer to the
Use_Memory signal from the Instruction_Decoding_Unit and the multiplexer (MUX) that connects
directly to Input2 on the ALU.
2.3 Bitwise OR
2.3.1 Overview
The previous task added four values that were provided as immediate values in program instructions,
writing the results to data memory at each stage. For this task, you will change that program so that it
does a bitwise OR at each stage instead of addition. In this case, you will need to use binary to work out
the expected results, look in the Additional Hints and Advice document for an example.
2.3.2 Detailed instructions
Make a copy of your program2.dat file (you might want to save it as program3.dat) and open it in a text
editor. If you have completed the previous task the last four digits of your student ID will be included as
immediate values.
v2.0 raw
1004 3000 1103 3001 1102 3002 1101 3003 f000
6
The previous program has three instructions where the second digit is 1 indicating that addition will be
used from the ALU (highlighted above). Change those instructions to indicate bitwise OR by changing
those 1s in the second digit to 2. Save the file and add to your report under the heading Test Program.
Create a table in the Expected Result to show the result at each step in both binary and hexadecimal. This
will involve doing a bitwise OR operation on the input data with the previous result.
Load your program file to the instruction memory, run it. Take an image when f000 is highlighted and add
to your report under the heading Circuit at end of program.
Compare the values in the data memory to the hexadecimal values from your table of expected results.
Write a statement under the heading Result that compares the expected results to the actual results.
Under the heading Explanation, explain in your own words how the simulation caters for the difference
between a 1 or a 2 as the second digit of the instruction. Your explanation should refer to the
ALU_Operation from the Instruction_Decoding_Unit as well as the ALU itself.
2.4 Completing the stop instruction
2.4.1 Overview
The programs used for the previous tasks all included the instruction f000 which should stop the program
from continuing. In the initial version of the CPU simulation that instruction doesn’t work, and the
simulation will just keep using the instructions in order from the Instruction_memory. In this task you will
amend the simulation so that the program does not continue when instruction f000 is reached.
2.4.2 Detailed instructions
In the CPU simulation, one of the outputs from the Instruction Decoding unit is labelled Stop. This is a 1-
bit control signal that will be on (1) when the op code (first digit of the instruction) is “f”, and the program
needs to stop. You need to use gates and wiring to make the clock input to the components (PC, ACC and
data memory) stay on 0 when the Stop signal is 1 but continue to work as now otherwise. That is, a clock
signal of 1 will go to the other components when the clock signal is 1 AND the Stop signal is NOT 1.
Choose any of the previous programs to run to demonstrate that the CPU simulation still works as
expected. In your Expected Result give a statement of what the program should do. Set up the
Instruction_Memory, Data_Memory and registers to run your chosen program. Take an image that shows
your setup and wiring and add to your report under Circuit at Start of Test.
Run your program and keep clicking the clock after the instruction f000 is highlighted in the program
memory to make sure that the program does not continue. Take an image where the instruction f000 is
highlighted and the clock signal is 1 (bright green) to show that the clock signal is not passed to the other
components and add the image to your report under Circuit at End of Test.
Under the heading Explanation, explain in your own words why some components need a clock signal
and how the stop instruction works now.
2.5 Branch always
2.5.1 Overview
Being able to change the program flow rather than always running instructions exactly in the order they
are loaded is fundamental to programming to be able to have programs that behave differently according
to the values of variables, and code structures like if/else statements and loops. As the program counter
7
(PC) stores the address of the next instruction to process, changing the flow requires setting that counter
to a different value rather than just adding 1 to go to the next instruction in sequence.
For this task, you will create an unconditional branch instruction. That is that when that instruction is
reached the program counter always changes to the address given in the instruction. You will create a
program to use that instruction to create a loop. As it will be an unconditional loop, there will be no way
to stop the loop so the program will be run manually. There is a later task to create a conditional branch
instruction that could be used for a controlled loop or if/else statements.
2.5.2 Detailed instructions
One of the unused outputs from the Instruction Decoder is labelled Branch_unc. This is a 1-bit control
signal which will be 1 when the CPU operation (first hex digit from the instruction) is 4. When the
Branch_unc signal is 1 the value stored in the PC should be overwritten with the address from the last
two hex digits of the instruction (which come out of the Instruction_Decoding_Unit as Addr_or_Imm)
instead of the output from the Adder that adds 1 to the value as now.
Before you can test your changes to the simulation, you need to prepare a suitable program. For this task,
you should create a program that uses a loop to repeatedly add up the values stored at the first four
addresses in the data memory. Do this by taking a copy of program1.dat and replacing the f000
instruction with an instruction to set the program counter to point to the address of the instruction that
adds the data from address zero in the data memory. Save the file and add to your report under the
heading Test Program.
Your Expected Result section of your report should be based on doing the addition 5 times. State the
expected result in both decimal and hexadecimal. This should be 5 times that from the first task.
Load your program into the instruction memory and your data into the data memory (as in the first task).
Run your program by stepping through with the clock signal until the addition has happened 5 times and
the branch instruction is highlighted. Take an image at this point and add to your report under the
heading Circuit after adding 5 times.
Write a statement under the heading Result that compares the expected result to the actual results.
Under the heading Explanation, explain in your own words how the branch instruction works and what
would happen if you carried on running the simulation. You may use additional images based on
continuing to run with your data to aid your explanation.
2.6 Amend the ALU
2.6.1 Overview
The ALU in the original CPU simulation is very limited, the only available operations being addition and
bitwise OR. For this task you will add more functionality to the ALU and write and test a program that
uses the new functionality.
2.6.2 Detailed instructions
The changes required to the ALU are as follows: - ALU operation 3 should be a bitwise AND of the two inputs to the ALU.
- ALU operation 4 should subtract the value of Input2 from the input from the ACC.
When you have made those changes, you should take an image of the ALU subcircuit only and add to
your report under the heading ALU circuit.
8
Create the program as described below to use to test your changes. You are expected to build on your
understanding from previous tasks without full details for each instruction.
The program should carry out the following instructions in this order:
i. Load an immediate value to ACC – that value should be the total of the last four digits of your
student ID.
ii. Store the value from the ACC to address 01 in data memory.
iii. Subtract 1 from the value from the ACC (use an immediate value).
iv. Store the result from the ACC to address 00 in data memory.
v. Do a bitwise AND between value from accumulator and value from address 01 in data memory.
vi. Stop the program.
Save the file and add to your report under the heading Test Program.
Under Expected Result, create a table showing the expected values at each stage. You will need to work
with the binary values to work out the bitwise AND, and the hexadecimal values to compare to the CPU
simulation.
Run your program and add an image under the heading Circuit at end of program. Write a statement
under the heading Result that compares the expected result to the actual results.
Under the heading Explanation, explain how the program could have been written without using the
subtraction that you added to the ALU and just using the addition that was already available instead. You
may use additional images to aid your explanation.
2.7 Conditional branch instruction
2.7.1 Overview
This task expects you to have completed both the unconditional branch and ALU amendment tasks and
the instructions are less detailed than previously. Do look in the Additional Hints and Advice document.
The branch instruction already completed would have limited practical use as the loop that was created
would never stop and it couldn’t be used for if/else statements. In this task, you will build on the earlier
amendment to create a branch instruction where the branch only happens when the value in the ACC is
not equal to zero. You will build on the program from the ALU amendment task to create a program that
uses an if/else structure with both conditional and unconditional branches to test whether a number is a
power of two or not.
2.7.2 Detailed instructions
To start this task, you first need to make a change inside the ALU circuit. The ALU has an unused output
labelled ACC_NE_Zero which should output 1 when the value from the ACC going into the ALU has a value
which is not equal to zero, and output zero when the ACC is zero. In the starter version, the ACC_NE_Zero
is not connected. You may use any components from Logisim Evolution inside the ALU to make it work so
that the output at ACC_NE_Zero is 1 only when the From_ACC value not zero.
Make sure that your output at ACC_NE_Zero would work in all situations by testing directly in the ALU by
manipulating values in the pins. Add images and a short statement about that testing to the ALU circuit
section of your report.
When your change to the ALU is working correctly, then you will need to add the functionality to the CPU
main circuit to pass an address to the program counter (PC). There is an output from the instruction
9
decoder that is labelled BNEZ (short for branch not equal to zero). When this signal is 1 AND the
ACC_NE_Zero from the ALU is 1, then the program counter should be set from the address in the
instruction. This will need to be incorporated with the branch always change already completed so that,
after this task, the address from the instruction should be used to set the program counter when
Branch_unc is 1 OR (BNEZ AND ACC_NE_Zero) are 1.
To test this change, you should write a program that has the following functionality: - Load an immediate value to the ACC.
- If that value is a power of two, write ff to address 2 in the data memory.
- If the value is not a power of two, write 00 to address 2 in the data memory.
- Stop the program.
Save the file and add to your report under the heading Test Program.
You will need to run your program multiple times, to make sure that you have tested different
combinations. Each time you will need to change the immediate value in the first instruction. One of your
tests needs to be the total of the last four digits from your student ID (as used in the ALU amendment
task). Add images and short statements to the Test evidence section of your report. You may want to add
new sub-headings.
Under the heading Explanation, you should explain how your program works, specifically the use of
branch instructions.
2.8 Incorporating Input and Output devices
2.8.1 Overview
This is an open-ended task that expects you to understand how the program instructions work. You are
expected to show creativity rather than following detailed instructions, but it doesn’t rely on any specific
prior tasks.
Your task is to add suitable input and/or output mechanisms to the CPU simulator to make simulation
more versatile using input and/or output components from the folders of Input/Output tools in Logisim
Evolution. You do not need to include both input and output but, your input and/or output devices need
to be incorporated into the CPU by adding more instructions to the instruction set, making appropriate
changes to the instruction decoder (and other parts of the simulation) and creating programs to
demonstrate your work. This is a flexible task and there are many possible approaches, so you need to
describe your work with suitable images in your report. Explain what you have done and why, including
the program(s) you have used for testing and the components you added. This explanation should be up
to 250 words, and you should add subheadings and images showing your changes and a range of testing.
10
- RISC-V Assembly Language Programming
This assembly program development starts by amending and testing an existing assembly program that
runs in the RARS RISC-V simulator. Download RISC-V_program_starter.asm from Moodle.
Adding the assembly language code to your report.
When you have finished your attempt at the RISC-V assembly language programming, make sure that you
have included your code containing all the tasks you have attempted in the appropriate appendix. The
code should assemble and run if copied and pasted into the RARS RISC-V simulator. If you have started a
task but not been able to complete it, you may submit the attempt commented out so that the remaining
code works and include comments explaining what you were trying to do. You should make sure that
your code is set out well, has suitable comments and is still able to complete the initial features when
extending a previous program. There are three separate sections in the appendices for your assembly
language code, one for tasks 3.1 to 3.4, another for tasks 3.5 to 3.7 and another for task 3.8.
3.1 Test the existing program with minor adjustments
3.1.1 Overview
In this task, you will make minor adjustments to the starter code in so that you can enter the last 4 digits
of your student ID and see the sum total of those 4 digits.
As this is the first task of this section, there are detailed instructions for how to complete task with more
explanation in the Additional Hints and Advice document and on the Road to 40 video.
3.1.2 Detailed instructions
Open the provided starter code (RISC-V_program_starter.asm) in RARS. Save, assemble, and run the
current code to see what is happening within the code. The current version of the starter code will ask for
the last 4 digits of your student ID to be entered. Begin entering the digits, pressing enter between each
digit. However, you will only be able to enter 2 of those digits. The program should output the sum of
those 2 digits and then stop. Take a screenshot of the Run I/O and paste this into the report under the
heading Starter Program with a statement clarifying this is the starter program result before any
modifications.
Next, briefly write what the expected result should be after modifications (i.e., you would like the
program to allow for the last 4 digits of your ID to be input and the output should be the sum of these 4
digits). Write this, along with the value of the sum of the last 4 digits of your student ID under the heading
Expected Result.
In the code, copy and paste the section of code between the set of two hash (##) symbols and paste
these two more times so the code will now allow 4 numbers to be entered. Assemble and run this
updated code. You should now be able to enter 4 digits one after another. Enter the last 4 digits of your
student ID, pressing enter between each digit. The result should be the sum of the 4 digits.
Check the result of the simulation, take a screenshot of the Run I/O, paste this under the heading Result.
Under the heading Explanation, explain why we have set the values of register a7 to various values
throughout the program and what each of them mean (a7 has the value 1, 4, 5 and 10 at different points
in the program).
11
3.2 Improving the messages that the program outputs
3.2.1 Overview
In the first task you made minor modifications to the code, so you are able to enter the last 4 digits of
your student ID, but it still wouldn’t be clear to a user that they have to press enter between each digit. In
this task, you will improve the messages in this task to make the aims of the program clearer for the user.
3.2.2 Detailed Instructions
You can see the program currently uses two messages stored in memory (“Please enter the last four
digits of your student ID” and “Enter next digit”). Unfortunately, when the program runs it is confusing as
the initial instruction tells you to enter the last 4 digits but does not tell you that you should enter them
separately, pressing enter between each digit. Someone could enter 1234 instead of 1, 2, 3 and 4.
Firstly, find the place with 3 hash (###) symbols in a row in the code (this should be near the top of the
program). You should write a section of code here to output “enterMsg2” which is already provided for
you in the .data section. You can copy and paste code which is used to output a previous message but
remember to change the message to “enterMsg2”.
Next, you will have to create a new message in the .data section. You must give this message a suitable
name and it should say “The total of the digits is: ”.
Finally, in the same way as before, locate where there are 4 hash (####) symbols in a row and write a
section of code here which will output your new message.
Assemble and run this code then take a picture of the Run I/O and paste this into the report under the
heading Results with a couple of sentences stating what you did. Then, under the heading Explanation,
explain the importance of clear messages for the user of a program and briefly what the difference is
between the .data section and the .text section.
3.3 Adding a subroutine
3.3.1 Overview
In the previous tasks, you have been asked to improve the program by allowing you to enter 4 digits and
making the messages clearer to improve the user interaction. You are now going to be using a subroutine
to improve the quality of the overall code.
3.3.2 Detailed Instructions
Firstly, you should identify the section of code which repeats. This section can be made into a subroutine.
You will need to take the code that repeats and give this an appropriate subroutine name.
Next, you should delete the rest of the repeated code as you will only need the subroutine. Call the
subroutine from the appropriate places in the program where the repeated code originally was removed
from. You should take a screenshot of the subroutine code and place this in the report under the heading
Subroutine Code with a sentence stating what you did. Next, assemble and run the program and take a
further screenshot of the Run I/O and place this in the report under the heading Result.
Under the heading Explanation, you should then explain the importance of using subroutines in
programming, what jal and ret stand for in the context of a subroutine in RISC-V assembly language
and how they are used.
12
3.4 Enhancing the functionality of the program
3.4.1 Overview
The program you have been running until now can only perform addition. In this task, you are going to be
improving the functionality of this program by including multiplication into the program as well as
keeping the original function of addition.
This is the last task to amend the original starter code, so your fully commented code needs to be added
to the appendix after this task.
3.4.2 Detailed Instructions
The program currently can add up the four numbers which you input into the program. You should use
this to help you include multiplication as well as keeping the addition in the program. You should also
create a new, appropriate message, which is output before the result of the multiplication.
Take a screenshot of the code you have written for the multiplication and enter this in the report under
the heading Multiplication code. Under the heading Expected Result, you should explain what you
believe the expected output of the code in the Run I/O should look like. You should plan to run the
program at least twice, with the result of the multiplication being zero and not being zero. One of the
tests needs to be the last four digits of your student id.
Place screenshots of the Run I/O for your tests in the Result section with a sentence comparing the
results to your expected result.
In the Explanation section, explain the importance of adding comments in your code. Also in the
Explanation section, you should explain how you would also incorporate division into the program and
what the outcome would be if you were to do so. You are not expected to make that change.
3.5 Splitting Numbers
3.5.1 Overview
You have looked at improving the professionalism and functionality of a basic RISC-V assembly language
program over the last few questions. In the following tasks, you will be creating a new program which
applies and expands the techniques you have been using.
In this task you will create a new assembly language program which enables you to input the last 4 digits
of your student ID number as one number (e.g., 4321) rather than pressing enter between each digit, and
the program will separate the individual digits from that number into different registers (e.g., 4321
becomes 4, 3, 2 and 1 stored in registers t1, t2, t3 and t4 respectively). You are not expected to include
any error checking to ensure that the user enters a 4-digit number as requested.
3.5.2 Detailed Instructions
Open a new, blank program in the RARS emulator and make sure to save this with an appropriate name.
Below is a section of pseudocode which you must use to begin the program, followed by short prompts to
help you finish the program. In the report, under the heading Pseudocode, you must finish writing the
pseudocode in full for the whole program, making sure you are clear. You may copy and paste the
beginning part of the pseudocode below into your report, but do not paste in the vague prompts.
.data
Define message asking for the last 4 digits of your student ID
Define message to output before individual digits are displayed
13
.text
Load appropriate value into a7 for displaying message
Load the address of the message to be displayed to a0
Execute system call
Load appropriate value into a7 for a user input from keyboard
Execute system call
Set register s0 to have the value from a0 (the user input)
Set register s1 to 10 (this will be used for division later)
Set register t0 to the sum of 1000 plus zero
Divide s0 by t0 and store the integer result in t1
Update s0 to be the remainder of s0 divided by t0
Divide t0 by s1 storing the integer result back in t0
Divide s0 by t0 and store the integer result in t2
Update s0 to be the remainder of s0 divided by t0
The following are prompts for the rest of the program:
- Part of the existing process needs to be carried out two more times (for the tens and units digits).
o Divide t0 by 10 (from s1) updating the value of t0 each time
o Divide the updated s0 by the updated t0 each time and store in appropriate registers
following the pattern above (t1, t2 …)
o Store the remainder back into s0 each time - Output the second message
- Output the results of the registers t1, t2, t3, t4 separating them with an output character
Under the heading Expected Result, describe the expected result when the last four digits of your student
ID are used as input to the program. Make sure that you describe what you would see in the registers and
exactly how the digits will appear in the Run I/O including the separator you have used.
Write, assemble, and run the program using your student ID and screenshot the Run I/O and the registers
with their values at the end of the program. Enter this into the report under the heading Result with a
brief sentence comparing your expected result to the results in the images.
Finally, under the heading Explanation, explain in detail what is happening in the program. You may
include screenshots of part of the code to help.
3.6 Splitting numbers with a loop
3.6.1 Overview
In the previous task, you created a new program to input a 4-digit number and split it up into its
individual digits (4321 becomes 4, 3, 2 and 1). In this task, you are going to expand on this by using a loop
to separate out, and print, the individual digits and extend the program to cater for a 5-digit input.
3.6.2 Detailed Instructions
To simplify the code by using a loop you may adapt and change your code quite a lot as you no longer
need to store all the separate digits in registers t1, t2, t3 and t4, but can output each digit to the console
as you go along.
14
Before you code your solution, you should create pseudocode. Your pseudocode does not have to be
quite as detailed as for the previous task. For example, you could have one line of pseudocode to output
a specific message or value from a register rather than covering each assembly language instruction
needed. Your pseudocode should clearly show what needs to be set up before the loop, how a simple
loop iterates through the thousands, hundreds, tens and units digits and how the output is produced.
Include your pseudocode in your report under the heading Pseudocode.
Create the program based on your pseudocode. Take a screenshot of your loop code and place this under
the heading Loop Code. Assemble and run the code using the last four digits of your own student ID and
take a screenshot of the Run I/O and place under the heading 4-Digit Result.
Extend your program so that it works for a 5-digit number. Test it with the last 5 digits of your student ID.
Take a screenshot and place under the heading 5-Digit Result in your report.
Finally, under the heading Explanation, describe why loops are important in programming and compare
loops to subroutines in the context of RISC-V assembly language. State and briefly explain the use of a
branch instruction to control the loop in your code (e.g., bnez, bne, beqz, …). Explain why there would
be a problem using addi to set a register to have a value of 10,000 and what you did instead.
3.7 Making use of arrays
3.7.1 Overview
This task is going to push the program you are designing even further. You have previously used a loop to
separate out the individual digits of a number. In this task you are going to store the separated digits in
an array. You can try this even if you haven’t managed to complete question 3.6 as you can expand
question 3.5 in a similar way in which case you would test with 4 digits instead of 5.
The instructions for this task and the following task will be much vaguer since these are the more difficult
questions and are open to you to find a way to answer that suits you best. You should still check the
Additional Hints document.
3.7.2 Instructions
Using what you know from arrays, and making use of your Moodle material, you should be able to store
the individual digits in an array in memory. Use pseudocode to plan your program and add it to your
report under the heading Pseudocode.
In the heading Expected Result, state the result you expect to find once the program has finished when
run using your student ID. Include what you expect to see in memory and registers as well as the Run I/O.
Assemble and run the program and take a screenshot of the run I/O and of the data segment showing the
digits in the array in memory. Place the screenshots under the heading Result with a brief sentence
comparing this to your expected result.
Finally, under the heading Explanation, describe briefly what an array is and why it is important in
programming. Then, explain in detail how arrays use memory in RISC-V assembly language, you may want
to refer to your image of the data segment. You may add images of code segments to aid your
explanation.
After this task you no longer need to change this program. Make sure your code contains suitable
comments and remember to copy and paste the entire program into the corresponding appendix.
15
3.8 Designing a console game
3.8.1 Overview
This is the final task on RISC-V assembly language, and this will be the most open-ended task of the
report. You will be given the task of designing and creating a simple console game in RISC-V using the
techniques you have developed throughout the course.
The game is ultimately your decision and can be single player or two people at the same computer. You
are required to explain your game and show your process of creating the game with images and text
showing stages in your development and your testing of the game at those stages. Within your report,
you should state the name of the game you are creating, detail instructions for how to play and the
outcomes if you were to win, lose, draw etc. You should include appropriate tests to show your game is
working correctly with “Win” and “Lose” if applicable.
You should explain the programming techniques used. To obtain full credit in this task, you should include
the use of arrays and memory, subroutines, loops and/or branch instructions. You are expected to write
about 250 words for this task and will need to add your own subheadings for this section and choose
appropriate images to enhance your explanations.
Once you have completed your game, you could add a brief discussion of improvements you would make
to it next time, any additions you would include or any limitations of your game in the form you submit it.
16
- Completing the Report, Submission and Marking
4.1 Completing the report
In your report, you are expected to complete the title page, update the contents page so that the section
headings and page numbers are correct, and add a short introduction and conclusion. Your introduction
should give a brief overview of what your report will include.
Your conclusion (about 200 words) should consider the two approaches shown in the report (CPU
simulation and RISC-V assembly language) and discuss the differences and similarities from your own
experience and consider how each approach has enhanced your skills or knowledge. Ensure that it is
strongly related to the work in your report rather than to general points about the approaches.
When you have completed your report, you should check that you have included your evidence in the
correct sections, written explanations as required and included the code in the appendices. Tasks will be
considered as attempted but not complete if the code is not available.
4.2 Submission
Submit your report to Moodle as a word document (.docx), pdf or open document format (.odt). The file
should be named with your initial and surname followed by “Computer Architecture report” (e.g., my
E_Duffin_Computer_Architecture_report.docx).
Turnitin will measure similarity between reports and with internet sources. This will identify highly similar
amendments made in the practical work or close similarity of the written work to other reports or
different sources. Similarity may be investigated as potential academic misconduct.
4.3 Marking Criteria
The report will be marked according to the marking grid below. Higher marks are gained from
submissions that show a more professional approach, not just the number of tasks completed. Both
aspects of practical work (CPU simulation and RISC-V Assembly language) have eight tasks to work on.
The marking grid shows that three tasks need to be complete for a pass (40%) and five tasks complete for
a good grade (60%). The tasks are not expected to all be the same level of difficulty.
Credit for the practical work depends on it meeting the requirements specified in this document; the
evidence and explanations in the report (images and text) and the code in the appendix matching that
evidence. The mark will be adjusted according to how professionally the tasks have been done, including
the clarity, accuracy, and completeness of the text in relation to the images. Professionalism includes the
position and labelling of components and wires (CPU Simulation), the code layout, choice of label names,
use of comments, not having unnecessary code (Assembly language).
The marking criterion for the report includes the use of the template and having a suitable introduction
and conclusion which need to be clearly related to the work in the report. Using the template includes
the title and contents pages, use of section headings, page layout, the length of the text explanations, the
use of citations and references in Cite Them Right Harvard format for all additional research.
The marker will mark each of the criteria (CPU simulation work, RISC-V assembly language work, Report)
using stepped marks, that is they will be at the bottom, middle or top of a grade band. For example, if an
aspect is marked in the 60s, it will be awarded 62, 65 or 68 according to its quality. The overall grade will
be calculated using the weightings of 40% for each of the practical areas and 20% for the report. For
example, if a student achieved 58% for CPU simulation, 65% for Assembly language and 45% for the
report then the overall mark would be 580.4 + 650.4 + 45*0.2 = 58.
Criteria 0-29% 30-39% 40-49% 50-59% 60-69% 70-85% 86-100%
CPU simulation
amendment,
testing and
explanation
40% of the unit
grade
There is little or
no evidence of
the CPU
simulation
work.
There is little or
no text
accompanying
the task(s).
There is
evidence of
completing at
least two of the
tasks.
There is some
attempt to
accompany the
evidence with
text.
There is
evidence that at
least three of
the tasks are
complete.
The tasks are
presented and
explained
adequately.
There is evidence that at
least four of the tasks
are complete and
working with an attempt
at one more task.
The tasks are explained
clearly and there is
evidence of considering
the presentation of the
circuit.
There is evidence that
five of the tasks are
complete and working
correctly.
The tasks are explained
carefully and
accurately with good
presentation of the
circuit.
There is evidence that six
of the tasks are complete
and working correctly with
an attempt at one more
task.
The tasks are explained
accurately, thoroughly,
and fluently. The circuits
are presented very well.
There is evidence that all
tasks are complete and
working correctly,
although there may be
minor issues on one task.
The tasks are explained
accurately, thoroughly,
and fluently. The circuits
are presented very well.
RISC-V
Assembly
language
amendment
and testing, and
explanation
40% of the unit
grade
There is little or
no evidence of
the CPU
simulation
work.
There is little or
no text
accompanying
the task(s).
There is
evidence of
completing at
least two of the
tasks.
There is some
attempt to
accompany the
evidence with
text.
There is
evidence that at
least three of
the tasks are
complete.
The tasks are
presented and
explained
adequately.
There is evidence that at
least four of the tasks
are complete and
working with an attempt
at one more task.
The tasks are explained
clearly and there is
evidence of considering
the presentation of the
code.
There is evidence that
five of the tasks are
complete and working
correctly.
The tasks are explained
carefully and
accurately with good
presentation of the
code including
comments.
There is evidence that six
of the tasks are complete
and working correctly with
an attempt at one more
task.
The tasks are explained
accurately, thoroughly,
and fluently. The code is
presented very well
including comments.
There is evidence that all
tasks are complete and
working correctly,
although there may be
minor issues on one task.
The tasks are explained
accurately, thoroughly,
and fluently. The code is
presented very well
including comments.
Report
Use of the
template,
introduction
and conclusion
20% of the unit
grade
There is little or
no attempt at
an introduction
or conclusion.
Little or no part
of the report
structure
template has
been
completed.
There is an
introduction or
conclusion.
Some parts of
the report
structure
template are
complete.
There is both
introduction
and conclusion.
Several parts of
the report
structure
template are
complete.
There is both
introduction and
conclusion which are
related to the work
covered.
The report structure
template has been used
mainly correctly.
There is both
introduction and
conclusion which are
strongly related to the
work covered.
The report structure
template has been
used correctly.
There is both introduction
and conclusion which are
strongly related to the
work covered. The
conclusion has critical
analysis in comparing the
approaches.
The report structure
template has been used
correctly including the
length of text and the
layout of the sections.
There is both introduction
and conclusion which are
strongly related to the
work covered. The
conclusion shows insight
in comparing the
approaches.
The report structure
template has been used
correctly including the
length of text and the use
and layout of sectio
