CSE502: Course Project

Due: last day of class

Project Description

Your goal is to design a processor core for a subset of the x86 ISA. Although the final product will be a functional x86 processor, you are not required to implement legacy x86 instructions. Instead, you should implement 64-bit instructions, full 64-bit (%r??) general-purpose registers, and support for 64-bit aligned memory accesses.

A basic overview of the Core interface follows (sc_{addr,inst,data} are 64, 128, and 64 bits, respectively):

sc_in<bool>        clk;
sc_in<bool>        reset;

sc_signal<mem_op>  i_op[#]; // i-cache op, either NONE or READ
sc_signal<int>     i_tagin[#]; // i-cache request tag (any value)
sc_signal<sc_addr> i_addr[#]; // i-cache address being read
sc_in<bool>        i_ready[#]; // i-cache reply ready
sc_in<int>         i_tagout[#]; // tag from the corresponding i-cache request
sc_in<sc_inst>     i_data[#]; // instruction contents from i-cache
sc_signal<mem_op>  d_op[#]; // d-cache op, either NONE, READ, or WRITE
sc_signal<int>     d_tagin[#]; // d-cache request tag (any value)
sc_signal<sc_addr> d_addr[#]; // d-cache address being read or written
sc_in<bool>        d_ready[#]; // d-cache reply ready
sc_in<int>         d_tagout[#]; // tag from the contents d-cache request
sc_inout<sc_data>  d_data[#]; // accessed data (for READ) or data to write (for WRITE)

The base core provides two registers, RIP and RSP. After reset, RIP contains the address of the first instruction the core should fetch and RSP contains the initial stack pointer.

A real core is able to execute instructions in various protection domains (e.g., Ring 0 or Ring 3). Your core needs to handle Ring 3 only. The OS will be emulated in your project environment and your core will not be responsible for executing OS instructions. When encountering the syscall instruction, you should perform a function call to the base core's syscall(rip,rsp,rax,rdi,rsi,rdx,r10,r8,r9) method to perform the system call side-effects, which will emulate the system call in Ring 0 and return. Because system calls are emulated, they will execute instantaneously (before the end of the current clk cycle). NOTE 1: You do not need to faithfuly model reading the registers from the register file for the purpose of implementing the syscall mechanism. NOTE 2: Care must be taken to ensure that the syscall instruction side-effects never execute speculatively.

Project Files

The project handout files are available in ~mferdman/project-handout/ . The handout files comprise project.tgz (the base infrastructure files), core_cse502.{h,cc} (starting files for the project), SConstruct (the project build script), and proj* directories (test applications). Note that project.tgz contents are likely to be updated as the semester progresses, incorporating bug fixes and improvements. Announcements will be sent to the course mailing list when major updates become available. New test-* files will also periodically appear in the directory.


The projects will be graded based on correct execution and performance (IPC) of the submitted core design. Points deducted for errors will be multiplied by the number of group members. The maximum number of points that can be received for the project depends on the implemented core organization according to the following:

Course Project                                                       Points
Single-Cycle or Multi-Cycle                                            50
5+ stage pipeline                                                      60
Super-scalar                                                           70
Super-scalar Out-of-order                                              80
Super-scalar Out-of-order with non-trivial branch predictor            90
SMT Super-scalar Out-of-order with non-trivial branch predictor       100

Submission Procedure

We will be collecting submissions on the VM machines from $HOME/submissions/final/. You should place the README, core_cse502.h, core_cse502.cc, and any new source files that you introduce to the project into this directory. Only one project per group should be submitted.

A README is required that contains at least the list of group members, the license, the project selected, and a description of the implementation in the following format:

POINTS: 10 //corresponds to the project selected
GROUP: name1, name2, ... //user IDs of all group members
LICENSE: All rights reserved. //the license applied to submission
IMPLEMENTATION: Description of implementation. //an overview of the implementaion


Always use your 'Unix' login and password for the course machines.

Rocks cluster - sbrocks.cewit.stonybrook.edu:22
VM - allv21.all.cs.sunysb.edu:130 - allv22.all.cs.sunysb.edu:130 - allv23.all.cs.sunysb.edu:130

Once you connect to the rocks head node run 'condor_status'. This will display all of the compute nodes that are present as well as the load and memory. Avoid selecting machines that have less than 1000mb of memory.

Example output:

sbrocks$ condor_status
Name               OpSys      Arch   State     Activity LoadAv Mem   ActvtyTime
slot2@compute-3-11 LINUX      X86_64 Unclaimed Idle     0.000  1005  9+08:38:55
slot1@compute-3-12 LINUX      X86_64 Unclaimed Idle     0.000  1005  0+00:50:04
slot2@compute-3-12 LINUX      X86_64 Unclaimed Idle     0.000  1005  6+16:52:47
slot1@compute-3-13 LINUX      X86_64 Unclaimed Idle     0.000   501  0+00:15:04 Avoid