Pipeline-prinsippet

Pipelining deler instruksjonsutføringen i $k$ stadier som kan overlappe. Ideelt sett økes gjennomstrømningen $k$ ganger sammenliknet med enkeltyklusdesign. Klassisk 5-stegs ARM-pipeline:

IF – Instruction Fetch: les instruksjon fra instruksjonscache, oppdater PC
ID – Instruction Decode / Register File Read
EX – Execute: ALU-beregning eller adresseberegning
MEM – Memory Access: les/skriv dataminne
WB – Write Back: skriv til registerfil

CPI-beregning

Ideell CPI for pipelinet prosessor = 1. Faktisk CPI øker pga. hazarder:

$\text{CPI} = 1 + \text{stall-sykluser per instruksjon}$

Ytelse: $\text{Tid} = \text{Instruksjonsantall} \times \text{CPI} \times \text{Klokkperiode}$

Datahazarder (RAW – Read After Write)

Instruksjon $i+1$ trenger et resultat som instruksjon $i$ ikke har skrevet til registerfil ennå. Løsninger:

Forwarding (bypassing): Rut resultatet direkte fra EX/MEM-stadiet tilbake til EX-stadiet uten å vente på WB. Eliminerer de fleste RAW-hazarder.
Stall (pipeline-boble): Sett inn NOP-sykler. Nødvendig for load-use-hazarder (én syklus stall) fordi data ikke er tilgjengelig før etter MEM-stadiet.

Kontrollhazarder (branch hazarder)

Oppstår ved betingede hopp (BEQ, BNE) fordi neste instruksjon hentes før forgreningsutfallet er kjent. Løsninger:

Flush: Forkast de hentede instruksjonene (1–3 tap-sykluser per forgrening).
Branch prediction: Gjett resultatet (f.eks. alltid «ikke-tatt»); flush bare ved feilgjetting.
Branch delay slot: Kompilatoren plasserer en nyttig instruksjon i sloten etter hoppet.

Forwarding-logikk

Hazard-deteksjonsenheten sammenligner destinasjonsregisteret til instruksjon i EX/MEM/WB-stadiet med kilderegistrene til instruksjonen i ID/EX-stadiet. Hvis match og register ikke er $R0$: aktiver forwarding-MUX.

Eksempel: CPI-beregning med hazarder

Et program har 1000 instruksjoner. 20% er load-instruksjoner; 50% av disse etterfølges av en instruksjon som bruker resultatet (load-use hazard → 1 stall-syklus). 15% er forgreninger; ingen branch prediction → 1 flush-syklus per forgrening.

Stall fra load-use: $1000 \times 0{,}20 \times 0{,}50 \times 1 = 100$ stall-sykler.
Stall fra branch: $1000 \times 0{,}15 \times 1 = 150$ flush-sykler.
Total sykler: $1000 + 100 + 150 = 1250$. CPI $= 1250 / 1000 = 1{,}25$.

Eksempel: Registeraktivitet og hazard per klokkesyklus

Den faste pipeline-oppgaven gir en kort kodesekvens og en 5-stegs pipeline UTEN hazard-håndtering, der registerfilen skrives i første halvdel og leses i andre halvdel av en syklus. For hver klokkesyklus skal du angi (a) registeraktivitet og (b) hvilken hazard som oppstår.

I1: ADD R1, R1, R2
I2: LDR R3, [R2, #20]
I3: STR R7, [R1, #24]
I4: SUB R2, R7, R1
I5: ADD R4, R7, R2

Pipeline-skjema (rad = instruksjon, kolonne = syklus): I1 leser registre i ID (syklus 2) og skriver i WB (syklus 5). Registeraktivitet i en gitt syklus = summen av hva instruksjonene i ID (les) og WB (skriv) gjør.

Syklus 3: I3 (STR) er i ID og leser registre; ingen instruksjon i WB ennå → «leser fra registeret».
Syklus 5: I1 er i WB (skriver R1) og I4 er i ID (leser R7, R1) → «leser fra og skriver til registeret».

Datahazard markeres der en instruksjon i ID trenger et register som en tidligere instruksjon ennå ikke har skrevet tilbake. I3 og I4 leser R1 som I1 skriver – siden write skjer i første halvdel av WB-syklusen og read i andre halvdel, er R1 trygt fra og med I1s WB-syklus; instruksjoner som leser R1 før dette har datahazard.

Studieguide: Pipelining

Studieguide: Pipelining