FAST – Department of Computing

FAST – Department of Computing

MODULE: CSYM028 2020/21

 

 

 

Module Code Level Credit Value Module Tutor

CSYM028 7 20 Dr. Michael Opoku Agyeman

 

 

Assignment Brief

Assignment title:

Modern Computer Architecture

Weighting:

100%

Deadline (Resit):

16th May 2021 (11:59pm)

Feedback and Grades due:

 

(to be confirmed)

Resit Information

– This is a resit assignment (capped to C-) – First sit for those with extension due to

mitigating circumstances approved (not capped)

 

 

 

 

FAST – Department of Computing

Modern Computer Architecture

Date: 8/03/2021 Note: You are to submit your document in word format. ‘The module tutor reserves the right to invite students to a meeting to discuss coursework submissions’ Deliverables :

1. Links to your designs in Tinkercad. Take a snapshot of the last edited information, as well as the image of your final design and paste below each link.

2. Links of demos recorded or hosted on Kaltura (Make all links visible on the front page). Note that this is one way of rectifying that the final Submission is your own work and hence you must submit in order to get a pass grade.

a. In your demo, give a detailed explanation as to how your code works b. Remember to use different tools such as whiteboard or Paint, datasheets,

Arduino IDE for memory analysis etc. to explain underlining principles into details. c. Wherever, possible use live coding to demonstrate your strengths d. If you started off your code with Arduino functions, such as “Pinmode()”, and have

managed to use direct register manipulation to improve your code, remember to demonstrate the logic behind it in both your report and the video. This is highly recommended.

3. Flowcharts. Note, this is one way of showing how you have developed your solution 4. Program code with comments – this must be in TEXT format. No screenshots allowed,

except of codes which I have provided you and have given you permission to use as part of your implementation (in which case, there will be no credit assigned to such code).

5. Description of how the code works 6. User Guide – Provide scenarios of inputs that should demonstrate the required features

specified in this brief and also provide expected results. This can be provided in a table format.

7. Evaluation of the output – Provide your observation, reflection and analysis.

Important:

• Except for the IR Remote library, do not use any library or macro function that has not been used in class.

• Do not use any electronic component that has not been used as part of the class activities, except for the IR Remote and receiver.

• Start your design with “pinMode()”, digitalWrite() and digitalRead() functions to complete your first working logic. Create a duplicate for amendment towards your final design.

 

 

FAST – Department of Computing

• Do not use “pinMode()”, digitalWrite() and digitalRead() function in your final code. Make use of direct manipulation of the ATmega328P register contents. Example:

DDRB = DDRB | B00100000; PORTD |= (1 << PORTD2);

• Use “Kaltura” for all your videos and make sure that anyone with the link to the video can view the content.

• Your code must be in text format.

• Citing code from online sources is not permissible Task Using an 8-bit microcontroller based on the AVR enhanced RISC architecture (ATmega328P), complete the following: Part 1: Arcade Game 1 Using multiple LCD Screens (at least 3), sound output, switches and input sensors, implement a fully functional arcade game in Tinkercad. The game should have at least two game play levels. Note – It is expected that the game you select will most likely be unique to you compared to that of other students doing this assignment – It is expected that the layout and/or logic implementation of different levels of the game will be unique to you. – The following arcade games are omitted from this assignment: Pacman and Tetris. Hence, do not implement these games.

 

 

FAST – Department of Computing

Part 2: Game Design 2

1. Build a game that challenges a player’s reaction time by making them stop a sweeping series

of RGB LEDs at a specified point within the series. Use 5 RGB LEDs, 5 pushbuttons and make the RGB LEDs cycle through the colours (random sweep) at a faster rate. The challenge for this game is the amount of time a player has to react. The game appears to move faster when the time a single RGB colour is on before the next colour. a) To achieve a level completion the player has to press a button while its corresponding

