Laboratory 5 (individual) -- E100 part 1

Worth: 20 points
Assigned: 6 February 2015
Due: 13 February 2015

Overview

This lab will exercise your understanding of the E100's instruction set and introduce you to a datapath and finite-state machine that implements some of this instruction set. You will demonstrate your understanding of the E100 by showing the results of an E100 program and by tracing through the execution of another E100 program on the datapath and finite-state machine provided. You will also be introduced to Git, a version control system that will prove useful for lab 8 as well as future projects.

E100

This section summarizes the E100 CPU that was covered in lecture.

The word size for the E100 is 32 bits. Numbers are stored in 2s complement representation (i.e., bit 31 has a place value of -2147483648). Words thus range in value from -2147483648 to 2147483647. E.g., 32'h80000000 represents -2147483648, 32'hffffffff represents -1, and 32'h7fffffff represents 2147483647. The calculator on the course web page converts between hexadecimal and signed numbers.

The E100 has instructions for arithmetic, array access, branches, function calls, and I/O. Each E100 instruction is composed of 4 memory words. The value of the first word of the instruction is called the opcode and specifies the operation for the instruction. The values of the next three memory words of an instruction are called arg1, arg2, and arg3.

The E100's program counter (PC) contains the address of the first word of the current instruction, so the current instruction can be pictured as follows:

```memory[PC+0]    opcode
memory[PC+1]    arg1
memory[PC+2]    arg2
memory[PC+3]    arg3
```

The following table describes the effect of each instruction on the E100's program counter (PC) and memory.
Instruction name Opcode Effect
halt 0 PC = PC+4
stop executing instructions
memory[arg1] = memory[arg2] + memory[arg3]
sub 2 PC = PC+4
memory[arg1] = memory[arg2] - memory[arg3]
mult 3 PC = PC+4
memory[arg1] = memory[arg2] * memory[arg3]
div 4 PC = PC+4
memory[arg1] = memory[arg2] / memory[arg3]
cp 5 PC = PC+4
memory[arg1] = memory[arg2]
and 6 PC = PC+4
memory[arg1] = memory[arg2] & memory[arg3]
or 7 PC = PC+4
memory[arg1] = memory[arg2] | memory[arg3]
not 8 PC = PC+4
memory[arg1] = ~memory[arg2]
sl 9 PC = PC+4
memory[arg1] = memory[arg2] << memory[arg3]
sr 10 PC = PC+4
memory[arg1] = memory[arg2] >> memory[arg3]
cpfa 11 PC = PC+4
memory[arg1] = memory[arg2 + memory[arg3]]
cpta 12 PC = PC+4
memory[arg2 + memory[arg3]] = memory[arg1]
be 13
```if (memory[arg2] == memory[arg3]) {
PC = arg1
} else {
PC = PC+4
} ```
bne 14
```if (memory[arg2] != memory[arg3]) {
PC = arg1
} else {
PC = PC+4
} ```
blt 15
```if (memory[arg2] < memory[arg3]) {
PC = arg1
} else {
PC = PC+4
} ```

Comparisons take into account the sign of the
number. E.g., 32'hffffffff (-1) is less than 32'h00000000 (0).
call 16 memory[arg2] = PC+4
PC = arg1
ret 17 PC = memory[arg1]

Partial E100 implementation

The following Verilog files implement an E100 datapath (except for hexdigit.v) and partial control unit for the E100. Create a new Quartus project with these files (most should look familiar).

Read top.v and control.v, and review the truth table for the portion of the control unit that we covered in lecture (fetch, decode, and execute for the add and be instructions). Familiarize yourself with the signals used to control the datapath, and trace through the execution of a simple instruction (e.g., add).

Pre-lab assignment

Your pre-lab assignment is to answer questions about the E100 instruction set and implementation. Write your answers to part1.txt and part2.txt and push the files to the lab 5 repository (see Submission section). Have this assignment completed before you arrive in lab; your time in lab will be spent writing assembly-language programs. Bring the file with your answers to lab in case you need to revise and re-submit your answers.

