Pipeline stalls and hazards in ARM Architecture - Step-by-Step Execution

Concept Flow - Pipeline stalls and hazards

Instruction Fetch

↓

Instruction Decode

↓

Execute

↓

Memory Access

↓

Write Back

↓

Check for Hazards

↓

No Hazard

↓

Continue

↓

Next Instruction

Instructions flow through pipeline stages; hazards cause stalls or flushes to keep correct execution.

Execution Sample

ARM Architecture

Cycle 1: Fetch Instr1
Cycle 2: Decode Instr1, Fetch Instr2
Cycle 3: Execute Instr1, Decode Instr2, Fetch Instr3
Cycle 4: Data hazard detected, stall pipeline
Cycle 5: Resume after stall

Shows how instructions move through pipeline stages and how a stall occurs due to a hazard.

Analysis Table

Cycle	Stage	Instruction	Hazard Detected?	Action	Pipeline State
1	Fetch	Instr1	No	Fetch Instr1	Instr1 in IF
2	Decode	Instr1	No	Decode Instr1; Fetch Instr2	Instr1 in ID; Instr2 in IF
3	Execute	Instr1	No	Execute Instr1; Decode Instr2; Fetch Instr3	Instr1 in EX; Instr2 in ID; Instr3 in IF
4	Decode	Instr2	Yes (Data Hazard)	Stall pipeline; Hold Instr2 in ID	Instr1 in MEM; Instr2 stalled in ID; Instr3 fetch paused
5	Execute	Instr2	No	Resume pipeline; Execute Instr2; Fetch Instr4	Instr1 in WB; Instr2 in EX; Instr3 in ID; Instr4 in IF
6	Memory	Instr2	No	Continue normal flow	Instr2 in MEM; Instr3 in EX; Instr4 in ID; Instr5 in IF
7	Write Back	Instr2	No	Complete Instr2; Continue	Instr2 in WB; Instr3 in MEM; Instr4 in EX; Instr5 in ID
8	Fetch	Instr6	No	Continue fetching	Pipeline full, no stalls
9	Fetch	-	No	No more instructions	Pipeline drains
10	-	-	No	Pipeline empty	Execution complete

💡 Pipeline drains after last instruction; no more instructions to fetch.

State Tracker

Variable	Start	After Cycle 1	After Cycle 2	After Cycle 3	After Cycle 4	After Cycle 5	Final
Instr1 Stage	None	IF	ID	EX	MEM	WB	Completed
Instr2 Stage	None	None	IF	ID	ID (Stall)	EX	Completed
Instr3 Stage	None	None	None	IF	ID (Paused)	ID	Completed
Pipeline Stall	No	No	No	No	Yes	No	No

Key Insights - 3 Insights

Why does the pipeline stall at cycle 4?

At cycle 4, a data hazard is detected because Instr2 depends on the result of Instr1 which is not yet available. The pipeline stalls to wait for the data, as shown in execution_table row 4.

What happens to instructions fetched after the stall?

Instructions fetched after the stall (like Instr3) are paused or held in earlier stages until the hazard clears, preventing incorrect execution. See execution_table rows 4 and 5.

How does the pipeline recover after a stall?

After the hazard is resolved, the pipeline resumes normal flow, advancing instructions through stages without stalls, as shown from cycle 5 onward in the execution_table.

Visual Quiz - 3 Questions

Look at the execution_table at cycle 4. What is the pipeline action taken?

A Stall pipeline and hold instruction in Decode stage

B Flush the pipeline and restart

C Continue fetching new instructions

D Skip the instruction causing hazard

💡 Hint

Check the 'Action' and 'Hazard Detected?' columns at cycle 4 in execution_table.

At which cycle does Instr2 move from Decode to Execute stage after the stall?

A Cycle 3

B Cycle 5

C Cycle 4

D Cycle 6

💡 Hint

Look at the 'Instruction' and 'Stage' columns for Instr2 in execution_table rows for cycles 4 and 5.

If the data hazard at cycle 4 was not detected, what would likely happen?

A Pipeline would stall anyway

B Pipeline would flush and restart

C Incorrect data would be used causing errors

D No effect, execution continues correctly

💡 Hint

Consider the purpose of stalls shown in execution_table and variable_tracker to prevent hazards.

Concept Snapshot

Pipeline stages: Fetch -> Decode -> Execute -> Memory -> Write Back
Hazards: Data hazards cause stalls; Control hazards cause flushes
Stalls pause pipeline to wait for data
Flushes clear wrong-path instructions
Goal: Keep pipeline moving correctly without errors

Full Transcript

In a pipelined processor, instructions pass through stages: Fetch, Decode, Execute, Memory, and Write Back. Hazards occur when instructions depend on each other or when control flow changes. Data hazards happen if an instruction needs data not yet ready, causing the pipeline to stall and hold instructions in place. Control hazards occur with branches, causing pipeline flushes to discard wrong instructions. The execution table shows instructions moving through stages each cycle, with a stall at cycle 4 due to a data hazard. The variable tracker shows how instruction stages and pipeline stall status change over time. Understanding these stalls and hazards helps keep the processor running correctly and efficiently.

