Processor Project

1 General Description

As a team, you will design a "miniscule instruction set" general purpose processor that can execute programs stored in an external memory. You will also model your design, test it, debug it, and assess its performance. Throughout the project, you will maintain current documentation for your design, as well as an ongoing record of your design process. Each team will present their design to the class.

The project is organized into regularly scheduled milestones that will guide you through a top-down design process. For each milestone, you will submit your current design documentation and an activity journal.

This is a big project and the milestone schedule allows little room for error. Later milestones tend to require more effort. If at all possible, you should work ahead of the schedule and even complete the project early.

2 Learning Objectives

In the process of completing the final project, students will develop their abilities to:

3 Completion Requirement

Because of the central role that the project plays in satisfying the learning objectives of this course, students must satisfactorily complete the project in order to pass the course.

4 Teams

The project will be completed in teams of 3 or 4. Teams will be formed using your input. Here are factors that may be considered when forming teams:

5 Weekly Meetings

When the project begins, each team will schedule a weekly design review meeting with their instructor. Plan for meetings to last about 15-30 minutes. Your instructor may use the design review meetings to quiz you about your design, so be prepared.

6 Requirements

Your processor must be capable of executing programs stored in an external memory with which it communicates using:

Your instruction set:

Additionally, your processor could support some of these:

All other design choices (RISC vs CISC, number of instructions, etc.) are yours to make. Designs will be evaluated based on their ability to perform general-purpose computations, the performance on those computations, the resources required and the interestingness of the design. See the project rubric for details on how projects will be evaluated. The rubric is not intended to be exhaustive.

In order to demonstrate that your processor has met the requirements, you must implement a program that computes the relatively prime value for a number using the Euclid algorithm.

7 I/O

Your processor must read in an input from the 16 bit data port and pass that value as an argument to relPrime. The result should then be put on the output wire. Your processor must be able to take in a second input and run relPrime again within the same simulation. Your final test bench will look something like this:

   module complete_datapath_tb();

    //inputs
    wire rst, CLK;
    reg [15:0] IN;

    //outputs
   wire [15:0]  OUT;

    complete_datapath UUT (
        .reset(rst),
        .input_port(IN),
        .output_port(OUT),
        .CLK(CLK)
        );

    //block to run the clock

    initial begin
        rst = 1;
        #(PERIOD);

        IN = 16'h13b0;
        rst = 0;
        @(OUT != 0);
        #(PERIOD);

        rst = 1;
        #(PERIOD);

        IN = 16h'1234;
        rst = 0;
        @(OUT != 0);
        #(PERIOD);

        $stop;
    end
    endmodule

This code is not fully functional, and is just meant to give you some guidance on what your should be structured like. Note that this simulation will run 2 separate inputs through relPrime and return both the values.

7 Interrupts

If you choose to implement interrupts, the details below should guide you. If interrupts are supported, the main program would consist of initialization followed by an infinite loop, and the program would respond to interrupts from two input devices. The interrupt mechanism facilitates the communication between the processor and the outside world.

8 Euclid's algorithm

For two numbers to be relatively prime, their greatest common divisor (gcd) must be one (i.e. they must have no common divisors other than one). Euclid's algorithm is used to determine the gcd of two numbers. The following is a high-level language specification for a program that your processor must be capable of executing. The program determines the relatively prime value to an input number using Euclid's algorithm.

// Find m that is relatively prime to n.
int
relPrime(int n)
{
   int m;

   m = 2;

   while (gcd(n, m) != 1) {  // n is the input from the outside world
     m = m + 1;
   }

   return m;
}

% http://dystopiancode.blogspot.com/2012/08/euclids-gcd-algorithm-in-ansi-c.html

// The following method determines the Greatest Common Divisor of a and b
// using Euclid's algorithm.
int
gcd(int a, int b)
{
  if (a == 0) {
    return b;
  }

  while (b != 0) {
    if (a > b) {
      a = a - b;
    } else {
      b = b - a;
    }
  }

  return a;
}

Note: There are many ways to determine a relatively prime value to a given number. This particular specification is chosen to test the performance of your processor.

9 Documentation

As you design your processor, keep the following in mind:

Documentation is an important part of your project. This is how you will communicate your ideas to the rest of world. Therefore, it is important to document your design process as well as your design. For this project, you will do it through several documents.

Design Document: : Describes the design in sufficient detail for an outsider to completely understand it. More specific suggestions along these lines are included in the Milestones section below. This part of the documentation should be continuously updated to reflect the current status of the design. All group members are responsible for maintaining the design document.

Design Process Journal: : Records the process by which the current design was developed. An outsider should be able to read this document and know the design options that have been considered, the design decisions that have been made, and the rationale for those decisions. This part of the documentation should be continuously appended to and reflect the complete history of the design. Each group member is responsible for their personal journal.

All documentation should be high quality product in electronic form. ASCII, text and handwritten documents are not acceptable. PDF, html and Word are examples of acceptable formats. Neat and legible, scanned diagrams are acceptable for all but the final project presentation and final project report.

All materials will be submitted to your team's repository. Make sure that your design documents are easily recognized. Never check in multiple design docs. You may be penalized if your instructor cannot find your design. Keep your repository organized. For example, after completing Milestone 5, your directory may look like this:

Design <dir>
  Design document.pdf
  Journal-mellor.pdf
  Journal-stammsl.pdf
  Journal-williarj.pdf

Implementation <dir>
  ... many processor files ...

10 Milestones

The project is organized into regularly scheduled milestones that will guide you through a top-down design process. For each milestone, you will specify your processor at the next lower level of abstraction, verify that your new specification satisfies the requirements imposed by the previous level, and state the requirements for the next level of specification. For example, the first part of milestone one essentially requires you to

By doing so, you are

This is a big project and the milestone schedule allows little room for error. Later milestones tend to require more effort. If at all possible, you should work ahead of the schedule and even complete the project early.

11 Presentations

Each team will present their project to the class. Presentations should include an overview of your design, highlighting unique or interesting features and a demonstration of its functionality (i.e. run it for us). Each team member must contribute in a substantial way. Presentations will be peer reviewed.

12 Final Documentation

Your final report will be a substantial document. It should include a cover page, a table of contents, an executive summary, an introduction, the body, a conclusion, and appendices. The body should summarize and discuss your instruction set design, your implementation, your testing methodology, and your final results. Except for the appendices, the report should be written as if the reader is familiar with computer architecture, but not with this project.

As an example of a professional report on a processor you can reference the data sheet for the MIPS R4300i processor.

13 Summary of Milestones

Deliverable
Milestone 1
Milestone 2
Milestone 3
Milestone 4
Milestone 5
Milestone 6: complete processor
Final project presentations
Final project report

14 Grading

Minimum requirements:

Processor with

Grades are distributed as follows:

Deliverable Point value
Milestone 1 0 .. 5
Milestone 2 0 .. 5
Milestone 3 0 .. 5
Milestone 4 0 .. 5
Milestone 5 0 .. 5
Oral presentation 0 .. 10
Final report 0 .. 10
Extra features 0 .. 20
Base project 0 or 45
Total out of 100

Additionally, each member's grade is adjusted based on their individual contribution to the project. You must provide evidence of your contribution to the project. This might include: