Lec 7 part2 · Lec 8 · pipelined control 과 data hazard·stall

1.1전반부(Lec7 part2): pipeline register 내용, write register ID 를 WB 까지 전달하는 수정, pipeline 표현 세 가지, pipelined control 전달 방식.

1.2후반부(Lec8): data dependence RAW·WAR·WAW, in-order pipeline 에서는 RAW 만 hazard (ISA 의 순차·atomic semantics 와 pipeline 겹침의 불일치).

1.3RAW hazard 조건 dist(I_OLD, I_YOUNG) ≤ dist(ID, WB) = 3, memory data hazard 는 없음.

1.4해결책 pipeline stall: upstream 정지·downstream drain, PC·IR latch 비활성, bubble 의 RegWrite·MemWrite = 0, stall condition 식(use_rs 의 x0 제외).

상황·문제campus 대상 virus attack 으로 Zoom 이 끊길 수 있어 연구실에서 강의, 녹화본은 PLMS 에 올린다고 안내.

상황·문제single-cycle CPU 를 IF·ID·EX·MEM·WB 5 stage 로 나누고 stage 사이에 pipeline register(IF/ID, ID/EX, EX/MEM, MEM/WB)를 둔다.

원인다음 stage 가 쓸 값은 모두 pipeline register 로 넘겨야 한다.

해결IF/ID: PC, IR / ID/EX: A, B, imm, PC / EX/MEM: ALUOut, B, next PC / MEM/WB: memory data, ALUOut. LD 를 stage 별로 따라가며 확인.

상황·문제LD 의 WB 에서 register file 의 write register ID 가 IF/ID 의 instruction(다른, 더 젊은 instruction)에서 온다.

원인rd 를 decode 시점에 바로 쓰면 WB 시점에는 이미 다른 instruction 의 필드가 된다.

해결destination register ID 를 ID stage 에서 pipeline register 에 넣어 WB 까지 전달한 뒤 register file 에 준다.

상황·문제lw 뒤 sub 가 한 cycle 씩 겹쳐 진행되는 clock 1~6 예를 본 뒤, pipeline 동작을 나타내는 diagram 을 소개.

해결graphical view(x=clock cycle, y=program 순서), 단순화된 stage 이름 표, resource view(y=stage, 칸에 instruction)를 이후 hazard 설명에 사용.

상황·문제control signal 은 single-cycle 과 같지만, ID 에서 만든 값이 EX·MEM·WB 등 각기 다른 stage·cycle 에 쓰인다.

원인생성 시점과 사용 시점이 달라 제때 해당 stage 에 전달해야 한다.

해결(1) ID 에서 한 번 decode 해 EX·M·WB control 을 pipeline register 로 전달, 또는 (2) instruction(필요한 field 만)을 전달해 stage 별 local decode. cost 가 낮은 쪽 선택.

상황·문제이상적 pipeline 조건(동일 연산, 균일 sub-operation, 독립 연산)이 instruction pipelining 에선 성립하지 않는다.

원인instruction 마다 하는 일이 다르고, memory read 와 addition 의 시간이 다르며, instruction 사이 dependence 가 있다.

해결instruction type 을 묶어 모든 stage 를 multi-function 으로, stage latency 를 균형 있게, dependence 는 검출·해결 (오늘의 주제).

상황·문제출석 확인 후 한국어로 보충: instruction type 을 묶는 것은 pipeline 구현 복잡도를 줄이려는 ISA 설계이며, stage 마다 일의 양이 달라도 clock cycle 은 같아 가장 긴 stage 에 맞춘다.

상황·문제Lec8(Pipelined CPU – Data Hazard) 시작. pipeline 안의 instruction 들 사이에 dependence 가 있다.

원인RAW(true dependence): 뒤 instruction 이 앞 instruction 이 쓴 r3 를 읽음. WAR(anti), WAW(output) 는 같은 register ID 를 쓰는 것뿐 true dependence 아님.

해결RAW 가 오늘 주제: 뒤 instruction 의 ID(register read)가 앞 instruction 의 WB 보다 먼저 올 수 있다. WAR·WAW 는 out-of-order 실행에서만 문제.

상황·문제addi 가 ra 에 쓰고 뒤따르는 addi 들이 ra 를 읽는 예: 첫 instruction 의 WB 는 t4 인데 둘째는 t2 에 읽어 옛 값을 얻는다.

원인ISA 는 instruction 이 순차적·atomic 하게 실행된다고 정의하지만, pipeline 은 sub-operation 을 겹쳐 실행해 순서가 보존되지 않는다.

