Computer Structure & Microprocessors (CPU)

The IPO model looks simple enough to be dismissed, but that simplicity is exactly its strength: no matter how complex a system looks, you can ALWAYS break it down into exactly three questions. Where does the data come in from (Input)? How is it transformed (Process)? What is the final result and where does it go (Output)?

For a pocket calculator, Input is the key presses, Process is the arithmetic, Output is the number shown on screen. For an FMGC, Input is dozens of sensors, Process is thousands of lines of flight-control logic, Output is commands sent to control surfaces. The same framework, applied at both extremes of complexity.

The three buses are like three kinds of roads in a city, each serving a different purpose: the address bus is like a signpost (telling you WHERE to go, carrying no cargo), the data bus is like the actual delivery truck (carrying the real DATA), and the control bus is like the traffic light system (commanding when to go, when to stop, which direction).

The most important distinction to remember: the address bus is ONE-WAY only (the CPU always issues the address, memory/devices always receive it), while both the data bus and control bus are TWO-WAY, since the CPU needs to both read and write data, and control signals also need feedback flowing back from the device.

The formula 2ⁿ (learned back in Module 01 for counting binary combinations, and again in Module 03 for counting decoder outputs) is applied here on the exact same principle: the number of address wires (n) determines the maximum number of distinguishable memory locations (2ⁿ).

With a 24-bit bus, 2²⁴ gives 16,777,216 addresses, and the largest address (all bits set to 1), converted to hex, needs exactly 6 digits (since 24 divides evenly by 4) to give FFFFFF: this is a direct hands-on application of the 4-bit-grouping-for-hex principle learned in Module 01.

This is a complete REAL example, packing the whole IPO framework and all three buses into ONE specific device: the A320 cockpit clock. The crystal oscillator (the time source, like an Input), the microprocessor processing the data (Process, using all three buses to talk to ROM/RAM), then sending it out on the ARINC 429 bus (Output).

The attached image shows a similar block diagram, with sensor data and pilot inputs flowing in, processed by the CPU together with memory, then output as control commands and displayed information: exactly the IPO plus 3-bus structure just learned, applied to a real aircraft system rather than an abstract example.

This is a very common visual misconception for beginners: picturing a “bus” as a single wire, like a network cable. The reality is entirely different: a “bus” is a BUNDLE of parallel wires, each carrying exactly one bit.

A 24-bit address bus is not “one line used 24 times”, it is 24 SEPARATE PHYSICAL WIRES, each carrying exactly 1 bit of the address, all 24 wires operating SIMULTANEOUSLY to transfer a complete address in a single clock tick. This physical wire count is exactly what technical documents mean by “bus width”.

This practice exercise runs the 2ⁿ formula in reverse with a much smaller n: an 8-bit bus gives 2⁸=256 possible addresses, far fewer than the 16,777,216 addresses of the 24-bit bus in the previous slide.

This enormous gap (256 versus over 16 million, even though the bit count only tripled from 8 to 24) vividly illustrates the EXPONENTIAL nature of the power function: each extra bit does NOT add a fixed amount to the address count, it DOUBLES the existing count. This is why modern systems always push hard to widen an address bus by even just a few bits, since the payoff grows non-linearly.

Picture RAM as a whiteboard (freely erasable and rewritable, but wiped clean when the room lights go off), and ROM as a printed page in a book (readable but not overwritable, and still intact even with the lights off).

The two criteria in the table are the two core questions worth asking about any memory type: can it be WRITTEN to (read/write versus read-only), and does it KEEP its data when power is lost (volatile versus non-volatile). These two criteria are independent of each other, and as the next slide shows, some “hybrid” memory types (like EEPROM/Flash) blur the traditional simple RAM/ROM boundary.

These three ROM types differ in exactly ONE respect: WHO is allowed to write, and HOW MANY TIMES. Mask ROM: the manufacturer fixes the contents permanently during fabrication, the end user can never write to it. OTP EPROM: the user can write to it, but only ONCE (like a sheet of paper writable only with permanent ink).

EPROM (the UV-erasable kind) is the most “flexible” of the three: the user can write to it, then shine UV light through a transparent window on the chip's casing to WIPE IT CLEAN, then write it again, repeatable many times. This is exactly what sets EPROM apart from the other two, making it the only truly “erasable and reprogrammable” type among the three.

