Lab 3b: Materialize Your Processor - Control

CSE 141L, Spring 2007, Donghwan Jeon

Due 5/29(Tu)

You should work on this lab with your team from lab 2.

Updates

• 5/30: SuperGarbage Simulator, app1.* and app2.* files are updated. Previous versions did not consider 8K data memory boundary, so you should use updated files. In addition, now app1 (fib) uses exactly the same algorithm with the native fib introduced in lab 2a. For example, if you change the number in app1.in file to a negative integer, app1 should output 0x3DEADBEEF.

• 5/30: dmem_no_refuse.v is posted. 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.

• 5/29: dmem.v is updated. The following changes are made:
  • dout is asserted only when a read operation is requested. If no read operation is requested or a read operation is refused, dout is always 0x3FFFFFFFF.
  • refused is asserted only when an operation is made. In the previous version, it was asserted even when there is no memory request at all.

  The figure below shows write operations in dmem.v. All memory locations are initilized to 0x0 before these operations. A write to address 0x5 was refused. Also note that dout is always 0x3FFFFFFFF since no read request was made. For your processor implementation, you have to request the same operation until it is not refused.

  

  On the other hand, the figure below shows read operations in dmem.v. As you might expect, a read to 0x5 returns the initial value 0x0, becaused the previous write operation to that address was refused. A read request to 0x6 is refused, asserting 0x3FFFFFFFF to dout.

  

• 5/27: app2 is posted. app2 is a sorting program. First, it reads two arguments - addr and N. Then it reads N values and store them starting from addr. Finally, it performs a bubble sort algorithm and prints the sorted data. In the given app2.in file, addr is 0x2001, N is 5, and data set is {4, 2, 3, 5, 1}. Thus, it should print numbers in the order of {1, 2, 3, 4, 5} after sorting.

• 5/27: app1 is posted. The only number in app1.in is the argument to the fibonacci function. Also SuperGarbageSim and app0 are updated to measure an execution time. Note that *.cnt is used to provide fake counter values in SuperGarbageSim. The final benchmark will be posted soon.

Overview

Deliverables

• Submit relevant source files (zipped) via e-mail to TA (djeon AT cs) by 10:00am, Tuesday 5/29. Your email title should be "[CSE141L] lab 3b, name0, name1".
• Leave your hardcopy report in TA's mailbox by 5:00pm, Tuesday 5/29. The mailbox is located on the second floor of EBU3b.
• 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.

Control Logic

Q1. Complete your design by implementing control logic. Keep your verilog 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 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.

Q2. 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 the behavioral simulation result in the report, and explain the simulation result.

SuperGarbage

io_devices.v

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

• io_devices.v
• top.v

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

• #1 : request the next word of SuperGarbage binary file
• #2 : request the current clock count
• #3 : request an input data from "input.txt" file
• others : reserved

Output Channels

• #1 : select a SuperGarbage binary file
• #2 : set clock count
• #3 : debug output
• others : reserved

Q3. Now you can test in and out instructions with the given io_devices.v module. Modify your assembly test program in Q2 so that you can test in and out instructions. The simplest way to test those instructions is to manipulate clock counter. Set a counter value using output channel #2, and request the clock counter number to see whether it was successfully updated. Include the behavioral simulation result 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 module. If possible, verify your loader in the simulator you wrote in lab2.

// 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 lab 3b, 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 chage 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

Q4. 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

• load $file.bin
         loads *.bin file and *.in file, and set the $PC to the entry point of the application

• go $number
         executes next $number instructions. if $number is not specified, continues execution until a 'halt' instruction is executed.

• step
         execute one instruction at the current $PC, and increase $PC.

• get_pc
         prints the current $PC value

• set_pc $value
         sets the $PC to $value

• disasm $addr $size
         disassembles instructions from $addr to $addr + $size

• get_mem $addr $size
         prints data memory values from $addr to $addr + $size

• set_mem $addr $value
         sets the value at $addr of the memory with the value $value

• count
         shows the number of executed instructions

• help
         shows a help message

Download the following java files, and compile.

• Instruction.java
• SuperGarbageSim.java

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

Q5. Run all three benchmark applications and get the number of excution cycles for each application. Also get the dynamic instruction count for each benchmark from the 'count' command of your ISA simulator, or adding an instruction counter to your processor which counts the number of executed instructions. What is the CPI (cycles per instruction) for each benchmark? Fill out the following table. Why do CPI vary across applications?

 

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

Evaluation

Q6. What is the maximum achievable frequency of your processor? Include a screen capture on the post-route simulation result at the frequency in your hardcopy report. Calculate the execution time for all three benchmarks.

Q7. What is the critical path of your processor? Draw the critical path on the datapath schematic you made in lab 3a.

Q8. 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

• You can see many useful techniques for the implementation of a processor in Krste's Slides for MIPS Processor Implementstion .

• The debugging in the Xilinx simulator is very painful and time-consuming. Please verify your binary files with your simulator thoroughly. Once you have verified that your binary files are bug-free, then start a behavioral simulation. If your design works fine in the behavioral simulation, try post-route simulation and make it work.

• It is very painful to generate memory modules every time you modify your binary file. Fortunately, you do not have to generate a new memory module for behavioral simulations. The output Verilog file of the Core Generator refers to a *.mif file for memory contents. Instead of generating new memory modules, you can simply modify your *.mif file, and perform the behavioral simulation again. It is highly recommended to generate *.mif files along with *.coe files from your simulator to make the debugging procedure much easier. The following mif file is the mif file for the 17-bit instruction memory you used in your fetch unit. It is similar to *.coe file, but uses a binary representation.

  
  00000000000000000
  00000000000000001
  00000000000000010
  00000000000000011
  00000000000000100
  00000000000000101
  00000000000000110
  00000000000000111
  00000000000001000
  
   ...........