RGB LED colour is on. i) Therefore, if RGB LED orange is on, button labelled “orange” must be pressed to win. ii) Challenge: Use an interrupt to create a cheat for reaction to a specific colour. Thus,

the game should give priority to a specific button corresponding to that colour. b) The game should use 5 RGB LEDs and 5 pushbuttons; the winning RGB LED colour is the

one whose button with corresponding colour label is pressed. c) After each level is complete or micro-win, the game will decrease the time each RGB LED

is on before moving on to the next stage. A micro-win will flash an alternating colour pattern on the RGB LEDs. Make sure your RGB LED flashing pattern is most likely unique to your design.

d) After 8 micro-wins, a more elaborate pattern will flash, signifying a big win. e) If an attempt fails, the game will reset back to the first level, and the succession

to the big win and will be restarted. h) Before starting the game, a player should be given 6 lives.

i) Each 5 consecutive big wins should add an additional life to the player.

 

 

FAST – Department of Computing

ii) 0 signifies when a player has no token and hence should not be allowed to play the game

iii) 4 fails should cost the player a life. i) In addition to the above, use sound to notify the status of the game. This should include

different sounds for i) a big win ii) a micro-win iii) a fail

j) The status of the game should be displayed on an LCD and the RGB LEDs. i) On the LCD, this should include

• The current micro-win, the remaining micro-wins (or score) to a big win, a fail and a reset.

• Number of lives remaining

• An indication of a big win, micro-win, fail and reset. ii) On the RGB LEDs use different display patterns for:

• a big win, a micro-win and a fail

• when the game resets due to a fail

Optional/Extra Credit – Part 3: Game Design (Proof of Concept)

 

Build a game that challenges a player’s reaction time by making them stop a sweeping series of LEDs at a specified point within the series. However, this time, use 8 LED, 8 pushbuttons and make the LED sweep at a faster rate. The challenge for this game is the amount of time a player has to react. The game appears to move faster when the time a single LED is on before the next one lights up is lowered.

f) To achieve a level completion the player has to press a button while its corresponding LED is on. i) Therefore, if LED 0 is on, button 0 must be pressed to win. ii) Hint: think of interrupts

g) The game should use 8 LEDs and 8 push buttons; the winning LED is one whose button with corresponding position value is pressed.

h) After each level is complete or micro-win, the game will decrease the time each LED is on before moving on to the next stage. A micro-win will flash an alternating pattern on the LEDs. Make sure your LED flashing pattern is most likely unique to your design.

i) After 5 micro-wins, a more elaborate pattern will flash, signifying a big win. j) If an attempt fails, the game will reset back to the first level, and the succession

to the big win and will be restarted. k) Before starting the game, a player should be given 5 lives.

i) Each 3 consecutive big wins should add an additional life to the player.

 

 

FAST – Department of Computing

ii) 0 signifies when a player has no token and hence, should not be allowed to play the game

iii) 3 fails should cost the player a life.

 

 

FAST – Department of Computing

 

 

 

FAST – Department of Computing

Make sure you read the section on “How to Document Programs”!

Dr. Michael Opoku Agyeman Hand in Date: 16/05/2021

How to Document Programs

1. The two golden rules when writing programs are:

a. Whenever possible, test sections of code you want individually. Don’t write the complete program and then try to find faults.

b. Do some design! Think the program through before you begin writing your code. 2. There are two general types of people who will read your programs, namely:

• The user of the program and someone who may want to modify it.

 

 

FAST – Department of Computing The user of a program needs to know how to run it, what it needs and what it does. Thus, the beginning of your program should have the following information:

• A general statement about what the program does. Notice this is what it does, not how it does it.

• How to run the program, including any information on options and arguments.

• Any active program requirements. This includes any input the user must provide.

• What output the program generates and where it goes?

• Any assumptions the program makes about its environment. For example, if your program expects to be able to write to the current directory, you should say so. If it needs to use

standard data from a particular place this must be documented, including where it must be,