This calculation is a classic “unit conversion” problem, and it needs exactly three steps, none of which can be skipped. Step 1: compute ONE chip's capacity by multiplying the number of addresses by the bits per address (16,384×4=65,536 bits). Step 2: convert bits to bytes (divide by 8, giving 8,192 bytes = 8KB, since 1 byte = 8 bits).

Step 3: divide the total capacity needed (32KB) by one chip's capacity (8KB) to get the number of chips required: 32÷8=4. The most common mistake in this type of problem is forgetting to convert bits to bytes in Step 2, which throws the final answer off by a factor of 8.

The row-column matrix structure solves a subtle but very real problem: sending an entire address all at once would require a large-capacity memory chip to have an enormous number of physical address pins (for example, a chip with 1 million cells would need 20 address pins if sent all at once).

The solution: arrange the memory cells into a row×column grid, then send the row address FIRST (latched by the RAS signal), followed by the column address (latched by the CAS signal), reusing the SAME set of address pins for both transmissions. That same 1-million-cell chip now needs only about 10 address pins (instead of 20), at the cost of a slightly longer read/write time since the address arrives in two steps instead of one.

This is a case where a strict technical term and everyday usage have DRIFTED APART, causing serious confusion if the two are not kept separate. Technically, “random access” simply means every memory cell is accessed with equal speed regardless of position, with NO connection whatsoever to whether it can be written to.

By that definition, ROM fully deserves the label “random access” too (as opposed to sequential-access memory like magnetic tape, which must be “wound” past every position in between). But in everyday usage, the word “RAM” has drifted to mean “read/write memory” specifically: this is exactly why no one ever calls ROM “a type of RAM”, even though technically ROM is random-access too.

This practice exercise applies the exact elimination logic just learned, based on the two criteria: RAM is ruled out immediately because its data is lost when powered off (unsuitable for control software that must persist long-term) AND because RAM is writable (risking accidental overwrite, exactly what the problem forbids).

Between ROM and EPROM, neither allows the user to accidentally overwrite it during normal operation (ROM cannot be written at all, EPROM can only be rewritten through a special deliberate UV process, never “accidentally”). Both are reasonable choices, depending on whether the software needs periodic updates (choose EPROM) or is permanently fixed forever (choose the cheaper Mask ROM when mass-produced).

Picture a CPU as a small office with exactly four dedicated staff. Registers are the small drawers on the desk (holding whatever is being worked on right now). The ALU is the calculator clerk (performing addition/subtraction/comparison). The instruction decoder is the intake clerk (reading a request and figuring out what it means). The control unit is the manager (coordinating all three of the others to do the right thing at the right time).

These four blocks do not work in isolation: they cooperate TIGHTLY within every single instruction cycle, and the next slide dives into the single most important register among them.

The accumulator earns a name of its own (rather than being just “one of many registers”) because of its SPECIAL role: most arithmetic/logic instructions use the accumulator as both the STARTING point (holding the first operand) and the ENDING point (holding the result after the calculation).

Picture it as the one and only mixing bowl on a kitchen counter: you pour ingredients in, mix (calculate), and the result also ends up RIGHT IN that same bowl, ready for the next step or to be poured out. This is exactly why the accumulator appears far more often in CPU technical documentation than any other register.

PC (Program Counter) and SP (Stack Pointer) are both “pointers” (registers holding only an address, not actual data), but they point at two entirely different things. The PC always points to the NEXT instruction to be fetched (like a finger tracking the next line to read in an instruction manual).

The SP points to the current top of the stack, a special area of RAM operating on a “last in, first out” principle (like a stack of plates: you can only add or remove a plate from the top). The stack is used to temporarily store a return address when calling a subroutine, or to save register states while handling an interrupt, so everything can later be restored exactly.

The reason the data bus buffer must be bidirectional lies in the very nature of the CPU's work with memory: the CPU does not only READ instructions and data (inbound), it must also WRITE calculation results back to memory (outbound), and both of these travel over the SAME physical data bus.

