Lec 4 · Pipelining 기초: 5-stage pipeline 과 hazard

1.1single-cycle datapath 에서 RISC-V R·I·B·J type 명령어의 실행 경로를 복습하고, LD 의 600 ps critical path 로 한계를 보임.

1.2multi-cycle·microcoded CPU 를 거쳐 5-stage pipeline(200 ps 단계, 5 GHz)과 iron law 로 CPI·cycle time trade-off 를 비교.

1.3structural·data(RAW/WAR/WAW)·control hazard 와 해결책(hardware 추가, interlock, bypass, speculation, kill/bubble)을 다룸.

1.4branch delay slot 이 1990년 이후 사라진 이유와 5-stage 에서도 CPI > 1 인 이유로 마무리. exception(slide 42~58)은 05강으로 넘어감.

상황·문제학부 CPU 설계 복습으로 pipelining 기초를 다룸. 명령어 처리는 IF·ID·EX·MEM·WB 5단계.

원인각 단계는 PC·instruction memory(I-cache)·register file·ALU·data memory(D-cache) 에서 수행되고, control logic 이 명령어를 보고 control signal 을 생성.

해결이 datapath 는 single-cycle CPU: 5단계를 한 cycle 에 모두 수행.

상황·문제명령어 유형마다 datapath 에서 사용하는 component 와 경로가 다름.

원인R-type: 두 register → ALU → register. LD(I-type): base + sign-extended imm 으로 주소 계산 후 memory read. BEQ(B-type): ALU 로 비교, PC+imm 을 target 으로. JAL(J-type): PC+imm 으로 무조건 jump, PC+4 를 rd 에 저장.

해결모든 유형이 명령어 크기 4 byte 가정으로 PC+4 를 계산. rd=x0 이면 return 주소 저장을 버릴 수 있음(x0 은 항상 0).

상황·문제single-cycle CPU 는 모든 명령어를 한 cycle 에 맞춰야 해서 clock cycle 이 길어짐.

원인LD 가 모든 단계를 거치는 worst-case critical path: memory 200 + RF 50 + ALU 100 + memory 200 + RF 50 = 600 ps. R-type 등은 그보다 짧은데도 같은 시간을 씀.

해결multi-cycle CPU 로 명령어별 필요한 단계만 수행. ALU 하나를 여러 cycle 재사용하고, ROM 의 microcode 가 micro PC 로 단계별 control signal 을 생성.

상황·문제multi-cycle 보다 더 나은 성능을 위해 pipelined CPU 를 설계.

원인빨래 예: 세탁기가 끝나면 건조 중에 다음 빨래를 세탁 → 단계를 overlap. datapath 를 5단계로 나누고 clock 은 가장 긴 단계(200 ps)로 결정 → 5 GHz.

해결iron law: time = instructions/program × CPI × time/cycle. multi-cycle 은 cycle time 을 줄이지만 CPI 증가, pipeline 은 짧은 cycle time 과 이상적 CPI=1 을 동시에 얻음.

상황·문제실제 program 에서 CPI=1 달성은 거의 불가능.

원인structural hazard(자원 부족), data hazard(앞 명령어 결과에 의존), control hazard(다음 PC 를 모름)가 있음.

해결기본 처리법은 bubble 삽입. bubble 1개면 3 명령어에 4 cycle → CPI 1.33, 2개면 1.67.

상황·문제두 명령어가 같은 hardware 자원을 동시에 필요로 할 때 발생.

원인classic 5-stage 정수 pipeline 은 단계마다 한 명령어만 자원을 쓰므로 설계상 없음. 그러나 multiplier·divider·FP unit·register write-back port 를 공유하는 구현에서는 발생.

해결hardware 추가(예: memory 에 두 번째 port) 또는 새 명령어 stall. 4-wide datapath 에 multiplier 4개는 비싸므로 성능-비용 trade-off.

상황·문제뒤 명령어가 앞 명령어의 결과 register 를 operand 로 쓰면 의존성이 생김.

원인RAW(true dependence), WAR(anti-dependence), WAW(output dependence). WAR·WAW 는 in-order CPU 에서는 순서상 문제 없음.

해결out-of-order core 에서는 실행 순서가 바뀌므로 WAR·WAW 도 처리해야 program semantics 보존. read-after-read 는 hazard 아님.

상황·문제RAW 의존 명령어는 앞 명령어의 결과가 register file 에 쓰이기 전에는 값을 읽을 수 없음.

