Pipeline hazards occur when the next instruction cannot execute in its designated clock cycle. There are three types of hazards: structural, data, and control hazards. Structural hazards occur when multiple instructions compete for the same hardware resource. Data hazards occur when an instruction depends on the result of a previous instruction. Control hazards arise from branches that change the program counter. Hazards reduce the performance from pipelining by causing pipeline stalls. Various techniques like forwarding, branch delay slots, and predicting branch outcomes earlier help to reduce the performance impact of hazards.
Pipeline hazards occur when the next instruction cannot execute in its designated clock cycle. There are three types of hazards: structural, data, and control hazards. Structural hazards occur when multiple instructions compete for the same hardware resource. Data hazards occur when an instruction depends on the result of a previous instruction. Control hazards arise from branches that change the program counter. Hazards reduce the performance from pipelining by causing pipeline stalls. Various techniques like forwarding, branch delay slots, and predicting branch outcomes earlier help to reduce the performance impact of hazards.
Pipeline hazards occur when the next instruction cannot execute in its designated clock cycle. There are three types of hazards: structural, data, and control hazards. Structural hazards occur when multiple instructions compete for the same hardware resource. Data hazards occur when an instruction depends on the result of a previous instruction. Control hazards arise from branches that change the program counter. Hazards reduce the performance from pipelining by causing pipeline stalls. Various techniques like forwarding, branch delay slots, and predicting branch outcomes earlier help to reduce the performance impact of hazards.
Pipeline hazards occur when the next instruction cannot execute in its designated clock cycle. There are three types of hazards: structural, data, and control hazards. Structural hazards occur when multiple instructions compete for the same hardware resource. Data hazards occur when an instruction depends on the result of a previous instruction. Control hazards arise from branches that change the program counter. Hazards reduce the performance from pipelining by causing pipeline stalls. Various techniques like forwarding, branch delay slots, and predicting branch outcomes earlier help to reduce the performance impact of hazards.
Download as PPT, PDF, TXT or read online from Scribd
Download as ppt, pdf, or txt
You are on page 1of 20
Pipelining Hazards
Pipeline Hazards (1)
Pipeline Hazards are situations that prevent the next instruction in the instruction stream from executing in its designated clock cycle Hazards reduce the performance from the ideal speedup gained by pipelining Three types of hazards Structural hazards Data hazards Control hazards
Pipeline Hazards (2) Hazards in pipeline can make the pipeline to stall Eliminating a hazard often requires that some instructions in the pipeline to be allowed to proceed while others are delayed When an instruction is stalled, instructions issued latter than the stalled instruction are stopped, while the ones issued earlier must continue No new instructions are fetched during the stall Structural Hazards (1) Arise from resource conflicts when the hardware cant support all possible combinations of overlapping instructions In simple words happens when multiple instructions competing for the same resource. If certain combination of instructions cant be accommodated because of resource conflicts, the machine is said to have a structural hazard It can be generated by: Some resources has not been duplicated enough to allow all the combinations in the pipeline to execute For example: a machine may have only one register file write port, but under certain conditions, the pipeline might want to perform two writes in one clock cycle this will generate structural hazard When a sequence of instructions encounter this hazard, the pipeline will stall one of the instructions until the required unit is available Such stalls will increase the Clock cycle Per Instruction from its ideal 1 for pipelined machines Structural Hazards (2) Consider a Von Neumann architecture (same memory for instructions and data) Structural Hazards (3) Stall cycle added (commonly called pipeline bubble) Structural Hazards (4) Another way to represent the stall no instruction is initiated in clock cycle 4 Instruction Number Clock number 1 2 3 4 5 6 7 8 9 10 load IF ID EX MEM WB Instruction i+1 IF ID EX MEM WB Instruction i+2 IF ID EX MEM WB Instruction i+3 stall IF ID EX MEM WB Instruction i+4 IF ID EX MEM WB Instruction i+5 IF ID EX MEM Structural Hazards (5) A machine with structural hazard will have lower CPI Why a designer allows structural hazard? To reduce cost Pipelining all the functional units or duplicating them may be too costly To reduce latency Introducing too many pipeline stages may cause latency issues Data Hazards (1) Arise when an instruction depends on the results of a previous instruction in a way that is exposed by overlapping of instruction in pipeline The 2 nd instruction needed a result which previous instruction have to produce. It forces 2 nd instruction to wait.
Consider the execution of following instructions, on our pipelined example processor: ADD R1, R2, R3 SUB R4, R1, R5 AND R6, R1, R7 OR R8, R1, R9 XOR R10, R1, R11 Data Hazards (2) The use of results from ADD instruction causes hazard since the register is not written until after those instructions read it. Data Hazards (3) Eliminate the stalls for the hazard involving SUB and AND instructions using a technique called forwarding Data Hazards (4) Store requires an operand during MEM and forwarding is shown here. The result of the load is forwarded from the output in MEM/WB to the memory input to be stored In addition the ALUOutput is forwarded to ALU input for address calculation for both Load and Store Data Hazards Classification Depending on the order of read and write access in the instructions, data hazards could be classified as three types. Consider two instructions i and j, with i occurring before j. Possible data hazards: RAW (Read After Write) j tries to read a source before i writes to it , so j incorrectly gets the old value; most common type of hazard, that is what we tried to explain so far. WAW (Write After Write) j tries to write an operand before is written by i. The write ends up being performed in wrong order, having i overwrite the operand written by j, the destination containing the operand written by i rather than the one written by j Present in pipelines that write in more than one pipe stage WAR (Write After Read) j tries to write a destination before it is read by i, so the instruction i incorrectly gets the new value This doesnt happen in our example, since all reads are early and writes late Control Hazards (1) Arise from the pipelining of branches/instructions that change the PC Can cause a greater performance loss than the data hazards This type of hazard is caused by uncertainty of execution path, branch taken or not taken When a branch is executed it may or it may not change the PC (to other value than its value + 4) If a branch is changing the PC to its target address, than it is a taken branch If a branch doesnt change the PC to its target address, than it is a not taken branch If instruction i is a taken branch, than the value of PC will not change until the end MEM stage of the instruction execution in the pipeline A simple method to deal with branches is to stall the pipe as soon as we detect a branch until we know the result of the branch Methods to Deal with Control Hazard:
Pipeline stall until branch target known. Always execute instructions following a branch regardless of whether branch taken or not taken. The simplest method of dealing with branches is to stall the pipeline as soon as the branch is detected until we reach the MEM stage, which determines the new PC. The pipeline behavior looks like: The stall does not occur until after ID stage (where we know that the instruction is a branch). One cycle is a repeated IF necessary if the branch would be taken. If the branch is not taken, this IF is redundant This control hazard stall must be implemented differently from a data hazard, IF cycle of the instruction following the branch must be repeated as soon as we know the branch outcome. Thus, the first IF cycle is essentially a stall (because it never performs useful work), which comes to total 3 stalls. Three clock cycles wasted for every branch is a significant loss. With a 30% branch frequency and an ideal CPI of 1, the machine with branch stalls achieves only half the ideal speedup from pipelining. The number of clock cycles can be reduced by two steps: - Find out whether the branch is taken or not taken earlier in the pipeline; - Compute the taken PC (i.e., the address of the branch target) earlier. The Branch delay slot scheduling method helps reducing the branch penalty. There are three modes of scheduling the delay slot in the branching instructions: Scheduling before the branch target instruction.(fig.1) Scheduling from the target instruction.(fig.2) Scheduling from fall through instruction.(fig.3)
Add $t1, $t2, $t4
Add $s1, $s2, $s3 If $s2 = 0 then Delay slots Add $s1, $s2, $s4 If $s2 = 0 then Delay slots Sub t4, t5, t6
Add $s1, $s2, $s3 If $s2 = 0 then Sub t4, t5, t6 Add $s1, $s2, $s3 If $s2 = 0 then Delay slots If $s2 = 0 then
Add $s1, $s2, $s3 From before Becomes From target Becomes Add $s1, $s2, $s3 If $s2 = 0 then Add $t1, $t2, $t4 From fall through Becomes References
Computer Architecture A Quantitative Approach, John L Hennessy & David A Patterson, ISBN 1-55860-329-8 Computer Architecture, Nicholas Charter, ISBN 0-07-136207