Pipeline Hazards Hazard Condition that disrupts the orderly flow - - PowerPoint PPT Presentation

pipeline hazards
SMART_READER_LITE
LIVE PREVIEW

Pipeline Hazards Hazard Condition that disrupts the orderly flow - - PowerPoint PPT Presentation

Pipeline Hazards Hazard Condition that disrupts the orderly flow of instructions Requires special attention by hardware and/or software to maintain program correctness and performance Structural Hazards Contention for hardware


slide-1
SLIDE 1

Pipeline Hazards

  • Hazard

Condition that disrupts the orderly flow of instructions Requires special attention by hardware and/or software to maintain program correctness and performance

  • Structural Hazards

Contention for hardware resources

  • Data Hazards

Data dependencies between instructions

  • Control Hazards

Disruptions caused by program control flow

1

slide-2
SLIDE 2

Data Dependencies

Dependent instructions: access common storage location

  • I1 and I2 instructions that access a common storage location
  • Read-after-Read (RAR) dependency
  • I2 reads the location read by I1

I1: ADD R1, R2, R3 I2 : ADD R4, R5, R2

  • Both I1 and I2 read register R2
  • Read-after-Write (RAW) dependency
  • I2 reads the location written by I1
  • No instruction between I1 and I2 writes to the same location

I1 : ADD R1, R2, R3 I2 : ADD R4, R1, R2

  • I2 reads the value in register R1 that was written by I1

2

slide-3
SLIDE 3

Data Dependencies

Dependent instructions: access common storage location

  • I1 and I2 instructions that access a common storage location
  • Write-after-Read (WAR) dependency:
  • I2 writes the location read by I1

I1 : ADD R1, R2, R3 I2 : ADD R2, R4, R5

  • I1 must read value of R2 prior to write by I2
  • Write-after-Write (WAW) dependency:
  • I2 writes the location written by I1

I1 :

ADD R1, R2, R3 I2 : ADD R1, R4, R5

  • Write of R1 by I1 must not occur after the write by I2
  • Final value of R1 due to write by I2 and not I1

3

slide-4
SLIDE 4

WAR Hazard

A : ADD R1, R2, R3 B : ADD R2, R4, R5

When is a dependency a hazard? 1 2 3 4 5 6 IF ID EX MEM WB IF ID EX MEM WB A B

4

slide-5
SLIDE 5

WAR Hazard

A : ADD R1, R2, R3 B : ADD R2, R4, R5

Register reads occur at an earlier pipeline stage than write

  • A reads R2 at cycle 2.
  • B writes R2 at cycle 6 (or later)
  • No WAR hazards in this pipelined implementation

When is a dependency a hazard? 1 2 3 4 5 6 IF ID EX MEM WB IF ID EX MEM WB A B

5

slide-6
SLIDE 6

WAW Hazard

A : ADD R1, R2, R3 B : ADD R1, R4, R5

  • Register writes occur only in WB stage
  • A writes R1 at cycle 5.
  • B writes R1 at cycle 6 (or later)
  • No WAW hazards in pipelined implementation

When is a dependency a hazard? 1 2 3 4 5 6 IF ID EX MEM WB IF ID EX MEM WB A B

6

slide-7
SLIDE 7

When is a dependency a hazard?

RAW Hazard

A : ADD R1, R2, R3 B : ADD R4, R1, R5

  • Hazard possible since register reads occur earlier than writes
  • A writes R1 at cycle 5
  • B may read R1 at cycle 3, 4 or 5

Instruction B reads stale value in R1 before it is updated by A (HAZARD!!)

Example: A and B consecutive instructions

1 2 3 4 5 6 IF ID EX MEM WB IF ID EX MEM WB A B

7

slide-8
SLIDE 8

RAW Hazards 1 2 3 4 5 6 IF ID EX MEM WB IF ID EX MEM IF ID EX MEM WB A X B 7 WB

  • A and B separated by 1 instruction: Hazard

MEM 1 2 3 4 5 6 IF ID EX WB IF ID EX MEM WB 7 IF ID EX MEM IF ID EX MEM WB 8 WB

  • A, B separated by 2 instructions
  • Hazard depends on register file design
  • No Hazard with split read/write protocol with writes earlier in cycle

