15.7 Datapath Basics: Connecting the CPU's Building Blocks
Trace the flow of data through a basic CPU datapath — register file, multiplexers, ALU, and back to the register file — and distinguish the datapath from the control logic that drives it.
The datapath is the network of interconnected hardware blocks — register file, multiplexers, ALU, and the wiring between them — that data actually flows through as a CPU executes an instruction; it is, quite literally, the physical path the data takes. Every building block covered earlier in this module (the ALU in Section 15.1, arithmetic circuits in Section 15.2, the logic unit in Section 15.3, shifters in Section 15.4, multipliers in Section 15.5, and the register file in Section 15.6) is a component that gets wired together into a datapath — this final topic is about how those pieces fit together into a coherent whole capable of executing instructions.
The Typical Datapath Flow
A basic single-cycle datapath's typical path runs: Register File → MUXes → ALU → MUXes → Register File. Execution begins with the register file supplying two source operands, read out via its two independent read ports (Section 15.6). Those operand values (or, in some cases, an alternative source such as an immediate value encoded directly in the instruction) pass through a multiplexer that selects, based on the instruction being executed, exactly which values actually feed the ALU — this first MUX stage is what lets the same ALU hardware handle both register-register operations and register-immediate operations without needing separate circuitry for each.
The ALU (Section 15.1) then computes its selected operation on the chosen inputs, producing a result and status flags. A second multiplexer stage selects what actually gets written back to the register file — this might be the ALU's own result directly, or (in a design that also accesses memory) a value loaded from memory instead, depending again on which instruction is executing. Finally, that selected value flows back into the register file's write port, completing the cycle by updating the destination register (Section 15.6) so the next instruction can use the updated value.
• Register File — supplies two source operands via its read ports. • MUXes (first stage) — select each ALU input: a register value, or an alternative source like an immediate. • ALU — computes the selected operation, producing a result and status flags. • MUXes (second stage) — select what gets written back: the ALU result, or an alternative like memory-loaded data. • Register File — the write port stores the selected value into the destination register.
Datapath vs Control Logic
A CPU datapath and its control logic are separate concepts, but they work together to execute instructions. The datapath is the collection of data-carrying hardware — registers, the ALU, multiplexers, and the wires connecting them — through which actual operand and result values physically flow. Control logic is a separate block (the control unit) that examines the current instruction's opcode and generates the control signals — which operation the ALU should perform, which input each multiplexer should select, whether the register file's write-enable should be asserted — that steer the datapath's behavior on each cycle.
This separation is deliberate and central to how CPUs are designed and reasoned about: the datapath is a fixed piece of hardware capable of many different behaviors, and the control logic's job is entirely about choosing, cycle by cycle, which of those behaviors actually happens by setting the datapath's various select and enable signals appropriately for the instruction currently being executed. Understanding a CPU therefore always means understanding two things together: what the datapath is physically capable of doing, and what sequence of control signals the control logic generates to make it execute a given instruction correctly.
• Datapath = the data-carrying hardware (registers, ALU, multiplexers, wiring) — where values physically flow. • Control logic = the decision-making hardware that generates select/enable signals based on the current instruction's opcode. • The datapath alone is 'dumb' — it cannot decide what to do; control logic tells it what to do, every cycle. • A CPU is correctly understood only by considering datapath and control logic together, as cooperating halves of the same machine.
Practical and Real-World Applications
This same Register File → MUXes → ALU → MUXes → Register File pattern, extended with a memory-access stage, is the backbone of the classic 5-stage pipeline (Instruction Fetch, Instruction Decode, Execute, Memory access, Write-back) used to teach and build most RISC-style processors: the register file read happens in Decode, the MUX-ALU-MUX sequence happens in Execute (and optionally Memory), and the final register file write happens in Write-back. Real, high-performance CPUs elaborate enormously on this basic structure — with multiple parallel execution units, out-of-order scheduling, and speculative execution — but every one of them is still, at its core, moving data through some version of this same register-file/ALU/multiplexer datapath pattern under the direction of increasingly sophisticated control logic.
Code Examples
Every stage of the datapath is used, and every multiplexer's select line and the ALU's operation and the write-enable signal are all set by the control logic based on decoding the ADD opcode — the datapath itself has no idea it's executing 'ADD' until the control unit tells each of its components what to do this cycle. Expected result: R3 ← R1 + R2
The datapath moves the data; the control unit (decoding the ADD opcode) decides every select/enable signal that makes it compute R1 + R2 and write it to R3.
1. Register File reads R1 and R2 (two operands out via the two read ports)
2. First MUX stage: both ALU inputs select the register values (not an immediate)
3. ALU: ALUOp = ADD, computes R1 + R2
4. Second MUX stage: write-back value selects the ALU result (not memory data)
5. Register File write port: Write Address = R3, Write Enable = 1, Write Data = ALU result
→ R3 is updated with R1 + R2Basic single-cycle datapath
Data flows down through the datapath every cycle; a separate control unit (not shown as a data path) generates every MUX-select, ALUOp, and write-enable signal that steers this flow for the instruction currently executing.
┌────────────────┐
│ Register File │
└───────┬────────┘
│ (two operands)
▼
┌──────────┐
│ MUXes │ (select ALU inputs: reg / immediate)
└────┬─────┘
▼
┌─────┐
│ ALU │
└──┬──┘
▼
┌──────────┐
│ MUXes │ (select write-back value: ALU result / memory data)
└────┬─────┘
▼
┌────────────────┐
│ Register File │ (write port)
└────────────────┘Important Rules
Typical datapath flow: Register File → MUXes → ALU → MUXes → Register File.
Multiplexers select each stage's actual input/output source (register vs immediate, ALU result vs memory data) based on control signals.
A CPU datapath and its control logic are separate concepts, but they work together to execute instructions.
The datapath is the data-carrying hardware; the control unit generates the signals (ALUOp, MUX selects, write-enable) that steer it.
The same basic datapath pattern, extended with a memory stage, underlies the classic 5-stage RISC pipeline.
Where this datapath pattern shows up
Every RISC-style CPU taught in computer architecture courses and built in practice — from simple single-cycle teaching processors to the execute stage of modern pipelined, superscalar, out-of-order CPUs — is built around this same core pattern of a register file feeding an ALU through selectable multiplexers, with a control unit generating the signals that make it execute each instruction correctly.
Treating 'the datapath' and 'the CPU's control logic' as the same thing, or assuming the datapath alone determines what instruction executes.
Keep the two concepts distinct: the datapath is fixed hardware that data flows through, and the control logic is what decides — cycle by cycle, based on the current instruction — exactly how that hardware behaves via its select and enable signals.
A CPU datapath and its control logic are separate concepts, but they work together to execute instructions — the datapath by itself cannot decide anything; it simply executes whatever the control signals it's given tell it to do.
In the typical datapath flow Register File → MUXes → ALU → MUXes → Register File, what is the purpose of the multiplexers? A. They generate the clock signal for the whole CPU B. They select, based on control signals, which of several possible sources feeds each stage — such as a register value or an immediate, or an ALU result or memory data C. They permanently store the instruction being executed D. They perform the actual arithmetic instead of the ALU
B. They select, based on control signals, which of several possible sources feeds each stage — such as a register value or an immediate, or an ALU result or memory data — The multiplexers in a datapath don't compute anything themselves — they select among several possible signal sources (for example, a register operand vs. an immediate value, or an ALU result vs. memory-loaded data) based on control signals, letting the same fixed hardware path support many different instruction behaviors.
How do the datapath and the control unit relate to each other in a CPU? A. They are the same physical block with two different names B. The datapath is the data-carrying hardware; the control unit is a separate block that generates the select/enable signals steering the datapath's behavior for the current instruction — they work together, but are separate concepts C. The control unit only matters during startup and has no role once instructions begin executing D. The datapath decides which instruction to execute next, and the control unit only stores results
B. The datapath is the data-carrying hardware; the control unit is a separate block that generates the select/enable signals steering the datapath's behavior for the current instruction — they work together, but are separate concepts — As the spec notes, a CPU datapath and its control logic are separate concepts, but they work together to execute instructions — the datapath is fixed hardware (registers, ALU, multiplexers, wiring) that data flows through, while the control unit examines the current instruction and generates every signal that determines how that fixed hardware actually behaves on a given cycle.
Sketch (in words) how the datapath's signal flow and control signals would differ for an instruction ADDI R2, R1, #5 (add the immediate value 5 to R1, store in R2) compared to the ADD R3, R1, R2 example traced in this lesson.
Only one register (R1) needs to be read via the register file's read ports, rather than two, since the second ALU operand is the immediate value 5 encoded in the instruction itself, not a second register. The first-stage MUX that normally selects Register B's output must instead select the immediate value 5 (sign- or zero-extended to the ALU's operand width) as the ALU's second input. The ALU still computes ADD (R1 + 5), the second-stage MUX still selects the ALU result for write-back, and the write port still updates the destination register — here R2 instead of R3, with Write Address = R2, Write Enable = 1.
Think about which operand source the first-stage MUX needs to select differently, and which register file read port is actually needed.