Hazard detection units: Worked examples — Hinglish deep dive

5.2.10 · D3 · Hardware › Processor Datapath & Pipelining › Hazard detection units

Yeh page Hazard detection units ki practice ground hai. Hum ek waqt mein ek instruction sequence ko pipeline ke through chalayenge aur decide karenge — har case class ke liye — ki hazard unit ko stall karna chahiye, forwarding unit humein bacha sakta hai, ya kuch karna hi nahi hai.

Shuru karne se pehle, ek chhoti si reminder taaki koi bhi symbol undefined na rahe.

Definition Woh words aur signals jo hum baar baar use karenge

Stage = pipeline mein ek workbench. Order mein: IF (fetch), ID (decode + registers padhna), EX (calculation karo), MEM (memory ko touch karo), WB (result wapas register mein likhna).
Pipeline register = woh box jo ek instruction ki info ko ek stage se agale stage tak le jaata hai. IF/ID woh box hai jo IF aur ID ke beech hai — yeh jo abhi ID mein hai usse hold karta hai (toh IF/ID.Rs, IF/ID.Rt woh registers hain jo decoding instruction padhti hai). ID/EX woh box hai jo ID aur EX ke beech hai — yeh jo abhi EX mein hai usse hold karta hai.
Rs, Rt = woh do register numbers jo instruction padhti hai. Rd = woh register number jisme woh likhti hai.
MemRead = 1 = "yeh instruction memory se padhti hai" — sirf loads (lw) yeh karte hain.
RegWrite = 1 = "yeh instruction WB par ek register likhegi." Joh instructions kuch nahi likhtiein (jaise sw, beq, j) unka RegWrite = 0 hota hai, toh unka Rd meaningless hai aur KABHI forward ya stall trigger nahi karna chahiye. Neeche har hazard test mein silently RegWrite == 1 producer par AND hota hai.
Stall signals jo hazard unit ek cycle ke liye pipe ko freeze karne ke liye assert karta hai: PCWrite = 0 (agla instruction fetch mat karo), IF/ID_Write = 0 (decoding instruction ko ID mein rokho taaki woh retry kare), Control_Mux = 0 (EX mein jaane wale saare control bits ko zero karo, ek bubble create karta hai = ek instruction jo kuch nahi karti).
Flush signals branches ke liye: Branch = 1 matlab "yeh instruction ek branch hai"; BranchTaken = 1 matlab "branch condition true nikli, toh PC change hoga." Unka AND Flush signal hai jo galat path ki instruction ko cancel karta hai.

Neeche wali picture apne dimag mein rakho: instructions left-to-right march karti hain, ek stage per clock tick.

Intuition Sirf RAW hazards kyun hain yahan — WAW aur WAR kahan gaye?

Parent note se teen data-hazard types yaad karo. WAR (write-after-read) aur WAW (write-after-write) ke liye instructions ko program order se bahar finish karna hota hai taaki trouble ho. Hamara simple 5-stage pipeline strictly in-order hai: har instruction ID mein apne registers padhti hai aur WB mein likhti hai, aur yeh stages sab ke liye same left-to-right order mein hoti hain. Toh ek purani instruction hamesha ek nayi ke likhne se pehle padhti hai (no WAR), aur hamesha ek nayi ke likhne se pehle likhti hai (no WAW). Sirf RAW (read-after-write) bachta hai — ek nayi instruction ek value padhti hai jo ek purani instruction ne abhi tak likhi nahi hai. Is page ke har example mein RAW case hai (ya ek control case). Out-of-order machines mein WAR/WAW wapas aate hain — dekho 5.2.11-Branch-prediction.

Scenario matrix

Is topic ka har sawaal exactly inhi cells mein se ek mein aayega. Page ka baaki hissa har ek ko fill karta hai.

#	Case class	Trigger	Hazard unit kya karta hai	Example
A	Koi dependency nahi	reads/writes overlap nahi karte	kuch nahi	Ex 1
B	ALU-ALU RAW, 1 apart	prev instr result agla feed karta hai	kuch nahi — forwarding fix karta hai	Ex 2
C	Load-use, 1 apart	`lw` phir instr uska `Rd` padhti hai	STALL 1 cycle, phir forward	Ex 3
D	Load-use, 2 apart	dono ke beech ek instr hai	kuch nahi — forwarding fix karta hai	Ex 4
E	Degenerate: `Rd = $0`	destination register zero hai	kuch nahi (kabhi `$0` par stall mat karo)	Ex 5
F	Rs aur Rt dono depend karte hain	instr loaded reg do baar padhti hai	phir bhi ek stall	Ex 6
G	Store-use RAW	`sw` abhi produce ki gayi value store karta hai	kuch nahi — forwarding fix karta hai	Ex 7
H	Control hazard, taken	branch PC change karta hai	FLUSH wrong-path instr	Ex 8
I	Control hazard, not-taken	branch fall through karta hai	kuch nahi (guess sahi tha)	Ex 9
J	Unconditional jump (`j`/`jr`)	PC hamesha change hota hai	FLUSH ek instr	Ex 10
K	Exam twist: stall + forward chained	`lw` phir do dependents	ek stall + do forwards	Ex 11

