CMPE 110留学生代做、代写C/C++程序、代写Architecture、代做C/C++设计

日期：2018-11-26 10:48

Assignment 2

CMPE 110: Computer Architecture, Fall 2018

Assigned: October 29

Due: November 7 at 3:00 PM

Goals

For this programming assignment, you will be writing C code to simulate a RISC-V processor that executes in a

5-stage pipeline with branch prediction.

This assigment will build on the simulated RISC-V processor that you developed for Assigment 1, and you are

encouraged to reuse your code. You will need to support the subset of the RISC-V ISA including RV32I, RV64I,

RV32M, RV64M, but not Synch, System, and Counters instructions (same instruction set as Assigment 1).

Your simulator will operate the same as last assignment and must be capable of executing simple assebly language

programs in RISC-V assembly.

Details and Requirements

Design Document

As part of the assignment, you are required to create and submit a Design Document detailing the structural and

logical design of your program. This assigment will involve a more complex design than the last, so it’s even more

important to do the design before you write a single line of code. You will not recieve any help without a minimal

working design document.

Code

Pipeline

You’ll need to write five fuctions (replacing void execute_single_instruction) that simulate each stage of the

pipeline:

void stage_fetch(struct stage_reg_d *new_d_reg)

void stage_decode(struct stage_reg_x *new_x_reg)

void stage_execute(struct stage_reg_m *new_m_reg)

void stage_memory(struct stage_reg_w *new_w_reg)

void stage_writeback(void)

To communicate between stages, you will use the provided stage register structures:

struct stage_reg_d{...};

struct stage_reg_x{...};

struct stage_reg_m{...};

struct stage_reg_w{...};

The structures are defined in riscv_sim_pipeline_framework.h. You’ll need to modify these structures,

adding fields to allow passing of any values you wish, but you may only use these structures to pass information

between stages.

Assignment 2, CMPE 110, Fall 2018 - 1 - ? 2018 Ethan L. Miller

You’ll need to implement stalling and data forwarding to handle hazards (RAW and WAR). You can implement

stalls by replacing the next instruction to execute with a NOP (of your desing) using the stage registers. Make sure

to follow concepts discussed in class for forwarding.

Each stage register can be accessed as input to any stage of the pipeline. When accessing data retrieved from the

register file in a particular stage, you are to avoid unecessary ALU operations on the values. Shifts and masks are

OK; additions and subtractions (let alone multiplications and divisions) are not.

Each stage may only write values to the output register passed as a parameter to the stage_? function. For example,

stage_fetch may only write to new_d_reg. The values in new_d_reg will be copied to current_stage_d_register

(defined in riscv_pipeline_registers.h) at the end of the cycle (after all stages have executed), and will thus

only be available to stages in the next cycle.

Branch Prediction

You’ll need to create a branch predictor using a Backwards Taken Forwards Not Taken (BTFNT) implementation

with a 32-entry Branch Target Buffer (BTB). The BTB will allow you to determine the target address of a branching

instruction within the Fetch Stage. The BTB should hold target addresses in a structure (ie: array) that can be

indexed by the tag of the branching instruction addresses, as we’ve discussed in class. Fetch will handle BTB hits

and misses accordingly. The BTB should be updated in a later stage (typically Execute), once the target address

is known. (The ALU operation of adding the offset to the PC takes the entire Decode stage.) Remember that only

backwards branches should have a target stored in the BTB, since forward branches are predicted not taken, and thus

shouldn’t update the PC in the Fetch stage with the branch target.

For extra credit, you may implement your branch predictor using a 2-bit branch prediction scheme instead of

the BTFNT scheme. This will require you to create a Branch History Table (BHT) in addition to the BTB. The BHB

will need to be accessible in Fetch and indexed similar to the BTB.

Provided Functions

The framework has been updated to include the pipeline structures and will execute each stage in-order. Additionally,

the program counter will now be accessed and updated using:

void set_pc (uint64_t pc);

uint64_t get_pc (void);

The memory and register accessing functions remain the same from Assignment 1 and are as follows:

bool memory_read (uint64_t address, void * value, uint64_t size_in_bytes);

bool memory_write (uint64_t address, uint64_t value, uint64_t size_in_bytes);

bool memory_status (uint64_t address, uint64_t *value);

