Pipelines: overlap work without erasing dependencies

Suppose each stage takes one clock cycle and an instruction passes through five stages. One isolated instruction still needs five cycles from entry to completion. If the pipeline accepts a new independent instruction every cycle, however, ten instructions finish in fourteen cycles: five to complete the first, followed by one completion per cycle for the remaining nine. Pipelining creates overlap. It does not make one instruction magically skip its own work, and a longer clock period can offset apparent gains from a shallow stage count.

This ideal calculation assumes balanced stages, no stalls, enough input work, and a single result every cycle after filling. Real implementations may admit several operations per cycle or split instruction handling into many more steps. Branch recovery and finite queues complicate fill and drain. Treat the simple equation as a baseline that exposes missing costs, then add only the effects supported by the model or measurement. A pipeline diagram becomes misleading when its stage count is quietly substituted for a processor specification.

A read-after-write dependency is a true data dependency: a consumer needs the result produced by an earlier operation. If an ADD creates a register value and the next ADD uses it, the second must receive the new value, not the stale register contents. Forwarding can deliver a result before ordinary register writeback when the implementation supports the path. Forwarding does not eliminate the time needed to produce the value; some producer-consumer combinations still require a stall.

A structural hazard occurs when simultaneous work needs a resource that cannot serve it all. In a teaching machine with one shared memory port, instruction fetch and a data load may conflict. A control hazard arises when the next path is unresolved. These categories suggest different remedies: a resource copy addresses one kind of conflict, prediction addresses some control uncertainty, and forwarding addresses some data availability. None is a general cure. Changing instructions can also shift pressure from one resource to another rather than remove the bottleneck.

To test a schedule, label each cycle and mark when every source becomes ready and every resource is occupied. Ask whether a consumer reads the value before its producer can supply it. Then check whether two proposed actions claim the same exclusive resource. A legal schedule under an explicit model is more useful than an attractive diagram with unspecified forwarding. For a real kernel, use the vendor model and measurements because cache behavior and issue width can invalidate the fictional assumptions.

The queue lab illustrates a related capacity mismatch: arrivals enter at rate λ while service removes work at rate μ. Predict whether its fluid backlog grows or drains before pressing play. This is not a pipeline hazard simulator; it has no stages, registers, or forwarding paths. Its limited connection is that adding demand beyond a bottleneck’s service rate accumulates waiting work. A pipeline needs separate resources and dependency reasoning to explain why a particular instruction waits.