Assignment 3: A SIK Pipeline

In this project, your team is going to build a pipelined implementation of SIK, the little instruction set design you built multi-cycle implementation of in Assignment 2.

Pipelined Stack Code?

SIK is a stack machine. That is not the kind of model you expect to be pipelining, because there are very frequenlty dependences between adjacent stack instructions thanks to everything operating on the top of the stack. In fact, the changes to the stack pointer itself are effectively serializing dependences! So, how are we going to get any parallelism out of this?

That's really all that's strange. Just keep in mind that a register-based stack machine is really a general register machine with some bookkeeping figuring out which registers we are using rather than just having constant register numbers in the instruction. As you'll see in the pipelined project, it even can be useful to think of there being a separate state in which the bookkeeping determines which registers will be used....

Single-Cycle Starting Point

Remember EE380? Not really? That's ok... just play along anyway. Back in EE380, we followed a rather neat plan in the textbook that basically recommended that a pipelined design could best be created by initially designing a slow single-cycle implementation. The function units, data paths, and control signals defined for the single-cycle implementation could then be used (with only minor modifications) in the pipelined version. It was mostly just a matter of carving the single-cycle design into appropriate pipeline stages. Well, now is the time we see if that approach really works....

I could ask you to design your own single-cycle implementation from scratch, but I'll save us all some time and give you an overview diagram for such a thing right here. You are not required to use the following, but let's start thinking with:

Of course, that leaves out a lot of details... and even then you're not yet ready to start writing Verilog code: design first, code second.

Setting The Stage(s)

One of the first steps in making a pipelined implementation is figuring-out how many stages there should be and what belongs in each.

It is fairly obvious that the memories (including the register file) will take a little while to access, and we all know ALUs are notoriously slow. Thus, we'd expect a stage for each of those things along any circuit path. However, there is also that funny little issue of decoding the register references from each stack instruction, and that's probably worthy of its own stage. That probably gives you at least the four stages shown above in yellow.

So, what else should you be thinking about?

In lectures you got a fairly detailed overview of how to go about designing hardware for a complete computer system. The bottom line is that you should start by defining the set of function units, data paths, and control signals you will need. Define the interfaces and signals. Then build the modules themselves. Note also that for this project, you are allowed to use things like the Verilog + operator to build an adder: you need synthesizable Verilog, but you don't have to specify things at any particular level. You are also free to use earlier project work from any of your team members, or the sample solutions for previous projects, as resources in creating this project; if you reuse significant portions, be sure to state that in your implementor's notes. My sample solution for the previous project, as was presented in class, is the following AIK specification and Verilog code.

Let's be completely clear about what I expect: your submission should be a viable four-or-more-stage, two-threaded, pipelined Verilog implementation of the SIK instruction set. For this project, I expect you to treat the instruction memory and data memory as able to sustain one access each per clock cycle; it is up to you if you treat them as a unified memory or as Harvard-style separate instruction and data memories. Of course, all significant design decisions made should be discussed in your Implementor's Notes.

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.

I strongly recommend writing a test program that tells you what failed by where it halts... but keep in mind that you will be running two threads interleaved. Thus, you'll need to have some way to intialize the two PCs, and you'll need the code for both programs loaded into memory somewhere. Despite that, the Verilog portion of your testbench can be something very simple, like:

module testbench;
reg reset = 0;
reg clk = 0;
wire halted;
processor PE(halted, reset, clk);
initial begin
  $dumpfile;
  $dumpvars(0, PE);
  #10 reset = 1;
  #10 reset = 0;
  while (!halted) begin
    #10 clk = 1;
    #10 clk = 0;
  end
  $finish;
end
endmodule

This just enables trace generation, intializes everything with a reset, and then keeps toggling the clk until the processor says it has reached a halted state.

Note that my online Verilog WWW interface allows use of $readmem directives, so it is much simpler to use that mechanism to initialize memory for your test cases. Include any such files in your submission as files with names ending in .vmem (to indicate that they are Verilog memory initialization files).

Due Dates

The recommended due date for this assignment is before class, Wednesday, April 5, 2017. However, the submission window will close when class begins on Monday, April 10, 2017. You may submit as many times as you wish, but only the last submission that you make before class begins on Monday, April 10, 2017 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 sik.v or the AIK file isn't sik.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).

Your team name is .
Your password is


EE480 Advanced Computer Architecture.