Assignment 4: Caching In

In this project, your team is going to take a pipelined, multithreaded, implementation of SIK and add a cache system to it. Why? Because memory is slow....

To build your solution, you can use my not-tested-very-well sample solution to the previous assignment (Sick3m.v) and/or any of the versions your team members helped create as a starting point, and you can combine ideas from them any way you wish. However, you're going to have to modify them to use the interface to the slow memory module provided below. Of course, you'll also need to build the instruction and data caches... which is what this assignment is all about.

The Slow Memory

There should be a single main memory shared by all code and data. This slow main memory is a separate module with the interface that we've been discussing -- pretty much the same interface that the memory had back in EE380, but with separate data in and out busses:

• mfc signals when memory fetch is complete
• rdata is the data value you can read when mfc is 1
• addr is the address to read or write from
• wdata is the data to be written
• rnotw is the signal that requests memory to do something; it is 1 to request reading from memory, 0 for writing to memory
• strobe needs to be 1 for rnotw to be examined; a value of 0 says neither reading nor writing is initiated this cycle
• clk needs to toggle with the processor clock; memory events are triggered by the positive edge of the clock

This slow memory module counts clk cycles to delay completion of a memory read for up to 4 clock cycles. During that time, the memory will not accept another read request. However, it will accept write requests and perform them immediately. In fact, if a memory write to the same address being loaded happens while waiting for the load to complete, the load will immediately complete and return the value being written.

Note also that the slow memory is designed so that you do not need to wait for a read to complete before issue of another load -- but the newer load request will abort the earlier one. This is intended to be useful for aborting a prefetch if a real cache miss occurs.

The memory module is called slowmem, and here it is. The delay for a read is set by MEMDELAY, and is currently 4 clock cycles.

The Caches

There will be two caches: one for instructions and one for data. They go it the obvious places in your pipe. Here are the other constraints on their design:

• Each cache should have a size you can adjust by just changing `define values. You should try your code with a cache size of 8 words and a cache size of 256 words. This should show a performance difference even on very small test programs; 8 words is intended to be small enough to force you to have to kick-out entries to make space for new entries.
• The cache associativity is up to you, but each line is to be just one word wide. Obviously, you also have free choice of replacement policy. You'll at least want to track which lines are dirty so you don't have to write-back clean lines.
• Although there are two caches, there is only one interface to slow main memory shared between them. You need to arbitrate between them to determine which goes first in case of a tie. I'd suggest the data cache should go first, since blocking it blocks everything.
• Your design should do automatic prefetch, although I recommend you add this feature after everything is working. For prefetch, I recommend picking the next address in sequence from the instruction cache. Feel free to be clever enough to skip the next address if it is already in cache, or to favor prefetching on the thread that most recently suffered an instruction fetch miss. Also feel free to abort a pending prefetch if a real cache miss occurs -- in other words, give cache misses priority over cache prefetches. Pre-arrival caching also may be used to note that the thing being prefetched is exactly what you want. Note that the instruction cache is read only, so all lines are always clean.

That's all there is to it.

Note that I haven't specified details such as what associativity and replacement policy to use for the caches -- that's up to you. I also haven't specified handling of writes as write-back or write-through, and I haven't written-up how you mark lines as invalid or dirty (although I did discuss these things in class). Keep it simple.

Test Plan

Yes, you still need one. Your project needs to include a test plan (best described in your Implementor's Notes) as well as a testbench implementing the planned test procedure.

The key difference here: your test plan should also be able to demonstrate an improvement as the cache size is increased from 8 to 256 words. Be sure to discuss the performance change you see in the implementor's notes.

Due Dates

The due date for this assignment is before the final exam, Wednesday, May 3, 2017. You may submit as many times as you wish, but only the last submission that you make will be counted toward your course grade.

Note that you can ensure that you get at least half credit for this project by simply submitting a tar of an "implementor's notes" document explaining that your project doesn't work because you have not done it yet. Given that, perhaps you should start by immediately making and submitting your implementor's notes document? (I would!)

Submission Procedure

You should submit a tarball (i.e., a file with the name ending in .tar or .tgz) that contains all things relevant to your work on the project. Minimally, the tarball should include the Verilog and AIK source code for the project and a semi-formal "implementors notes" document as a PDF named notes.pdf. It also may include test cases (e.g., source SIK code and .VMEM files), sample output, a make file, etc., but should not include any files that are built by your Makefile (e.g., no binary executables). Be sure to make it obvious which files are which; for example, if the Verilog source file isn't sick.v or the AIK file isn't sick.aik, you should be saying where these things are in your implementor's notes.

Submit your tarball below. The file can be either an ordinary .tar file created using tar cvf file.tar yourprojectfiles or a compressed .tgz file file created using tar zcvf file.tgz yourprojectfiles. Be careful about using * as a shorthand in listing yourprojectfiles on the command line, because if the output tar file is listed in the expansion, the result can be an infinite file (which is not ok).