[Solved] CS410001-Project #1

1. Project Objective
   1. Implement a single-cycle functional processor simulator.
   2. Design your own test case to test the functionality of your simulator.

2. Project Description
3. Architecture Design:
   • Refer to textbook Chapter 2 Instructions and Chapter 4.1~4.4 The Processor.
   • The executable file should be named single_cycle and take no command-line arguments.
   • All registers, except PC and $sp, are initialized to 0s.
   • Assume that the instruction memory is of 1K bytes size and all contents are initialized to 0s.
   • The data memory is of 1K bytes size and the memory contents are initialized to 0s.
   • Your test case should run no more than 500,000 cycles.

1. Instruction Set:

• Implement all the instructions specified in the reduced MIPS R3000 ISA in Appendix A, Datasheet for the Reduced MIPS R3000 ISA.
• The execution of the single-cycle processor simulator should terminate after executing the halt instruction.

1. Input Test Case File and Format:

• Design your own test case by providing the following two binary files:

1. iimage.bin:
   1. This file specifies the instruction image (in big-endian format, encoded in binary).
   2. The first four bytes indicate the initial value of PC, i.e. the starting address to load the instruction image.
   3. The next four bytes specify the number of words to be loaded into instruction memory.
   4. The remaining are the program instructions to be loaded into I-memory.
   5. dimage.bin:
   6. This file specifies the data image (in big-endian format, encoded in binary).
   7. The first four bytes indicate the initial value of $sp.
   8. The next four bytes specify the number of words to be loaded into data memory, starting from address 0.

• For format details, please refer to Appendix B, Input Samples.
• Place both iimage.bin and dimage.bin under a folder named testcase/ at the same directory where your executable file resides.
• We will pool all test cases from the class to evaluate everyones simulator. Your (valid) test case gets higher grade if more simulators failed running your test case.

1. Output File and Format:

• For each test case, generate the following two output files:
  1. rpt: Record all the register values at each cycle.
  2. rpt: Record any error messages.
• Place the output files at the same directory where your executable file resides.
• For details, please refer to Appendix C-1, Output Samples for Project 1 and Appendix D, Error Detection Samples.

1. Modularized implementation

• Suggest that you should modularize your simulator implementation based on processor architecture. For example, this is a possible program structure:
  1. c // Define simulator behaviors and main function
  2. c // Define & decode instructions
  3. c // Register function
  4. c // Memory function (for both instruction & data memories)
  5. c // other miscellaneous functions

• Appropriate header file or object-oriented programming format are also highly recommended design pattern.

3. The 2-submission Process
4. Each project has two submissions. The second due date is normally one week after the first one.
   • Before 1^st submission: we will release a golden executable and open test cases to help you verify your designs.
   • 1^st submission: submit your simulator and test case for evaluation.
   • After 1^st submission (before 2^nd submission): we will release all test cases (including hidden test cases and all test cases submitted by the class) for you to polish your simulator.
   • 2^nd submission: submit your revised simulator and project report (format is specified in the Grading Policy section).

1. Prepare your project package for development and submission

• Before you start your project
  1. Use SSH to access workstation.
  2. Clone sample files from GitHub to your home directory.

l Clone a repository NTHU Architecture 2016 from GitHub and name it as studentID_01/ under /home/archi/studentID. Inside the folder, it contains two folders:

1. simulator/ : contains your Makefile, and source code.
2. Your Makefile should support the following two functions:

• make to build your simulation environment
• make clean to erase from the build tree the files built by make all.

1. Modulize your source code as recommended.
2. testcase/ : contains your test case files for evaluation.
3. Do coding/debugging/testing using Git version control tool.

• Before submission and after completing your project
  1. Check your output file format using test_script.py
  2. Compress the folder studentID_01 as studentID_01.tar.gz, and upload studentID_01.tar.gz and studentID_report.pdf to the iLMS system.

• Note: TAs will check your Git log during 1-on-1 Demo. Please follow version control rule when doing programming.
• Note:. Verify your package format by executing test_script.py before each submission. Wrong submission format earns no points.

4. Grading Policy
5. First submission

• Correctness of simulator: 25%
  1. TAs open test cases: 15%
  2. TAs hidden test cases: 5%*Correct Ratio
  3. Students valid test cases: 5%*Correct Ratio

• Test case strength: 20%*(1 [1.5]^-n), n: number of other simulators defeated 1. Submit your test case to participate in the pool test.

l Note: You get zero points if your test case is invalid.

1. Second submission

• Correctness of simulator: 30%

1. TAs open test cases: 5%
2. TAs hidden test cases: 10%*Correct Ratio
3. Students valid test cases: 15%*Correct Ratio

• Performance: 5%

1. TA will collect the execution time of your simulator running all the valid test cases (including all open, hidden and students test cases).
2. TA will rank all execution times in 5 levels and grade accordingly.

l Note: If your simulator fails to execute the valid test cases you will get the lowest performance grade.

• Report & Demo: 20%

1. The report file should be named studentIDpdf, where studentID is the NTHU student id you used for school registration.
2. Each person should reserve a 15-min demo with TA. During the 1-on-1 demo, TAs will ask you questions related to your project report, test case and your implemented code on workstation.
3. Your project report is recommended to follow this outline:

1) Project Description

• Program Flow Chart

• Detailed Description

2) Test case Design

2-1) Detailed Description of Test case

Note: The project report is limited to 10 pages.

Note: Your report can be either in Chinese or English, or mixed.

Note: For convenience, please synchronize your submission code with your code in workstation. This allows smoother demo on workstation.