Practice

1. What is the main reason for a pipeline stall in ARM architecture?

easy

A. The memory is too fast

B. The processor runs out of power

C. An instruction must wait due to a hazard to avoid errors

D. The program has no instructions left

Solution

1. Step 1: Understand what a pipeline stall means

   A pipeline stall occurs when the processor must pause instruction execution to prevent errors.

2. Step 2: Identify the cause of the stall

   Stalls happen because of hazards, which force instructions to wait to keep correct operation.

3. Final Answer:

   An instruction must wait due to a hazard to avoid errors -> Option C

4. Quick Check:

   Pipeline stall = waiting due to hazard [OK]

Hint: Stalls happen when instructions must wait to avoid errors [OK]

Common Mistakes:

• Thinking stalls happen because of power or memory speed
• Confusing stalls with program end
• Assuming stalls are caused by hardware failure

2. Which of the following is the correct term for a hazard that occurs when two instructions need the same hardware resource at the same time?

easy

A. Data hazard

B. Memory hazard

C. Control hazard

D. Structural hazard

Solution

1. Step 1: Recall types of hazards

   Hazards include data, structural, and control hazards.

2. Step 2: Identify hazard by resource conflict

   Structural hazard happens when hardware resources are needed by multiple instructions simultaneously.

3. Final Answer:

   Structural hazard -> Option D

4. Quick Check:

   Resource conflict = Structural hazard [OK]

Hint: Resource conflicts cause structural hazards [OK]

Common Mistakes:

• Mixing data hazard with resource conflicts
• Confusing control hazard with hardware resource issues
• Assuming memory hazard is a standard hazard type

3. Consider this simplified ARM pipeline sequence: Instruction 1 writes to register R1, Instruction 2 reads from R1 immediately after. What happens if there is no hazard management?

medium

A. Instruction 2 reads an old value from R1 causing incorrect results

B. Instruction 2 skips reading R1

C. The processor stalls automatically and waits

D. Instruction 2 reads the correct updated value from R1

Solution

1. Step 1: Understand data hazard in pipeline

   Instruction 2 depends on the result of Instruction 1, which updates R1.

2. Step 2: Effect of no hazard management

   Without hazard management, Instruction 2 reads R1 before Instruction 1 writes the new value, so it reads old data.

3. Final Answer:

   Instruction 2 reads an old value from R1 causing incorrect results -> Option A

4. Quick Check:

   Data hazard without fix = wrong read [OK]

Hint: Without hazard fix, dependent reads get old data [OK]

Common Mistakes:

• Assuming processor stalls automatically without hazard logic
• Thinking Instruction 2 skips reading register
• Believing Instruction 2 always reads updated value

4. In an ARM pipeline, a control hazard occurs due to a branch instruction. Which fix helps reduce stalls caused by this hazard?

medium

A. Using branch prediction to guess the next instruction

B. Increasing the clock speed

C. Adding more registers

D. Disabling the pipeline

Solution

1. Step 1: Identify control hazard cause

   Control hazards happen when the pipeline must decide which instruction to execute after a branch.

2. Step 2: Understand branch prediction role

   Branch prediction guesses the next instruction to reduce waiting and stalls.

3. Final Answer:

   Using branch prediction to guess the next instruction -> Option A

4. Quick Check:

   Branch prediction reduces control stalls [OK]

Hint: Branch prediction reduces control hazard stalls [OK]

Common Mistakes:

• Thinking clock speed fixes hazards
• Believing more registers solve control hazards
• Assuming disabling pipeline is a solution

5. You have a sequence of instructions where Instruction A writes to register R2, Instruction B reads R2, and Instruction C is a branch depending on R2. How can pipeline stalls be minimized in this scenario?

hard

A. Insert NOPs (no operation) between all instructions

B. Use forwarding to pass data directly and branch prediction for the branch

C. Disable branch instructions to avoid control hazards

D. Increase pipeline stages to slow down execution

Solution

1. Step 1: Identify hazards in instruction sequence

   Instruction B reading R2 after A causes a data hazard; Instruction C branch depending on R2 causes a control hazard.

2. Step 2: Apply techniques to reduce stalls

   Forwarding passes updated data directly to dependent instructions, and branch prediction guesses branch outcome to reduce stalls.

3. Final Answer:

   Use forwarding to pass data directly and branch prediction for the branch -> Option B

4. Quick Check:

   Forwarding + branch prediction minimize stalls [OK]

Hint: Forwarding and branch prediction reduce stalls best [OK]

Common Mistakes:

• Inserting too many NOPs causing slow execution
• Disabling branches which breaks program logic
• Increasing pipeline stages without hazard fixes