Question bank — Von Neumann architecture — components, bottleneck

False — every computer has those. The defining choice is that instructions and data live in one memory reached over one shared bus. The word is shared, not exists.

False — the bottleneck is structural. Even at equal speed, a single shared bus forces instruction transfers and data transfers to take turns (serialize). Speed only sharpens a problem that sharing already creates.

False — it uses separate memories and buses for code and data, so a fetch and a data access can happen simultaneously. The fix is a second channel, not faster silicon.

False — split L1-I / L1-D caches ("modified Harvard") only apply at the top level; main memory stays unified. The machine is still fundamentally Von Neumann; the cache hides the bottleneck, it does not remove it.

Partly (right in spirit, wording too shallow) — the sharp point is that an instruction is itself just a number, indistinguishable in form from data, so it lives in the same store — see Stored Program Concept. That sameness, not mere "storage", is what makes code loadable and rewritable.

True — nothing about the bits distinguishes them; a value written to the wrong address can land on code. This is a direct consequence of the shared, undifferentiated store (and the root of self-modifying code and many security exploits).

False — the PC is a register inside the Control Unit (see CPU Registers). It holds an address into memory, but it is not itself stored in main memory.

False — the Fetch-Decode-Execute Cycle runs them in sequence for one instruction. The whole point of the bottleneck is that the one bus cannot serve both a fetch and a data access simultaneously.

False — once ${\text{IPS}}_{\max }=B/(1+d)$ is the wall, a faster clock just makes the CPU idle more while waiting. Beyond that point the bus, not the clock, is the limit.

Partly — it captures the bus ceiling correctly, but real CPUs use pipelining, out-of-order execution, and non-blocking caches to overlap waiting with useful work, so measured IPS can approach that ceiling far better than the simple "wait then compute" picture suggests. The formula is the limit, not the everyday behaviour.

Error: CPU double-counts. The five classic parts are Memory, Control Unit, ALU, I/O, and Bus — the CU + ALU + registers together form the CPU.

Error: the PC is incremented always, right after fetch, so the default "next" is ready. A jump then simply overwrites the PC — see Fetch-Decode-Execute Cycle.

Error: it is $B/(1+d)$. The +1 is the instruction fetch itself, which also travels the shared bus. Forgetting it ignores the very traffic that causes the bottleneck.

Error: Decode only interprets the opcode bits into control signals. Execute is the step that meaningfully changes state (writes a register, memory, or the PC).

Error: even at $d=0$, ${\text{IPS}}_{\max }=B/(1+0)=B$ — still capped by how fast the bus supplies instructions. Fewer data accesses ease it; they never remove it.

Error: it is inverted (see Figure 2). Useful work is compute time over total time, $U=t_c/(t_c+t_m)$; the quoted ratio is the idle fraction.

Because loading a new program becomes just writing different numbers into memory, a fast memory operation — versus rewiring hardware, which took days on pre-1945 machines.

Because the single shared bus is a narrowing through which all traffic (code + data) must squeeze one item at a time — a geometric constriction, like the neck of a bottle, independent of raw speed.

So the "default next instruction" address is already correct for the common case; branch/jump instructions then only need to overwrite the PC, keeping the control logic uniform.

It keeps hot instructions/data in fast storage next to the CPU, so most accesses never travel the shared bus — cutting average access time and the CPU's waiting (see Memory Hierarchy and Caching).

Harvard's parallel code/data fetch suits fixed, streaming workloads; Von Neumann's single unified memory is simpler and more flexible for general programs where code/data proportions vary — a design trade, not a ranking.

They give separate fast code and data paths at the top level (Harvard-like parallelism), yet both draw from one unified main memory below — so the Von Neumann core remains.

Memory is too far and slow to drive the control logic directly; the CPU decodes bits held inside itself in the Instruction Register (IR), where control signals can be generated at CPU speed.

Because they let the CPU do useful work during the wait $t_m$ (issuing later instructions, servicing other accesses), so idle time overlaps with compute time instead of stacking after it — raising real $U$ toward the ${\text{IPS}}_{\max }$ ceiling without changing that ceiling.

Yes — the instruction fetch itself uses the bus, so $T=1$ and ${\text{IPS}}_{\max }=B$. The floor is one transfer per instruction, never zero.

$U=t_c/(t_c+0)=1=100\%$ — the ideal, no-bottleneck limit. Real systems approach it only as caches make effective $t_m\to 0$.

$U=t_c/(t_c+t_m)\to 0$ — the CPU spends essentially all its time waiting. This limiting behaviour is the bottleneck in its extreme form.

No — it becomes invisible in practice, not gone. The unified main memory and shared bus still exist; any miss, cold start, or cache-bypassing access exposes the same structural limit.

Yes — even one instruction that reads and writes data must serialize its fetch and its data transfers over the one bus. The bottleneck is per-access contention, not a large-program-only effect.

${\text{IPS}}_{\max }=B/(1+d)\to 0$ as $d\to \infty$ — instruction rate collapses because each instruction monopolizes the bus for many data words, starving the fetch of the next one.

It hides it — reordering fills idle slots with independent work, but every fetch and data access still crosses the same one bus, so ${\text{IPS}}_{\max }=B/(1+d)$ remains the hard ceiling.