and its format.

The goal of documentation in the program header is to get the user to read it! This means that too much documentation is as bad as insufficient documentation. Avoid documenting things that are obvious. Keep documentation concise and organize it so that it is easy to read, with the most important points at the beginning or otherwise highlighted. Example Header:

/*–

**********************************************************

****************************-

— Produced By: Computer Systems Engineering @ UoN

— URL: https://mypad.northampton.ac.uk/smartsc/ — Author: Dr. Michael Opoku Agyeman

— Date: Yesterday/This Month/This Year

— Purpose: To do something cool!

— Modifications: Mr. somebody else *today* fixed my bug

**********************************************************

*************************** –*/

Each function and interrupt routine should also have a header e.g.

/*–

**********************************************************

****************************-

— Date: Yesterday/This Month/This Year

— Purpose: To do something cool!

— Called by: some other Entity/process

— Modifications: Mr. somebody else *today* fixed my bug

**********************************************************

*************************** –*/

 

 

 

FAST – Department of Computing The second audience is a person who may wish to modify it. This person will be an embedded system ‘C’ programmer with expertise as extensive as yours. This person needs to know how your program does what it does. This type of documentation needs to be in the body of the code, with the pieces of code it documents. Remember, this person has expertise, so the only things necessary to document are things that are not completely obvious. If you are using an assignment statement, don’t explain how it works if it is obvious. A comment explains what an output may do in the real world will be more helpful. Documentation in the body of the code (called inline documentation) should not be added to the right of the code. Instead add entire lines of the documentation above the section of the code being documented. Although it should be obvious, ensure that your documentation is correct. Documentation is so important it will be worth 15% of the grade of each program. Style Your program should be easy to read. This means that the flow of control should be obvious, the names of the variables descriptive and the design as simple as possible.

Make use of white space. Use it for logical blocks of code that are processed similarly:

• put a blank line after a closing } that ends a block.

• put spaces after commas.

However:

• If every line of code is separated from the next by a blank line, there are too many blank lines.

• If there is neither rhyme nor reason readily discernible for where blank lines are placed, then they are a distraction and there are usually too many of them.

• If a function is so big that it needs many blank lines, it is too big.

• If a block of code needs more than one blank line before or after it, there is something seriously astray.

• If you have more than two blank lines between functions, you probably have too many blank lines.

Make good use of functions including parameter passing.

Proper style requires the use of consistent indentation and white space.

You should also ask yourself the following questions:

• Is your solution well designed?

• Did you complete one part of the task before starting another?

• Did you give the user sufficient information?

A rubric containing the marking criteria is located at the end of this document. Dr. Michael Opoku Agyeman

 

 

FAST – Department of Computing Hand in Date: 24/01/2021

Assessment Item

Grading Rubric

A B C F

Idea Generation (Design) and Code Functionality (Implementation) Learning Outcomes: a, b, c, d, e, f

Excellently laid out and prepared portfolio. Demonstrates the ability to communicate clearly and smoothly. Follows the guidelines provided in the assessment brief notes to an outstanding degree. Rational for entry can be easily identified, be understood and includes all required information. Documents and implements more than 80% of full assignment correctly. Implementation and results can easily be repeated by following video tutorial and documentation. Design specification is logical and coherent. Appropriate methodologies are used, and all elements of these methodologies are skillfully developed. Exceptional level of development with fully functional and completed outcome. Shows considerable attention to details. Clear evidence of testing and refinements made. A coherent testing strategy was used. States a conclusion with justification, based on a reasonable interpretation of the data. Evaluates weaknesses and limitations. Suggests realistic improvements Show an excellent understanding of the task. Shows an

