Structural hazards: Question bank — Hinglish deep dive

5.2.5 · D5 · Hardware › Processor Datapath & Pipelining › Structural hazards

Andar jaane se pehle, ek anchor jo baar baar kaam aayega. Ek structural hazard = do pipeline stages ek hi physical hardware ko same clock cycle mein chahte hain. Data ka order nahi (Data Hazards), branch decision nahi (Control Hazards) — sirf resource contention.

Definition Local legend — 5-stage pipeline

Ek classic instruction paanch stages se guzarta hai, har ek clock cycle mein ek stage. Paanch workers ko ek assembly line par imagine karo, jo ek chalti hui car par ek-ek kaam kar rahe hain:

IF (Instruction Fetch) — memory se instruction padhna.
ID (Instruction Decode) — samajhna ki instruction kya maang raha hai, source registers padhna.
EX (Execute) — ALU arithmetic/logic karta hai.
MEM (Memory access) — data memory padhna ya likhna (sirf loads/stores ise zyada use karte hain).
WB (Write Back) — result ko ek register mein store karna.

Poora idea (dekho Pipelining Fundamentals) ye hai ki jab ek instruction EX mein hai, agla ID mein hai, uske baad wala IF mein, aur aise hi — paanch instructions overlap karte hain. Is overlap ke liye figure s01 dekho, aur notice karo ki un stages mein se do ek hi column mein memory ke liye haath kaisa badhaate hain.

Definition CPI formula mein teen symbols

Performance math padhne ke liye teen seedhi quantities chahiye. Inhe figure s02 se anchor karo, jo pipeline timeline ko ek inserted bubble ke saath draw karta hai.

CPI = Cycles Per Instruction — average mein, har ek complete instruction ko kitne clock cycles lage. Ideal = $1.0$ (har cycle mein ek instruction complete hoti hai).
$p$ = hazard hone ki probability per instruction — $0$ aur $1$ ke beech ka fraction. Agar chaar mein se ek instruction collide kare, toh $p = 0.25$ .
$s$ = stall penalty, yaani har collision par kitne extra clock cycles (bubbles) force hote hain. Single-port memory clash par $s = 1$ lagta hai; slow multi-cycle unit par zyada bhi ho sakta hai.
$f_{mem}$ = instructions ka fraction jo loads ya stores hain. Ye memory-port hazard ke specific case mein sirf $p$ hi hai, kyunki sirf load/store instructions MEM stage tak pahunchte hain aur IF ke saath port ke liye ladte hain.

Formula

$CPI_{actual} = 1 + p \times s$ kyun hai Step 1 — baseline. Bina hazards ke, har cycle mein ek instruction complete hoti hai, isliye pehla term $1$ hai. Step 2 — wasted cycles count karo. Har instruction mein se, hazard $p$ probability se aata hai. Jab aata hai, pipeline younger instruction ko freeze karti hai aur $s$ bubbles insert karti hai — $s$ cycles mein koi useful kaam nahi hota. Step 3 — saari instructions par average lo. Har instruction par expected extra cycles hai (hone ki chance) $\times$ (hone par cost) $= p \times s$ . Ye sirf ek weighted average hai: jo instructions collide nahi karti woh $0$ add karti hain, jo karti hain woh $s$ add karti hain. Step 4 — jodo. Har instruction ki total cost = baseline + average stall = $1 + p \times s$ . Yahi poora formula hai: $CPI_{actual} = 1 + p \times s$ Memory hazard ke liye, $p = f_{mem}$ aur $s = 1$ substitute karo aur milega $CPI_{actual} = 1 + f_{mem}$ .

True ya false — justify karo

Structural hazard tab bhi ho sakta hai jab sabhi instructions ek dusre se bilkul independent hon

True. Structural hazards hardware ke baare mein hain, data ke nahi. Paanch independent instructions phir bhi ek single memory port par collide kar sakti hain kyunki wo alag-alag stages mein ek saath rehti hain.

Agar pipeline mein structural hazard hai, toh data hazard bhi hona chahiye

False. Ye dono orthogonal hain. Memory-port conflict is baat se independent hai ki instructions koi register values share karti hain ya nahi.

Zyada pipeline stages add karne se structural hazard ka chance hamesha badhta hai

False, "hamesha" nahi. Zyada stages matlab zyada instructions in-flight, toh collision ke zyada mauke — lekin actual hazard is baat par depend karta hai ki kitni stages ek given resource share karti hain. Well-separated resources wali deep pipelines hazard-free ho sakti hain.

Harvard architecture single-memory-port structural hazard ko poori tarah khatam kar deta hai

Uss specific hazard ke liye True. Alag instruction aur data memories matlab IF (Instruction Fetch) aur MEM (Memory access) kabhi ek port par nahi ladte. Doosre structural hazards (single ALU, ek write port) phir bhi reh sakte hain — dekho Memory Hierarchy.

Structural hazard CPI ko 1.0 se upar le jaata hai

True jab bhi woh actually stall karta hai. Har inserted bubble ek aisa cycle hai jisme koi instruction complete nahi hoti, toh

CPI_{actual} = 1 + p \times s > 1

(jahan

p

hazard probability hai aur

s

stall penalty).

Compiler instruction reordering hamesha structural hazard ko hata sakta hai

False. Reordering tabhi help karta hai jab independent instructions ho jo move ki ja sakein. Agar do forced-adjacent instructions ko scarce resource chahiye, toh koi schedule isse avoid nahi kar sakta — hardware duplication hi ek fix hai.

Superscalar processor scalar se structural hazards ke liye zyada prone hota hai

Principle mein True. Har cycle mein kaafi instructions issue karna ek saath zyada read/write ports aur functional units maangta hai, toh Superscalar Processors ko structural hazards door rakhne ke liye hardware add karna padta hai.

Structural hazards sirf compile time par detect kiye ja sakte hain

Aaam tor par False. Do stages actually collide karti hain ya nahi ye runtime timing par depend karta hai (cache misses, variable-latency units), isliye hardware interlock logic detect karne aur stall karne ke liye usually zaroori hota hai.

Structural hazard ke liye insert ki gayi stall (bubble) pipeline ke useful kaam ko aage badhati hai

False. Ek bubble ek deliberate NOP hai — ye baad ki stages ko idle rakhta hai taaki resource free ho jaye. Ye by design ek cycle waste karta hai.

Agar processor mein zero structural hazards hain, toh uska CPI guaranteed 1.0 hoga

False. Data aur control hazards phir bhi stalls add kar sakte hain. Zero structural hazards sirf CPI inflation ka ek source hata deta hai.

Error dhundho

"Hamare paas do structural hazards hain kyunki instruction I2, I1 ke result par depend karti hai."

Error ye hai ki ek dependency ko structural hazard keh diya. Pichle result ka wait karna data hazard hai. Structural = shared hardware, shared data nahi.

"Hamari pipeline stall karti hai jab bhi do instructions ALU ko alag cycles mein use karti hain, toh ye structural hazard hai."

Alag cycles mein same unit use karna exactly wohi hai jo pipeline ko karna chahiye — koi conflict nahi. Hazard ke liye same cycle chahiye. Yahan koi hazard nahi hai.

"Register file mein ek second write port add karne se hamara load-use data hazard theek ho jaayega."

Galat hazard. Extra write ports ek structural write-back collision theek karte hain. Load-use stall ek data hazard hai aur use forwarding ya stall chahiye, zyada ports nahi.

"Kyunki hamare paas alag I-cache aur D-cache hain, pipeline kabhi stall nahi hogi."

Alag caches ek structural hazard (IF vs MEM memory port) khatam karte hain. Cache misses, data hazards, aur control hazards phir bhi pipeline stall kar sakte hain.

"Structural hazard hamesha exactly ek cycle ki cost karta hai."

Penalty

s

