cse141L Lab 5: Materialize Your Processor - Control


Changelog

May 27

The hexidecimal numbers in the SuperGarbage input files (*.in) were padded with 0's to make clear that they are 34-bits long. This should eliminate the problem of 34'hXXXXXXXXX being read from the SuperGarbage input files during simulation.


Due: May 27

Overview

Finally, it is time to make your processor work. In this lab you will implement the control logic of the processor on top of the datapath implementation you made in the last lab and verify it with behavioral simulations. First, you will write your own testbench which tests all the instructions your ISA supports. Then your processor will run our official benchmark - SuperGarbage. You will be provided an automated test environment to easily load applications into your processor and evaluate their performances.

Control Logic

Question 1: Complete your design by implementing control logic. Keep your Verilog code as clean as possible. Naming convention, proper indentation, and style will be graded. Include all the source files in your hardcopy report.

Instruction Test

The first test your processor has to pass is a simple instruction test. Write a simple assembly program which uses all the instructions in your ISA except in and out. in and out will be tested in the SuperGarbage benchmark with a provided testing environment. Generate a COE file either manually or with your assembler, and verify that your processor successfully handles all the instructions in a behavioral simulation. Try to make your test program as concise as possible while it covers all the instructions.

Question 2: Include your test assembly file in the hardcopy report, and explain your testing strategy. Make sure that it covers all the instructions in your ISA. Also include a short sample of part of the behavioral simulation waveform in the report (annotated to demonstrate correct execution), and explain the simulation result.

SuperGarbage

In this lab, the main test your processor has to pass is SuperGarbage. If you are not familiar with SuperGarbage, take a quick look at lab 1 of cse141. As you might have already noticed, SuperGarbage is a simple virtual machine. With a VM, you can run any SuperGarbage application regardless of your ISA. As far as your SuperGarbage implementation is correct, you will be able to run any SuperGarbage applications, which allows us provide the class with standard applications that run on everybody's ISA, saving us all a significant amount of effort. You are provided with io_devices.v module, which supplies SuperGarbage applications to your processor. It also provides a clock counter for performance evaluations.

io_devices.v

Download the following two files, and add them to your Xilinx project.

You might need to change top.v file if you have modified core interface. As you can see in top.v file, the device module communicates with your core module via the I/O interface. The interface of the io_devices module is as follows:

module io_devices#(parameter D_WIDTH = 34, PA_WIDTH = 4)
(
	input 	reset,
	input 	clk,
	
	input	read_req,
	input	write_req,
	input	[PA_WIDTH-1 : 0] read_addr,
	input	[PA_WIDTH-1 : 0] write_addr,
	input	[D_WIDTH-1 : 0] din,
	output	[D_WIDTH-1 : 0] dout,
	output	read_ack,
	output	write_ack
);

The io_devices module provides the following services via I/O channels:

Input Channels

Output Channels

Question 3: Now you can test in and out instructions with the given io_devices.v module. Modify your assembly test program in Question 2 so that you can test in and out instructions. The simplest way to test those instructions is to manipulate the clock counter. Set a counter value using output channel #2, and request the clock counter number to see whether it was successfully updated. Include a portion of the behavioral simulation waveform (annotated to demonstrate correct execution) in the report, and explain it.

Write a simple loader

To run a SuperGarbage application, your processor should properly load the application first into the data memory. The figure below shows the format of the SuperGarbage binary file and how a loader works. After selecting the application to load, the loader requests the selected SuperGarbage binary file via input channel #1, word by word. For every two words, the loader stores the second word at the address indicated by the first word. In the figure below, the loader first reads address 3 and data 0, so it stores data 0 into address 3. The loader continues loading data until the specified address is -1 (0x3FFFFFFFF), which means the end of the file. The data for the address -1 indicates the entry point of the SuperGarbage program. After loading an application, the loader should call SuperGarbage VM with the starting address of the SuperGarbage memory and the entry point of the program.

The following java-style pseudo-code shows how to load a program from the io_devices module and start SuperGarbage VM. You can choose an application among three provided SuperGarbage applications by changing num_app variable in the pseudo-code. You should write a loader in your assembly language, build coe files, and generate memory modules. If possible, verify your loader in the ISA simulator you wrote in cse141's first lab.

