A topic in the Open Knowledge Graph — a free, open map of 15,290 topics and the order to learn them in.
The CPU datapath is the collection of functional units and interconnects that carry data during instruction execution: the register file, ALU, program counter, instruction register, and data/address buses. Instructions follow a fetch-decode-execute cycle — the program counter addresses instruction memory, the fetched instruction is decoded into control signals, and operands flow through the ALU to produce a result that is written back to a register or memory. The datapath layout determines which operations can be performed and how control signals must be routed.
Trace a simple MIPS single-cycle datapath for ADD, LOAD, STORE, and BEQ instruction types. Draw the data flow for each and identify which MUX selections and control signals are needed. Build a datapath in a hardware simulator like Logisim.
The CPU datapath is best understood as a carefully arranged set of wires and functional units through which data travels on its way to becoming a result. The key components are the program counter (PC), which holds the address of the current instruction; instruction memory, which supplies the instruction bits; a register file, which stores operand values; the ALU, which performs arithmetic and logic; and data memory, which handles loads and stores. Multiplexers (MUXes) sit at critical junctions, selecting which data source to forward at any given moment.
Every instruction travels through a common sequence called the fetch-decode-execute cycle. In fetch, the PC's value is sent to instruction memory and the returned instruction bits are loaded into the instruction register; simultaneously, the PC increments (PC + 4 in a 32-bit word machine). In decode, the instruction bits are broken apart — the opcode identifies the operation type, and register numbers are extracted and sent to the register file to retrieve operand values. In execute, the ALU processes those operands. For R-type arithmetic instructions, the cycle ends with a write-back of the ALU result to the destination register.
Different instruction types diverge after the execute stage. A LOAD instruction uses the ALU to compute a memory address, then reads from data memory at that address, then writes the loaded value into a register — three distinct stages after decode. A STORE sends both an address (from the ALU) and a value (from a register) to data memory and writes nothing back. A branch instruction uses the ALU to test a condition and also computes the branch target address; if the condition is true, the PC is updated to the branch target instead of PC+4.
This is where MUXes become essential. The register file's write-data port might receive either an ALU result (for arithmetic) or data from memory (for loads) — a MUX selects between them based on the instruction type. The PC update might go to PC+4 or a branch target — another MUX. All of these selection signals come from the control unit, which decodes the opcode and drives every MUX and write-enable signal in the datapath. The datapath moves data; the control unit decides where it goes.
Understanding the single-cycle datapath is the foundation for understanding pipelining. In the single-cycle design, every instruction occupies the full clock period — even a simple ADD waits while the combinational logic settles through every stage. Pipelining overlaps these stages so that while one instruction is in the ALU, the next is being decoded and a third is being fetched. The same datapath hardware is reused, but now divided into pipeline registers that hold intermediate values between stages. The hazards that arise (data hazards, control hazards) are the direct consequence of trying to share this datapath across overlapping instructions.