Recall SIRF kaun sa data hazard stall force karta hai?

Load-use hazard: lw EX mein aur bilkul agli instruction uska Rd padhti hai. ::: Kyunki loaded value MEM ke end tak ready nahi hoti, toh forward karne ke liye abhi kuch hai hi nahi.

Example 1 — Cell A: bilkul koi dependency nahi

Worked example Koi overlap nahi

add  $3, $1, $2     ; writes $3
sub  $6, $4, $5     ; reads $4, $5 - add se untouched

Forecast: Abhi guess karo — stall, forward, ya kuch nahi?

Steps

List karo ki sub kya padhta hai: Rs = $4, Rt = $5. Yeh step kyun? Hazard unit sirf younger instruction ki reads ko older wali ki writes se compare karta hai. Agar kuch nahi padhaa jaata jo abhi likha gaya tha, toh koi dependency nahi hai.
List karo ki add kya likhta hai: Rd = $3 (aur add.RegWrite = 1, toh yeh ek real destination hai). Kyun? $3 ek hi register hai jis par add hazard create kar sakta tha — aur sirf isliye kyunki RegWrite = 1 hai.
Compare karo: kya $3 == $4 hai? Nahi. Kya $3 == $5 hai? Nahi. Kyun? Load-use condition aur forwarding condition dono inhi equalities par hinge karti hain. Dono fail hoti hain.

Answer: Kuch mat karo. Full speed, zero bubbles.

Recall Verify karo

Cycles used = 2 instructions normally overlap kiye, koi extra cycles nahi. Penalty = 0. ✓

Example 2 — Cell B: ALU→ALU RAW, forwarding bacha leta hai

Worked example Back-to-back arithmetic dependency

add  $1, $2, $3     ; produces $1 in EX
sub  $4, $1, $5     ; needs $1 immediately

Forecast: sub ko $1 chahiye ek cycle baad jab add use compute karta hai. Stall? Ya data teleport ho sakta hai?

Steps

add $1 compute karna apne EX stage ke end par khatam karta hai — value EX/MEM register mein baithi hai. Kyunki add.RegWrite = 1, yeh value ek legitimate forwarding source hai. Kyun? ALU result EX complete hote hi exist karta hai; hume WB ka wait nahi karna padta. RegWrite check wahi hai jo forwarding ko Rd field par trust karne deta hai.
sub exactly ek cycle baad EX pahunchta hai. Us waqt add ki value EX/MEM mein hai. Yeh kyun matter karta hai: forwarding unit EX/MEM ko seedha ALU input mein route kar sakta hai. Data already alive hai jab chahiye.
Hazard unit check: kya yeh ek load hai? add.MemRead = 0. Toh load-use stall condition false hai. Kyun? Stalling sirf us ek case ke liye reserved hai jab forwarding cover nahi kar sakti. Yeh woh case nahi hai.

Answer: Koi stall nahi. Forwarding unit EX/MEM → ALU select karta hai. Penalty = 0.

Recall Verify karo

Figure mein red arrow $1 ko EX/MEM se sub ke EX mein deta hai. Timing line up hoti hai → 0 stall cycles. ✓

Example 3 — Cell C: load-use, classic stall

Worked example

lw phir immediate use

lw   $2, 20($1)     ; loads $2, MemRead = 1
add  $4, $2, $5     ; reads $2 right away

Forecast: Load ka data MEM ke end tak ready nahi hota. Kya forwarding yahan jeet sakti hai? Guess karo.

Steps

