代做CMPE 110、代写RISC-V CPU、代写java/c++、代做python

日期：2018-11-26 10:49

Assignment 3

CMPE 110: Computer Architecture, Fall 2018

Assigned: November 9

Due: November 21 at 3:00 PM

Goals

For this programming assignment, you’ll augment your code from Assignment 2 by adding a split instruction and

data cache to your pipelined RISC-V CPU. The instruction set is the same as for Assignments 1 and 2, and the

framework is largely unchanged from Assignment 2, with the small changes listed in the next section.

By simulating caches, you’ll better understand how caches work (you’ll have to write code simulating them) and

will understand how to add variable pipeline delays to a RISC-V pipeline.

Your simulator will operate the same as in previous assignments, and must be capable of executing simple

assembly 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. As with previous assignments, a good design is essential to getting your simulator

to work properly. Make sure that you and your group go over the design to ensure that it works properly before

starting to write code. A good design will make your code straightforward, but no amount of skillful coding will

enable a poor design to work.

While we are happy to go over your design document with you and your group, you will not recieve any help

with your code without a minimal working design document.

Code

Assignment 3 builds on Assignment 2, adding caches and adapting the pipeline to handle variable-length stalls.

Caches

You’ll need to implement two caches for this assignment: an instruction cache (I-cache) and data cache (D-cache).

These should be implemented as arrays. They may be arrays of structs, or they may be done as “parallel” arrays,

one containing cache data and the other containing cache metadata (tags, valid bits).

You should write one set of functions to access a cache, and use the functions to access both your I-cache and

D-cache as necessary. The functions should take a pointer to the cache as their first parameter, and will likely need

to take parameters regarding the cache (cache size, number of lines, block size, etc.). You may find it useful to define

a struct representing an entire cache, with the parameters as members and a pointer to the cache array(s). If you

do this, your cache access functions would only need to take a pointer to an instance of this struct.

Your caches are direct-mapped, and have the following characteristics:

I-cache: 8 KiB, 16 byte block size

D-cache: 16 KiB, 8 byte block size, write-through

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

Pipeline changes

You’ll be accessing the caches in the Fetch (I-cache) and Memory (D-cache) stages. However, if the memory you

want isn’t already in the cache, you’ll need to stall your pipeline to fetch it. This will require modifying the pipeline

you wrote for Assignment 2 (please see Assignment 2 for further details) to allow it to stall if requested data isn’t

available.

To make these changes, memory_read() and memory_write() will now return a bool that’s true if the

operation succeeded and false if it’s still pending (not yet done). If memory read returns false, data copied

into the value pointer will be incorrect. There’s an additional call:

bool memory_status(uint64_t address, void * value)

that can be used to check the status of a previously-made memory_read() or memory_write() call. If the call has

finished, memory_status() will return true and, if the address was being read, will copy the memory value to

the passed pointer. IMPORTANT: this pointer need not be the same one as the one used in the memory_read()

call; in fact, there’s a good chance it won’t be. Instead, you should call memory_status() from either the Fetch or

Memory stage if there’s a pending operation, passing the address into which the values should be copied. DO NOT

PASS POINTERS IN THE STAGE REGISTERS. EVER.

Your memory reads should all be the length specified by the cache block sizes above. Memory writes should be

their “natural” size. If you have a write miss on your D-cache, your simulator should “write around” the cache: it

should write the value to memory and leave the D-cache unmodified. (On write hits, the D-cache should be updated

along with the memory.)

Obviously, your pipeline must stall as long as a memory operation is outstanding; your simulator should insert

stalls as necessary to handle this.

Note, too, that it’s possible you might encounter two misses on a single cycle, one in the I-cache and one in the

D-cache.

Other changes

We’re going to tighten the restrictions on register file access and on memory access. Register file reads will only

be allowed in the Decode stage, and register file writes will only be allowed in the Writeback stage. If your code

already does this (following the requirements from Assignment 2), these changes won’t affect you. If not, you’ll

need to ensure that your code meets the Assignment 2 requirements. Similarly, memory reads will only be allowed

in Fetch and Memory, and memory writes will only be allowed in Memory. Again, this matches the design you

should already have implemented; if so, your code won’t need to change.

Provided Functions

The only change to the framework is listed above, and deals with memory accesses. Otherwise, the framework

interface is the same as for Assignment 2; see that assignment for more details.

The framework provides an additional variable that counts the number of cycles that have been executed since

the simulator started. You can print this value using the (new) cyclecount simulator command.

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

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

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

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 3, 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 code:

How can my code access and modify the caches?

How do I stall the pipeline on a cache miss?

How do I check to see when the pipeline can resume, and how do update the cache?

What happens if there are two cache misses on the same cycle?

You will build on this project in the last assignment, so you should design your code to be modular and

expandable. Think about upcoming topics (virtual memory translation) and how your code will handle them.

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. You can assemble code using the Web form at http://elm-vm-1.

soe.ucsc.edu/cmpe110/riscv-assemble.html

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.

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

messages. If you want to demonstrate that you’ve been working on your design and code throughout the entire

assignment period, the best way to do so is your git commit log.

Extra Credit

There are two ways to get extra credit on this assignment. However, you must do the following before starting on

the extra credit:

Commit (to GitLab @ UCSC) working code and design document for the “regular” part of the

assignment.

Submit (via Google Form) the commit ID of this commit.

Once you have done this, you may start on either or both extra credit goals.

1. Implement a two-way set-associative write-back D-cache. The parameters in the regular assignment remain

the same, but you need to implement writeback (with possible stalls in doing so) and two-way set associativity.

The D-cache should be write-allocate: on a write miss, it should read the cache line into the cache before

modifying it by writing the new value.

2. Implement a unified Level 2 cache. This cache should be 128 KiB, two-way set-associative, block size 32 bytes

and writeback. Like the first extra-credit cache, this cache should do write-allocate on write misses.

Don’t submit the commit ID for extra credit to the Google Form. Instead, submit it as part of the writeup you

turn in via Canvas. Your extra credit commit should include your design document and code modified to satisfy one

or both extra credit goals. Since you committed your “regular” design and code, we can look at both if necessary.

IMPORTANT NOTE: late submissions (after the due date) are ineligible for extra credit.

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