void register_read (uint64_t register_a, uint64_t register_b,

uint64_t * value_a, uint64_t * value_b);

void register_write (uint64_t register_d, uint64_t value_d);

Logistics

This assignment will be completed as a group, and each member must make a meaningful contribution. Your group

will need to maintain the assignment on GitLab @ UCSC. You should be committing and pushing code regularly.

This allows you to demonstrate progress, roll back if a change breaks your code, and see what you’ve changed to

get something to work (or not work). It also serves as a backup in case you lose your computer. Your git repository

Assignment 2, CMPE 110, Fall 2018 - 2 - ? 2018 Ethan L. Miller

should only contain source code and any documentation you plan to submit, along with (optionally) assembly code

you’re using for testing. It may not contain object code (.o files). Your TAs and professor will be available to

help with issues and advice relating to git, but we can’t help if you don’t commit/push often and if you don’t use

meaningful commit messages.

Your program will be graded by cloning, checking out the submitted commit ID, building, and running on the

UCSC Unix Timeshare. Your repository must contain and build with a Makefile. If your project does not compile

on the UCSC Unix Timeshare, you will receive a maximum grade of 10% on the project.

Deliverables

Git Repository

At a minimum, your repository must include the following elements:

Design Document: design for your code. Acceptable formats are PDF and plain text. The design

document must be named designdoc.pdf or designdoc.txt, as appropriate. You may commit

source files for the design document to your repository, as long as they’re small (under 1 MB each).

README file: top-level description of the program and includes and notes that may be helpful to

the graders (bugs, requirements, incomplete functionality). If you have any test plans, they should

go here. Must be a plain-text (ASCII) file named README.

Code and Makefile: your repo should contain your code and a Makefile that builds your code.

We’ll supply the “wrapper” code; your Makefile should build it as well.

Canvas

As part of the final submission, each team member must individually submit (on Canvas) a 2– 3 paragraph writeup

that describes separately the work they did, and the work their teammates did. Each submission must also include

the names and CruzIDs of your partners, as well as the commit ID that you want graded, which should match the

commit ID you submitted as a group (see below).

Google Form

The group must also submit a commit ID to a Google form, linked from the assignment description in Canvas. This

form will validate that the commit ID is a 40 character hex value, making it less likely that a typo will result in an

invalid commit ID. We’ll grade the latest commit ID submitted from each group, as long as one is submitted before

the deadline. If none is submitted before the deadline, we’ll use the first commit ID submitted after the deadline,

and mark the assignment late accordingly. Note that each group need only submit one commit ID; there’s no need

for group members to each submit to this form.

Grading

We will grade your assignment by running programs similar in complexity to a provided test program and comparing

the resultant memory to its expected values.

In addition to program functionality, you will be graded on design and on style. Your design needs to be deliberate

and representative of your understanding of the material. Your code needs to be clean, consistent, commented,

and easy to follow.

Assignment 2, CMPE 110, Fall 2018 - 3 - ? 2018 Ethan L. Miller

Getting Started and General Advice

Create your design document, as a group, right away. Then get a TA to review your document and give you feedback.

A good design document will simplify splitting up the work between team members and will help each team member

understand what they need to do. This is more important in this assignment as the division of work may not be

obvious.

Consider the following when designing your pipeline and branch predictor:

What does each stage need to know to avoid hazards and to function properly?

How do I flush the pipeline if there is a mispredict?

What is the minimum necessary information to keep in the BTB?

How do I calcualte the BTB tag? How do I handle BTB misses?

You will build on this project in future assignments and should design your code to be modular and expandable.

Think about upcoming topics and how to prepare for them (out-of- order execution, caching, etc.).

Test your project! You should be testing your project on the Unix Timeshare by cloning a fresh copy and

building with your Makefile. You will be provided with a simple test-bench but consider writing your own. The

TA’s can go over this in section or office hours.

Do extensive unit testing! You can test each stage of your pipeline separately by creating “pre-defined” values

for the stage registers and seeing if your stage does the right thing given a particular set of values for the input stage

registers. Your design document should make it easy to write these tests, since you can say what each stage does and

how it should behave.

Minor simulator command changes. The simulator has changed slightly. Please read the assignment on

Canvas for details, and for links to the framework files.

As always, get started early, commit and push your code often, and write meaningful comments and commit

messages.