Compare with the address bus: the CPU ONLY EVER issues an address outward (it never “receives” an address sent back from memory), so the address bus buffer only needs one direction. This is exactly why, on a CPU block diagram, the buffer connecting to the data bus is always drawn with a double-headed arrow, while the one connecting to the address bus has only a single-headed arrow.

This is a pair of functional blocks very easy to conflate, since they always “work right next to each other” in every instruction cycle, yet their jobs are entirely separate. The ALU is like the CPU's “hands”: it ACTUALLY performs the calculation (add, subtract, AND, OR...) on specific data.

The instruction decoder is like the “eyes and interpreting brain”: it does no calculation at all, it just LOOKS at the instruction just fetched and DETERMINES what it is (add? compare? jump?), then signals the ALU (or another block) what TO DO. If the instruction decoder “misreads” an instruction, the ALU will still correctly perform an operation, just the WRONG one, clearly demonstrating these two blocks are functionally independent despite always working side by side.

This practice exercise requires applying exactly the distinction just learned: inverting a bit (NOT) is a genuine LOGIC OPERATION performed on data, so the responsible block is certainly the ALU, not the accumulator (which only HOLDS data, without calculating anything itself) and not the instruction register (which only stores the instruction code, without processing data).

The full sequence: the data to be inverted is usually loaded into the accumulator first, the ALU reads that data, performs the NOT operation, then writes the result BACK into the accumulator: three blocks cooperate (accumulator, ALU), but the actual calculation is carried out by exactly one of them (the ALU).

The Fetch-Decode-Execute cycle is the “heartbeat” of every CPU, repeating billions of times per second without ever stopping (unless a HALT instruction is hit). Picture it like reading a recipe book one line at a time: Fetch is “read the next line” (grab exactly the instruction the PC is pointing at), Decode is “understand what that line says to do” (say, “add 2 spoons of sugar”), Execute is “actually do it” (pour the sugar in).

The key point to grasp: this is not three steps done once and finished, it is an INFINITE LOOP, each pass handling exactly one instruction, then automatically looping back to Fetch for the next one, continuing indefinitely.

Distinguishing a T-state from a machine cycle is like distinguishing “one clock tick” from “one stage of work”: a T-state is just ONE single tick of the system clock (not enough to accomplish anything meaningful on its own), while a machine cycle (M0, M1...) is a GROUP of T-states combined to complete one meaningful stage (for example, M1 is the entire opcode fetch-and-decode stage).

An analogy: a T-state is like a single footstep, while a machine cycle is like “walking from this room to that room”, a complete action requiring several footsteps COMBINED to finish.

This calculation applies the most basic physics formula relating time and frequency: the period (T) is always the RECIPROCAL of the frequency (f), since frequency measures “how many times per second” while period measures “how long each time takes”.

With a 50MHz clock (50 million times per second), a single cycle lasts only 1/50,000,000 second = 20 nanoseconds (ns, one billionth of a second). If an instruction needs 11 T-states to complete, the total execution time is simply 11 times the duration of one T-state: 11×20ns=220ns, faster than a blink of an eye by millions of times.

Splitting the AX register into two halves, AH/AL, is a concrete example showing that a “large” 16-bit register can actually be accessed as two independent “small” 8-bit registers, a technique very common in x86 architecture.

With the hex value 07FEh, splitting it into AH=07h (the high byte, the first 8 bits) and AL=FEh (the low byte, the last 8 bits) is simply “slicing in half” a 4-digit hex string into two 2-digit pairs. Converting FEh to binary uses exactly the hex-binary lookup table learned in Module 01 (F=1111, E=1110), joined together to give 11111110.

This is something very easy to overlook when first learning about machine cycles: implicitly assuming EVERY instruction costs the same number of T-states, when in reality that is far from true.

The underlying reason: an instruction operating purely INTERNALLY within the CPU (say, adding two registers together) can finish in just a few T-states since all the data is already available on-chip. But an instruction needing to ACCESS EXTERNAL MEMORY (reading/writing RAM) must wait extra time for the signal to propagate out over the address bus, wait for memory to respond, then transfer data back over the data bus: each of these steps adds T-states, making a memory-access instruction ALWAYS slower than one operating purely on internal registers.

