Hazard detection units: Question bank — Hinglish deep dive

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

Questions se pehle, yeh page har woh vocabulary khud se build karta hai jo woh use karta hai. Yeh setup ek baar padho; poora bank isi par tika hai.

Paanch lanes (pipeline stages)

Pipeline ko paanch lanes ki tarah imagine karo, aur ek instruction har clock tick par ek lane daayein khisak rahi hai:

IF — instruction fetch: memory se agla instruction pakdo.
ID — instruction decode: pata lagao yeh kya hai aur apne source registers padho.
EX — execute: ALU arithmetic karta hai.
MEM — memory: data memory ko touch karo (sirf loads aur stores yahan real kaam karte hain).
WB — write-back: result ko register file mein likho.

Pipeline registers (ID/EX-style names)

Lanes ke har pair ke beech mein ek pipeline register baitha hota hai — ek latch jo har clock edge par ek instruction ka data ek stage se agale mein le jaata hai. Inhe un do stages ke naam se jaana jaata hai jinke beech yeh baitha hai:

Aisi register ke andar ek field dot ke saath likhi jaati hai: ID/EX.MemRead ka matlab hai "jo bhi instruction currently EX mein hai uska MemRead control bit".

Register fields Rs, Rt, Rd

Har MIPS instruction teen tak registers number se name karti hai:

Is bank mein use hone wale control signals

Definition Woh signals jo aap neeche milenge

PCWrite — program counter par ek 1-bit enable. PCWrite = 1 PC ko agla instruction fetch karne deta hai; PCWrite = 0 ise freeze karta hai.
IF/ID write-enable — IF/ID register ke liye wahi idea; ise 0 set karna instruction ko ID mein rok deta hai.
MemRead — ek decoded control bit jo sirf load instruction ke liye 1 hota hai (yeh MEM mein memory padhta hai).
Stall — hazard unit ka output jo, jab 1 ho, pipe ke front ko freeze karta hai aur ek bubble inject karta hai.
Flush — ek signal jo already-fetched wrong-path instruction ko discard karta hai use NOP mein convert karke.
Branch — 1 agar current instruction ek branch hai. BranchTaken — 1 agar us branch ki condition sach nikli.

Yeh sab pipeline control signals se aate hain jo control unit ID mein generate karta hai.

Bubble kahan se aata hai — control mux

Forwarding vs. stalling (do ilaaj)

Forwarding = ek shortcut wire jo ek freshly-computed value ko backward ek aisi instruction tak le jaata hai jise abhi chahiye, register file tak pahunchne ka intezaar karne ki jagah. Forwarding unit dwara EX/MEM ya MEM/WB se handle kiya jaata hai.
Stall = pipeline ke front ko ek tick ke liye freeze karna aur ek bubble inject karna taaki ek not-yet-ready value ko appear hone ka waqt mile.

Load-use detection condition, poori tarah se explain ki gayi

Is bank mein har stall ek Boolean expression se aati hai. Yeh poori tarah se likhi hai:

Kyun exactly ek bubble kaafi hai

Load lw aur uske consumer add ko, tick by tick, ek bubble insert hone ke saath trace karo:

Cycle	IF	ID	EX	MEM	WB
1	`lw`	—	—	—	—
2	`add`	`lw`	—	—	—
3	`add`	bubble	`lw`	—	—
4	…	…	bubble	`lw`	—
5	…	`add`	…	bubble	`lw`

Cycle 3 mein hazard unit detect karta hai lw EX mein hai aur add ID mein hai, toh woh add ko freeze karta hai (ID mein hold karta hai) aur ek bubble inject karta hai. Cycle 5 tak load ki value MEM/WB tak pahunch gayi hai, jo exactly woh stage hai jahan se forwarding unit bypass kar sakta hai add ke EX mein. Ek bubble woh minimum delay hai jo load ko forwardable position mein le aati hai — isliye exactly ek kaafi hai.

