1 / 24

Forwarding and Hazards

Forwarding and Hazards. *Roles change with Phase. Overview What are Hazards?. Hazards are problems that occur within the instruction pipeline of the central processing unit (CPU) microarchitecture that can potentially result in an incorrect computation. There are several types of hazards

rupert
Télécharger la présentation

Forwarding and Hazards

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Forwarding and Hazards *Roles change with Phase

  2. OverviewWhat are Hazards? • Hazards are problems that occur within the instruction pipeline of the central processing unit (CPU) microarchitecture that can potentially result in an incorrect computation. • There are several types of hazards • Structural Hazards • Data Hazards • Control Hazards

  3. Block Diagram

  4. Structural Hazards • When the current instruction cannot execute in the proper clock cycle because the hardware does not support the combination of instructions that are set to execute • These are not a problem in the MIPS architecture, as there is sufficient hardware to implement everything we need • The only solution, would they occur, would be to add more hardware

  5. Data Hazards • When the current instruction cannot execute in the proper clock cycle because data that is needed to execute instruction is not available. • Load-use data hazard: a specific form of data hazard in which the data being loaded by a load instruction has not yet become available when it is needed by another instruction

  6. Read-after-Read (RAR) • This is a false dependency • Reading won’t alter the contents of the register file, and the registers are read at different times

  7. Write-after-Write (WAW) • This is not a hazard to be concerned with • The output of the second operation in no way relies on the output of the first • Output is stored again in the next pipeline stage, overwriting the value from the first instruction

  8. Write-after-Read (WAR) • This is also not a hazard • The “sub” instruction reads in the value of $t3 five stages before it’s written into the register file

  9. Read-after-Write (RAW) • This refers to a situation where a previous instruction has not finished writing a value to memory before it needs to be used • This can occur because of the pipelined nature of our processor. Data is written back to the register file two stages after the subsequent instruction needs this information. • This is known as a true-data dependency

  10. Data HazardsTrue-Data Dependencies • Stalling – inserts a bubble, or a nop (no operation) into the pipeline • Forwarding – Copies data from inside the pipeline before it is written back to the register.

  11. Forwarding Example add $t1, $t2, $t3 add $t4, $t1, $t5

  12. Forwarding Logic

  13. Selector MUXs

  14. Data HazardsLoad-Use Hazard • There is a case where forwarding will not solve our problems, as the load will not resolve until the last clock cycle in the pipeline, while the subsequent instruction needs the information in the previous cycle. • Therefore, we must stall the pipeline in order to let the load instruction to “catch up”

  15. Load-Use Example

  16. Hazard Detection Unit

  17. Bubble Control Flow Chart

  18. Handling the Bubble

  19. Inserting the Bubble

  20. Control Hazards • Branch (beq) • Two paths that can be taken, uses a statement that checks which branch will be taken. • (Think of an “if” statement in Java, or C.) • Jump (j) • Always “jumps” to a different location in the code.

  21. Control HazardsFlush Logic • Because there are two options in a branch, we assume the branch will not be taken. If the branch is taken we must remove the instructions that have entered the pipeline. • We do this with a “flush” where we turn all values in the pipeline into nop.

  22. Flush Logic

  23. Questions?

More Related