Classic 5-stage pipeline (IF - ID - EX - MEM - WB): Question bank

5.2.3 · D5 · Hardware › Processor Datapath & Pipelining › Classic 5-stage pipeline (IF - ID - EX - MEM - WB)

Shuru karne se pehle, ek word jo hum baar baar use karte hain: ek stage assembly line ka ek segment hota hai (IF, ID, EX, MEM, WB), aur ek pipeline register flip-flops ka ek chhota bank hota hai jo ek instruction ke aadhe-adhoore results ko do stages ke beech freeze kar deta hai taaki paas wali instruction ka data andar na aa jaye.

True or false — justify karo

TF — "Pipelining har ek individual instruction ko kam time mein complete karta hai."

False. Ek akela instruction phir bhi paanch saare stages se guzarta hai, aur ab har boundary par latch overhead bhi pay karna padta hai, isliye uski latency thodi badh jaati hai; jo cheez improve hoti hai woh hai throughput (instructions finished per second).

TF — "Ek 5-stage pipeline mein sirf ek akela instruction run karna single-cycle datapath se faster hota hai."

False. Koi follow-on instruction nahi hai toh overlap karne ke liye kuch nahi hai, isliye ek instruction khatam karne ke liye 5 clock periods plus 4 latch delays pay karne padte hain — ek combinational sweep se slower. Pipelining sirf ek stream par faayda deta hai.

TF — "Agar paanch saare stages ki delay equal ho, toh ideal speedup exactly 5 hai."

Almost — yeh

N \to \infty

ke saath 5 ke paas jaata hai, lekin finite

N

ke liye strictly kam hota hai fill cost ki wajah se, aur aur bhi kam jab latch overhead

d

har cycle charge hota hai.

TF — "Clock period average stage delay se set hoti hai."

False. Har stage ko ek shared clock period milta hai, isliye clock slowest stage ke andar fit hona chahiye:

T_{c l k} = max_{i} (t_{i}) + d

. Average irrelevant hai; ek slow stage poori line ko pace karta hai.

TF — "Zyada pipeline stages add karne se speedup hamesha badhta hai."

False. Har nayi boundary latch overhead

d

add karti hai; jaise stages chhote hote hain,

d

T_{c l k}

ka ek bada fraction ban jaata hai, aur hazards badh jaate hain, isliye speedup saturate ho jaata hai aur gir bhi sakta hai. Dekho Clocking & Latch Overhead.

TF — "Register operands EX stage mein read hote hain kyunki wahan use hote hain."

False. Operands ID mein read hote hain aur results WB mein written hote hain. EX sirf woh values consume karta hai jo ID/EX mein latch ho chuki hain; Register File sirf ID (read) aur WB (write) mein touch hoti hai.

TF — "Ek add instruction ek cycle bachane ke liye MEM stage skip kar deta hai."

False. Woh phir bhi MEM se guzarta hai kuch kiye bina — har instruction ka same 5-stage shape rehta hai taaki control uniform rahe aur har cycle ek instruction finish ho sake. Skip karna lock-step tod deta.

TF — "Pipeline registers sirf data jaise operands aur ALU results carry karte hain."

False. Woh control signals (RegWrite, MemRead, MemWrite, ...) bhi aage carry karte hain, kyunki ID mein liya gaya decision MEM/WB mein kaafi cycles baad arrive karna chahiye usi instruction ke saath.

TF — "Steady state mein paanch saare stages hamesha useful work kar rahe hote hain."

False. Hazard-free mein bhi, arithmetic ops ke liye MEM ya stores ke liye WB jaise stages us instruction ke liye idle rehte hain; aur fill/drain ke dauran kuch stages mein kuch nahi hota. "Full" ka matlab hai ek instruction per stage, har stage real work nahi kar raha.

Error dhundo

Flaw dhundo: "Kyunki pipeline har cycle ek instruction finish karti hai, N instructions exactly N cycles leti hain."

Yeh fill cost ignore karta hai. Pehla result sirf cycle

k

par aata hai, isliye total cycles

k + (N - 1)

hain,

N

nahi. One-per-cycle rate tab shuru hoti hai jab pipe full ho jaati hai.

Flaw dhundo: "Hum IF/ID register drop kar sakte hain kyunki IF aur ID same cycle mein run karte hain."

Woh same cycle mein alag-alag instructions par run karte hain. Latch ke bina, jo instruction fetch ho rahi hai woh jo decode ho rahi hai use corrupt kar deti — register exactly wahi hai jo neighbours ko alag rakhta hai.

Flaw dhundo: "Is cycle WB mein register mein write ki gayi value possibly next cycle tak read nahi ho sakti."

Classic fix yeh hai ki Register File mein cycle ke pehle half mein write karo aur doosre half mein read karo, isliye is-cycle-WB ki value is-cycle-ID instruction ke liye readable hai. Us trick ke bina ek extra stall chahiye hoga.

Flaw dhundo: "Pipeline ko faster banane ke liye, slowest stage ki delay se neeche clock period ko bas lower kar do."

Tab slowest stage ki combinational logic latch ke sample lene se pehle settle nahi ho paayegi, garbage capture hoga. Clock

max_{i} (t_{i}) + d

se neeche nahi ja sakta; slowest stage ko shorten karna padega, sirf clock nahi.

Flaw dhundo: "Kyunki sw (store) koi result compute nahi karta, woh WB skip kar sakta hai aur us slot ko doosri instruction ke liye free kar sakta hai."

