---

Data Hazard in the modified Pipelined CPU

---

• Cause of Read after Write synchronization errors
  • What you have learned in the last few webpages is what the distributed system experts call the "read after write synchronization error" or "read after write data hazard"

  • The "read after write data hazard" is created by a consumer instruction (using a register value) that obtained an out of data value written by a producer instruction (using the same register as target).

  • We saw one type of instruction that produces value for registers: ALU instructions that update a register

  • Recall there are 3 types of instruction: ALU, Memory access (LD, ST) and Branching

  • Branch instructions do not update registers, so they cannot cause any read after write data hazards.

  • The STORE instruction does not update registers, so neither can a STORE instruction cause read after write data hazard

  • However.... the LOAD instruction does update registers.... oh boy.... here we go again...

• There is still something wrong with the improved pipeline...
  • Consider the following program that is executed by the basic pipeline:

       LD  [R2+R3], R1            R2=11, R3=9, R4=1, R5=8, R6=0, R7=2
    			      Suppose Memory[20] = 4000
       ADD R4, R1, R4
       ADD R5, R1, R5
       ADD R6, R1, R6
       ADD R7, R1, R7
       ...
    

  • The correct behavior (one that an assembler programmer would expect) is: R1 := Memory[R2+R3] = 4000, then the other instructions will add R1=4000 to registers R4, R5, R6 and R7

  • But that's NOT will happen in the improved pipelined CPU...

• CPU Cycle 1

  • At start of the CPU cycle, the IF stage sends out PC
  • At end of the CPU cycle, the IR(ID) register is updated with the instruction fetched (LD [R2+R3], R1)

  

  • The picture above depicts the content of the CPU at end of the first CPU cycle (and the start of the 2nd cycle)

• CPU Cycle 2
  • At start of the CPU cycle, the ID stage sends out selection signal that selects values from R2 and R3

  • At end of the CPU cycle, A register is updated with R2 = 11, B register is updated with R3= 9.
  • Also, at the end of the CPU cycle, the instruction (LD [R2+R3], R1) is moved into IR(EX) and instruction ADD R4, R1, R4 is fetched into IR(ID)

  

  • The picture above depicts the content of the CPU at end of the second CPU cycle (and the start of the 3rd cycle)

• CPU Cycle 3
  • At start of the CPU cycle, the EX stage selects values from R2 and R3 for the ALU, use the ALU opcode to make ALU add the input values forming the result 20

    Notice that this is an ADDRESS, and the value must still be fetched from this memory location into register R1

    Also, at start of the CPU cycle, the ID stage selects R4 and R1 to be copied into the A and B registers:

  • At end of the CPU cycle, ALUo and DMAR registers is updated with the value R1+R2 = 20 (future value of R1)

    The LOAD instruction does NOT produce a valid result for the destination register. So we enter an INVALID tag into the Tag Register of Forwarding Register 1 to prevent the value being fetched by the multiplexor.

    An invalid tag is easy to formulate: suppose you have 8 registers in the CPU, just enter the value 9 or higher into the tag register or we can add one more bit in the tag register field to indicate if the tag is "valid".

    Also, at the end of the CPU cycle, A is updated to R4 (=1) and B is updated to the "current value" of R1 (= 123). This "current" value is a wrong value because there is a more current one on the way from the memory....

    Notice that the CPU - at this moment - does not have a clue what that "more current value of R1" is.... because the CPU must still get that value from the memory....

    Also, at the end of the CPU cycle, the instruction (LD [R2+R3], R1) is moved into IR(MEM), ADD R4, R1, R4 is moved into IR(EX) and instruction ADD R5, R1, R5 is fetched into IR(ID)

  

  • The picture above depicts the content of the CPU at end of the 3rd CPU cycle (and the start of the 4th cycle)

  • You may already see that ADD R4,R1,R4 will not execute correctly....

• CPU Cycle 4
  • At start of the CPU cycle, the address in LMAR (= 20) is sent on the address bus and the value in the memory location 20 is being fetched. This value will arrive towards the end of the CPU cycle (because the memory is pretty slow).

  • Also at start of the CPU cycle, the EX stage selects values from R4 and the old value of R1 for the ALU, because the source register ID does not match any tags. The ALU will produce an INCORRECT result because an old value of R1 was used.

    Also, at start of the CPU cycle, the ID stage selects R1 and the same OLD value of R1 to be copied into the A and B registers.

    Notice that the LOAD instruction in MEM stage will cause the IF stage to STALL....

  

  • At end of the CPU cycle, LMDR register in MEM stage is updated with the value fetched from memory (4000).

  • Also, at end of the CPU cycle, the instruction ADD R4,R1,R4 has updated ALUo (and DMAR) registers with the value INCORRECT value R4+R1 = 124 (R1 should be equal to 4000).

    Also, at the end of the CPU cycle, A is updated to R5 and B is updated to the old value of R1 .

    Also, at the end of the CPU cycle, the instruction (LD [R2+R3], R1) is moved into IR(WB), ADD R4, R1, R4 is moved into IR(MEM), instruction ADD R5, R1, R5 is moved into IR(EX) and the instruction NOP is inserted into IR(ID) (See: click here )

  
  • The picture above depicts the content of the CPU at end of the 4th CPU cycle (and the start of the 4th cycle)

  • We can see that R4 will be updated with an INCORRECT value by the pipelined CPU. So the forwarding hardware that we added to correct the behavior in