해결뒤 3개(2~4번째)만 문제, 5번째부터는 WB 이후 읽으므로 안전. architecture 와 microarchitecture 의 불일치가 hazard 의 원인.

상황·문제instruction type 별로 register read(ID)·write(WB) 가 언제 일어나는지 표로 정리하고, hazard 발생 조건을 찾는다.

원인dependence type, 관련 instruction type, instruction 사이 거리가 hazard 여부를 결정한다.

해결I_YOUNG(R/I, LD, SD, Bxx, JALR)이 I_OLD(R/I, LD, JAL, JALR)가 쓰는 register 를 읽고 dist(I_OLD, I_YOUNG) ≤ dist(ID, WB) = 3 이면 RAW hazard.

상황·문제load·store 사이에 memory 를 통한 hazard 가 생길 수 있는지 질문.

원인memory read·write 가 모두 같은 MEM stage 에서 일어나 stage 거리가 0.

해결현재 pipeline 에서는 memory data hazard 불가능.

상황·문제dist(i,j)=1, dist(ID,WB)=3 인 예: j 는 t3 에 register 를 읽지만 i 의 WB 는 t5.

원인i 의 WB 전에 j 가 ID 를 하면 옛 값을 읽는다.

해결j 의 ID 를 늦추며 bubble 을 넣어 dist 를 4 로 만들면(bubble 3개) WB 이후 최신 값을 읽는다. 앞선 instruction 은 계속 진행.

상황·문제stall 을 실제 hardware control 로 어떻게 구현하나.

원인bubble 이 만드는 쓰레기 값이 architectural state(memory, register file)를 바꾸면 안 된다.

해결IF·ID(upstream)는 PC·IR latching 을 끄고, EX·MEM·WB(downstream)는 계속 진행(drain). bubble 의 RegWrite·MemWrite 를 0 으로 넣어 pipeline register 로 전달.

상황·문제의존 없는 더 젊은 instruction 을 먼저 실행하면? → 그것이 out-of-order execution, 이후 간단히 다룸. drain 은 막힌 지점 뒤(downstream)의 물이 계속 흘러 나가는 것.

해결IR·PC register 의 enable 을 막아 j·k 를 유지하고, bubble 의 write enable 을 0 으로 두면 control signal pipeline 이 알아서 전달한다고 한국어로 재설명.

상황·문제ID 의 I_YOUNG 이 EX·MEM·WB 에 있을 수 있는 I_OLD 가 쓸 register 를 읽으려 하면 ID 에서 stall 해야 한다.

원인rs1·rs2 각각이 EX·MEM·WB stage 의 rd 와 같고 그 stage 가 RegWrite 이면 RAW hazard.

해결stall = OR of (rs{1,2}_ID == rd_{EX,MEM,WB}) && use_rs{1,2}(IR_ID) && RegWrite_{EX,MEM,WB}. use_rs1(I) 는 rs1 을 쓰고 rs1 != x0 일 때 참 (x0 는 항상 0).

IF/ID, ID/EX, EX/MEM, MEM/WB. 다음 stage 에 필요한 data·control·rd 를 보관.

ID 에서 decode 한 EX·M·WB control 을 pipeline register 로 전달하거나 instruction field 를 넘겨 stage 별 decode.

뒤 instruction 이 앞 instruction 이 쓴 register 를 읽음. in-order pipeline 에서 hazard 를 만든다.

같은 register ID 를 써서 생기는 dependence. out-of-order 실행에서만 문제.

I_YOUNG 이 I_OLD 가 쓰는 register 를 읽고 dist(I_OLD, I_YOUNG) ≤ dist(ID, WB) = 3.

hazard 가 사라질 때까지 뒤 instruction 을 멈추고 빈 slot(bubble)을 흘림.

stall 중 downstream(EX·MEM·WB) instruction 은 계속 진행해 pipeline 을 빠져나감.

(rs_ID == rd_EX/MEM/WB) && use_rs(IR_ID) && RegWrite_EX/MEM/WB 를 rs1·rs2 에 대해 OR. use_rs 는 x0 제외.

4.1LD 의 WB 에서 write register ID 를 IF/ID 의 instruction 에서 가져오면 왜 틀리나?

4.2WAR·WAW dependence 가 5-stage in-order pipeline 에서 문제가 안 되는 이유는?

4.3dist(i,j)=1 인 RAW hazard 에서 bubble 은 몇 개 필요한가?

4.4memory data hazard 가 이 pipeline 에서 생기지 않는 이유는?

4.5stall 시 bubble 이 architectural state 를 바꾸지 않게 하려면?

4.6use_rs1(I) 가 rs1 != x0 를 확인하는 이유는?