Hazard detection unit tab hi fire karta hai jab forwarding tumhe bacha nahi sakta. Woh ek sentence hi hai jo in mein se zyaadatar traps ko unlock karta hai.

True or false — justify karo

Forwarding unit aur hazard detection unit logic ka ek hi block hai

False. Yeh alag combinational blocks hain: forwarding choose karta hai kaunsi wire ALU ko feed kare (data routing), jabki hazard detection decide karta hai stall/flush karna hai ya nahi (control flow). Yeh coordinate karte hain lekin inke alag kaam hain aur alag outputs hain.

Har data hazard ek pipeline stall force karta hai

False. Arithmetic instructions ke beech zyaadatar RAW (read-after-write) hazards forwarding se free mein theek ho jaate hain — result EX ke end mein exist karta hai aur bypass kiya ja sakta hai. Sirf load-use case, jahan value literally abhi exist nahi karti, stall chahiye.

Hazard detection unit EX stage mein rehti hai jahan ALU hota hai

False. Yeh ID stage mein rehti hai, kyunki ID woh jagah hai jahan instruction ke source registers (Rs, Rt) decode hote hain. ID mein dependency detect karna hume EX se pehle stall karne deta hai kabhi bhi stale value consume karne se.

Hazard detection unit combinational honi chahiye, clocked nahi

True. Stall/flush ka faisla usi cycle mein ready hona chahiye jab offending instruction ID mein ho — clock edge se pehle jo galat values latch kare. Ek clocked (sequential) unit ek cycle late decide karti.

Ek bubble ka load-use stall hamesha dependent instruction ke liye sahi data lane ke liye kaafi hota hai

True (classic 5-stage MIPS with forwarding ke liye). Ek bubble load ko MEM/WB mein push karta hai, aur wahan se forwarding unit loaded value ko dependent instruction ke EX mein bypass kar sakta hai. Forwarding ke bina aapko zyaada stalling ki zaroorat hogi.

Ek instruction ko flush karna aur stall karna ek hi operation hai

False. Stall ek instruction ko ek jagah hold karta hai aur agle cycle mein retry karta hai (woh abhi bhi correct path par hai). Flush ek instruction ko discard karta hai kyunki woh wrong path par thi (jaise taken branch ke baad) — woh kabhi useful nahi ho sakti, toh hum use permanently khatam karte hain.

MIPS mein register 0 par likhna ek false load-use hazard create kar sakta hai

True — aur isliye real detection logic Rd != 0 check add karta hai. Register 0 zero par hardwired hai; us par ek "dependency" meaningless hai, toh ise hazard treat karna pointless bubbles insert karta.

Simple 5-stage in-order pipeline mein WAR aur WAW hazards common hain

False. Ek in-order pipeline mein instructions program order mein read aur write karti hain, toh WAR (write-after-read) aur WAW (write-after-write) nahi aa sakti. Yeh sirf out-of-order execution mein matter karte hain, jo reads aur writes ko reorder karta hai.

Structural hazards usi load-use comparison logic se detect kiye ja sakte hain

False. Structural hazards resource conflict se aate hain (jaise ek memory port ek hi cycle mein IF aur MEM dono serve kar rahi ho), na ki register-number match se. Inhe resources duplicate karke avoid kiya jaata hai (alag I- aur D-memory), ek alag mechanism.

Branches ko EX ki jagah ID stage mein resolve karna un instructions ki sankhya kam karta hai jinhe hume flush karna padta hai

True. Agar branch outcome ID mein pata chal jaaye, sirf us ek instruction ko jo iske peeche fetch hui (IF/ID mein) galat hai. Baad mein EX mein resolve karne ka matlab hai do ya teen galat instructions already pipe mein aa gayi hain aur sab flush karni padti hain.

Error dhundho

Claim: "Hum load ka result seedha ID/EX register se agli instruction ke ALU mein forward karte hain, toh kabhi koi stall ki zaroorat nahi." — kya galat hai?

