Hazards in Computer Architecture

Hazards in Computer Architecture – In normal procedure, when an instruction is available in the pipeline, it gets executed in various stages. But if an instruction is available and can not be executed for any reason, a hazard exists for that instruction. There are three types of hazards, as follows.

1. Structural Hazard
2. Data Hazard
3. Control Hazard.

Structural Hazard

A structural hazard occurs when a part of the processor’s hardware is needed by two or more instructions at the same time. For example, suppose in a system a single memory unit is used instead of separate instruction and data memories. A sequential (non-pipelined) implementation would work equally well with either approach, but in a pipelined implementation, it creats a trouble. If an instruction is fetching the data and another instruction is also reading or writing its data at the same time, a structural hazard occurs.

This type of hazard occurs when two activities require the same resources simultaneously.

1. Some functional units are not fully pipelined, so a sequence of instructions using a non-pipelined unit can not proceed at the rate of one per clock cycle.
2. Some resources have not been duplicated enough to allow all combinations of instructions in the pipeline to execute.

Example: If a system has shared a single-memory pipeline for data and instructions. As a result, when an instruction contains a data memory reference load memory (LD), it will conflict with the instruction reference instruction fetch (IF) for later instructions. This is shown in the table below.

Instruction	Clock Cycle 1	Clock Cycle 2	Clock Cycle 3	Clock Cycle 4	Clock Cycle 5	Clock Cycle 6	Clock Cycle 7	Clock Cycle 8	Clock Cycle 9	Clock Cycle 10
1	IF	ID	EX	(LD)	ST
2		IF	ID	EX	LD	ST
3			IF	ID	EX	LD	ST
4				(IF)	ID	EX	LD	ST

To resolve this problem, the pipeline is stalled (waits) for one clock cycle when a data-memory access occurs. The effect of the stall is actually to occupy the resource for that instruction slot. The table below shows how the stalls (SL) are actually implemented. However, the introduction of a stall reduces the performance of the system.

Instruction	Clock Cycle 1	Clock Cycle 2	Clock Cycle 3	Clock Cycle 4	Clock Cycle 5	Clock Cycle 6	Clock Cycle 7	Clock Cycle 8	Clock Cycle 9	Clock Cycle 10
1	IF	ID	EX	LD	ST
2		IF	ID	EX	LD	ST
3			IF	ID	EX	LD	ST
4				(SL)	IF	ID	EX	LD	ST

Data Hazard

Data hazards occur when the pipeline changes the order of read/write access to operands so that the order differs from the order seen by sequentially executing instructions on a non-pipelined system. Data hazards are also known as data dependency.

Data dependency is the condition in which the outcome of the current operation is dependent on the outcome of a previous instruction that has yet not been executed to completion because of the effect of the pipeline. Data hazards arise because of the need to preserve the order of the execution of instructions.

The following example shows the data hazards

Add R2, R1, R0 [R2] ← [R1]+[R0]
               ↗
Sub R1, R3, R4 [R1] ← [R3]-[R4]

Data hazards are classified into three types:

1. RAW (Read After Write)
2. WAW (Write After Write)
3. WAR (Write After Read)

RAW (Read After Write)

A Read After Write hazard occurs when, in the code as written, one instruction reads a location after an earlier instruction writes new data to it, but in the pipeline, the write occurs after the read. So the instruction doing the read operation gets the state data. It is also known as true data dependency.

The following example shows the possible RAW hazard.

Add t1, A, B
               ↘
Sub t2, t1, C

Internal forwarding can be a solution for such types of problems.

WAW (Write After Write)

A Write After Write hazard is a situation in which two writes occur out of order. Normally, it is considered that the WAW hazard is present only in pipelines that write in more than one pipe stage or allow an instruction to proceed even when a previous instruction is stalled.

The following example shows the possible WAW hazard.

Add t1, A, B
             ↓
Sub t1, C, D

The WAW hazards can be avoided by doing following changes in the pipeline:

1. Move write back for an ALU operation into the LD stage, since the data value is available by then.
2. By assuming that the data memory access takes place in two pipeline stages.

WAR (Write After Read)

A Write After Read hazard is the reverse of RAW. This hazard occurs when a write operation oles read operation. The following example shows the possible WAR hazard

Add R1, R2, R3
               ↙
Sub R2, R4, R5

The WAR hazard can be avoided by internal forwarding and by modifying the pipeline architecture such that consecutive Write and Read occur after a few cycles.

Control Hazard

The control hazard occurs when a decision needs to be made, but the information needed to make the decision is not available. A control hazard is actually the same thing as a RAW hazard, but is considered separately because different techniques can be employed to resolve it.

The control hazards result when a new location in the program is branched. This invalidates everything that is loaded in the pipeline. The control hazards can be handled if the pipeline waits until the branch target is known.

The simplest method of dealing with branches is to stall (wait) the pipeline as soon as the branch is detected until the execution reaches the load (LD) stage, which determines the new content of the program counter. The pipeline behavior looks as shown in the table below.

Branch	IF	ID	EX	LD	ST
Branch Successor		IF (Stall)	Stall	Stall	IF	ID	EX	LD	ST
Branch Successor + 1						IF	ID	EX	LD	ST

The stall does not occur until after the ID stage, where it is known that the instruction is a branch.

Related Questions and Answers