Well laid out and prepared portfolio. Demonstrates the ability to communicate clearly and smoothly. Follows the guidelines provided in the assessment brief. Rational for entry can be easily identified, be understood and includes nearly all required information. Documents and implements more than 70% of full assignment correctly. Implementation can be repeated by following video tutorial and documentation. Design specification is mostly logical and coherent. Appropriate methodologies are used, and some elements of these methodologies are well developed. High level of development with a mostly completed and functional outcome. Shows a good level of attention to details. Evidence of testing and refinement made. A coherent testing strategy was used. States a conclusion based on a reasonable interpretation of the data. Identifies some weaknesses and limitations. Suggests some improvements Shows proficient understanding of the task. Shows proficient understanding of how technical aspects are

Reasonably well laid out and prepared portfolio. Demonstrates the ability to communicate basically. Rational for entry can be somewhat identified, be understood and includes nearly all required information. Documents and implements more than 60% of full assignment correctly. Implementation can be repeated with some effort by following video tutorial and documentation. Design specification is reasonable. Some appropriate methodologies are used, and some elements of these methodologies are developed. Satisfactory level of development with a partially completed and partially functional outcome. Shows a reasonable attention to details. Satisfactory evidence of testing but not much evidence that refinements were made. A basic testing strategy was used. States a conclusion with justification, based on a reasonable interpretation of the data. Evaluates weaknesses and limitations. Suggests only superficial improvements. Shows a good understanding of the task. Makes a sound observation f the problem and is able to analyze some but not all of the more technical aspects of the problem. Good review and analysis of the underlying theory. Satisfactory and clear, satisfactory level of

Basic or poorly prepared portfolio. Little ability to communicate. Can explain a few of the main ideas, be partially understood and includes a little of the required information. Documents and implements less than 50% of full assignment correctly. Basic or poor design methodology with little or no effort to use any design methodology. Basic or poor level of development with an incomplete and partially or non-functional outcome. Shows little or no attention to details. Little or no evidence of testing and no evidence that refinement was made. No reference to indicate that a testing strategy was used States a conclusion which is based on poor interpretation of the data. Poorly written conclusions Identifies weaknesses which are irrelevant. Suggests irrelevant/no improvements. Shows basic or no understanding of the task. Doesn’t seem to have a grasp of the problem and is unable to analyze the more technical aspects of the problem. Poor review and analysis of the underlying theory. Has not presented convincing statements, needs complete

 

 

FAST – Department of Computing

excellent understanding of the way that the technical aspects are combined to produce the system. Exceptionally thorough review and analysis of the underlying theory. Original &/or distinguished idea, has shown exceptional level of individual competence

combined to produce the system. Thorough review and analysis of the underlying theory. Clear and well- developed Statements.

individual intellectual capability in dealing with challenges.

rethinking of the statements.

Assessment Submission

To submit your work, please go to the ‘Submit your work’ area of the Module

NILE site. It is important that you submit your work to the correct module

NILE site, and that your work is submitted on time.

 

Academic Practice

This is an individual assignment and you are expected to work independently.

The University of Northampton policy will apply in all cases of copying,

plagiarism or any other methods by which students have obtained (or

attempted to obtain) an unfair advantage.

Support and guidance on assessments and academic integrity can be found

from the following resources

SkillsHub: http://skillshub.northampton.ac.uk

CfAP: http://tinyurl.com/UoNCfAP

Module Learning Outcome

Subject-Specific Knowledge, Understanding & Application

a) Demonstrate reasonably deep issues underlying the design of modern computer architecture

b) Analyse a fairly complex problem and justify the possible solutions

c) Appraise the consequences of certain architectural decisions on the actual performance or power consumption of the processor

 

 

FAST – Department of Computing

d) Evaluate and explain specific tradeoffs between complexity/ cost/performance/power-consumption in modern computer systems

Changemaker & Employability Skills

e) Be an independent and self-critical learner, guiding the learning of others and managing own requirements for continuing professional development

f) Reflect on own and others’ functioning in order to improve practice

You didn't find what you were looking for? Upload your specific requirements now and relax as your preferred tutor delivers a top quality customized paper

Order Now