Load ne EX mein rahte hue memory nahi padhi hoti; uska result sirf MEM ke end mein exist karta hai. ID/EX mein forward karne ke liye kuch hota hi nahi. Yeh timing gap hi poori wajah hai ki load-use stall exist karta hai.

Claim: "Stall par hum PCWrite = 1 set karte hain taaki PC chalta rahe." — kya galat hai?

Stall ke liye PCWrite = 0 chahiye (upar definitions se freeze setting). Agar stall ke dauran PC aage badha toh hum agla instruction fetch karke phir kho dete. PC aur IF/ID ko freeze karna hi pipeline ke front ko wait karata hai.

Claim: "Bubble insert karne ke liye hum ID/EX control signals ko freeze karte hain taaki woh apni purani value hold karein." — kya galat hai?

Bubble ID/EX control signals ko zero karke banaya jaata hai — control mux ko us ke all-zero input par switch karke — us slot ko NOP mein badal ke. Purani control values hold karna ek real operation ko slip through karne deta aur state corrupt kar deta.

Claim: "Load-use stall ke dauran hum load instruction ko ID mein hold karte hain." — kya galat hai?

Hum dependent instruction (consumer) ko ID mein hold karte hain; load khud normally EX/MEM mein aage badhta hai taaki uska data available ho sake. Load ko hold karna purpose ko defeat karta — use value produce karne ke liye aage badhna chahiye.

Claim: "Taken branch ke baad flush karne ke liye sirf Stall = 1 set karna kaafi hai." — kya galat hai?

Stalling wrong-path instruction ko rakh leti aur use re-run karti — lekin woh ek aisi path par hai jise hum chhodh rahe hain. Hume Flush chahiye: IF/ID ko NOP mein convert karo taaki galat instruction discard ho jaaye, phir branch target fetch karo.

Claim: "Detection condition sirf Rs check karta hai, kyunki woh pehla operand hai." — kya galat hai?

Condition MemRead ko dono Rs aur Rt ke OR ke saath AND karta hai, kyunki dependent instruction load ka destination kisi bhi source operand se padh sakti hai. Rt miss karna ek real hazard ko second-operand dependencies par slip past karne deta.

Claim: "Kyunki forwarding EX/MEM aur MEM/WB hazards handle karta hai, hazard unit unhe bhi check kar sakta hai aur load case skip kar sakta hai." — kya galat hai?

Ulta hai. Forwarding pehle se hi EX/MEM aur MEM/WB cases resolve karta hai, toh hazard unit ko un ke liye stall karne ki zaroorat nahi. Woh ek case jo forwarding fix nahi kar sakta — load result abhi produce nahi hua — exactly woh case hai jo hazard unit ko pakadna hi chahiye.

Why questions

Hazard detection unit specifically ID/EX.MemRead kyun dekhta hai opcode ki jagah?

MemRead = 1 woh clean, decoded flag hai jo load identify karta hai — woh akela instruction jiska result EX ke end tak ready nahi hota. Ek control bit dekhna hazard unit ke andar opcode re-decode karne se sasta aur tez hai.

Stall ka faisla ek single clock cycle ke andar kyun khatam hona chahiye?

Kyunki agle rising edge par, pipeline registers naye values latch kar lete hain. Agar Stall signal time par assert nahi hua, stale operand EX mein chala jaata hai aur galat result commit ho jaata hai — simple pipeline mein unrecoverable.

Jab bhi possible ho forwarding ko stalling se kyun prefer kiya jaata hai?

Forwarding zero extra cycles khaata hai — woh sirf ek existing value ko mux ke through reroute karta hai. Stalling throughput ka ek poora cycle (ek bubble) waste karta hai. Toh hum tab stall karte hain sirf jab needed data physically exist hi nahi karta.

Branch resolution pehle (ID mein) move karne ke liye extra hardware kyun chahiye, aur kya yeh worth it hai?

Tum ID mein ek comparator aur ek target-address adder add karte ho. Yeh usually worth it hota hai: branch penalty ~3 flushed instructions se gir kar 1 ho jaati hai, loops mein har taken branch par cycles bachate hue, jo aksar hoti hain.

