代写CMPE 110、代做RISC-V、代写C/C++编程、C/C++语言代做

日期：2018-11-26 10:48

Assignment 1

CMPE 110: Computer Architecture, Fall 2018

Assigned: October 10

Due: October 24 at 3:00 PM

Goals

In this programming assignment, you will be simulating a single-cycle RISC-V processor in C.

For the first assignment, your code will need to implement a single function that takes in the current value of

the program counter and executes a single instruction. To do this, your code will need to read (and perhaps write)

memory, read (and perhaps write) the register file, and produce a new value for the program counter. RISC-V has no

CPU flags (for user mode), so these are the only things your code will need to do.

We’ll provide you with a memory and register file, each of which may be accessed by a simple interface that

we’ll detail below. However, there are limits on how often these access may be made for each call to your “do one

instruction” function. The memory supports one read call and one call that may either read or write a value. The

register file supports one call that reads two registers, and one additional call that writes one register. These limits

are reset when your “do one instruction” function returns.

Your simulator will support a limited instruction set of the RISC-V ISA, restricted to the 32-bit base with 64-

bit extensions (RV32I and RV64I). You must also implement the RV32M and RV64M instructions (multiply and

divide). You need not implement the Synch, System, and Counters instructions from RV32I. You can find a RISCV

Reference Card linked on the RISC-V resource page on Canvas.

Your simulator should be capable of executing simple assembly language programs in RISC-V assembly. You

may want to use a C compiler to write some code, or you can write test code directly 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. While you are not required to complete your design document before starting your

program, it’s highly encouraged and a prerequisite to receiving programming help in office hours. We will gladly

help you with the design in office hours, and you can change it as your assignment progresses.

Code

You will need to write a single function that does all of the work for this assignment:

void execute_single_instruction(const uint64_t pc, uint64_t *new_pc)

This function will take the original value of the program counter, execute the instruction (including function

calls to memory and register file operations), and place the new value for the program counter into the memory

pointed to by the new_program_counter argument. Your function must use this exact name, and must take the

parameters as described above.

The code for this assignment can be large, but it won’t be very complex. You’re encouraged to break your

function into smaller functions to make it easier for you to write. Most of your design will be decoding the fetched

instruction into respective components necessary for the type of instruction. The RISC-V Instruction Set Manual

will be invaluable for this; study it well and the patterns will become obvious. For execution, you may use the built

in C arithmetic expressions. Do not use loops to implement this code—they should not be necessary.

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

Provided Functions

We will provide functions to access memory, and to access the register file.

Memory

There are three functions to access memory:

bool memory_read (uint64_t address, uint64_t *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);

The return value for each call will be a boolean value, where true means that the operation has finished, and

false means that memory is still busy. For the first assignment, the calls will always return true, so you don’t

need to check the return value.

The first two calls are self-explanatory. The first call reads a value from memory, and the second writes a

value to memory. The size_in_bytes argument must be either 1, 2, 4, or 8, and address must be a multiple of

size_in_bytes. If these requirements are not met, the results of the function call are unpredictable; there are no

explicit errors, just as there are no explicit errors in hardware. The third call is used to check on a read that previously

returned false; since that never happens, there’s no reason to use it for Assignment 1.

Each time execute_single_instruction is called, you may make one call to memory_read() to read your

instruction, and a second call to either memory_read() or memory_write(). Further calls will always fail, returning

unpredictable values.

Registers

There are two functions to access the register file:

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);

You may call each function at most once per call to execute_single_instruction. Further calls will always

return 0 for all values.

Since there are only 32 registers, the functions will mask off the register identifiers (register_?) to be 5 bits

long. Register 0 will always read as 0, and writes to register 0 will have no effect, but generate no error. Reads and

writes always operate on the entire register. You may want to take this into account for operations that only affect

part of a register, such as lbu. This may mean that one of the two registers you need to read is the register you plan

to modify.

We’ll provide the memory and register file in the next few days. For now, your efforts should focus on the

design document. You have the prototypes for your function for all of the code we’re going to provide.

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

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

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

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 1, CMPE 110, Fall 2018 - 3 - ? 2018 Ethan L. Miller

Getting Started and General Advice

Meet with your group and set expectations. It is important to do this early, be sure to include: division of labor, coding

style, preferred communication channels and times, scheduled in- person meetings, responsibility for submitting

the final commit ID.

As a group, discuss design before doing any coding. Your design should be solid before you start to code. As

each stage will execute consecutively, starting with a flow-chart will be extremely helpful. You may want to bring

your completed design document to office hours and have it reviewed before continuing.

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 (pipelining, out-of- order execution, branch

prediction, 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.

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

messages.