1.2Instruction execution and pipelining

Performance design for embedded systems is not as simple as "adding pipeline stages increases throughput." When a hazard disrupts the pipeline, a pipeline stall (a gap in execution) occurs, and that gap is hard to predict—which is precisely why, in hard real-time control, a configuration with "high average performance but an unpredictable worst-case response time" can itself become a problem. This section builds an understanding of how pipelining works and the types of hazards, then develops the perspective of judging how far an embedded device can afford to rely on pipeline depth and branch prediction.

1.2.1The instruction execution cycle and pipelining

• The instruction execution cycle proceeds through the basic stages: instruction fetch (IF: retrieving the instruction from memory), instruction decode (ID: decoding the instruction and reading registers), execute (EX: computation/address calculation), memory access (MEM: reading/writing data), and register write-back (WB: storing the result to a register).
• Pipelining is a technique that assigns each stage to dedicated hardware and staggers multiple instructions to execute in overlapping parallel, raising throughput (instructions completed per unit time). Ideally, performance scales with the number of stages, but when a hazard occurs, some stages idle (stall), and the theoretical performance is not achieved.

1.2.2Types of hazards and branch prediction

• A data hazard is a dependency conflict that arises because an instruction immediately following another needs that instruction's result as input before the result is finalized. A structural hazard is a conflict where multiple instructions simultaneously need the same hardware resource (such as the same memory port). A control hazard is a conflict arising because, until a branch instruction's target is resolved, it is undetermined which instruction should be fetched next.
• Branch prediction is a technique that guesses in advance whether a branch will be taken, in order to speed fetching ahead and reduce stalls caused by control hazards. A correct prediction avoids the stall, but a mispredicted branch requires discarding (flushing) the instructions already fed into the pipeline and starting over, and the penalty on a misprediction can, depending on the situation, exceed what a design without branch prediction would incur. In embedded hard real-time control, the worst-case delay on a misprediction must be accounted for in the estimate.

Suppose you are a firmware developer for industrial control equipment, and the motor control loop has a hard real-time requirement that it must complete within a fixed time every cycle without exception. A teammate proposes, "switching to a high-performance processor with deep pipeline stages and dynamic branch prediction would raise average throughput and make the performance requirement easier to meet." What must be noted here is that an improvement in average performance does not automatically satisfy a real-time control requirement. Dynamic branch prediction does shorten the average execution time of a motor control loop with many conditional branches, but a misprediction causes a temporarily large delay due to the pipeline flush, and because the timing of that delay depends on data-dependent conditional branches at runtime, accurately estimating the worst-case response time in advance becomes difficult. In hard real-time control, a configuration that "always completes within a predictable range of execution time" is more valuable than one that is "fast on average but occasionally lags badly," so in this scenario you should prefer a processor core with shallow pipeline stages and simple, predictable pipeline behavior that does not rely on branch prediction, or a core where branch prediction can be disabled or locked, prioritizing a configuration whose worst-case execution time (WCET) can be statically analyzed. Rather than the shortsighted judgment that "raising performance satisfies the requirement," the core of embedded performance design is discerning whether what is required is average performance or worst-case predictability.

1.2.3Section summary

• The instruction execution cycle proceeds IF -> ID -> EX -> MEM -> WB. Pipelining overlaps these stages to raise throughput
• A hazard is one of three types: data/structural/control. Branch prediction avoids a stall when correct but incurs a flush penalty when wrong
• In embedded hard real-time control, there are cases where predictability of worst-case response time takes priority over average performance