1Learning Outcomes¶
Identify the three types of hazards encountered in the RISC-V pipeline.
Explain why the hardware requirements of the RISC-V pipeline do not cause structural hazards.
🎥 Lecture Video
One of the costs of pipelining is that it introduces pipeline hazards. A pipeline hazard, or simply hazard, is a situation in which a planned instruction cannot execute in the “proper” clock cycle. In other words, a hazard is when executing a combination of instructions would be impossible or would lead to incorrect program execution.
2Introduction to Hazards¶
There are three types of hazards:
Structural hazard: The hardware in the processor cannot support the combination of instructions that we want to execute in the same clock cycle.
Data hazard: Instructions have data dependencies, and some instructions must wait for previous instructions to complete—otherwise outdated values would be used in computation.
Control hazard: The flow of execution depends on previous instructions. The wrong instructions are executed.
In this unit, we describe each type of hazard and resolve hazards through various solutions in hardware, during execution time, or in the program code:
Stalling is one inefficient solution to resolving any type of hazard, where we delay instructions until we can execute them without incurring hazards. Because performance suffers with stalling, we will discuss ways to avoid stalling where possible (though it is always a good last resort). See this section.
Specify hardware requirements, i.e., on specific hardware units within the pipeline.
Forwarding, also known as bypassing, is when we wire more connections in the datapath and instead use results when computed. See this section.
Code scheduling, where we rearrange instructions at compile-time to avoid hazards.
In practice, computers use a combination of the above techniques to maximize throughput and maintain the benefits of instruction-level parallelism that pipelining provides.
3Structural Hazards¶
From earlier:
Structural hazard: The hardware in the processor cannot support the combination of instructions that we want to execute in the same clock cycle.
From P&H 4.6:
A structural hazard in the laundry room would occur if we used a washer-dryer combination instead of a separate washer dryer. Our carefully scheduled pipeline plans would be foiled.
The RISC-V instruction set was designed to be pipelined, making it fairly easy for designers to avoid structural hazards when designing a pipeline.
In other words, in our current five-stage processor, structural hazards are not an issue unless changes are made to the pipeline. The structural hazards that could exist are prevented by RV32I’s hardware requirements.
Suppose we had the following five instructions simultaneously executing in our five-stage pipeline as in Figure 1.
Figure 1:The five instructions inst1, inst2, inst3, inst4, inst5 are executing in order and occupying all five stages of our pipeline in the same clock cycle.
If we changed the major hardware components of our pipeline, how might these changes result in structural hazards?
3.1RegFile¶
The register file (RegFile) used in our processor supports simultaneous read and write by two different instructions.
In Figure 1, the register file is accessed simultaneously by inst4 in the ID stage (to read two registers), and inst1 in the WB stage (to write to a register). The RV32I RegFile design in Figure 2 means that inst1 and inst4 can simultaneously perform write and read, respectively, to the RegFile without causing a structural hazard.
By contrast, the alternate RegFile design in Figure 3 can cause structural hazards. RegWEn specifies if the RegFile will be used for reading or writing in this cycle, and the port rs specifies the 5-bit-wide register value to use for either reading or writing. However, this RegFile design does not support simultaneous read/write, and therefore trying to execute inst1 and inst4 in the same cycle will cause a structural hazard.
3.2Memory¶
The instruction memory (IMEM) and data memory (DMEM) used in our processor are separate hardware elements.
Figure 4:RV32I IMEM and DMEM are two separate hardware units.
In Figure 1, memory is accessed by inst5 in the IF stage (to read an instruction from IMEM) and inst2 in the MEM stage (to read data from DMEM). The separate IMEM and DMEM in Figure 4 do not cause a structural hazard, because inst5 and inst2 can simultaneously access memory.
By contrast, if we used a single memory block called that could only support one read/write at a time (to any part of memory—instruction or data), then inst5 and inst2 attempting to access memory in the same cycle would cause a structural hazard.
We will discuss this later, but under the hood, IMEM and DMEM are actually caches of main memory, as shown in Figure 5. This design allows them to be much closer to the processor to keep memory access fast.
Figure 5:Processor and Memory diagram of separate IMEM/DMEM in memory.