Load-use condition evaluate karo (producer lw ID/EX mein hai, consumer add IF/ID mein hai): $ID/EX.MemRead = 1 \land (ID/EX.Rd = IF/ID.Rs \lor ID/EX.Rd = IF/ID.Rt)$ Yahan MemRead = 1 hai, aur Rd = $2 = Rs of add. Condition TRUE. Yeh step kyun? Yeh exactly woh combinational test hai jo unit perform karta hai. IF/ID.Rs/IF/ID.Rt add ke read registers hain; ID/EX.Rd lw ka destination hai. Jab yeh fire hota hai, forwarding provably bahut slow hai.
Teen stall signals assert karo jo reminder mein define hain: PCWrite = 0, IF/ID_Write = 0, Control_Mux = 0. Kyun? PCWrite = 0 aur IF/ID_Write = 0 PC aur ID box ko freeze karte hain taaki add agla cycle retry kare; Control_Mux = 0 control bits ko zero karta hai taaki EX mein jaata bubble kuch na kare.
Agla cycle, lw ka data MEM/WB tak pahunchta hai; add (ek cycle peeche roka gaya) ab EX mein enter karta hai aur MEM/WB se forward karta hai. Kyun kaam karta hai: ek-cycle delay exactly itna hai ki loaded value forwardable ban jaye.

Answer: 1 stall cycle, phir forward. Penalty = 1.

Recall Verify karo

Detection ke bina add stale $2 padhta hai. Detection ke saath: 1 bubble → pair ke liye total cycles exactly 1 se badhta hai. Penalty = 1. ✓

Example 4 — Cell D: load-use, lekin do instructions apart

Worked example Ek gap din bachaa leta hai

lw   $2, 20($1)     ; load $2
or   $8, $6, $7     ; independent - gap mein baitha hai
add  $4, $2, $5     ; reads $2, lekin DO instructions baad

Forecast: Beech mein independent or kuch change karta hai kya?

Steps

Jab add ID mein hai, lw ab EX mein nahi hai — woh MEM/WB tak advance kar gaya hai. Yeh step kyun? Load-use condition ID/EX.MemRead check karta hai. Lekin lw ab MEM/WB mein hai, ID/EX mein nahi. Toh stall condition false hai.
add EX pahunchta hai jab lw ka data MEM/WB mein baitha hota hai (lw.RegWrite = 1 ke saath, woh box ek valid forward source hai). Kyun matter karta hai: MEM/WB → ALU se forwarding legal hai aur data ready hai.
Hazard unit kuch nahi karta; forwarding unit routing karta hai. Kyun? Gap instruction ne exactly woh ek cycle kharida jo ek load ko chahiye.

Answer: Koi stall nahi. Penalty = 0. (Isliye compilers load delay slots fill karne ke liye reorder karte hain.)

Recall Verify karo

Cycles: lw, or, add bina bubble ke pipeline karte hain → 0 extra cycles. ✓

Example 5 — Cell E: degenerate destination `$0`

Worked example Woh register jo hamesha zero hai

lw   $0, 20($1)     ; "loads" into $0 - lekin $0 hardwired to 0 hai
add  $4, $0, $5     ; reads $0

Forecast: Load ka Rd = $0 add ke Rs = $0 se match karta hai. Naive logic chillata hai "stall!". Kya karna chahiye?

Steps

MIPS mein, register $0 permanently 0 hai; isme likhna discard ho jaata hai. Yeh step kyun? Agar ek value kabhi actually change nahi hoti, toh protect karne ke liye koi dependency nahi hai — $0 padhna hamesha 0 deta hai, load ho ya na ho.
Toh real condition mein ek extra guard hota hai: ID/EX.Rd ≠ 0. Kyun? Iske bina, koi bhi instruction jo ek bogus lw $0 ke baad $0 padhti hai woh needlessly stall karti — pure waste.
Yahan Rd = $0 hai, toh guard ID/EX.Rd ≠ 0 false evaluate karta hai, poore AND ko FALSE force karta hai. Kyun? Stall condition ek bada AND hai; ek false term ($0 guard) usse kill kar deta hai chahe kitne bhi register numbers match karein. Yahi hum chahte hain — kabhi ek aise value ke liye stall mat karo jo change hi nahi ho sakti.

Answer: Koi stall nahi. Penalty = 0. Hamesha Rd ≠ $0 guard add karo.

Example 6 — Cell F: loaded register do baar padha gaya

Worked example Dono operands load se aate hain

lw   $2, 0($1)      ; load $2
and  $2, $2, $2     ; reads $2 as BOTH Rs and Rt

Forecast: $2 dono Rs aur Rt par match karta hai. Do matches — do stalls?

Steps

