Fetch: Copy the instruction at address in PC into IR.
Why? The CPU needs the instruction inside itself to act on it — memory is too far/slow to decode in place.
PC ← PC + 1 (point to next instruction).
Why now? Increment early so that even if the instruction is a jump, the "default next" is ready; jumps just overwrite PC.
Decode: CU interprets the bits in IR (which operation? which operands?).
Why? Bits are meaningless until the CU maps the opcode to control signals.
Execute: ALU/CU/memory perform the action (add, load, store, branch).
Why? This is the only step that changes the machine's state meaningfully.
An average instruction needs 1 fetch (the instruction) + on average ddata accesses (operands/results).
Then memory transfers per instruction:
T=1+d (words)
If the bus delivers B words/second, then instructions/second is limited by:
IPSmax=TB=1+dB
Utilisation idea: if the CPU could compute an instruction in time tc but must wait time tm for memory, the fraction of time doing useful work is:
U=tc+tmtc
As memory gets relatively slower (tm↑), U→0. That falling Uis the bottleneck.
Imagine a chef (CPU) in a kitchen, and one tiny hallway (the bus) to a single pantry (memory). In that pantry you keep both the recipe cards AND the ingredients. To cook, the chef must run down the hallway to grab a recipe card, run back, then run down again for the carrots, then again for the onions — one trip at a time, because the hallway fits only one person. The chef is super fast at chopping but spends all day running back and forth. That endless running in one narrow hallway is the Von Neumann bottleneck. A trick: keep a small shelf of favourite ingredients right next to the chopping board (a cache) so most of the time he doesn't need the hallway.
Dekho, Von Neumann architecture ka core idea bahut simple hai: instructions (program) aur data, dono ek hi memory me rakhe jaate hain, aur CPU unhe ek hi shared bus ke through laata hai. Isi liye program ko bhi sirf numbers ki tarah memory me store kar sakte ho — yahi "stored program" concept hai, jo computers ko itna flexible banata hai. Components yaad rakhne ke liye soch lo: Memory, Control Unit (jisme PC aur IR), ALU, I/O, aur Bus.
Ab problem kya hai? Kyunki memory aur CPU ke beech sirf ek hi rasta (bus) hai, ek time pe sirf ek cheez travel kar sakti hai — ya to instruction aayega, ya data. Dono saath me nahi. Iska matlab CPU bahut tez hai, par memory ka intezaar karta rehta hai. Isi waiting ko Von Neumann bottleneck kehte hain. Ek line me: ek hi darwaza, do bheed — instruction aur data dono usi bus pe baari-baari aate hain.
Maths bhi simple hai aur ratne ki zaroorat nahi. Agar ek instruction ko average d data accesses chahiye, to total 1+d words memory se laane padte hain (1 khud instruction ke liye). Agar bus B words/second deta hai, to maximum instructions per second = B/(1+d). Aur agar CPU compute me tc aur wait me tm lagaata hai, to useful kaam ka fraction U=tc/(tc+tm) hota hai — jaise-jaise memory relatively slow hoti jaati hai, U girta hai. Yahi bottleneck ka asli proof hai.
Solution? Cache! CPU ke paas ek chhoti, tez memory rakho jisme frequently-used cheezein ho. Tab zyaadatar baar slow bus ki zaroorat hi nahi padti — effective access time average ho jaata hai (jaise 0.9×1+0.1×20=2.9 ns). Aur ek alternative design hai Harvard architecture, jisme code aur data ke liye alag-alag bus hote hain, to dono ek saath aa sakte hain. Yeh samajh lo to exam aur real CPUs dono clear ho jaayenge.