This practice exercise applies exactly the formula learned in the 50MHz calculation slide: first compute the period T=1/20,000,000=50ns (note that MHz means millions of Hz, not thousands), then multiply by the number of required T-states: 4×50ns=200ns.

Compare with the 50MHz/11-T-state example from the previous slide (220ns): although the frequency here is LOWER (20MHz versus 50MHz, so each T-state is slower), because FEWER T-states are needed (4 versus 11), the total execution time actually ends up slightly FASTER. This shows execution time depends on BOTH factors together (frequency and T-state count), not on either one alone.

Pipelining is one of the cleverest performance ideas in CPU architecture, and the easiest way to picture it is comparing it to a laundry assembly line: instead of one person washing an ENTIRE load (finishing the wash before starting to dry, finishing the dry before starting to fold) before starting the next load, three people handle three different stages AT THE SAME TIME on three different loads: person 1 is washing load 3, person 2 is drying load 2, person 3 is folding load 1, all happening simultaneously.

Applied to a CPU: while instruction A is being Executed, instruction B (which comes after) can already be Decoded, and instruction C (after that) can already be Fetched, ALL AT THE SAME TIME, instead of waiting for instruction A to fully finish before starting instruction B.

Separating the instruction bus from the data bus (illustrated here by Harvard architecture, as opposed to Von Neumann architecture, which shares one memory and one bus for both instructions and data) solves a classic bottleneck: with only ONE shared bus, the CPU cannot fetch a new instruction AND read/write data in the same clock tick, since both must “queue up” for the same shared pathway.

With two separate buses (one for instruction memory, one for data memory), the CPU can do BOTH at the SAME TIME: fetching the next instruction while reading or writing the current instruction's data, with neither having to wait for the other. This is exactly why high-performance embedded microcontrollers often choose Harvard architecture over the simpler Von Neumann design.

Interrupts solve a very practical problem: if the CPU had to constantly “check in” with every peripheral device to see if anything new happened (called polling, like glancing out the door every few seconds to see if a guest has arrived), a great deal of processing time would be wasted on checks that find “nothing new”.

With the interrupt mechanism, a peripheral device PROACTIVELY “knocks on the door” (raising a signal on the IRQ line) exactly when there is something to handle, while the CPU is free to focus on other work until an actual knock occurs. When an interrupt fires, the CPU pauses its current task, saves its ENTIRE current state to the stack (exactly the stack concept learned in Part 3), handles the urgent event, then restores the exact previous state to resume the interrupted work as if nothing happened.

The AIMS system on the Boeing 777 is a textbook example of the “no single point of failure” design philosophy: instead of fully trusting ONE microprocessor (no matter how powerful), the system runs TWO identical microprocessors in parallel, both receiving the exact same input data, both running the exact same program.

If both produce the SAME result, the system trusts that result. If the results DIFFER, that is definite proof a FAULT occurred in one of the two processors (from hardware failure, interference, or a rare software bug), and the system can detect it immediately instead of silently producing a wrong answer that no one notices.

This is one of the most common misconceptions about pipelining: assuming that if a CPU processes multiple instructions “overlapping” in time, EACH individual instruction must also finish faster. The reality is quite different.

Pipelining improves THROUGHPUT (the total number of instructions completed over a long stretch of time), just as a laundry assembly line handles more loads per hour. But the TIME for one SPECIFIC load to go from start-of-wash to finish-of-fold (latency, the delay of a single instruction) is not shortened at all, and can even lengthen slightly due to having to “wait its turn” in the pipeline. Do not confuse “faster at the system level” with “faster at the individual-instruction level”.

This wrap-up question requires connecting the ENTIRE design philosophy learned across Part 5: even the most powerful microprocessor can suddenly fail (random hardware fault, cosmic radiation interference at high altitude, a rare software bug), and when it fails, it does NOT automatically alert the system that it is now wrong.

This is why critical avionics systems (where a fault could seriously endanger flight safety) never bet everything on ONE single point of failure, no matter how good its performance. The solution is always REDUNDANCY: running multiple processors in parallel and cross-checking their results, exactly as in the AIMS case study, so that a single fault can never silently turn into a wrong decision affecting the entire flight.