A single-issue processor follows a structured approach in which the instruction fetch (IF) stage retrieves and issues instructions sequentially in program order, a process known as in-order issue. The execution of an instruction begins as soon as its required operands are available, provided that it is not dependent on prior instructions, meaning that read-after-write (RAW) hazards are avoided.
The processor contains multiple pipelined functional units, each with variable latencies. This variability implies that the execution (EX) stage can span multiple cycles, depending on the specific operation type and its latency. Furthermore, the memory (MEM) stage may also introduce additional delays if a data cache miss occurs, leading to multi-cycle memory access times. These conditions collectively result in an out-of-order execution model, where instructions do not necessarily complete in the same order they were issued. Consequently, instructions can also be committed out of order, introducing potential write-after-read (WAR) and write-after-write (WAW) hazards that must be managed.
To handle dependencies and maximize instruction throughput, a Scoreboard-based dynamic scheduling mechanism is employed.
Definition
The Scoreboard ensures that data-independent instructions behind a stalled instruction can proceed without waiting unnecessarily. This capability allows multiple instructions to be in execution simultaneously, necessitating the presence of multiple execution units or pipelined execution units.
A key structural modification in Scoreboard-based pipelines is the division of the instruction decode (ID) stage into two distinct sub-stages:
- Issue Stage: In this phase, the instruction is decoded, and structural hazards are checked. The instruction will be stalled if no execution unit is available.
- Read Operands (RR) Stage: At this stage, the instruction waits until its required operands are available and no data hazards exist. Once these conditions are met, operands are read, and the instruction is prepared for execution.
This division allows instructions to execute as soon as conditions 1 and 2 are satisfied, without waiting for previous instructions to complete. The Scoreboard continuously tracks dependencies and the state of ongoing operations, dynamically resolving conflicts and ensuring execution progresses efficiently.
Behavior of the Scoreboard Pipeline
While instructions pass through the issue stage in order, they can be stalled or allowed to bypass each other in the read operands stage, leading to out-of-order operand reads. This means that instructions may enter execution at different times based on operand availability, contributing to out-of-order execution and out-of-order completion (commit).
Unlike processors that employ forwarding, the Scoreboard does not support direct data forwarding from one pipeline stage to another. Instead, control remains centralized within the Scoreboard, which determines when each instruction is permitted to proceed.
Because multiple instructions may be in the EX phase simultaneously, multiple execution units or pipelined execution units must be present to sustain parallel execution. However, unlike processors utilizing register renaming, this implementation does not perform such renaming at compile time.
As a result, the lack of register renaming, combined with out-of-order commit, creates conditions where WAR and WAW hazards can still occur.
Handling Data Hazards in the Scoreboard
The Scoreboard systematically detects and resolves WAR and WAW hazards through controlled stalling mechanisms:
- Write-After-Read (WAR) Hazard: This hazard arises when an instruction attempts to write to a register before a prior instruction has finished reading from it. To prevent this, the Scoreboard ensures that registers are only read during the Read Operands stage and delays write-back operations until the previous instructions have completed their read operations.
- Write-After-Write (WAW) Hazard: This occurs when two instructions write to the same register in an overlapping manner. The Scoreboard detects this hazard and stalls the issue of the newer instruction until the previous instruction completes its write operation.
Centralized Control and Execution Tracking
All hazard detection and resolution are centralized within the Scoreboard, which maintains a comprehensive record of data dependencies. Every instruction must pass through the Scoreboard before execution, allowing it to track when each instruction can safely read its operands, begin execution, and write its result. The Scoreboard continuously monitors the pipeline, updating the execution state as instructions progress.
If an instruction cannot be executed immediately due to dependencies, the Scoreboard dynamically observes changes in the pipeline and determines the earliest possible moment for the instruction to proceed. Additionally, it enforces write constraints to prevent WAR and WAW conflicts, ensuring a stable execution order despite the out-of-order execution and commit nature of the pipeline.
Stages of Scoreboard-Based Execution
The Scoreboard-based execution model is structured into four distinct stages, each responsible for managing dependencies, scheduling execution, and resolving hazards dynamically. The Scoreboard ensures that instructions are issued in-order but allows operands to be read, instructions to be executed, and results to be written out-of-order, optimizing parallelism while maintaining correctness.
Execution Behavior Summary
The table below summarizes the ordering constraints at each pipeline stage:
Stage In-Order Out-Of-Order Functionality Issue ✅ Decode instructions, check for structural hazards, check for WAW hazards on destination Read Operands ✅ Resolve RAW hazards, check for structural hazards when reading registers Execution ✅ Execution latency depends on the functional unit and cache performance Write Results ✅ Resolve WAR hazards, check for structural hazards when writing to the register file
1. Issue Stage: Instruction Decoding and Hazard Checking
The issue stage is responsible for decoding instructions and checking for structural and write-after-write (WAW) hazards. Instructions are issued in program order to maintain a structured hazard-checking process. If an instruction is ready for execution and a functional unit (FU) is available, it proceeds to execution. However, if a structural hazard occurs (i.e., no available FU) or if another active instruction is set to write to the same destination register (WAW hazard), the instruction issue is stalled. No subsequent instructions are issued until these hazards are resolved.
This step ensures that only one instruction at a time writes to a given register, preventing conflicts in the pipeline. The Scoreboard updates its internal data structures accordingly to track issued instructions and their dependencies.
2. Read Operands Stage: Data Hazard Resolution
Once an instruction has been issued, it waits until all required source operands are available before proceeding to execution. This step addresses read-after-write (RAW) hazards dynamically. A source operand is considered available if:
- No previously issued instruction is scheduled to write to it, or
- A functional unit is actively writing its value to a register.
When the operands become available, the Scoreboard signals the functional unit to read the required registers and begin execution. Unlike some pipeline architectures, the Scoreboard does not support data forwarding, meaning that instructions must wait for operands to be written back before execution can commence.
Since instructions can read operands out-of-order, they may bypass earlier instructions that are stalled due to dependencies. This allows the pipeline to maximize instruction throughput while ensuring correct operand sequencing.
3. Execution Stage: Operation Processing and Variable Latency
Once the functional unit has received its operands, it begins execution. Different instructions require different amounts of time to complete, meaning that execution latency varies depending on the operation type and the functional unit involved. The Scoreboard does not enforce strict execution timing but instead allows instructions to proceed independently.
For load/store instructions, execution latency depends on cache performance. If a cache hit occurs, execution completes quickly, while a cache miss results in a multi-cycle delay. This variability means that multiple instructions can be in execution simultaneously, requiring multiple FUs or pipelined execution units.
4. Write Result Stage: Register Write and Final Hazard Resolution
Once execution is complete, the instruction enters the write result stage. Before writing to the destination register, the Scoreboard checks for WAR hazards. A WAR hazard occurs if a subsequent instruction is scheduled to read a register that the current instruction is about to overwrite. If such a hazard is detected, the Scoreboard stalls the write operation until the dependent instruction has safely read its value.
Once the hazard check is complete and no conflicts are detected, the instruction writes its result to the register file, and the Scoreboard updates its internal status to reflect that the register is available for future instructions.
Optimizations for Scoreboard Execution
Several improvements can enhance the Scoreboard’s efficiency:
-
Postponing WAW Hazard Checking:
Instead of checking for WAW hazards during the Issue stage, the check can be deferred to the Write Result stage. This allows more instructions to be issued without stalling, improving overall pipeline throughput. -
Data Forwarding:
While the baseline Scoreboard does not support data forwarding, an optimized version could include a mechanism for forwarding results directly from the execution units to dependent instructions, reducing stalls in the Read Operands stage.
Scoreboard Structure and State Tracking
The Scoreboard maintains a centralized status table to track the state of instructions and functional units. The three primary components of this structure include:
-
Instruction Status:
This keeps track of which stage each instruction is currently in (Issue, Read Operands, Execution, Write Result). -
Functional Unit (FU) Status:
This table records the state of each functional unit, including:- Busy: Indicates whether the FU is currently executing an instruction.
- Operation (
): Specifies the operation being performed ( +,-,*, etc.). - Destination Register (
): The target register for the operation result. - Source Registers (
, ): Registers that provide operand values. - Producer Functional Units (
, ): Identifies which functional unit will generate the operand values. - Operand Read Flags (
, ): Flags that indicate whether the source registers have been read (set to NO once read).
-
Register Result Status:
This structure keeps track of which functional unit is responsible for writing to each register. If no pending instructions are set to modify a register, the status remains blank, indicating it is available for new instructions.
Scoreboard Execution Model - Example