Load-use condition Rs == Rd OR Rt == Rd use karta hai. Yeh step kyun? Yeh ek single boolean OR hai — koi bhi ek match ise ek baar fire karne ke liye kaafi hai.
Dono disjuncts true hain, lekin true-or-true ka OR phir bhi sirf ek true signal hai. Kyun? Stall poori instruction ke baare mein ek decision hai, per-operand nahi. Ek instruction ek cycle stall karti hai chahe kitne bhi operands clash karein.
Ek bubble ke baad, forwarding MEM/WB se $2 dono ALU inputs ko deliver karta hai.

Answer: 1 stall cycle (do nahi). Penalty = 1.

Recall Verify karo

OR(True, True) = True → ek stall assertion → 1 bubble. ✓

Example 7 — Cell G: store-use RAW (store ko fresh value chahiye)

Worked example Abhi produce ki gayi value store karna

add  $4, $1, $2     ; produces $4 in EX
sw   $4, 0($5)      ; stores $4 to memory - RAW on $4

Forecast: sw memory likhta hai, register nahi (sw.RegWrite = 0). Lekin yeh abhi bhi $4 ko data source ke roop mein padhta hai. Kya iske liye stall, forward, ya kuch nahi?

Steps

sw ke reads identify karo: sw $4, 0($5) $5 (address base) aur $4 (store kiya jaane wala data) padhta hai. Dono Rs/Rt fields hain. Yeh step kyun? Store registers waise hi padhti hai jaise koi bhi instruction; hazard machinery un reads ko older writes se compare karta hai. Yahan add.Rd = $4 sw ke data register se match karta hai.
add.RegWrite = 1 aur add.MemRead = 0, toh add ek ALU producer hai, load nahi. Kyun matter karta hai: load-use stall condition ko producer par MemRead = 1 chahiye. add ise fail karta hai → koi stall nahi. Store ka apna RegWrite = 0 yahan irrelevant hai kyunki sw consumer hai, source nahi.
add ka result EX/MEM mein baitha hai (phir MEM/WB mein) exactly jab sw ko chahiye. Forwarding unit use sw ke pipeline register mein route karta hai MEM stage memory likhne se pehle. Kyun? Store data sirf MEM stage par consume hota hai — ALU input se bhi baad mein — toh forwarding ke paas hamesha waqt hota hai. Stores kabhi load-use stall cause nahi karte.

Answer: Koi stall nahi. $4 ko store data path mein forward karo. Penalty = 0.

Recall Verify karo

Producer add: MemRead = 0 → load-use condition false → 0 stall cycles. ✓

Example 8 — Cell H: control hazard, branch taken

Worked example Branch decide karta hai "kahin aur jao"

      beq  $1, $2, Label   ; taken (assume $1 == $2)
      add  $3, $4, $5      ; wrong-path - already fetched
Label: sub  $6, $7, $8     ; asli agla instruction

Forecast: Jab tak hume pata chalta hai ki branch taken hai, add already pipe mein hai. Iske saath kya hoga?

Steps

Branch ko early (ID mein) resolve karo: ek comparator se $1 aur $2 compare karo, ek adder se target compute karo. Yeh Branch = 1 set karta hai aur, kyunki equal hai, BranchTaken = 1. Yeh step kyun? ID mein resolve karne ka matlab hai ki hume ek cycle baad "taken" pata chalta hai beq fetch karne ke baad — toh sirf ek galat instruction (add) fetch ho gayi.
Flush condition (reminder se flush signals use karke): $Flush = Branch \land BranchTaken$ . Dono true → flush. Kyun? Pehle se fetch ki gayi wrong-path instruction ko cancel karna hoga state corrupt hone se pehle.
IF/ID = NOP set karo (add ko bubble mein badlo) aur PC ko Label ke address se load karo. Kyun? Bubble baad ke stages mein kuch nahi karta; corrected PC sub ko agla fetch karta hai.

Answer: 1 flush (1 penalty cycle) ID-stage resolution ke saath.

Recall Verify karo

ID resolution ke saath penalty = 1 cycle (ek galat fetch). Agar EX mein resolve hota, penalty 3 hoti. ID resolution → penalty 1. ✓

Example 9 — Cell I: control hazard, branch NOT taken

Worked example Predict-not-taken kaam aa jaata hai

beq  $1, $2, Label   ; NOT taken (assume $1 != $2)
add  $3, $4, $5      ; sahi agla instruction - isko rakho!

Forecast: Humne add fetch kiya "branch not taken" assumption par. Branch sach mein taken nahi hai. Reward?

Steps