원인interlock 만 쓰면 add x1 → sub x2,x1 사이에 bubble 3개. decode 단계에서 source register 와 앞선 명령어의 destination 을 비교해 hazard 검출.

해결bypass(data forwarding): ALU·memory 출력을 mux 로 ALU 입력에 전달해 bubble 제거. value speculation 은 branch prediction·stack pointer update·memory address disambiguation 등 제한된 경우에만 효과적.

상황·문제IF 는 다음 PC 가 필요하지만, 그 PC 를 결정할 정보는 앞 명령어가 몇 단계 지나야 나옴.

원인opcode·offset 은 decode 에서, branch 조건과 jump register 값은 execute 에서 알 수 있음. PC+4 로 가져온 다음 명령어가 틀릴 수 있음.

해결unconditional PC-relative jump 는 decode 단계 adder 로 target 계산, FKill 신호로 방금 fetch 한 명령어를 bubble 로 바꿈 → bubble 1개.

상황·문제초기 MIPS 는 jump 뒤 bubble 을 없애려고 ISA semantics 를 바꿈: branch/jump 다음 명령어는 항상 실행.

원인software 가 delay slot 을 유용한 명령어로 채워야 하고, 못 찾으면 NOP. MIPS = Microprocessor without Interlocked Pipeline Stages.

해결1990년 이후 RISC ISA 는 delay slot 없음: microarchitecture 세부를 ISA 에 넣고, 30-stage·4-issue(최대 120 명령어) 에서는 무의미, NOP 이 I-cache 를 낭비. 좋은 branch predictor 가 필요성을 줄임.

상황·문제conditional branch 는 조건이 ALU(EX) 에서 나오므로 jump 보다 늦게 결정됨.

원인EX 단계에 도달할 때 이미 잘못된 경로에서 명령어 2개를 fetch 함.

해결FKill·DKill 로 두 명령어를 죽여 bubble 2개. jump register 도 register 값이 필요해 bubble 2개.

상황·문제bypass 가 있어도 모든 bubble 을 없앨 수는 없음.

원인branch predictor 도 항상 맞지 않음. full bypass 는 deep pipeline·superscalar 에서 비용이 너무 큼. load 결과는 바로 다음 명령어의 EX 에 전달 불가.

해결자주 쓰는 bypass 경로만 제공하고 area 는 cache 등에 사용. load-use 에는 bubble 1개. MIPS-I 의 load delay slot(slot 명령어는 load 이전 값을 봄)은 MIPS-II 에서 제거됨.

상황·문제exception 부분(slide 42~) 은 시작하지 못하고 종료. project proposal guideline 을 PLMS 에 올릴 예정, 다음 주는 추석이라 그다음 주에 수업.

clock cycle 을 결정하는 최장 latency 경로. single-cycle 에서는 LD 의 600 ps.

ROM 에 저장된 단계별 control signal row. micro PC 로 순서 제어.

time = instructions/program × CPI × time/cycle.

hazard 해소를 위해 비워 두는 slot. bubble 1개/3 명령어면 CPI 1.33.

같은 hardware 자원을 동시에 요구. hardware 추가 또는 stall.

true / anti / output dependence. in-order 에서는 RAW 만 문제.

hazard 가 풀릴 때까지 의존 명령어를 issue 단계에 대기시킴.

결과를 register file 대신 mux 경로로 다음 명령어 ALU 입력에 전달.

다음 PC 결정 정보가 decode·execute 에서야 나와 잘못 fetch 한 명령어를 kill.

branch/jump 다음 명령어를 항상 실행하는 ISA semantics. 1990년 이후 RISC 에서 폐기.

load 결과는 다음 명령어 EX 에 바로 전달 불가 → bubble 1개.

4.1single-cycle CPU 에서 clock cycle 을 결정하는 명령어와 그 latency 는?

4.25-stage pipeline 의 이상적 CPI 가 5 가 아닌 이유는?

4.3in-order 5-stage 에서 WAR·WAW 가 문제가 되지 않는 이유는?

4.4add x1 → sub x2,x1 에서 interlock 만 쓸 때와 bypass 를 쓸 때 bubble 수는?

4.5conditional branch 와 unconditional jump 의 bubble 수가 다른 이유는?

4.6branch delay slot 이 현대 ISA 에서 사라진 이유 2가지는?