resource par depend karta hai. Single-cycle resource ek bubble costa hai (

s = 1

), lekin multi-cycle unit (jaise non-pipelined divider) kaafi stall cycles force kar sakti hai (

s > 1

"PC+4 compute karne ke liye ALU use karna theek hai kyunki branches rare hain."

PC+4 sirf branches par nahi, har instruction fetch par hota hai. Main ALU ko iske liye share karna EX (Execute) stage se constantly clash karta hai — isliye ek sasta dedicated PC incrementer add kiya jaata hai.

"Structural hazards door ho jaayenge agar hum clock ko bas slow kar dein."

Slow clock cycle ka time badalta hai, ye nahi ki do stages ek hi cycle mein ek resource chahte hain. Conflict — aur stall count — wahi rahta hai.

Why questions

Designers structural hazard ko tolerate kyun karte hain instead of hardware duplicate karne ke?

Kyunki duplication silicon area, power, aur design complexity cost karta hai. Embedded/low-power chips mein ek occasional stall second memory port ya extra ALU se sasta hota hai.

Single unified memory hazard kyun deta hai lekin split I/D caches nahi?

Unified memory mein ek access port hota hai; IF (fetch) aur MEM (data access) dono same cycle mein use chahte hain. Split caches har stage ko uska apna port dete hain, toh fight karne ke liye koi shared resource nahi hota.

Structural hazard fundamentally "hardware count" problem kyun hai na ki "program logic" problem?

Ye iss liye aata hai ki stages ki sankhya se kam instances ek resource ke hote hain jo simultaneously chahiye hain. Instructions bilkul logically unrelated ho sakti hain — kami physical hai.

Do register reads aur ek register write usually bina hazard ke same cycle mein kyun ho sakte hain?

Kyunki standard register file 2 read ports aur 1 write port ke saath banaya jaata hai. Hardware exactly wohi combination provide karta hai, toh ye provisioned hai, contested nahi.

Load/store instructions ka fraction badhane se single-port memory design mein stall rate kyun badhti hai?

CPI model mein stalls

= f_{mem} \times s

hai, jahan

f_{mem}

load/store instructions ka fraction hai. Zyada memory instructions matlab zyada

f_{mem}

, toh zyada cycles jahan MEM, IF ke saath ek port ke liye clash karta hai.

"Instructions ko alag schedule karo" ek limited solution kyun hai?

Ye tabhi kaam karta hai jab independent instructions ho jinhe conflict ke around reorder kiya ja sake. Data dependencies aur back-to-back resource demands aise koi legal reordering nahi chhodti jo clash avoid kare — ye limitation Instruction-Level Parallelism se judi hai.

Hum bubble baad wali stage par kyun insert karte hain na ki pehli wali par?

Pehli (younger) instruction wahi hai jo safely wait kar sakti hai; older instruction ko apna resource rakhne dena correct program order preserve karta hai aur pipeline ko aage drain karta hai.

Edge cases

Non-pipelined single-cycle processor mein structural hazard situation kya hai?

Koi nahi. Ek time mein ek instruction execute hone ke saath, koi do stages overlap nahi karti, toh kuch bhi ek resource ke liye contend nahi kar sakta. Structural hazards ek pipelining phenomenon hain — dekho Pipelining Fundamentals.

Agar ek pipeline sirf 2 stages deep hai, toh kya usmein phir bhi memory structural hazard ho sakta hai?

Haan, agar dono stages ek hi single-port memory ko ek cycle mein touch karein (jaise fetch + data access). Depth itni badi honi zaroori nahi — do overlapping stages jo ek resource share karein kafi hain.

Zero-load-store program: kya single-port unified memory phir bhi koi structural hazard cause karta hai?

Nahi — instruction fetch akela har cycle mein memory hit karta hai, lekin MEM-stage data accesses ka koi doosra claimant nahi hota, toh practically koi collision nahi hota. Hazard ke liye do simultaneous claims chahiye.

Limiting case mein CPI kya hoga jahan har instruction ek-cycle structural stall trigger karti hai?

CPI = 1 + p \cdot s

mein

p = 1, s = 1

CPI = 2.0

milta hai — pipeline effectively apna throughput halve kar leti hai, har do cycles mein ek useful instruction karti hai.

Kya alag resources par do structural hazards same instruction ko same cycle mein stall kar sakte hain?

Instruction tab tak stall karti hai jab tak dono resources free nahi ho jaate, lekin ek single bubble ek single cycle cover karta hai; total stall maximum wait hai, sum nahi, agar resources overlapping cycles mein free ho jaayein.

Degenerate case: infinite hardware (har stage ke liye ek port/unit) — structural-hazard CPI contribution kya hai?

Zero. Jab har stage ke paas apna dedicated resource ho, koi do stages kabhi contend nahi karti, toh structural stalls khatam ho jaate hain aur

CPI_{actual}

ka ye term bilkul nikalh jaata hai.

Recall Ek-line self-test

Ek dost kehta hai "humein stall mila, toh ye definitely structural hazard hai." Missing step kya hai? ::: Identify karo kyun: shared hardware = structural, ek value ka wait = data, branch ka wait = control. Akela stall apna cause nahi bataata.