1. Trace how an E100 would execute the following memory image (addresses and values are shown in decimal). Write the PC value and memory contents after each instruction executes (you need only show values that have changed). You need not consider how the E100 datapath/FSM would execute this program; you need only consider the instruction-level behavior of the program. In other words, you should only be using the above table to answer this question; you should not be referring to the datapath and FSM in the partial E100 implementation (which doesn't even implement all the instructions used in this question).
```memory[0] = 12
memory[1] = 30
memory[2] = 32
memory[3] = 31
memory[4] = 11
memory[5] = 38
memory[6] = 42
memory[7] = 45
memory[8] = 16
memory[9] = 20
memory[10] = 39
memory[11] = 0
memory[12] = 1
memory[13] = 41
memory[14] = 28
memory[15] = 29
memory[16] = 0
memory[17] = 0
memory[18] = 0
memory[19] = 0
memory[20] = 2
memory[21] = 40
memory[22] = 28
memory[23] = 29
memory[24] = 17
memory[25] = 39
memory[26] = 0
memory[27] = 0
memory[28] = -100
memory[29] = 197
memory[30] = 12000
memory[31] = 5
memory[32] = 600
memory[33] = 599
memory[34] = 598
memory[35] = 597
memory[36] = 596
memory[37] = 10000
memory[38] = 11000
memory[39] = 13000
memory[40] = 14000
memory[41] = 15000
memory[42] = 900
memory[43] = 800
memory[44] = 700
memory[45] = 2
```
```Your responses should have the following form:
```
<instruction number> pc:<pc #> mem[<mem location>]:<new mem value>
```
You only need to insert mem if it changes during that instruction.
1	pc:4	mem[37]:12000
```
2. Now consider a different memory image:
```memory[0]  = 15
memory[1]  = 8
memory[2]  = 12
memory[3]  = 13
memory[4]  = 0
memory[5]  = 0
memory[6]  = 0
memory[7]  = 0
memory[8]  = 0
memory[9]  = 0
memory[10] = 0
memory[11] = 0
memory[12] = 1000
memory[13] = 2000
```
Trace through how the datapath and finite-state machine provided would execute this program. For each cycle, list the state that the finite-machine is in during that cycle and any changes to memory or registers (PC, op1, op2, opcode, arg1, arg2, arg3, memory_address) that will occur at the end of that cycle.

Your responses should have the following form:

```<cycle number> state:<current_state> <modified_register>:<new_register_value> mem[<mem location>]:<new mem value> ```

Note that you only need to insert mem or registers if their values change in that cycle. Acceptable states are found in control.v and include but are not limited to: (state_reset, state_fetch2, state_decode, state_fetch1, state_blt1, state_halt). Registers are found in the datapath and include but are not limited to: (pc, mar [for memory address register], arg1, arg2, arg3, op1, op2). When your <current state> is state_halt, you should stop. (Don't have more than one state_halt.)
Your first two lines should be:

```1	state:state_reset
2	state:state_fetch1	mar:0
```

The starting value of PC, op1, op2, opcode, arg1, arg2, arg3 are all 0. The starting value of memory_address is undefined. The starting contents of memory are given above.

To get you started, here are the answers for the first few cycles:

Cycle 1:

• FSM state = state_reset
• No changes to any registers or memory.

Cycle 2:

• FSM state = state_fetch1
• memory address register becomes 0

Cycle 3:

• FSM state = state_fetch2
• opcode becomes 15

Submission

There is no in-lab demonstration for this lab. Instead, have the pre-lab assignment completed before you arrive in lab (you may revise and re-submit your answers up to the end of the due date). During the lab, you will discuss the E100 instruction set and implementation, and you will practice writing assembly-language programs.

Git is a Version Control System (VCS) that you will be using to keep backups of your project. For more on how Git works, we recommend reading the Git tutorial when you are able. For now, we will guide you through how to submit your answers using Git. This process is meant to introduce you to using Git, but its usefulness may not become apparent until later labs.

First, ensure that you have registered for a username on GitHub and have registered your username on the ENGR 100 website (link on the homepage). If you do not receive an email about repository access from GitHub, please notify an instructor. Second, ensure that you have created SSH keys to access GitHub. GitHub offers a great tutorial on this. We also have a tutorial and a tips page that you should take a look at.

```    \$ git clone https://[USERNAME]@github.com/ENGR100-W15/[USERNAME]-LAB5.git
```

You should end up with a message similar to

`Insert response here`

You should now have a directory labeled [USERNAME]-LAB5 in your current directory, which you can verify with ls.

Entering this directory with cd [USERNAME]-LAB5, you should see a few files, including a README, part1.txt, and part2.txt. The README explains the format in which you should submit this assignment, while the other two files provide samples.

When you are finished with your assignment (or if you just want to make a backup), it's time to commit and push your files. Committing is the process of making a backup, or commit, on your local machine (or in this case your CAEN account), and pushing is the processes of sending that backup to GitHub so that the instructors (and in the future, your teammates) may access the files. To commit, we must first add all of the changes that will go in the commit. You can add one file at a time or multiple with either of:

```     \$ git add part1.txt
`     \$ git commit -m "Completed part1 and part2 of lab5"`
`     \$ git push`