Store mein sach mein koi WB write nahi hota, lekin uska slot kisi doosri instruction ko nahi diya ja sakta — lock-step advance ka matlab hai har cycle har stage mein exactly ek instruction hoti hai. Store simply WB idle karta hai; koi queue jump nahi karta.

Flaw dhundo: "Total combinational work 750 ps hai, isliye pipelining 5× speedup deta hai ek instruction per 150 ps par."

Pipeline period slowest stage plus

d

se set hoti hai, total work ko 5 se divide karne se nahi. Unbalanced stages fast stages mein slack waste karte hain, isliye throughput one per

max_{i} (t_{i}) + d

hai, jo 5× se kam deta hai.

Why questions

Hum har do stages ke pair ke beech ek pipeline register kyun rakhte hain, sirf ek central buffer nahi?

Kyunki paanch alag-alag instructions paanch stages par simultaneously occupy karte hain, aur har stage ko apni instruction ke partial results chahiye. Har boundary ko independently apna state ka slice freeze aur forward karna chahiye.

Speedup

k

(stages ki sankhya) par kyun cap hoti hai aur kabhi exceed nahi karta?

Tum at best ek saath

k

instructions overlap kar sakte ho, isliye throughput zyada se zyada

k

factor se improve hota hai. Fill cost

(k - 1)

iss ideal ko sirf reduce karta hai, kabhi beat nahi karta.

ID mein decide kiye gaye control signals pipeline registers mein neeche kyun travel karne chahiye?

Kyunki jinhe woh control karte hain (memory access, register write) woh actions cycles baad MEM aur WB mein hote hain, lekin decision sirf ek baar ID mein opcode decode hone par liya ja sakta hai — isliye signal apni instruction ke saath saath chalta hai.

Ek unbalanced pipeline (unequal delay wale stages) wasteful kyun hai?

Clock slowest stage tak stretch hoti hai, isliye har fast stage har cycle mein baaki slack ke liye idle baithta hai. Stage delays ko balance karna hi hai jo

T_{c l k}

ko ideal ke paas shrink karne deta hai.

Per-instruction latency pipelining ke under kyun worse hoti hai jabki throughput improve hoti hai?

Har

k

boundary latch delay

d

add karti hai, isliye ek instruction ki trip

k (max_{i} t_{i} + d)

hoti hai total kaam ke ek combinational sweep ke bajaye. Dekho Single-cycle vs Multicycle Datapath.

Arithmetic instructions ke liye idle MEM/WB slots kyun rakhe jaate hain ek chhote custom path ki jagah?

Uniform 5-stage shape control logic ko simple rakhta hai aur one-finish-per-cycle rhythm preserve karta hai; variable-length paths collide karte aur complex arbitration ki zaroorat padti.

Edge cases

Edge case — jab

N = 1

(ek akela instruction) tab speedup kya hoga?

\frac{N k}{k + N - 1} = \frac{k}{k} = 1

: bilkul speedup nahi, aur real hardware mein single-cycle se thoda worse kyunki latch overhead extra hai. Overlap ke liye stream chahiye.

Edge case — pehle

k - 1

cycles mein pipeline kya karti hai?

Woh filling kar rahi hoti hai: sirf shuruat ke stages mein real instructions hoti hain aur koi result abhi tak nahi aaya. Pehla completion cycle

k

par hota hai, isliye total cycles

k + (N - 1)

hote hain.

Edge case — last instruction fetch hone ke baad aakhiri

k - 1

cycles mein kya hota hai?

Pipe drains hoti hai: baad ke stages stream ki tail process karte rehte hain jabki front stages khaali baithte hain. Yeh drain cycles fill cost ke mirror image hain.

Edge case — agar latch overhead

d

badhkar

T_{c l k}

ko dominate karne lage, toh speedup kya limit karta hai?

Speedup 1 ki taraf collapse hota hai, kyunki almost poora clock period computing ki jagah latching mein spend hota hai. Isliye tum arbitrarily zyada tiny stages mein split nahi kar sakte — dekho Clocking & Latch Overhead.

Edge case — ek nop (no-operation) instruction: kya woh phir bhi paanch saare stages consume karta hai?

Haan. Woh IF/ID/EX/MEM/WB se kisi bhi instruction ki tarah flow karta hai, simply koi writes assert nahi karta. Exactly aise hi ek stall/bubble inject kiya jaata hai — ek disguised nop ek slot occupy karta hai. Dekho Pipeline Hazards (structural, data, control).

Edge case — sirf ek stage (

k = 1

) ke saath kya "pipelining" ka koi matlab hai?

Nahi.

\frac{N k}{k + N - 1} = \frac{N}{N} = 1

sabhi

N

ke liye: ek single stage bas single-cycle datapath hai, overlap karne ke liye kuch nahi aur koi inter-stage register add karne ke liye nahi.

Edge case — ek instruction jo na memory read karti hai na register write karti hai (jaise ek plain store to nowhere / ek nop store): kaunse stages real work karte hain?

Sirf IF, ID, aur EX kuch meaningful karte hain; MEM aur WB idle rehte hain. Phir bhi instruction un do stages par occupy rehti hai lock-step timing preserve karne ke liye.

Recall Ek-line survival summary

Reads ID mein, writes WB mein; clock = ==slowest stage + $d$ ; N instructions $k + (N - 1)$ cycles leti hain; pipelining throughput boost karta hai, single-instruction latency nahi; speedup $k$ == par cap hota hai. Agar ye paanch yaad rahe toh koi trap nahi pakad sakta.