1. ECE 353 Lab 3 Pipeline Simulator
Additional Material

2. Recapitulation… Pipeline latches
Used to pass information from stage to stage.
Each latch has a producer stage and a consumer stage.
Flags have to be maintained to ensure that:
A producer does not overwrite needed latch contents, and that
A consumer does not read stale latch contents
A struct can be used to represent the latch contents.

3. Suggested Sequence
Phase 0: Write out the structure of your code in pseudo-code. Hand- simulate everything. Decide on the data structures required and the various function interfaces. Do a correctness check by hand of the pseudo-code.
Phase 1: Complete the simulator assuming that there are no syntax errors in the input assembly code.
Phase 2: If the code from Phase 1 runs successfully, then write the code for syntax checking. Checking for opcode and register name correctness is simple and should be done first; checking lw/sw syntax is a bit more difficult.

4. Get the design done right before coding…
“The life of a software architect is a long, and sometimes painful, succession of suboptimal decisions made partly in the dark…” ---- Falessi, et al., ACM Comp. Surveys, 2011

5. Design Process
Code to simulate program reading into IM and syntax error checks can be written – and tested -- separately from the rest of the work.
Write a small assembly program.
Hand-simulate the execution of this program, stage by stage. As you do so, identify for each stage (IF, ID, EX, MEM, WB):
The information the stage needs at the start of the operation (including leftover work from the previous cycle).
The information the stage gets from the pipeline latch to its left
The activity the stage needs to perform.
Transfer this information to the simulator design:
Information needed by stage at the start => state of the stage and flags to check
Activity: May include counter settings, if necessary, and latch checks. At the end, identify if the op is complete, determine if the latch to its right is ready to receive.

6. Reading from file to Instruction Memory (IM)
IM is treated as a linear array.
Use fgets() to read the instruction file.
Write what was read into the array representing IM.

7. Check for specified syntax errors
Non-existent opcode: Possible approaches
Finite State Machine.
Table of opcodes that is then searched for a match.
If the opcode test is passed, knowing the opcode allows us to interpret each of the remaining fields.
If a field must be a register,
Check if the register is specified numerically (e.g., $8) or symbolically (e.g, $t0).
If specified numerically, check if the number is in the range 0 to 31.
If specified symbolically, use a table lookup or a Finite State Machine to:
Check for a match to an acceptable symbol: If no match, announce error and stop.
If a match is found, output the numerical equivalent.

8. Syntax error checking (continued)
If the field must be an immediate operand, check that the number can be expressed in 16 bits (range check).
If we have a load or store instruction, check that the last field has the correct syntax: number(register).
May be best to have separate functions to do each type of check, e.g.,
isAReg(char *s) to check if it is a valid register name or number
isImmOperand(char *s) to check if the character string is a number within the allowed range.
memAccessFormat(char *s) to check if the number(register) format is followed for a load or store instruction.

9. FSM Design
Determine how you would manually emulate the FSM; this leads to the next step.
Decide on the states of the machine and the state-transition rules; draw the state-transition diagram.
Hand-simulate the machine to make sure the design is correct.
Code: For each presentState, carry out the specified activity in that state and define the nextState.
Example: For the lw address syntax check, we might have the following states defined:
Start.
Bulding displacement value.
Building register name (either symbolic or numerical).
Checking register name.
Looking for spurious text beyond the closing ‘)’.
Error.

10. Checking for a structural hazard
A stage has to make sure that the
Latch it is updating is empty before it updates it.
Latch data it is consuming are valid before it reads it.
For a multi-cycle operation in any stage, the latch it is consuming from only empties out in the final cycle of that operation.
A latch can be filled (by its producing stage) in the same cycle in which its consuming stage empties out.

11. RAW Hazards
RAW hazards are detected in the ID stage; instructions are stalled there until these hazards are cleared.
RAW needs a status bit associated with each register, indicating whether it contains valid data or is awaiting the output of an ongoing instruction.
Exception: $zero always holds 0, so it has no hazards associated with it.

12. Control Hazards beq is detected in ID and resolved in EX.
Recall (from ECE 232) that:
beq displacements are in units of words and are with respect to the next instruction.

13. Each Stage Start of a cycle: End of a cycle:
Committed to anything already from the previous cycle (multicycle instruction; instruction stopped due to a hazard)? Need to keep track of this by means of a state variable.
Process if possible; wait if necessary.
If no commitments from the prior cycle, is there new work for this stage waiting in the LHS latch?
End of a cycle:
Any commitments carried over to the next cycle?
Can the result (if any) of this stage’s operation be moved into the RHS latch?
Do any flags need to be changed?

14. Partial Example: WB stage
Does WB need to remember anything from the previous cycle?
Check if there is anything new in the MEM/WB latch.
If so,
Does this require any WB activity? If so,
Carry out the register write operation (update the array representing the register file)
Increment the stage usage count
Set the appropriate flag to indicate that the register in question now has valid data.
Else,
Do nothing other than removing whatever was in the MEM/WB latch.
Else
Do nothing.

15. Partial Credit
If the program does not work completely, we will assign partial credit for the following:
Detection of the error types covered in the lab description and the lectures.
Correct reading of the program into IM.
Correct parsing of the various fields of each instruction.
Whether straight-line code without any hazards and with m=n=c=1 works correctly.
Whether code with the following produces correct results:
RAW hazards.
Multicycle operations.
Structural hazards.