Visual walkthrough — Microcontroller architecture — ARM Cortex-M series (M0, M3, M4, M7)
5.5.1 · D2· Coding › Embedded Systems & Real-Time Software › Microcontroller architecture — ARM Cortex-M series (M0, M3,
Hum bilkul neeche se shuru karte hain: CPU ka "instruction run karna" ka matlab kya hai?
Step 1 — Ek instruction asal mein teen chhote kaam hai
KYA. Processor jo bhi instruction run karta hai, woh secretly teen alag tasks hote hain jo order mein hote hain:
- Fetch — memory mein jao, instruction ke bits uthao.
- Decode — figure out karo ki woh bits ka matlab kya hai (add? load? jump?).
- Execute — actually karo (numbers add karo, data move karo).
WHY alag karo? Kyunki har kaam chip ke andar alag hardware use karta hai. Fetch memory bus use karta hai; decode ek lookup circuit use karta hai; execute math unit use karta hai (the ALU, Arithmetic Logic Unit — woh part jo add/subtract karta hai). Agar tum inhe alag rakho, tum baad mein inhe ek saath run kar sakte ho — yahi pipeline ki poori trick hai. Lekin pehle, slow way se karo.
PICTURE. Ek instruction teen stations se guzarta hai, ek ke baad ek. Abhi kuch overlap nahi hai.

Ek-ek karke karo, ek instruction = 3 cycles (har station par ek tick). Dus instructions hote toh cycles. Wasteful — jab Decode kaam karta hai, Fetch hardware idle baitha rehta hai. Chalo isko fix karte hain.
Step 2 — Assembly line: teen kaaon ko overlap karo
KYA. Instruction #1 ke teeno stations complete karne ka wait karne ki jagah, jaise hi #1 Decode mein move karta hai, hum instruction #2 ko Fetch mein daaldo. Ab teeno stations ek saath alag-alag instructions par busy hain.
WHY. Exactly yahi ek car factory mein hota hai: jab car A ko wheels lag rahe hain, car B pehle se doors le rahi hai. Line full hone ke baad koi bhi station kabhi idle nahi hota. Hum stations ki sankhya ko pipeline depth kehte hain, jo se likhi jaati hai. Yahan hai (Fetch, Decode, Execute) — yeh M0/M3 pipeline hai.
PICTURE. Diagram ko calendar ki tarah padho. Har column ek clock cycle hai; har row ek instruction hai. Kaam ka diagonal band neeche aur daayein slide karte hue dekho.

Picture mein do cheezein notice karo:
- Cycles 1–2: pipeline fill ho rahi hai — abhi har station busy nahi hai. Yeh startup cost hai.
- Cycle 3 se aage: ek instruction har single cycle mein finish hota hai (Execute se bahar nikalta hai).
Step 3 — Cycles count karo → derive karo
KYA. Hum ab ek -stage pipeline mein instructions run karne ke liye total cycles count karte hain, seedha Step 2 ki picture se padh ke.
WHY. Yeh parent note ka headline formula hai. Hum ise earn karna chahte hain, yaad nahi karna.
PICTURE. Same grid — maine count ke do pieces highlight kiye hain.

Figure mein logic follow karo:
- Pehla instruction kuch finish hone se pehle saare stations se guzarna chahiye → iska cost cycles hai. (Red band.)
- Uske baad, baaki remaining instructions mein se har ek pehle wale ke ek cycle baad pop out hota hai → iska cost aur cycles hai. (Mint band.)
Inhe add karo:
- — pipeline depth (stations ki sankhya), fill cost ke roop mein ek baar pay kiya.
- — kitne instructions run karte ho.
- isliye aata hai kyunki pehla instruction dono fill () aur " mein se ek" mein count hota hai, toh hum double-count subtract karte hain.
Sanity check (parent ka Example 1). M3 mein hai. Ek 10-instruction loop body, ek baar run karo: cycles. baar run karo, pipe passes ke beech kabhi drain nahi hoti, toh total instructions hain: cycles — nahi . Tum 2-cycle fill sirf ek baar pay karte ho. ✓
Step 4 — Deeper pipeline: same formula, bada fill cost
KYA. M7 mein stations hain. Ise plug in karo aur fill cost ko shallow M0+ ke against compare karo.
WHY. Log assume karte hain "6 stages > 2 stages, toh M7 3× faster hai." Formula kehta hai depth sirf fill cost ko change karta hai, jo ek fixed penalty hai, multiplier nahi. Dekho yeh kitna bada hai.
PICTURE. Do pipelines side by side, same 8 instructions. Count karo ki kitne cycles har ek ko fill karne mein "waste" ho rahe hain.

- M0+ (): fill cost cycle.
- M7 (): fill cost cycles.
Ek lambi stream ke liye yeh mushkil se matter karta hai ( wash out ho jaata hai). Lekin dekho kya hota hai short, branchy code ke saath aage — yahan depth hurts karta hai.
Step 5 — Chhupa hua cost: ek branch pipe ko flush karta hai
KYA. Ek branch ek instruction hai jo kehta hai "kahin aur jump karo" (ek if, ek loop-back). Takleef yeh hai: CPU ne branch ke peeche pehle se agle kuch instructions already fetch kar liye hain, guess karte hue ki tum seedha fall through karoge. Agar branch instead jump karta hai, toh woh guessed instructions wrong hain aur unhe throw away karna padega — pipe flush ho jaati hai aur refill karni padti hai.
WHY yeh deep pipelines ke liye zyada matter karta hai. Flush branch ke peeche currently in-flight instructions ko waste karta hai — aur deep pipe mein yeh zyada hote hain. Penalty roughly Fetch ke baad stages ki sankhya ke barabar hoti hai, yaani yeh ke saath badhti hai.
PICTURE. Ek branch marked cycle par; sab kuch red jo fetch-then-discarded ho gaya. Shallow vs deep ke liye red "wasted" region ka size compare karo.

- — branch ke peeche in-flight instructions, sab waste.
- M0+ par (): ~1 cycle lose. M7 par (): ~5 cycles lose har baar jab ek branch CPU ko surprise karta hai.
Step 6 — Superscalar: doosri lane add karo → derive karo
KYA. M7 ke paas sirf deeper pipe nahi hai — yeh dual-issue (superscalar) bhi hai: yeh ek hi cycle mein do instructions fetch aur start kar sakta hai, agar woh ek doosre par depend nahi karte. Hum lanes ki sankhya ko (issue width) kehte hain; yahan hai.
WHY sirf "agar depend nahi karte." Agar instruction #2 ko instruction #1 ka result chahiye, toh woh ek saath nahi run kar sakte — #2 ko wait karna padega. Toh sirf ek fraction instruction pairs hi actually pair up karne ke liye independently enough hote hain. Woh fraction hi poori kahani hai.
PICTURE. Do lanes page ke neeche run kar rahi hain. Green pairs ek saath issue hue (independent); grey pairs ek-ek karke run karne par forced (dependent). Green rows ka fraction hai.

Instructions completed per cycle count karo:
- fraction waqt mein hum ek cycle mein instructions complete karte hain.
- Baaki waqt () mein hum sirf complete karte hain.
- — fraction of pairs jo ek saath issue hote hain ( = kabhi nahi, = hamesha).
- — kitni lanes hain (instructions issuable per cycle).
- — extra instructions jo ek lane 1 ke baseline se aage deti hai.
Step 7 — Degenerate cases (kabhi gap mat chhodna)
KYA / WHY / PICTURE. Har formula ko apne extremes survive karne chahiye. Yeh corners hain, har ek same models se padha gaya.

- (single instruction): . Ek instruction poori depth leti hai — koi overlap possible nahi. Step 1 se match karta hai. ✓
- (long stream): ; fill cost negligible hai. Yahan deep pipes shine karte hain.
- (fully dependent code, superscalar): . Doosri lane dead weight hai — tumne silicon aur power pay kiya kuch nahi ke liye. Yeh M7 ki doosri lane ka worst case hai.
- (perfectly independent): . Theoretical ceiling, real control code mein almost kabhi reach nahi hoti.
- Constant flushing (har cycle ek branch): effective — ek deep pipe shallow wali se slower ho jaati hai. Yeh "M0+ tiny branchy handlers par M7 ko beat kar sakta hai" ka mathematical form hai.
Ek-picture summary
Yeh final figure teeno effects — fill cost, branch flush, superscalar pairing — ko ek hi timeline par stack karta hai taaki tum poora trade ek nazar mein dekh sako.

Recall Feynman retelling — plain words mein wapas bolo
Har instruction asal mein teen kaam hai: uthao, samjho, karo. Inhe ek-ek karke karna hardware waste karta hai, toh hum ek assembly line banate hain — jab ek instruction "hो raha" hai, agla "samjha" ja raha hai, aur uske baad wala "utha" ya ja raha hai. Line full hone ke baad, ek instruction har tick end se roll off karta hai. Line start karne mein kuch ticks lagte hain , lekin yeh ek baar pay karte ho, toh lambe run mein har instruction effectively ek tick cost karta hai.
Line ko lamba karna (zyada, chhote stations) factory ko apni clock faster run karne deta hai — lekin do cheezein baadhta darti hain. Pehli, startup zyada cost karta hai ( bada hota hai). Doosri, ek if ya loop ka matlab hai ki CPU ne guess kiya ki aage kaunse instructions aate hain aur unhe line mein bhara; agar guess galat nikla, toh woh line mein sab kuch dump karta hai aur refill karta hai — aur lambi line ka matlab hai zyada dumped kaam. Toh short, jumpy code ke liye, ek chhoti line (M0+) actually steadier aur quicker ho sakti hai.
Finally, M7 do lines side by side rakhta hai aur ek saath do instructions run karne ki koshish karta hai. Lekin yeh tabhi kar sakta hai jab do instructions ek doosre par depend na karein. Agar sirf fraction pairs independent hain, tumhara real speedup hai, nahi. Isliye honest rule yeh hai: deep + wide pipelines raw throughput aur high clock speed khareedti hain long streaming math ke liye — yeh tumhe tiny real-time control code ke liye free, deterministic speed nahi deti. Sabse chhota core chunno jo deadline phir bhi meet kare.
Yeh kahan connect hota hai
- Pipelining and superscalar execution par bana hai — yeh page un formulas ka from-scratch derivation hai.
- Branch-flush cost wahi hai jo Interrupts and the NVIC latency ko bounded but non-zero banata hai.
- Determinism ki chinta Cache vs TCM in real-time systems aur RTOS task scheduling and context switching design ko drive karti hai.
- Parent overview: the ARM Cortex-M family note.
Recall Quick self-test
500 instructions ka cycles count 6-stage pipe par, no stalls? ::: cycles. M7 dual-issue with : kya IPC hai? ::: . Branch M7 ko M0+ se zyada kyun hurt karta hai? ::: Flush in-flight instructions waste karta hai, aur M7 ka vs M0+ ka matlab hai 5 wasted vs 1. Agar hai, toh kya doosri issue lane kisi kaam ki hai? ::: Nahi — , single-issue ke identical; tumne power/area kuch nahi ke liye pay kiya.