A X Y B

8

slide-9
SLIDE 9

RAW Hazards

A, B separated by 3 instructions: No Hazard

MEM 2 3 4 5 6 ID EX WB IF ID EX MEM WB 7 1 IF IF ID EX MEM IF ID EX MEM WB 8 WB A X Y Z IF ID EX MEM B

Register file design alternatives:

1. value returned by read equals the value being written at that cycle 2. value returned by read is the old value

  • 1 implies no RAW hazard
  • 2 implies RAW hazard

9

slide-10
SLIDE 10

Pipeline Hazards

  • Hazard

Condition that disrupts the orderly flow of instructions Requires special attention by hardware and/or software to maintain program correctness and performance

  • Structural Hazards

Contention for hardware resources

  • Data Hazards

Data dependencies between instructions

  • Control Hazards

Disruptions caused by program control flow

10

slide-11
SLIDE 11

Lazy Execution of Branch Equal Instruction: beq Rt, Rs, d

PC +

IM

P C + 4 I n s t r u c t i

  • n

Decode REG FILE

EXT

PC

C n t r l

(rs) (rt)

d

rs rt rd

C n t r l

A L U

Mux F L A G

REG FILE

d

PC ADD AND MUX

IF ID EX MEM WB

<<

11

slide-12
SLIDE 12

Control Hazards

  • Branch instruction disrupts the sequential instruction stream
  • For conditional branches need to determine Branch Outcome
  • For unconditional and taken conditional branches need to determine branch

Target Address

  • Target Address: next instruction from a non-sequential address
  • Cannot fetch next instruction till target address computed
  • Do not know target address (at least) till branch instruction decoded
  • Branch Outcome:
  • Depends on internal state (e.g.register values)
  • Need to evaluate branch condition
  • May happen deep in the pipeline
  • Cannot know for certain which instructions to bring into pipeline
  • What if the incorrect instruction sequence is executed?

Problem: Need to stall the pipeline till branch outcome is known and target address is

computed.

12

slide-13
SLIDE 13

Control Hazards

A: beq R2, R3, L1 B C D E

  • L1: P
  • In our lazy design: the branch was resolved only

in the MEM stage

  • The PC was updated with the target address only

at the end of cycle 4

  • What happens to the pipeline?

13

slide-14
SLIDE 14

Control Hazards

WB MEM EX ID IF WB MEM EX ID IF WB MEM EX ID IF WB MEM EX ID IF WB MEM EX ID IF WB MEM EX ID IF WB MEM EX ID IF

12 11 10 9 8 7 6 5 4 3 2 1 A B C D P Q R

  • Instructions B, C, D will enter the pipeline while branch outcome is being determined
  • Need to make sure they do not compromise correctness
  • Want to reduce the performance degradation

14

slide-15
SLIDE 15

Control (Branch) Hazards

:

Problems:

  • The target address of the branch is not known (at least) till instruction is decoded
  • What is the address of instruction P?
  • The outcome of the branch (taken/ not taken) is determined deep in the pipeline
  • Should we execute B or P after A?

What should the pipeline (processor) do after fetching the branch instruction?

  • We don’t know it’s a branch (at least for now) till instruction is in ID
  • Default execution will begin reading instruction B in IF
  • What then?

15

slide-16
SLIDE 16

B C

Control Hazard

IF EX ID

A

MEM WB

B

T = 1 IF EX ID MEM WB

C A

T = 2 IF EX ID MEM WB

D B A

T = 3 IF EX ID

D

MEM WB

P C B A

T = 4

TAKEN BRANCH 16

slide-17
SLIDE 17

Simple Software Solution: Insert NOPs

MEM

2 3 4 5 6

ID EX WB

7 1

IF

8

A

IF ID EX MEM

B P

9

WB

beqz R2, label NOP NOP NOP B

  • label: P

Possible execution sequences: Branch Not Taken: A, NOP, NOP, NOP, B Branch Taken: A, NOP, NOP, NOP, P

  • Adds 3 cycles to execution time for every branch

NOP NOP NOP

17