Simple predict-not-taken policy ke under, pipeline sequentially fetch karna jaari rakhti hai. Yeh step kyun? "Not taken" guess karne ka matlab hai ki hum speculatively fall-through instruction add fetch karte hain.
Branch resolve hota hai: Branch = 1, BranchTaken = 0 → guess sahi tha. Kyun matter karta hai: add exactly sahi instruction thi. Kuch undo karne ki zaroorat nahi.
Flush condition: $Branch \land BranchTaken = 1 \land 0 = 0$ . Koi flush nahi.

Answer: 0 penalty. Isliye not-taken prediction fall-through par free hai. (Smarter guessing ke liye 5.2.11-Branch-prediction dekho.)

Recall Verify karo

AND(1, 0) = 0 → koi flush nahi → penalty 0. ✓

Example 10 — Cell J: unconditional jump (`j` / `jr`)

Worked example PC

hamesha change hota hai

      j    Target        ; unconditional - PC ban jaata hai Target, koi condition nahi
      add  $3, $4, $5     ; fall-through - HAMESHA galat
Target: sub $6, $7, $8    ; asli agla instruction

Forecast: Ek jump mein koi "taken/not-taken" nahi hota — yeh hamesha redirect karta hai. Toh kya add kabhi sahi instruction hai?

Steps

j (fixed address par jump) aur jr (ek register mein held address par jump) ko instructions ke roop mein pehchano jo PC ko unconditionally change karte hain. Yeh step kyun? beq ke unlike, compare karne ke liye kuch nahi hai — "taken" outcome 1 par fixed hai. Toh ek jump ke liye Flush sirf Jump = 1 hai (koi BranchTaken term nahi chahiye).
j fetch karne ke baad wale cycle mein, hum pehle se fall-through add fetch kar chuke hain. Yeh poori certainty ke saath wrong path par hai. Kyun matter karta hai: kyunki jump hamesha taken hota hai, speculatively fetched add hamesha garbage hai — koi lucky "not-taken" case nahi hai.
Ek instruction flush karo: IF/ID = NOP set karo, aur PC ko Target se load karo (j ke liye) ya register value se (jr ke liye, jo ID ke register padhne ke baad known hoti hai). Kyun? Ek galat fetched instruction, ek bubble — wahi 1-cycle penalty jaisi taken branch ki jab jump target ID mein compute hoti hai.

Answer: 1 flush (1 penalty cycle) ID mein resolve hue jump ke liye. Ek branch ke unlike, yeh cost unavoidable hai — tum predict-not-taken se hamesha-taken jump se bach nahi sakte.

Recall Verify karo

Jump hamesha redirect karta hai → hamesha 1 fall-through instr flush karo → penalty 1 (ID resolution). ✓

Example 11 — Cell K (exam twist): stall phir do chained forwards

Worked example Ek load poori chain ko feed karta hai

lw   $2, 0($1)      ; load $2
add  $4, $2, $3     ; needs $2 immediately  -> load-use!
sub  $5, $4, $2     ; needs $4 (from add) AND $2 (from lw)

Forecast: Total penalty cycles count karo. Trap: kya sub ke liye doosra stall hai?

Steps

lw → add ek load-use hazard hai (Ex 3 pattern). 1 cycle stall karo. Yeh step kyun? add $2 padhta hai jabki lw EX mein hai → forwarding impossible → ek bubble.
Bubble ke baad, add execute karta hai aur MEM/WB se $2 forward karta hai. Kyun? Ab tak loaded value forwardable hai — exactly woh stall ne humein kharida.
sub $4 padhta hai (add ne produce kiya, EX/MEM se forward) aur $2 (lw se, ab WB mein — normally padha ya MEM/WB se forward). Dono pure ALU/available forwards hain → koi extra stall nahi. Kyun? Sirf load-use stalls hote hain. add ek load nahi hai, toh sub ki usse dependency sirf forwarding maangti hai.

Answer: Total penalty = 1 stall cycle, plus forwarding add aur sub dono mein. Exam trap yeh sochna hai ki sub ek doosra stall add karta hai — nahi karta.

Recall Verify karo

Load-use stalls tabhi fire hote hain jab producer EX mein ek load hai. Sirf lw→add qualify karta hai → 1 stall total. ✓

Wrap-up: woh decision jo tum ab automatically run karte ho

Flowchart dikhata hai ki forwarding unit apna source kaise pick karta hai: yeh EX/MEM (most recent producer) ko MEM/WB par prefer karta hai, aur yeh tabhi forward karta hai jab producer ka RegWrite = 1 aur Rd ≠ 0 confirm ho.

Yeh pipeline control signals (stall/flush lines) aur control unit se tie back karta hai jo yeh logic host karta hai. Hinglish walkthrough ke liye dekho 5.2.10 Hazard detection units (Hinglish).