// SuperGarbage Loader
// num _app
// 0: app0.bin
// 1: app1.bin
// 2: app2.bin

final int num_app = 0;

word mem[4096];
word startPC;

// basic code stub
set $SP;
set $GP;

// select an app
out( num_app, 1);

// load data from an external device while(addr != -1)
do {
    word addr, data;
    addr = in(0x1);
    data = in(0x1);
    
    if (addr == 0x3FFFFFFFFL) {
        startPC = data;
        break;
        
    } else {
        mem[addr] = data;
    }
} while(true);

// Finally, call SuperGarbage VM
SuperGarbage(startPC, mem);

SuperGarbage Applications

In this lab you will use the following three SuperGarbage applications to test your design. Put them in your Xilinx project directory. Applications get inputs from input channel #3, which is fed by the input file. If you want to change input data, modify the input file for the corresponding application.

Benchmark Assembly File Binary File Input File Counter Input File
Compare
app0.s
app0.bin
app0.in
app0.cnt
Fibonacci
app1.s
app1.bin
app1.in
app1.cnt
Bubble Sort
app2.s
app2.bin
app2.in
app2.cnt

Question 4: Run your loader with the first application, and make sure that your loader is working. Include your loader assembly source file in the hardcopy report.

SuperGarbageSim

Although SuperGarbage VM is very simple, it is not easy to understand a SuperGarbage code. To help you understand the behavior of SuperGarbage applications, you are provided with a SuperGarbageSim, a reference simulator for SuperGarbage applications. SuperGarbageSim can load and execute any SuperGarbage application binary file. You can also monitor or modify contents of memory and the program counter. The SuperGarbageSim supports the following commands:

Download the following java files, and compile.

You can start SuperGarbageSim with the following command:

 prompt> java SuperGarbageSim 

Here are a few examples of SuperGarbageSim commands:

 prompt> load test1.bin      // load 'test1.bin' file
 prompt> disasm              // disassembles 10 instructions from PC
 prompt> disasm 0x10 15      // disassembles 15 instructions from 0x10 
 prompt> set_mem 14 0x0      // set the memory location 14(0xe) to 0x0 

SuperGarbage Performance

Download dmem_no_refuse.v . Use this module instead of dmem.v when you evaluate the performance of your processor. It has the same interface with dmem.v, but it never asserts refused signal.

All three provided SuperGarbage applications measure their execution times by using the counter service implemented in io_devices.v. They calculate the execution time by requesting the counter value at the beginning and end of the execution and getting the difference. Then, they send the number of cycles for the execution to the debug output channel (output #3) so that you can easily see it.

Question 5: Run all three benchmark applications and get the number of execution cycles for each application. What is the CPI (cycles per instruction) for each benchmark? Fill out the following table. Why does CPI vary across applications?

 
  Benchmark 0 Benchmark 1 Benchmark 2
# of Cycles for the Execution
 
 
 
Dynamic Instruction Count
 
 
 
CPI (Cycles per Instruction)
 
 
 

Evaluation

Now that you have passed two important tests, let's evaluate the performance of your processor. Place and Route your processor (with your core module as the top module, because io_devices is not synthesizable).

Question 6: What is the maximum achievable frequency of your processor? Calculate the execution time for all three benchmarks.

Question 7: What is the critical path of your processor? Draw the critical path on a datapath schematic of your processor.

Question 8: Propose a way that will improve the performance of your processor. Why do you think it is an effective way to boost the performance?

Tips


00000000000000000
00000000000000001
00000000000000010
00000000000000011
00000000000000100
00000000000000101
00000000000000110
00000000000000111
00000000000001000

 ...........

Deliverable

  • You have a lab interview for this lab. Sign-ups TBA.
  • Bring your hardcopy report at your interview time. Like previous labs, your report consists of answers to the questions.
  • Submit relevant source files (zipped) via e-mail to both TAs. Your email title should be "[CSE141L] lab 5, name0, name1". Rename your zip file to end with .isazip instead of .zip to avoid email bounces.
  • All Verilog designs must be synthesizable and implementable.
  • For Verilog implementations, use consistent and readable naming style. The naming convention, proper indentation, and style will be graded.

Due: May 27