Hazard detection unit akela saari pipeline stalls kyun eliminate nahi kar sakta?

Woh sirf detect aur react kar sakta hai; woh aisa data invent nahi kar sakta jo exist nahi karta. Load-use dependency ke liye value simply abhi available nahi hoti, toh kuch delay unavoidable hai — unit sirf ise ek bubble tak minimize karta hai kai ki jagah.

Control-signal path ko ek aisi mux kyun chahiye jo saare signals ko zero force kar sake?

Kyunki woh zeroing mux bubble insert karne ka physical mechanism hai. All-zero input select karna ID/EX slot ko NOP mein badal deta hai taaki ek stalled ya flushed instruction registers ya memory alter na kar sake.

Branch prediction (5.2.11-Branch-prediction) control-hazard flush logic ka complement kyun hai, na ki replacement?

Prediction path guess karti hai taaki hum speculatively fetch kar sakein, lekin har galat guess ko abhi bhi wrong-path instructions discard karne ke liye Flush machinery chahiye. Prediction yeh reduce karta hai ki hum kitni baar flush karte hain; yeh flush karne ki zaroorat nahi hatata.

Edge cases

Agar load ka destination register dependent instruction ke Rs aur Rt dono ke barabar hai (dono operands), toh kitne bubbles insert hote hain?

Abhi bhi exactly ek. Condition ek single OR hai — yeh ek baar fire karta hai chahe ek ya dono operands match karein — aur ek bubble kaafi hai load ko ek forwardable stage tak pahunchaane ke liye (cycle 5 tak MEM/WB, jaise timing table ne dikhaya).

Kya hoga agar load ke baad wali instruction load ke Rd se alag register padhti hai?

Koi hazard nahi — Rd == Rs / Rd == Rt comparison fail hota hai, toh Stall = 0 aur pipeline full speed par chalti hai. Paas mein load ka hona hi harmful nahi hai bina matching register ke.

Ek load ke baad ek store aata hai jo loaded value ko apni data-to-store ke roop mein use karta hai — kya yeh abhi bhi load-use hazard hai?

Haan, agar store Rt (store-data register) se load ka Rd padhta hai. Consumer ka store hona timing nahi badalta: value abhi bhi ready nahi hoti, toh stall bilkul usi tarah required hai.

Agar ek taken branch ke baad turant wrong path par ek aur branch aata hai toh kya?

Wrong-path branch kisi bhi aur wrong-path instruction ki tarah flush hoti hai PC ko affect karne se pehle. Sirf correct target fetch karne ke baad hi hum agla real branch evaluate karna shuru karte hain.

Ek branch ID mein resolve hoti hai aur not taken nikali — hazard unit kya karta hai?

Kuch khaas nahi. Sequentially-fetched agla instruction (PC+4) already sahi tha, toh Flush = Branch AND BranchTaken false evaluate karta hai aur koi bubble insert nahi hota.

Do independent loads back-to-back, jahan pehle load ke baad doosri instruction value use karti hai — kya stall chahiye?

Nahi. Jab consumer ID pahunchta hai, pehla load already MEM/WB mein hota hai, toh forwarding value supply kar sakta hai. Load-use stall sirf tab trigger hota hai jab consumer seedha load ke peeche ho (ek cycle apart).

Agar ID/EX.MemRead = 1 hai lekin loaded value baad ki kisi bhi instruction se kabhi use nahi hoti, kya unit stall karta hai?

Nahi. Rs ya Rt par koi register match nahi hone se, detection condition false hai. Bina dependent consumer wala load zero penalty ke saath flow karta hai — unit dependencies par react karta hai, loads par nahi.

Recall Ek-line summary lock karne ke liye

Hazard detection unit sirf load-use case ke liye stall karta hai (value abhi produce nahi hui), sirf wrong-path branch instructions ke liye flush karta hai, aur chup rehta hai jab bhi forwarding unit pehle se data reroute kar sakta ho.