Turning a Single-Cycle Datapath into a Pipelined One

Overlapping instruction execution requires more than just running the same single-cycle hardware faster; it requires physically separating each pipeline stage with storage elements and duplicating control logic across stages. This article explains how pipeline registers preserve instruction state between stages and how control signals travel alongside data through the pipeline.

Pipeline RegistersPipelined DatapathPipeline Control Signals

~3 min read · Updated Sep 6, 2026

Why the Single-Cycle Datapath Cannot Simply Run Faster

Pipelining does not mean reusing the exact same single-cycle datapath and clocking it more quickly. Since five different instructions occupy five different stages simultaneously, the hardware for each stage must be physically separated, and the partial results of an instruction still in progress must be preserved as it moves from one stage to the next.

Pipeline Registers: Preserving State Between Stages

Between every pair of adjacent pipeline stages, a Pipeline Register stores all the values an instruction needs to carry forward into the next stage.

IF/ID register: holds the fetched instruction and incremented PC
ID/EX register: holds decoded register values, immediate, and control signals
EX/MEM register: holds ALU result, register value for stores, and control signals
MEM/WB register: holds the value to be written back and control signals

Each of these registers updates once per clock cycle, allowing one instruction's partial results to sit safely in a register while the next instruction's results are simultaneously being computed one stage earlier.

Control Signals Must Travel With the Instruction

In the single-cycle design covered earlier in this series, control signals were generated and used within the same cycle. In a pipelined design, a control signal generated during decode might not be needed until several cycles later, once the instruction reaches the memory or write-back stage. To handle this, control signals are carried forward through the same pipeline registers alongside the data they apply to, ensuring each signal arrives at the correct stage at the correct time for its own specific instruction.

An Example: Following a Load Instruction Through the Pipeline

Consider a load instruction moving through all five stages over five clock cycles.

Cycle 1 (IF): fetch the load instruction
Cycle 2 (ID): decode it, read base register, generate control signals
Cycle 3 (EX): ALU adds base register and offset to form the address
Cycle 4 (MEM): read the value from data memory at that address
Cycle 5 (WB): write the retrieved value into the destination register

At every one of these cycles, other instructions are simultaneously occupying the other four pipeline stages, each carrying their own data and control signals through their own pipeline registers without interfering with the load instruction's progress.

Why This Structural Change Matters

This separation of stages using pipeline registers is what makes overlapped execution physically possible. Without it, the hardware for a later stage would have no reliable way of knowing which instruction's data it is currently supposed to be working on, since multiple instructions occupy the datapath's different regions at the same instant.

Written & researched by Dr. Shahin Siami

Related Articles

Cache Fundamentals: How Small, Fast Memory Predicts What You Need Next

A cache works because programs tend to access the same or nearby data repeatedly rather than randomly. This article explains the principle of locality that makes caching effective, how a direct-mapped cache locates data using an address, and what happens on a cache hit versus a cache miss.

Continue

The Memory Hierarchy: Why Computers Use Several Kinds of Memory

No single memory technology is simultaneously fast, large, and cheap. This article introduces the concept of a memory hierarchy that combines several different memory technologies to approximate the speed of the fastest one at the cost of the cheapest, then walks through the core technologies that make up each level.

Continue

Common Misconceptions About Processor Design and Chapter Four's Big Picture

After covering datapaths, pipelining, hazards, and real-world processor comparisons, it is time to correct a handful of persistent misconceptions about how processors actually behave. This article addresses common fallacies about pipelining and performance, then ties together the full journey from simple datapaths to superscalar execution covered throughout this chapter.

Continue

Real-World Pipelines: Comparing ARM and Intel, and Speeding Up Matrix Multiply

Theoretical pipeline concepts take concrete shape in real commercial processors, which vary widely in pipeline depth and issue width depending on their design goals. This article compares how the ARM Cortex-A53 and Intel Core i7 implement pipelining differently for power efficiency versus raw performance, then shows how instruction-level parallelism accelerates matrix multiplication in practice.

Continue

Instruction-Level Parallelism: Executing More Than One Instruction at Once

A single pipeline can only advance one instruction into each stage per cycle, which caps its performance at roughly one instruction per clock. This article explains how processors go beyond that limit by issuing multiple instructions simultaneously, the hardware duplication this requires, and the fundamental limits imposed by dependencies between instructions.

Continue

How a Pipelined Processor Handles Exceptions

Not every instruction executes as expected — some trigger error conditions like an undefined opcode or an arithmetic overflow that the processor must respond to safely. This article explains what exceptions are, how a pipelined processor detects and handles them without corrupting program state, and why exceptions are treated similarly to control hazards.

Continue