1 / 25

Understanding Pipelining and Hazards in Computer Architecture

This lecture from Caltech's CS184b course explores the principles of pipelined processor design and various types of hazards that can occur during instruction execution. Topics include structural, data, and control hazards, and strategies for accommodating these issues. Emphasis is placed on the DLX architecture, discussing the effects of pipeline latency, the importance of instruction scheduling, and the impacts of different execution paths on performance. The session aims to provide a comprehensive understanding of pipelining for improved processor efficiency.

velma
Télécharger la présentation

Understanding Pipelining and Hazards in Computer Architecture

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. CS184b:Computer Architecture[Single Threaded Architecture: abstractions, quantification, and optimizations] Day5: January 17, 2000 Pipelining ISA Processor Execution Caltech CS184b Winter2001 -- DeHon

  2. Today • Pipelined Processor Issue • Hazards • structural • data • control (next time) • accommodating • impact • RISC/CISC wrapup (maybe) • Admin question: this time good next term? Caltech CS184b Winter2001 -- DeHon

  3. DLX Datapath DLX unpipelined datapath from H&P (Fig. 3.1) Caltech CS184b Winter2001 -- DeHon

  4. DLX Model Behavior • Read Registers • Perform primitive ALU Op • Read/Write memory • Write register result Caltech CS184b Winter2001 -- DeHon

  5. Pipeline? Caltech CS184b Winter2001 -- DeHon

  6. Pipeline DLX DLX unpipelined datapath from H&P (Fig. 3.4) Caltech CS184b Winter2001 -- DeHon

  7. Hazards • Structural (resource bound) • Data (value timing) • Control (knowing where to go next) Caltech CS184b Winter2001 -- DeHon

  8. Structural Hazards • Arise when • Instructions have varying resource requirements • Usage of resources not occur at same time • Not want to provide resources for worst-case • typically because it’s not the “common” case • performance impact small compared to cost of handling worst case Caltech CS184b Winter2001 -- DeHon

  9. Structural Hazards • Have to consider: • all possible overlaps of instructions • simplified by considering instruction classes • (e.g. add R1,R2,R3, sub R3,R4,R5, … all use same resource set…) Caltech CS184b Winter2001 -- DeHon

  10. Structural Hazard: Identify • Identify by: • looking at instruction (class) resource usage in pipeline • Register-Register Op: • IF - I-mem port • ID - 2 register read ports • EXU - ALU • MEM - --- • WB - 1 register write port Caltech CS184b Winter2001 -- DeHon

  11. Structural Hazard: Identify • R-R: 1I 2RR 1A -- 1RW • L/S: 1I 1RR 1A 1AB,1DB 1RW • BR: 1I 1RR 1A -- -- • Conflicts: • standard DLX • RF has 1R, 1RW port Caltech CS184b Winter2001 -- DeHon

  12. Structural Hazard: Identify • Pipelined Memory access • R-R: 1I 2RR 1A -- -- 1RW • L: 1I 1RR 1A 1AB 1DB 1RW • S: 1I 1RR 1A 1AB,1DB -- 1RW • BR: 1I 1RR 1A -- -- Caltech CS184b Winter2001 -- DeHon

  13. Structural Hazards: Deal • Datapath cannot handle • Always have the option of idling on a cycle • “Bubble” into pipeline • allow downstream continue, stall upstream • Options: • detect when occurs and stall one instruction • detect will occur at issue and stall Caltech CS184b Winter2001 -- DeHon

  14. Pipeline DLX Caltech CS184b Winter2001 -- DeHon

  15. Data Hazards • Pipeline Latency • Instruction effects not completed before next operation begins Caltech CS184b Winter2001 -- DeHon

  16. Data Hazard: Example • ADD R1,R2,R3 • XOR R4,R1,R5 Caltech CS184b Winter2001 -- DeHon

  17. Data Hazard: Solving • Primary problem (DLX) • data not back in RF • read stale data • Partially solve with bypassing • when good data exist before use Caltech CS184b Winter2001 -- DeHon

  18. Data Hazard: Solving • [todo: draw DP with bypass muxes] Caltech CS184b Winter2001 -- DeHon

  19. Data Hazard • Note: since ops may stall, interrupt, resume • cannot decide how to set bypass muxes in ID stages • have to determine based on state of pipeline Caltech CS184b Winter2001 -- DeHon

  20. Data Hazard • Not all cases can bypass • if data not available anywhere, yet... • e.g. • LW R1,4(R2) • ADD R3,R1,R4 Caltech CS184b Winter2001 -- DeHon

  21. Model/Common Case • Common/simple case • Implementation transparency • Could have slowed the initiation interval for all ops • OR could have said can’t use value for number of cycles • But, only few sequences/cases problematic • let rest run faster Caltech CS184b Winter2001 -- DeHon

  22. Types of Data Hazards • RAW (example seen) • WAW • order of writes transposed going to memory • leave wrong value in memory • WAR • read gets value computed “after” it should have completed Caltech CS184b Winter2001 -- DeHon

  23. Compiler • Instruction Scheduling can try to avoid • (making some assumptions about implementation) • Schedule instructions in delay slot • possible when have parallelism/independent tasks • another example where optimize across larger block give tighter results Caltech CS184b Winter2001 -- DeHon

  24. Big Ideas • Preserve the (simple, stable) model • While providing high-performance implementation Caltech CS184b Winter2001 -- DeHon

  25. Big Ideas • Ops with different requirements • Some cases can run faster than others • Fast in simple, common cases • Correct in others Caltech CS184b Winter2001 -- DeHon

More Related