NMOS/PMOS 구조부터 차단 · 선형 · 포화 영역과 핀치오프까지

1. MOSFET의 구조

MOSFET = Metal–Oxide–Semiconductor Field Effect Transistor. 금속(요즘은 폴리실리콘) 게이트가 산화막을 사이에 두고 반도체 위에 얹혀 있는 구조.

NMOS 단면도

꼭 챙겨야 할 두 가지

① 단자는 4개다. G, S, D 말고 바디(B, bulk/substrate) 가 있다. 수업에서 보통 생략하는데, NMOS는 바디를 GND에, PMOS는 VDD에 묶어두기 때문에 안 그려도 되는 것뿐이다. 바디 전압이 소스와 달라지면 Vt가 변한다 (body effect, → 10장).

② 게이트는 채널과 전기적으로 완전히 절연되어 있다. 산화막(SiO₂)이 사이에 있으므로 DC에서 게이트 전류 = 0. 이것이 BJT 대비 MOSFET의 결정적 장점이고, 게이트는 사실상 커패시터로 동작한다.

게이트–채널 사이의 단위면적당 커패시턴스:

$$C_{ox} = \frac{\varepsilon_{ox}}{t_{ox}}$$

• $\varepsilon_{ox}$ : 산화막 유전율
• $t_{ox}$ : 산화막 두께 (얇을수록 $C_{ox}$ ↑ → 구동력 ↑)

2. 소스와 드레인은 어떻게 구분하나

구조적으로 두 n+ 영역은 완전히 대칭이다. 어느 쪽이 소스인지는 공정이 아니라 전압이 결정한다.

기준은 "캐리어가 나오는 쪽(source)".

자주 나오는 함정

$$V_{gs} = V_g - V_s = V_g$$

이 단순화는 소스가 GND(0 V)에 물려 있을 때만 성립한다.

• CMOS pull-down network의 맨 아래 트랜지스터 → 소스가 GND → 성립
• NAND 게이트에서 위에 쌓인 NMOS → 소스가 떠 있음 → $V_s \neq 0$ → 성립 안 함

3. $$V_{gs}$$가 하는 일 — 채널 만들기

게이트에 전압을 걸면 p형 기판 표면이 세 단계로 변한다. 이것이 문턱 전압 $V_t$의 정체다.

(a) $$V_{gs}$$ < 0 — 축적 (accumulation)

게이트가 음전하 → p형의 다수 캐리어인 정공이 표면으로 끌려옴 → 표면이 더 강한 p형.

결과: n+ / p / p+표면 / n+ 구조 = back-to-back PN 접합. 어느 방향으로 전압을 걸어도 둘 중 하나는 역바이어스.

→ I = 0

(b) 0 < $$V_{gs}$$ < c — 공핍 (depletion)

게이트 양전하가 정공을 밀어냄 → 표면에 공핍층 형성 (움직이지 않는 acceptor 음이온만 남음).

아직 전자가 없어서 여전히 채널이 없다.

→ I ≈ 0

(c) $$V_{gs}$$ > $$V_t$$ — 반전 (inversion)

게이트 전압을 더 올리면 소수 캐리어인 전자가 표면으로 끌려와 모인다. 표면이 p형에서 n형으로 반전(inverted).

이제 n+ 소스 — n채널 — n+ 드레인이 하나로 연결된다.

→ 전류 통로 생성

$V_t$의 엄밀한 정의 표면의 전자 농도가 기판의 정공 농도와 같아지는 순간 (strong inversion, $\psi_s = 2\phi_F$). 최신 공정: $V_{t0} \approx 0.3 \sim 0.5\ \mathrm{V}$ 교과서 예제: $0.5 \sim 0.7\ \mathrm{V}$

정리

노트에 "Vgs < 0 → Vgs < Vt → I = 0"이라고 쓴 것은 맞다. 다만 조건의 본질은 Vgs < 0이 아니라 Vgs < Vt 다. $V_{gs}$가 양수여도 $V_t$보다 작으면 (b) 상태라 여전히 채널이 없다.

4. Vds가 하는 일 — 캐리어 흘리기

채널이 만들어진 상태에서 $V_{ds} > 0$을 걸면 전자가 소스 → 드레인으로 drift한다. $V_{ds}$ 크기에 따라 채널 모양이 달라지고, 그것이 세 가지 동작 영역이 된다.

세 영역의 채널 모양

왜 드레인 쪽 채널이 얇아지나

핵심 아이디어 하나만 잡으면 다 풀린다.

채널을 유지하는 힘은 그 지점에서의 "게이트 − 채널" 전압차 다.

소스에서 드레인 방향 위치를 $y$, 그 지점의 채널 전위를 $V(y)$라 하면:

채널 전하 밀도:

$$Q(y) = -C_{ox}\big(V_{gs} - V(y) - V_t\big)$$

드레인 쪽으로 갈수록 전하가 줄어들어 채널이 얇아진다 → 삼각형 모양.

선형 영역 (linear / triode / ohmic)

위 전하 분포를 채널 전체에 대해 적분하면:

$$I_{ds} = \mu_n C_{ox}\frac{W}{L}\left[(V_{gs}-V_t)V_{ds} - \frac{V_{ds}^2}{2}\right]$$

$V_{ds} \ll (V_{gs}-V_t)$ 이면 $V_{ds}^2$ 항이 무시되어:

$$I_{ds} \approx \mu_n C_{ox}\frac{W}{L}(V_{gs}-V_t),V_{ds}$$

즉 $I \propto V_{ds}$ → 옴의 법칙을 따르는 저항처럼 보인다.

등가 저항:

$$R_{on} = \frac{1}{\mu_n C_{ox}\dfrac{W}{L}(V_{gs}-V_t)}$$

게이트 전압으로 저항값을 조절하는 전압제어 가변저항인 셈. → Transmission gate, pass transistor가 바로 이 영역을 사용한다.

포화 영역 (saturation) — 핀치오프

드레인 쪽 게이트–채널 전압 $V_{gd} = V_{gs} - V_{ds}$가 계속 줄어들다가, 어느 순간 $V_{gd} = V_t$가 된다. 그 지점에서 채널 전하가 정확히 0 → 핀치오프(pinch-off).

$$V_{gs} - V_{ds} = V_t \quad\Longrightarrow\quad \boxed{V_{ds,sat} = V_{gs} - V_t}$$

이 $V_{gs} - V_t$를 overdrive voltage $V_{ov}$ 또는 $V_{eff}$라고 부른다. 앞으로 계속 나오는 값이니 이름을 외워둘 것.

이 값을 선형 식에 대입하면 포화 전류:

$$I_{ds} = \frac{\mu_n C_{ox}}{2}\frac{W}{L}(V_{gs}-V_t)^2$$

여기에 $V_{ds}$가 없다. → "does not follow Ohm's law"가 이 뜻.

5. I–V 특성 곡선

• 곡선 하나하나가 특정 $V_{gs}$에 대응
• 점선(핀치오프 궤적) 왼쪽 = 선형 영역, 오른쪽 = 포화 영역
• $V_{gs}$가 커질수록 포화 전류가 제곱으로 커진다

6. 핀치오프인데 왜 전류가 0이 아닌가

"채널이 끊겼는데 왜 전류가 흐르지?" — 가장 많이 막히는 지점

(1) 채널이 완전히 끊긴 게 아니다

반전층(strong inversion 수준의 전하)이 사라진 것이지, 그 자리가 절연체가 된 게 아니다. 그 구간은 좁은 공핍 영역이 된다.

(2) 그 공핍 영역에 매우 강한 횡전계가 걸린다

• 소스 ~ 핀치오프 지점: 항상 $V_{ds,sat} = V_{gs}-V_t$ 가 걸림 (고정)
• 초과분 $(V_{ds} - V_{ds,sat})$: 전부 이 좁은 공핍 구간에 몰림
• 폭이 좁으니 전계는 어마어마함

채널을 타고 온 전자가 핀치오프 지점에 도착하면 이 전계에 즉시 쓸려서(swept) 드레인으로 빨려 들어간다.

(3) 전류를 제한하는 건 채널 쪽이다

채널이 공급할 수 있는 만큼만 흐르고, 채널에 걸리는 전압은 $V_{ds}$를 아무리 올려도 $V_{ds,sat}$로 고정.

→ 전류 포화

비유 수도관 끝에서 물이 폭포로 떨어지는 상황. 폭포 높이($V_{ds}$)를 아무리 높여도 관을 통과하는 유량은 관이 정하지, 낙차가 정하지 않는다.

실제로는 완전히 평평하지 않다 — Channel Length Modulation

$V_{ds}$를 더 올리면 핀치오프 지점이 소스 쪽으로 조금씩 이동 → 유효 채널 길이 $L_{eff}$ 감소 → 전류 소폭 증가.

$$I_{ds} = \frac{\mu_n C_{ox}}{2}\frac{W}{L}(V_{gs}-V_t)^2,(1+\lambda V_{ds})$$

출력 저항:

$$r_o \approx \frac{1}{\lambda I_{ds}}$$

아날로그 증폭기 이득을 결정하는 핵심 파라미터. 디지털에서는 대개 무시한다.

7. 세 영역 정리

암기용 한 줄 $V_{gs}$가 켜는지 결정하고, $V_{ds}$가 어떻게 켜지는지 결정한다.

8. PMOS

모든 극성이 반대. n-well 안에 p+ 소스/드레인을 만들고, 캐리어는 정공이다.

부등호 뒤집히는 게 헷갈릴 때

절댓값으로 생각하면 NMOS와 완전히 같은 문장이 된다.

• PMOS도 $|V_{gs}| > |V_{tp}|$ 면 켜진다
• PMOS도 $|V_{ds}| \ge |V_{gs}| - |V_{tp}|$ 면 포화다

레이아웃에 직결되는 사실

$\mu_p < \mu_n$ 이므로 같은 $W/L$이면 PMOS가 2~3배 약하다. CMOS 인버터의 상승/하강 시간을 맞추려면 PMOS의 $W$를 2~3배로 키운다.

→ 인버터 그림에서 PMOS가 항상 뚱뚱하게 그려지는 이유.

9. 왜 CMOS는 NMOS를 아래, PMOS를 위에 두는가

앞 내용의 직접적인 귀결.

NMOS로 1(VDD)을 전달한다고 해보자.

게이트는 VDD로 고정인데, 출력이 올라가면 소스 전압도 같이 올라간다.

$$V_{gs} = V_{DD} - V_{out}$$

$V_{out}$이 오를수록 $V_{gs}$가 줄어들고, $V_{out} = V_{DD} - V_{tn}$ 이 되는 순간 $V_{gs} = V_{tn}$ → 트랜지스터가 꺼진다.

출력이 VDD까지 못 간다. ("threshold drop")

10. 2차 효과 (곧 나올 것들)

이름만 미리 알아두면 좋은 것들.

Subthreshold conduction (문턱 이하 전도)

$V_{gs} < V_t$ 에서도 전류가 완전히 0은 아니다. $V_{gs}$에 지수적으로 의존하는 누설 전류가 흐른다.

$$I_{ds} \propto e^{,V_{gs}/(nV_T)}$$

→ 저전력 설계에서 결정적. 대기 전력(standby power)의 주범.

Body effect (기판 효과)

$V_{sb} > 0$ 이면 문턱값이 올라간다.

$$V_t = V_{t0} + \gamma\left(\sqrt{2\phi_F + V_{sb}} - \sqrt{2\phi_F}\right)$$

• $\gamma$ : body effect coefficient
• $\phi_F$ : Fermi potential

→ NAND처럼 트랜지스터가 직렬로 쌓일 때 위쪽 트랜지스터가 느려지는 원인.

Velocity saturation (속도 포화)

최신 short-channel 공정에서는 전계가 너무 강해 캐리어 속도가 포화한다.

$$I_{ds} \propto (V_{gs}-V_t)^\alpha \quad,\quad \alpha \approx 1 \sim 1.3$$

→ 제곱 법칙이 깨진다. 교과서의 제곱식은 long-channel 근사라는 점을 기억할 것.

11. 핵심 공식 요약

NMOS

동작 조건
  차단   : Vgs < Vt
  선형   : Vgs > Vt  AND  Vds < Vgs − Vt
  포화   : Vgs > Vt  AND  Vds ≥ Vgs − Vt

경계
  Vds,sat = Vgs − Vt  =  Vov  (overdrive voltage)

$$\text{선형: } I_{ds} = \mu_n C_{ox}\frac{W}{L}\left[(V_{gs}-V_t)V_{ds} - \frac{V_{ds}^2}{2}\right]$$

$$\text{포화: } I_{ds} = \frac{\mu_n C_{ox}}{2}\frac{W}{L}(V_{gs}-V_t)^2,(1+\lambda V_{ds})$$

$$R_{on} = \frac{1}{\mu_n C_{ox}\frac{W}{L}(V_{gs}-V_t)} \qquad r_o \approx \frac{1}{\lambda I_{ds}}$$

$$C_{ox} = \frac{\varepsilon_{ox}}{t_{ox}} \qquad V_t = V_{t0} + \gamma\left(\sqrt{2\phi_F + V_{sb}} - \sqrt{2\phi_F}\right)$$

자주 쓰는 파생 관계

• Response time (also called execution time)
  • How long it takes to do a task
• Throughput
  • Total work done per unit time
  • e.g., tasks/transactions/… per hour

Realative Performance

$$ \frac {Performance_x} {Performance_y} = \frac {Execution\ time_y} {Execution\ time_x} = n $$ x,y 분자 분모 뒤바뀌는거 주의 x가 n만큼 y보다 빠르다 or 느리다

Measuring Execution Time

• Elapsed time ( total excution time, wall time)

  • Total response time, Including all aspects
    • $ time ls: measure time under the file, ls(list files in derectory)

• CPU Time

  • Time spent processing a given job

CPU Time

$$ CPU_{Time} = \frac {CPU\ Clock\ Cycles} {Clock\ Rate} = CPU\ Clock\ Cycle \times CCT $$

거속시 관계처럼 유연하게 생각하기 $$ Time = \frac{CC} {Rate} = CC \times CCT $$

Perfomance improved by

• reducing number of clock cycle
• increasing clock rate

Example

Computer A: 2GHz clock, 10s CPU time • Designing Computer B – Aim for 6s CPU time – Can do faster clock, but causes 1.2 × clock cycles

• How fast must Computer B clock be?

CPI (Cycle per Insturction)

Instruction Count for a program

• Determined by program, ISA and compiler

$$ Clock Cycle = Instruction\ Count \times Cycle\ per\ Instruction $$

$$ CPU_{Time} = \frac {IC \times CPI} {Clock\ Rate} = IC \times CPI \times CCT $$

ISA (instruction set Architecture)

• defines types of instuctions

• defines addressing mode

  ALU: ADD R1, R2, R3 -> Register addressing mode BNE R1, R2, L1 LD R, 8(R2) -> Indirect addressing mode

bracket means no data -> need to access memory

RISC (Reduced Inst Set Computing)

• ADD R1 R2 R3: add R2, R3

CISC (Complex Inst Set Computing)

• ADD R1, (R2), (R3): bring R2, R3 data from memory and add -> store to R1
• include multiple instructions
• inefficient

 j = b(i) + c(i)

 RISC - MIPS, ARM
 LD R4, (R2)
 LD R5, (R3)
 ADD R1, R4, R5

 CISC
 ADD R1, (R2), (R3)

Average cycles per instruction

• Determined by CPU hardware
• If different instructions have different CPI

0. 스코어보드란 / 이 파일의 역할

UVM에서 스코어보드 = "DUT 출력이 맞는지 판정하는 심판". 방식은 두 가지:

• 예측형(reference model): 입력을 받아 "정답"을 스스로 계산 → DUT 출력과 비교. ← 이 프로젝트
• 비교형: 두 DUT/두 경로 출력을 나란히 비교

여기서는 골든 캐시 모델을 들고, 4개 소스에서 트랜잭션을 받아 판정한다:

1. 4개 입력 포트 — uvm_analysis_imp_decl (36, 4649행)

`uvm_analysis_imp_decl(_req)
`uvm_analysis_imp_decl(_rsp)
`uvm_analysis_imp_decl(_mem)
`uvm_analysis_imp_decl(_rst)

왜 필요? analysis export는 콜백 함수가 write() 하나뿐이다. 한 컴포넌트가 여러 소스를 받으면 이름이 겹친다. uvm_analysis_imp_decl(_req)를 선언하면 write_req() 라는 별도 이름의 콜백이 생긴다. 그래서 4개 소스 → write_req/write_rsp/write_mem/ write_rst 4개 콜백.

uvm_analysis_imp_req #(l1_cache_item, l1_cache_scoreboard) req_export;   // → write_req()
uvm_analysis_imp_rsp #(l1_cache_item, ...)                 rsp_export;   // → write_rsp()
uvm_analysis_imp_mem #(l1_cache_mem_item, ...)             mem_export;   // → write_mem()
uvm_analysis_imp_rst #(l1_cache_reset_item, ...)           rst_export;   // → write_rst()

포트별 연결은 env에서:

• CPU 모니터 req_ap → req_export (수락된 모든 요청, 발행 순서)
• CPU 모니터 rsp_ap → rsp_export (read 응답)
• 메모리 모니터 ap → mem_export (burst 단위)
• reset 드라이버 ap → rst_export

2. 골든 모델 = 캐시 전체 (54~65행) ★

tag_t      m_tag   [SETS][WAYS];               // DUT 태그 배열의 거울
bit        m_valid [SETS][WAYS];
bit        m_dirty [SETS][WAYS];
bit [31:0] m_data  [SETS][WAYS][WORDS_PER_LINE];
plru_t     m_plru  [SETS];                     // PLRU 트리
bit [31:0] main_mem [int];                     // 예측 DRAM (워드 주소 → 값)

pending_read_t rd_q     [$];   // 발행됐지만 아직 응답 안 온 read + 기대값
exp_mem_t      exp_mem_q[$];   // 일어나야 할 memory burst 큐

핵심: 이전 버전은 메인 메모리만 모델링해서 "이건 hit이었어야 했다"를 판단할 수 없었다. 지금은 DUT의 태그/valid/dirty/data 4-way 전부 + PLRU + DRAM을 미러링하므로:

• hit/miss 그리고 어느 way인지 예측
• read가 반환할 정확한 데이터(byte 단위) 예측
• dirty victim이면 어느 주소로 어떤 4 beat를 쓸지 예측
• 뒤따르는 fill burst와 그 데이터 예측

주소 분할(get_set 등)과 PLRU 함수(plru_victim/plru_update)는 RTL과 같은 패키지 함수를 쓴다 → 모델과 DUT가 주소 해석에서 어긋날 수 없음. (단 이건 양날 — §10)

3. write_req — 예측 엔진 (122~210행) ★★★

요청이 수락되는 순간 호출. RTL의 동작을 그대로 흉내 내며 모델을 갱신하고, read면 기대값을 큐에 넣고, miss면 예상 burst를 큐에 넣는다. 순서가 중요하다:

1. set/tag/word/line_addr 계산
2. hit 탐색: 4개 way에서 valid && tag일치 검색
3-A. hit  → hit_cnt++, victim_state=NONE
3-B. miss → miss_cnt++
     - victim 선택: invalid way 우선, 없으면 plru_victim  (RTL과 동일 로직!)
     - victim_state 분류: INVALID / CLEAN / DIRTY
     - dirty victim이면:
         exp_mem_q에 eviction(rw=1, victim 주소, 4 beat) push
         main_mem에 victim 데이터 반영  ← DRAM에 씀
         did_evict=1, evict_cnt++
     - fill:
         exp_mem_q에 fetch(rw=0, 새 라인 주소) push
         m_data에 DRAM(mem_value)에서 4워드 로드
         m_tag/m_valid=1/m_dirty=0 설정
4. way_use[way]++
5. 접근 반영:
     write → m_data에 byte 단위 병합(be), m_dirty=1
     read  → exp_data = m_data[st][way][wd] 스냅샷, rd_q에 push
6. m_plru 갱신 (hit/fill 모두)
7. cov_ap.write(item)  ← 주석 달린 item을 커버리지로

write-allocate가 정확히 모델링됨: dirty victim 데이터를 DRAM에 쓰고(step 3-B), 새 라인을 그 DRAM에서 fetch(mem_value). 실제 캐시의 evict→fill 순서와 같다.

byte 단위 write 반영 (194~195행):

for (int b = 0; b < BE_WIDTH; b++)
    if (item.be[b]) m_data[st][way][wd][b*8 +: 8] = item.wdata[b*8 +: 8];

be가 켜진 레인만 갱신 → partial write를 RTL과 똑같이 흉내. 안 그러면 read 비교에서 가짜 실패.

4. 순서 문제와 "발행 시점 스냅샷" (2328, 200201행) ★★★ 면접 최다 질문

// write_req 안에서 (read일 때):
p.exp_data = m_data[st][way][wd];   // ← 지금(발행 시점) 값을 잡아둠
rd_q.push_back(p);

문제: DUT가 파이프라인이라 read 응답이 나가는 바로 그 사이클에 다음 요청이 수락 될 수 있다. 응답 시점(write_rsp)에 "현재 모델"과 비교하면, 모델은 이미 다음 요청으로 앞서 나가 있어 가짜 실패가 난다. (실제로 이것 때문에 런당 2건씩 헛 실패했었음)

해결: read의 기대값을 발행 시점(write_req)에 스냅샷해서 rd_q에 넣고, 응답이 올 때(write_rsp) 꺼내서 비교. 수락된 모든 요청(read+write)이 req_export에 발행 순서대로 오므로, 시뮬레이터가 모니터 스레드를 어떤 순서로 스케줄하든 프로그램 순서가 보존된다.

이게 "파이프라인 DUT의 스코어보드를 어떻게 짰나"의 정답. core의 2-포트 모니터 (req_ap/rsp_ap)와 한 세트로 동작.

5. write_rsp — read 검증 (215~245행)

p = rd_q.pop_front();                       // FIFO — 발행 순서대로

if (p.addr !== item.addr)                   // 순서 검증
    → SCB_ORDER 에러

if (p.skip)                                  // poison된 라인 → 데이터 비교 건너뜀
    skipped_cnt++; return;

if (item.rdata === p.exp_data) match_cnt++;  // 데이터 비교
else                          → READ_DATA_BUG 에러

• rd_q가 비었는데 응답이 오면 → SCB_SYNC (응답이 요청보다 많음 = DUT가 없는 응답을 냄)
• 주소 순서 불일치 → SCB_ORDER (out-of-order 응답)
• skip은 async reset poison 처리(§7)

6. write_mem — 메모리 burst 검증, 순서까지 (250~303행)

관측된 burst를 exp_mem_q의 예측과 순서대로 대조. 4중 체크:

1. exp_mem_q 비었는데 burst 관측 → MEM_UNEXPECTED (없어야 할 트래픽)
2. 방향(rw) 불일치           → MEM_DIRECTION (evict를 fetch로 등)
3. 주소 불일치               → MEM_ADDR
4. beat 수 != WORDS_PER_LINE → MEM_LEN (짧거나 긴 burst)
5. (skip이면 데이터 비교 생략)
6. beat별 데이터 불일치       → WRITE_BACK_BUG / FILL_DATA_BUG

이 덕에 없어야 할 / 빠진 / 주소 틀린 / 순서 바뀐 / 길이 틀린 / 데이터 틀린 burst가 전부 잡힌다. "빠진 burst"는 여기서 안 잡히고 check_phase가 잡음(§8).

7. write_rst — flush + poison (94~117행) ★ 난이도 높음

리셋을 걸기 직전 reset 드라이버가 알려주면 호출. 모델을 DUT처럼 flush하는데, 모델이 알 수 없는 상태를 격리하는 게 핵심.

// in-flight write-back은 일부 beat만 DRAM에 갔을 수 있음 → 그 라인 DRAM은 불확실
foreach (exp_mem_q[i])
    if (exp_mem_q[i].rw == 1'b1) poisoned[exp_mem_q[i].addr] = 1'b1;

rd_q.delete();        // 진행 중이던 read 추적 버림
exp_mem_q.delete();   // 예측 burst 버림

for (each set) m_valid=0, m_dirty=0, m_plru=0;   // DUT 플롭 flush와 동일

poison의 의미: write-back burst가 절반만 나간 채 리셋되면 DRAM이 예측 불가능한 상태가 된다. 그 라인 주소만 poison 표시하고, 이후 그 라인의 데이터 비교만 건너뛴다(rd_q/exp_mem_q의 skip). 프로토콜·순서·burst 길이 체크는 전부 유지.

"모델이 모르는 건 모른다고 인정하고 범위를 좁혀 격리". 무리하게 다 맞추려다 가짜 통과를 만드는 것보다 정직하고 안전. 리셋당 보통 ≤1라인, 카운트를 리포트에 찍음. m_data/main_mem은 안 지움 — valid=0이라 fresh fill 없이는 안 읽힘.

8. check_phase — 끝판 안전망 (308~317행) ★

"조용히 통과"를 막는 최종 검사. 에러 0이 검증됨이 아니다의 실천.

total_reads==0 && total_writes==0 → SCB_NO_TRAFFIC  (트래픽 전무 = 무의미한 통과)
rd_q.size() != 0                  → SCB_DANGLING     (응답 안 온 read = DUT가 응답 누락)
exp_mem_q.size() != 0             → SCB_MEM_MISSING  (일어났어야 할 burst가 안 일어남)
mismatch_cnt != 0                 → SCB_FAILED

run_phase가 아니라 check_phase에 둔 이유: 모든 트랜잭션이 처리된 뒤, 시뮬레이션 종료 직전에 도는 UVM 페이즈라 "남은 것"을 정확히 셀 수 있다.

9. 영리한 디테일 — 주소 의존 DRAM 기본값 (83~89행)

function bit [31:0] mem_value(bit [31:0] word_addr);
    return main_mem.exists(word_addr) ? main_mem[word_addr] : `L1_MEM_DEFAULT(word_addr);
endfunction
// `L1_MEM_DEFAULT(a) = 32'hDEAD_0000 | (a & 0xFFFF)  ← 주소마다 다른 값

아무도 안 쓴 주소를 읽으면 DRAM이 주는 값. 상수(예: 0xDEADBEEF)로 하면 안 되는 이유: cold fill의 4 beat가 전부 똑같아 보여서 워드 선택/순서 버그가 숨는다. 주소 의존이면 beat마다 값이 달라 그런 버그가 드러난다. 드라이버(l1_cache_mem_driver)도 같은 식을 써야 모델과 일치.

10. 솔직한 한계 (면접에서 물으면 가점)

PLRU/주소 함수를 RTL과 공유한다. 모델이 plru_victim/get_set 등 RTL과 같은 패키지 함수를 쓴다. 장점은 주소 해석 불일치가 원천 봉쇄. 단점은 그 함수 자체에 버그가 있으면 모델과 DUT가 같이 틀려서 못 잡는다(whitebox reference model의 고전적 약점). 여기선 데이터/eviction 주소/순서는 독립적으로 검증하므로, 못 잡는 건 순수 "교체 정책 결정" 한 가지뿐. 진짜 독립성을 원하면 PLRU를 모델에 따로 구현해야 한다.

→ 이걸 말할 수 있으면 "reference model의 독립성 trade-off를 이해한다"로 읽힌다.

11. 면접 예상 질문

12. 셀프 체크

1. read 기대값을 응답 시점이 아니라 발행 시점에 스냅샷하는 이유는?
2. write_mem에서 "빠진 burst"를 못 잡는 이유와, 그럼 어디서 잡히나?
3. dirty miss일 때 exp_mem_q에 몇 개가, 어떤 순서로 push되나?
4. async reset에서 poison하는 대상과, poison되면 무슨 검사가 꺼지나?
5. DRAM 기본값이 상수 0xDEADBEEF면 어떤 버그가 숨나?
6. 이 스코어보드가 원리상 못 잡는 버그 하나는?

0. 큰 그림 — 이 모듈의 구성

컨트롤러는 크게 7개 블록으로 나뉜다. 순서대로 읽으면 데이터 흐름이 보인다.

핵심 원칙: hit는 파이프라인이 조합적으로 처리(FSM은 ST_IDLE에 머무름), miss만 FSM이 여러 사이클에 걸쳐 처리(그동안 stall).

1. S1 → S2 파이프라인 레지스터 (66~96행)

always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin ... 리셋 ... end
    else if (!pipeline_stall) begin       // ← stall이면 값 유지(홀드)
        s2_valid <= cpu_req_valid;
        s2_rw    <= cpu_req_rw;
        s2_addr  <= cpu_req_addr;
        s2_be    <= cpu_req_be;
        s2_wdata <= cpu_req_wdata;
    end
end

• S1(입력 핀) → S2(레지스터)로 요청을 1사이클 지연. 이 레지스터가 파이프라인 단 경계.
• !pipeline_stall 일 때만 갱신 = stall이면 S2가 그 요청을 붙잡고 있음 (miss 처리 동안 요청이 날아가지 않게).
• s1_* 는 입력 주소에서 조합적으로 뽑은 필드, s2_* 는 레지스터된 주소에서 뽑은 필드. (get_set/get_word/get_tag는 l1_cache_pkg.sv)

2. 라인 상태 — 플롭에 둔 이유 (98~108행)

logic [WAYS-1:0] valid_bits [SETS];   // set당 4비트 (way별 valid)
logic [WAYS-1:0] dirty_bits [SETS];
plru_t           plru_bits  [SETS];   // set당 3비트 PLRU

• valid/dirty/PLRU를 SRAM이 아니라 플롭에 뒀다.
• 이유: 리셋 한 사이클에 캐시 전체가 flush된다 (FSM 리셋 블록 280~284행에서 전 set을 0으로). SRAM에 두면 전원 인가 후 전 라인을 순회 무효화하는 상태가 필요하고, 그 전까진 태그가 X라 hit 판정에 합성 불가 ===를 써야 한다.
• 용량: 64 set × 4 way × 2bit(valid+dirty) + 64 × 3(plru) = 감당 가능한 플롭 수.

3. 배열 read 주소 mux (136~149행) ★

동기 SRAM이라 N에 준 주소가 N+1에 데이터로 나온다. 그래서 "지금 어느 주소를 줘야 다음 사이클 S2가 원하는 데이터가 오는가"를 3경우로 나눈다.

always_comb begin
    if (!pipeline_stall && cpu_req_valid) begin        // ① 정상
        tag_raddr  = s1_set;
        data_raddr = make_data_addr(s1_set, s1_word);
    end
    else if (state == ST_WB_READ) begin                // ② victim 읽어내는 중
        data_raddr = make_data_addr(s2_set, wb_cnt[1:0]);
    end
    else begin                                          // ③ stall/idle
        tag_raddr  = s2_set;
        data_raddr = make_data_addr(s2_set, s2_word);
    end
end

왜 ③에서 S2로 폴백? stall 중엔 S1에 새 주소가 와도 무시해야 하고, 요청이 없을 땐 드라이버가 버스에 X를 실으므로 그 X로 배열을 인덱싱하면 안 된다.

4. Forwarding — read-before-write 우회 (166~210행) ★★

동기 SRAM은 "쓰기 직전 값"을 반환한다(STUDY_sram.md §4). 그래서 직전 사이클에 쓴 위치를 지금 읽으면 stale. 1단 포워딩으로 우회.

// 직전 사이클의 write/read 정보를 플롭에 저장
prev_data_we, prev_data_wbe, prev_data_waddr, prev_data_wdata, prev_data_raddr <= ...

// 바이트 단위로 우회
safe_data_rdata[w][b*8 +: 8] =
    (prev_data_we[w] && (prev_data_waddr == prev_data_raddr) && prev_data_wbe[b])
    ? prev_data_wdata[b*8 +: 8]     // 직전에 쓴 값
    : data_rdata[w][b*8 +: 8];      // 배열이 준 값

포인트 3개 (면접에서 여기 파고듦):

1. 비교 대상이 s2가 아니라 prev_*_raddr — 직전 사이클에 실제로 인가한 read 주소. ST_WB_READ에선 read 주소가 라인을 순회(§3 ②)하므로 s2_word가 아님. 그래서 "직전에 준 read 주소"를 플롭으로 잡아 비교.

2. 바이트 단위 — partial write(be != 4'b1111)면 쓴 레인만 포워딩, 나머지는 배열 값. 워드 통째로 포워딩하면 안 건드린 바이트가 오염됨.

3. 1사이클 깊이면 충분 — write 다음다음 사이클엔 배열 자체가 새 값을 가짐. stale인 건 딱 한 사이클.

태그(safe_tag_rdata)도 같은 원리인데 바이트 분할이 없다(태그는 통째 갱신).

5. Hit 판정 — 4-way 병렬 비교 (215~230행)

for (int w = 0; w < WAYS; w++)
    way_hit[w] = set_valid[w] && (safe_tag_rdata[w] == s2_tag);

assign cache_hit = s2_valid && (|way_hit);   // |way_hit = OR 리덕션

for (int w = 0; w < WAYS; w++)
    if (way_hit[w]) hit_way = way_t'(w);      // 어느 way가 hit인지

• 4개 way의 태그를 동시에 s2_tag와 비교 (direct-mapped는 1개만, 4-way는 4개 병렬).
• set_valid[w] 조건 필수 — valid 안 된 way의 쓰레기 태그가 우연히 맞는 걸 배제.
• 정상 캐시라면 set당 같은 태그는 최대 1개 way에만 있음 → hit_way 유일.
• 비교에 safe_tag_rdata(포워딩된 값)를 쓰는 게 중요 — 방금 쓴 태그도 반영.

6. Victim 선택 (236~257행)

for (int w = WAYS-1; w >= 0; w--)           // 높은 way→낮은 way
    if (!set_valid[w]) begin
        first_invalid = way_t'(w); has_invalid = 1'b1;
    end
victim_sel = has_invalid ? first_invalid : plru_victim(plru_bits[s2_set]);

우선순위: ① invalid(빈) way가 있으면 그걸 먼저 채움(cold fill) → ② 없으면 PLRU가 지목.

• 루프가 높은→낮은 순회 + 덮어쓰기라, first_invalid엔 가장 낮은 번호의 invalid way가 남음.
• plru_victim()은 3비트 트리를 따라 내려가 victim 결정 (l1_cache_pkg.sv).
• victim_dirty = victim이 valid && dirty → write-back 필요 여부.

⚠️ 여기 주석의 교훈: always_comb 안에서 logic x = 0; 같은 선언 초기화 금지. 절차 블록 변수는 static이라 time 0에 한 번만 초기화됨. 그래서 first_invalid/ has_invalid를 블록 밖에 선언하고 안에서 대입. (실제로 다른 곳에서 이 함정에 물렸음)

7. CPU 응답 (262~265행)

assign cpu_rsp_valid = ((state == ST_IDLE)     && s2_valid && cache_hit && !s2_rw)
                    || ((state == ST_COMPLETE) && s2_valid &&              !s2_rw);

assign cpu_rsp_rdata = (state == ST_COMPLETE) ? fill_data : safe_data_rdata[hit_way];

읽기 응답이 나가는 두 순간:

• ST_IDLE의 read hit → 데이터는 배열에서(safe_data_rdata[hit_way], 포워딩 반영)
• ST_COMPLETE의 read (miss 처리 끝) → 데이터는 fill에서 잡아둔 fill_data

write는 응답 없음(!s2_rw 조건). fill_data는 FSM이 fetch 중 요청 워드를 잡아둔 값(§8 ST_FILL_RCV).

8. FSM (I) — 순차 블록: 무엇을 래치하나 (270~339행)

state <= next_state 외에, 상태별로 레지스터에 무엇을 저장하는지.

ST_IDLE:
    hit  → PLRU 갱신, write면 dirty 세팅
    miss → victim_way/victim_tag 래치, 카운터 리셋 (miss 시퀀스 준비)

ST_WB_READ:
    if (wb_cnt > 0) wb_buf[wb_cnt-1] <= safe_data_rdata[victim_way];  // 1사이클 뒤 캡처
    wb_cnt <= wb_cnt + 1;

ST_FILL_RCV:
    if (mem_rd_valid) begin
        if (fill_beat == s2_word) fill_data <= mem_rd_data;  // 요청 워드만 잡아둠
        fill_beat <= fill_beat + 1;
    end

ST_COMPLETE:
    valid_bits[s2_set][victim_way] <= 1'b1;      // 라인 유효화
    dirty_bits[s2_set][victim_way] <= s2_rw;     // write miss면 dirty
    plru_bits[s2_set] <= plru_update(..., victim_way);

wb_cnt-1 캡처의 의미: 동기 read라 주소를 준 다음 사이클에 데이터가 옴. wb_cnt=N일 때 word N 주소를 인가(§3 ②) → wb_cnt=N+1이 됐을 때 word N 데이터 도착 → wb_buf[N]에 저장. 그래서 "한 사이클 뒤(wb_cnt-1)"에 캡처.

왜 victim을 버퍼에 복사? fill(ST_FILL_RCV)이 같은 물리 위치 {s2_set, victim_way}에 새 라인을 덮어쓴다. 그러니 덮이기 전에 victim을 먼저 읽어내야 한다 → WB_READ에서 wb_buf로 스냅샷.

9. FSM (II) — 조합 블록: next_state + 출력 (344~444행)

맨 위에 기본값 전부 비활성(모든 we=0, mem_req=0, stall=0…)을 깔고, 상태별로 덮어씀. 이게 latch 방지 + 안전한 기본 상태의 정석.

ST_IDLE:
    hit & write → data_we[hit_way]=1, data_wbe=s2_be   (제자리 갱신)
    miss        → stall=1, next = victim_dirty ? WB_READ : FILL_REQ

ST_WB_READ:  stall=1;  wb_cnt==4 → next=WB_SEND
ST_WB_SEND:  stall=1
    !req_sent → mem_req(rw=1, victim 주소) 발행
    req_sent  → mem_wr_data=wb_buf[wb_ptr], last=마지막워드; ready&last → next=FILL_REQ
ST_FILL_REQ: stall=1;  mem_req(rw=0, 새 라인 주소);  req_ready → next=FILL_RCV
ST_FILL_RCV: stall=1
    mem_rd_valid → data_we[victim_way]=1, wbe=all, {set,fill_beat}에 기록; last → next=COMPLETE
ST_COMPLETE: stall=0(!);  tag_we[victim_way]=1(태그 커밋);
             write면 data_we[victim_way]=1 + s2_be (스토어 반영);  next=IDLE

miss 처리 흐름 (dirty): IDLE → WB_READ(victim 버퍼링) → WB_SEND(메모리로 스트리밍) → FILL_REQ(새 라인 요청) → FILL_RCV(4비트 수신) → COMPLETE(커밋+응답) → IDLE. clean victim이면 WB 두 단계 건너뛰고 바로 FILL_REQ.

10. ★ 반드시 외울 설계 포인트 3개

(a) ST_COMPLETE에서 stall을 푼다 (428~440행)

ST_COMPLETE: begin
    pipeline_stall = 1'b0;   // ← 여기서 해제
    ...
end

여기서 stall을 유지하면 다음 사이클 ST_IDLE에서 S2가 같은 요청을 그대로 들고 있어 응답을 두 번 내보낸다. stall을 풀어야 파이프라인이 진행되어 S2가 넘어감.

(b) 왜 조합 루프가 없나

tag_raddr가 pipeline_stall로 선택되지만, tag_rdata는 플롭 출력(동기 SRAM)이라 stall→raddr→rdata→hit→stall 피드백이 끊긴다. 비동기 SRAM이면 이 mux가 루프를 닫는다 (이전 버전의 675 버그).

(c) always_comb 정적 변수 함정 (§6)

절차 블록 선언 초기화는 static. 루프/조합 블록에선 선언과 대입 분리.

11. Cycle-by-cycle — clean read miss (가장 단순)

메모리 latency=2 가정. victim이 clean이라 write-back 없음.

dirty miss면 N+1 앞에 WB_READ(≈5) + WB_SEND(req+4beat) 가 추가된다.

12. 면접 예상 질문

13. 셀프 체크

1. pipeline_stall이 1이면 S1→S2 레지스터는 어떻게 되나? 왜 그래야 하나?
2. clean miss와 dirty miss의 상태 경로 차이는?
3. ST_WB_READ에서 wb_buf[wb_cnt-1]로 한 사이클 뒤에 캡처하는 이유는?
4. forwarding에서 prev_data_raddr(직전 read 주소)로 비교하는 이유는? s2면 왜 안 되나?
5. ST_COMPLETE에서 pipeline_stall = 0으로 푸는 이유는?
6. victim으로 dirty way가 뽑혔는데 그걸 버퍼에 안 읽고 바로 fill하면 무슨 일이?

0. 큰 그림 — 이 모듈의 구성

컨트롤러는 크게 7개 블록으로 나뉜다. 순서대로 읽으면 데이터 흐름이 보인다.

핵심 원칙: hit는 파이프라인이 조합적으로 처리(FSM은 ST_IDLE에 머무름), miss만 FSM이 여러 사이클에 걸쳐 처리(그동안 stall).

1. S1 → S2 파이프라인 레지스터 (66~96행)

always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin ... 리셋 ... end
    else if (!pipeline_stall) begin       // ← stall이면 값 유지(홀드)
        s2_valid <= cpu_req_valid;
        s2_rw    <= cpu_req_rw;
        s2_addr  <= cpu_req_addr;
        s2_be    <= cpu_req_be;
        s2_wdata <= cpu_req_wdata;
    end
end

• S1(입력 핀) → S2(레지스터)로 요청을 1사이클 지연. 이 레지스터가 파이프라인 단 경계.
• !pipeline_stall 일 때만 갱신 = stall이면 S2가 그 요청을 붙잡고 있음 (miss 처리 동안 요청이 날아가지 않게).
• s1_* 는 입력 주소에서 조합적으로 뽑은 필드, s2_* 는 레지스터된 주소에서 뽑은 필드. (get_set/get_word/get_tag는 l1_cache_pkg.sv)

2. 라인 상태 — 플롭에 둔 이유 (98~108행)

logic [WAYS-1:0] valid_bits [SETS];   // set당 4비트 (way별 valid)
logic [WAYS-1:0] dirty_bits [SETS];
plru_t           plru_bits  [SETS];   // set당 3비트 PLRU

• valid/dirty/PLRU를 SRAM이 아니라 플롭에 뒀다.
• 이유: 리셋 한 사이클에 캐시 전체가 flush된다 (FSM 리셋 블록 280~284행에서 전 set을 0으로). SRAM에 두면 전원 인가 후 전 라인을 순회 무효화하는 상태가 필요하고, 그 전까진 태그가 X라 hit 판정에 합성 불가 ===를 써야 한다.
• 용량: 64 set × 4 way × 2bit(valid+dirty) + 64 × 3(plru) = 감당 가능한 플롭 수.

3. 배열 read 주소 mux (136~149행) ★

동기 SRAM이라 N에 준 주소가 N+1에 데이터로 나온다. 그래서 "지금 어느 주소를 줘야 다음 사이클 S2가 원하는 데이터가 오는가"를 3경우로 나눈다.

always_comb begin
    if (!pipeline_stall && cpu_req_valid) begin        // ① 정상
        tag_raddr  = s1_set;
        data_raddr = make_data_addr(s1_set, s1_word);
    end
    else if (state == ST_WB_READ) begin                // ② victim 읽어내는 중
        data_raddr = make_data_addr(s2_set, wb_cnt[1:0]);
    end
    else begin                                          // ③ stall/idle
        tag_raddr  = s2_set;
        data_raddr = make_data_addr(s2_set, s2_word);
    end
end

왜 ③에서 S2로 폴백? stall 중엔 S1에 새 주소가 와도 무시해야 하고, 요청이 없을 땐 드라이버가 버스에 X를 실으므로 그 X로 배열을 인덱싱하면 안 된다.

4. Forwarding — read-before-write 우회 (166~210행) ★★

동기 SRAM은 "쓰기 직전 값"을 반환한다(STUDY_sram.md §4). 그래서 직전 사이클에 쓴 위치를 지금 읽으면 stale. 1단 포워딩으로 우회.

// 직전 사이클의 write/read 정보를 플롭에 저장
prev_data_we, prev_data_wbe, prev_data_waddr, prev_data_wdata, prev_data_raddr <= ...

// 바이트 단위로 우회
safe_data_rdata[w][b*8 +: 8] =
    (prev_data_we[w] && (prev_data_waddr == prev_data_raddr) && prev_data_wbe[b])
    ? prev_data_wdata[b*8 +: 8]     // 직전에 쓴 값
    : data_rdata[w][b*8 +: 8];      // 배열이 준 값

포인트 3개 (면접에서 여기 파고듦):

1. 비교 대상이 s2가 아니라 prev_*_raddr — 직전 사이클에 실제로 인가한 read 주소. ST_WB_READ에선 read 주소가 라인을 순회(§3 ②)하므로 s2_word가 아님. 그래서 "직전에 준 read 주소"를 플롭으로 잡아 비교.

2. 바이트 단위 — partial write(be != 4'b1111)면 쓴 레인만 포워딩, 나머지는 배열 값. 워드 통째로 포워딩하면 안 건드린 바이트가 오염됨.

3. 1사이클 깊이면 충분 — write 다음다음 사이클엔 배열 자체가 새 값을 가짐. stale인 건 딱 한 사이클.

태그(safe_tag_rdata)도 같은 원리인데 바이트 분할이 없다(태그는 통째 갱신).

5. Hit 판정 — 4-way 병렬 비교 (215~230행)

for (int w = 0; w < WAYS; w++)
    way_hit[w] = set_valid[w] && (safe_tag_rdata[w] == s2_tag);

assign cache_hit = s2_valid && (|way_hit);   // |way_hit = OR 리덕션

for (int w = 0; w < WAYS; w++)
    if (way_hit[w]) hit_way = way_t'(w);      // 어느 way가 hit인지

• 4개 way의 태그를 동시에 s2_tag와 비교 (direct-mapped는 1개만, 4-way는 4개 병렬).
• set_valid[w] 조건 필수 — valid 안 된 way의 쓰레기 태그가 우연히 맞는 걸 배제.
• 정상 캐시라면 set당 같은 태그는 최대 1개 way에만 있음 → hit_way 유일.
• 비교에 safe_tag_rdata(포워딩된 값)를 쓰는 게 중요 — 방금 쓴 태그도 반영.

6. Victim 선택 (236~257행)

for (int w = WAYS-1; w >= 0; w--)           // 높은 way→낮은 way
    if (!set_valid[w]) begin
        first_invalid = way_t'(w); has_invalid = 1'b1;
    end
victim_sel = has_invalid ? first_invalid : plru_victim(plru_bits[s2_set]);

우선순위: ① invalid(빈) way가 있으면 그걸 먼저 채움(cold fill) → ② 없으면 PLRU가 지목.

• 루프가 높은→낮은 순회 + 덮어쓰기라, first_invalid엔 가장 낮은 번호의 invalid way가 남음.
• plru_victim()은 3비트 트리를 따라 내려가 victim 결정 (l1_cache_pkg.sv).
• victim_dirty = victim이 valid && dirty → write-back 필요 여부.

⚠️ 여기 주석의 교훈: always_comb 안에서 logic x = 0; 같은 선언 초기화 금지. 절차 블록 변수는 static이라 time 0에 한 번만 초기화됨. 그래서 first_invalid/ has_invalid를 블록 밖에 선언하고 안에서 대입. (실제로 다른 곳에서 이 함정에 물렸음)

7. CPU 응답 (262~265행)

assign cpu_rsp_valid = ((state == ST_IDLE)     && s2_valid && cache_hit && !s2_rw)
                    || ((state == ST_COMPLETE) && s2_valid &&              !s2_rw);

assign cpu_rsp_rdata = (state == ST_COMPLETE) ? fill_data : safe_data_rdata[hit_way];

읽기 응답이 나가는 두 순간:

• ST_IDLE의 read hit → 데이터는 배열에서(safe_data_rdata[hit_way], 포워딩 반영)
• ST_COMPLETE의 read (miss 처리 끝) → 데이터는 fill에서 잡아둔 fill_data

write는 응답 없음(!s2_rw 조건). fill_data는 FSM이 fetch 중 요청 워드를 잡아둔 값(§8 ST_FILL_RCV).

8. FSM (I) — 순차 블록: 무엇을 래치하나 (270~339행)

state <= next_state 외에, 상태별로 레지스터에 무엇을 저장하는지.

ST_IDLE:
    hit  → PLRU 갱신, write면 dirty 세팅
    miss → victim_way/victim_tag 래치, 카운터 리셋 (miss 시퀀스 준비)

ST_WB_READ:
    if (wb_cnt > 0) wb_buf[wb_cnt-1] <= safe_data_rdata[victim_way];  // 1사이클 뒤 캡처
    wb_cnt <= wb_cnt + 1;

ST_FILL_RCV:
    if (mem_rd_valid) begin
        if (fill_beat == s2_word) fill_data <= mem_rd_data;  // 요청 워드만 잡아둠
        fill_beat <= fill_beat + 1;
    end

ST_COMPLETE:
    valid_bits[s2_set][victim_way] <= 1'b1;      // 라인 유효화
    dirty_bits[s2_set][victim_way] <= s2_rw;     // write miss면 dirty
    plru_bits[s2_set] <= plru_update(..., victim_way);

wb_cnt-1 캡처의 의미: 동기 read라 주소를 준 다음 사이클에 데이터가 옴. wb_cnt=N일 때 word N 주소를 인가(§3 ②) → wb_cnt=N+1이 됐을 때 word N 데이터 도착 → wb_buf[N]에 저장. 그래서 "한 사이클 뒤(wb_cnt-1)"에 캡처.

왜 victim을 버퍼에 복사? fill(ST_FILL_RCV)이 같은 물리 위치 {s2_set, victim_way}에 새 라인을 덮어쓴다. 그러니 덮이기 전에 victim을 먼저 읽어내야 한다 → WB_READ에서 wb_buf로 스냅샷.

9. FSM (II) — 조합 블록: next_state + 출력 (344~444행)

맨 위에 기본값 전부 비활성(모든 we=0, mem_req=0, stall=0…)을 깔고, 상태별로 덮어씀. 이게 latch 방지 + 안전한 기본 상태의 정석.

ST_IDLE:
    hit & write → data_we[hit_way]=1, data_wbe=s2_be   (제자리 갱신)
    miss        → stall=1, next = victim_dirty ? WB_READ : FILL_REQ

ST_WB_READ:  stall=1;  wb_cnt==4 → next=WB_SEND
ST_WB_SEND:  stall=1
    !req_sent → mem_req(rw=1, victim 주소) 발행
    req_sent  → mem_wr_data=wb_buf[wb_ptr], last=마지막워드; ready&last → next=FILL_REQ
ST_FILL_REQ: stall=1;  mem_req(rw=0, 새 라인 주소);  req_ready → next=FILL_RCV
ST_FILL_RCV: stall=1
    mem_rd_valid → data_we[victim_way]=1, wbe=all, {set,fill_beat}에 기록; last → next=COMPLETE
ST_COMPLETE: stall=0(!);  tag_we[victim_way]=1(태그 커밋);
             write면 data_we[victim_way]=1 + s2_be (스토어 반영);  next=IDLE

miss 처리 흐름 (dirty): IDLE → WB_READ(victim 버퍼링) → WB_SEND(메모리로 스트리밍) → FILL_REQ(새 라인 요청) → FILL_RCV(4비트 수신) → COMPLETE(커밋+응답) → IDLE. clean victim이면 WB 두 단계 건너뛰고 바로 FILL_REQ.

10. ★ 반드시 외울 설계 포인트 3개

(a) ST_COMPLETE에서 stall을 푼다 (428~440행)

ST_COMPLETE: begin
    pipeline_stall = 1'b0;   // ← 여기서 해제
    ...
end

여기서 stall을 유지하면 다음 사이클 ST_IDLE에서 S2가 같은 요청을 그대로 들고 있어 응답을 두 번 내보낸다. stall을 풀어야 파이프라인이 진행되어 S2가 넘어감.

(b) 왜 조합 루프가 없나

tag_raddr가 pipeline_stall로 선택되지만, tag_rdata는 플롭 출력(동기 SRAM)이라 stall→raddr→rdata→hit→stall 피드백이 끊긴다. 비동기 SRAM이면 이 mux가 루프를 닫는다 (이전 버전의 675 버그).

(c) always_comb 정적 변수 함정 (§6)

절차 블록 선언 초기화는 static. 루프/조합 블록에선 선언과 대입 분리.

11. Cycle-by-cycle — clean read miss (가장 단순)

메모리 latency=2 가정. victim이 clean이라 write-back 없음.

dirty miss면 N+1 앞에 WB_READ(≈5) + WB_SEND(req+4beat) 가 추가된다.

12. 면접 예상 질문

13. 셀프 체크

1. pipeline_stall이 1이면 S1→S2 레지스터는 어떻게 되나? 왜 그래야 하나?
2. clean miss와 dirty miss의 상태 경로 차이는?
3. ST_WB_READ에서 wb_buf[wb_cnt-1]로 한 사이클 뒤에 캡처하는 이유는?
4. forwarding에서 prev_data_raddr(직전 read 주소)로 비교하는 이유는? s2면 왜 안 되나?
5. ST_COMPLETE에서 pipeline_stall = 0으로 푸는 이유는?
6. victim으로 dirty way가 뽑혔는데 그걸 버퍼에 안 읽고 바로 fill하면 무슨 일이?

1. 역할

캐시가 태그와 데이터를 담는 SRAM의 동작 모델. 실칩에선 벤더의 컴파일된 SRAM 매크로를 쓰지만, 시뮬레이션에선 그 동작을 흉내 내는 behavioral 모델이 필요하다.

모듈 2개:

4-way라서 l1_cache_top.sv에서 way당 하나씩, 총 8개 (태그 4 + 데이터 4)를 generate로 인스턴스화한다.

2. 핵심 개념 — 동기 읽기 (synchronous read)

always_ff @(posedge clk) begin
    rdata <= mem[raddr];    // 주소는 이번 엣지에, 데이터는 다음 엣지에
    ...
end

"N번째 클럭에 주소(raddr)를 주면, N+1번째 클럭에 데이터(rdata)가 나온다."

rdata가 플롭(always_ff의 <=)이라서다. 조합이 아니라 레지스터를 거쳐 나온다.

이게 2단 파이프라인을 성립시킨다:

• S1: CPU 요청 → set index를 SRAM 주소에 인가
• S2: (다음 사이클) 태그/데이터 도착 → hit/miss 판정

주소를 준 사이클과 데이터가 나오는 사이클이 1칸 어긋난 것 = 파이프라인 단 경계.

⚠️ 버그 스토리 (면접 최고 소재)

이전 버전은 비동기 읽기였다:

assign rdata = mem[raddr];   // 조합 — 주소 주면 즉시 데이터

두 가지가 망가졌다:

1. 조합 루프: stall → raddr → rdata → hit → stall 이 닫힌 고리 → 합성 시 발진
2. 파이프라인 모델 불일치: S1 주소 → S2 데이터 구조인데 즉시 읽기라 타이밍 안 맞음 → read 1495건 중 675건(45%) 오답

assign → always_ff @(posedge clk) 한 줄로 675 에러 → 0. "동기 vs 비동기 SRAM 읽기 차이"를 물으면 이 실제 경험으로 답한다.

3. sram_macro 블록별

logic [DATA_WIDTH-1:0] mem [0:(1<<ADDR_WIDTH)-1];

• 1<<ADDR_WIDTH = 2^ADDR_WIDTH (비트 시프트로 2의 거듭제곱)
• ADDR_WIDTH=8 → mem[0:255] = 256워드, 각 워드 DATA_WIDTH 비트
• [DATA_WIDTH-1:0] = packed(워드 안 비트), [0:...] = unpacked(워드 개수)

always_ff @(posedge clk) begin
    rdata <= mem[raddr];              // 읽기
    if (we) mem[waddr] <= wdata;      // 쓰기 (we=1일 때만)
end

• 매 상승엣지에 읽기·쓰기 동시 (1 read port + 1 write port)
• we(write enable)가 1일 때만 waddr에 기록

4. 미묘하지만 중요 — read-before-write 충돌

주석의 "sampled before this edge's write"가 이 부분. 같은 사이클에 같은 주소를 읽고 쓰면?

rdata <= mem[raddr];           // ①
if (we) mem[waddr] <= wdata;   // ②

<=(non-blocking)의 규칙: 우변(RHS)을 먼저 전부 계산 → 좌변(LHS)을 나중에 한꺼번에 갱신.

raddr == waddr 이고 we=1 일 때:

• ①의 우변 mem[raddr]은 쓰기 전 옛날 값으로 계산됨
• ②는 그 후에 mem 갱신

→ rdata는 옛날 값을 내보낸다 (방금 쓴 값이 아니라).

포인트: 두 문장 순서를 바꿔도 결과 동일. NBA는 우변을 전부 먼저 평가하니까. 이게 "read-before-write" / "read-old-data" 동작이고, 실제 SRAM의 흔한 모드다.

그래서 코어에 forwarding이 필요

배열이 "쓰기 직전 값"을 주므로, 직전 사이클에 쓴 위치를 지금 읽으면 stale. l1_cache_core.sv의 safe_data_rdata/safe_tag_rdata가 우회:

"직전 사이클에 이 주소에 썼나? 그러면 배열 값 대신 그때 쓴 데이터를 써라"

이 SRAM의 read-before-write 성질과 코어의 forwarding은 한 세트. 하나를 이해하면 다른 하나가 왜 있는지 보인다.

타이밍 정리

cycle N   : mem[A]에 write (엣지 끝에서 mem 갱신)
            같은 A를 raddr로도 인가
cycle N+1 : rdata = (N 시점의 옛날 mem[A])  ← stale! forwarding이 여기서 개입
cycle N+2 : rdata = (새 값)                  ← 이제 배열 자체가 새 값

forwarding이 딱 1사이클 깊이면 충분한 이유가 이 표에 있다.

5. sram_macro_be — byte enable 버전

데이터 배열은 partial write(워드 일부 바이트만)를 지원해야 한다. 차이는 쓰기부:

if (we) begin
    for (int b = 0; b < BE_WIDTH; b++)
        if (wbe[b]) mem[waddr][b*8 +: 8] <= wdata[b*8 +: 8];
end

• BE_WIDTH = DATA_WIDTH/8 = 4 (32비트 = 4바이트)
• 바이트 레인 4개를 각각 확인: wbe[b]=1인 레인만 갱신
• wbe=4'b0001 → 최하위 바이트만, 4'b1111 → 전체 워드

예: 워드 0xAABBCCDD, wdata=0x11223344, wbe=4'b0011 → 결과 0xAABB3344 (상위 2바이트 유지, 하위 2바이트 교체)

+: 연산자 (indexed part-select) — 문법 단골

wdata[b*8 +: 8]   // "b*8 비트부터 위로 8비트"

for 변수로 비트 범위를 [b*8+7 : b*8] 처럼 쓰면 변수 범위 불가로 문법 에러. 그래서 +:(또는 -:)를 쓴다.

6. 큰 그림

CPU 요청 ──▶ [코어 S1] ──raddr──▶ [이 SRAM] ──rdata(1사이클 뒤)──▶ [코어 S2] ──▶ hit/miss
                                       ▲
                             read-before-write 성질
                                       │
                            [코어 forwarding이 보완]

7. 면접 예상 질문

8. 셀프 체크 (안 보고 답해보기)

1. raddr==waddr, we=1 일 때 rdata에 나오는 건 새 값인가 옛날 값인가? 왜?
2. assign rdata = mem[raddr] 로 바꾸면 어떤 두 가지가 깨지나?
3. forwarding이 1사이클 깊이면 충분한 이유는?
4. wbe=4'b1010, 워드 0x11223344, wdata=0xAABBCCDD → 결과는?
5. 왜 태그 배열엔 byte enable이 없나?

L1 Cache Controller 프로젝트 시리즈 1편 캐시의 기하학적 정의, 주소 분해, FSM 상태, PLRU 함수

이 파일의 역할

l1_cache_pkg = 캐시의 "설계도 상수 + 도구 모음"

모든 캐시 파일이 이 패키지를 import해서
  - 캐시 크기/구조 (파라미터)
  - 주소를 어떻게 나누는지 (헬퍼 함수)
  - FSM 상태
  - PLRU 로직
을 공유한다. "단일 진실 공급원(single source of truth)".

목차

1. Cache Geometry — 캐시 구조 파라미터
2. 주소 분해 — tag/set/word/byte
3. 타입 정의 (typedef)
4. Controller FSM — 상태 정의
5. Tag 배열 구조
6. 주소 헬퍼 함수
7. Tree-PLRU 함수

1. Cache Geometry — 캐시 구조

localparam int ADDR_WIDTH     = 32;
localparam int DATA_WIDTH     = 32;
localparam int BE_WIDTH       = DATA_WIDTH/8;          // 4 (byte enable)

localparam int WAYS           = 4;                     // 4-way
localparam int WAY_BITS       = 2;                     // $clog2(4)
localparam int SETS           = 64;                    // 64 sets
localparam int SET_BITS       = 6;                     // $clog2(64)
localparam int WORDS_PER_LINE = 4;                     // 라인당 4워드
localparam int WORD_BITS      = 2;                     // $clog2(4)
localparam int BYTE_BITS      = 2;                     // 워드 안 바이트
localparam int OFFSET_BITS    = WORD_BITS + BYTE_BITS; // 4 → 16B 라인
localparam int TAG_BITS       = ADDR_WIDTH - SET_BITS - OFFSET_BITS;  // 22

4KB 계산

캐시 라인 = WORDS_PER_LINE × 4바이트
          = 4 × 4 = 16바이트

전체 크기 = 라인 × SETS × WAYS
          = 16B × 64 × 4
          = 4096B = 4KB ✅

$clog2 — 비트 폭 계산

$clog2(N) = N을 표현하는 데 필요한 비트 수 (ceiling log2)

$clog2(4)  = 2   (WAYS=4 → WAY_BITS=2)
$clog2(64) = 6   (SETS=64 → SET_BITS=6)

왜? 4개를 구분하려면 2비트 (00,01,10,11)
    64개를 구분하려면 6비트

DATA_ADDR_BITS

localparam int DATA_ADDR_BITS = SET_BITS + WORD_BITS;  // 8 → 256 words/way

데이터 배열 주소 = {set, word}
  = 6비트 + 2비트 = 8비트
  = 2^8 = 256워드 per way

한 way에 256워드 = 64 set × 4 word ✅

2. 주소 분해 — 핵심 개념

addr[31:10] = tag          (22b)
addr[ 9: 4] = set index    (6b → 64 sets)
addr[ 3: 2] = word in line (2b → 4 words)
addr[ 1: 0] = byte in word (2b)

그림

32비트 주소:

 31                    10  9      4  3   2  1   0
┌────────────────────────┬─────────┬──────┬──────┐
│         tag            │   set   │ word │ byte │
│        (22비트)         │ (6비트)  │(2비트)│(2비트)│
└────────────────────────┴─────────┴──────┴──────┘
         │                    │        │       │
    "이 데이터 맞나"         64개 set    라인 안   워드 안
     확인용                 중 선택     4워드     4바이트

각 필드가 하는 일

byte (addr[1:0]):
  워드(4바이트) 안에서 어느 바이트
  → byte enable로 선택

word (addr[3:2]):
  캐시 라인(16B=4워드) 안에서 어느 워드
  → 2^2 = 4워드

set (addr[9:4]):
  64개 set 중 어디에 매핑되나
  → 2^6 = 64 set

tag (addr[31:10]):
  같은 set에 여러 주소가 매핑되므로
  → 태그로 "진짜 이 주소 맞나" 확인
  → 4개 way의 태그와 비교

왜 이렇게 나누나 (지역성)

낮은 비트(byte/word) = offset
  → 인접 주소는 같은 라인 → 공간 지역성 활용

중간 비트(set) = index
  → 주소를 64개 set에 분산

높은 비트(tag) = 나머지
  → 같은 set 안에서 구분

3. 타입 정의 (typedef)

typedef logic [SET_BITS-1:0]       set_t;       // set 번호 (6비트)
typedef logic [TAG_BITS-1:0]       tag_t;       // 태그 (22비트)
typedef logic [WAY_BITS-1:0]       way_t;       // way 번호 (2비트)
typedef logic [WORD_BITS-1:0]      word_t;      // word 번호 (2비트)
typedef logic [DATA_ADDR_BITS-1:0] data_addr_t; // 데이터 주소 (8비트)
typedef logic [BE_WIDTH-1:0]       be_t;        // byte enable (4비트)

typedef = 타입에 이름 붙이기

logic [5:0] 대신 set_t
→ 코드가 의미로 읽힘: set_t set = get_set(addr);
→ 폭이 바뀌어도 typedef만 고치면 됨

이름 규칙: _t 접미사 = type

4. Controller FSM — 상태 정의

typedef enum logic [2:0] {
    ST_IDLE     = 3'd0,
    ST_WB_READ  = 3'd1,   // dirty victim을 데이터 배열에서 읽기
    ST_WB_SEND  = 3'd2,   // victim을 메인 메모리로 전송
    ST_FILL_REQ = 3'd3,   // 라인 fetch 요청
    ST_FILL_RCV = 3'd4,   // 버스트 받아서 배열에 씀
    ST_COMPLETE = 3'd5    // tag/valid/dirty/PLRU 갱신, CPU 응답
} cache_state_t;

상태 흐름

각 상태의 역할

ST_IDLE:     CPU 요청 대기. hit이면 여기서 바로 처리
ST_WB_READ:  쫓겨날 victim이 dirty면 먼저 데이터 배열에서 읽음
ST_WB_SEND:  읽은 victim을 메인 메모리에 씀 (write-back)
ST_FILL_REQ: 새 라인을 메모리에서 가져오라고 요청
ST_FILL_RCV: 버스트로 오는 데이터를 받아서 배열에 저장
ST_COMPLETE: 태그/valid/dirty/PLRU 갱신하고 CPU에 응답

주석의 핵심 — ST_COMPLETE의 이유

// ST_COMPLETE costs one extra cycle per miss but removes the structural
// conflict between the last fill beat and the pending store's write.

ST_COMPLETE를 따로 둔 이유:

마지막 fill beat(FILL_RCV)와
대기 중인 store의 쓰기가 같은 사이클에 충돌
→ 구조적 충돌 (structural conflict)

해결: 완료 사이클을 하나 더 둠 (ST_COMPLETE)
→ miss당 1사이클 손해
→ 대신 충돌 제거

이게 이력서의 combinational loop 이슈와 같은 맥락!
  (구조적 충돌을 상태 분리로 해결)

write-back / write-allocate와 연결

miss가 나면 (write-allocate):
  victim 있음 + dirty → WB_READ → WB_SEND (메모리에 씀)
  victim 없음 or clean → 바로 FILL_REQ

→ dirty victim만 write-back (깨끗하면 그냥 덮어씀)
→ write-back 정책: 캐시에만 쓰다가 쫓길 때 메모리로

5. Tag 배열 구조

typedef struct packed {
    tag_t tag;
} tag_data_t;

태그 배열의 한 엔트리 = 태그만 담음

주석: "valid/dirty live in flops in the core (so reset flushes the
       whole cache in one cycle); only the tag needs an SRAM."

valid/dirty는 플립플롭에 (SRAM 아님)
  → 리셋 시 한 사이클에 전체 캐시 무효화 가능
  (SRAM은 한 번에 리셋 못 함)

태그는 SRAM에
  → 용량이 크니까 (22비트 × 256엔트리)

struct packed = 구조체를 비트로 촘촘히 packing

왜 valid/dirty를 플롭에?
  리셋하면 모든 valid=0 되어야 함 (캐시 비우기)
  SRAM은 일괄 리셋 불가 → 플롭이면 한 사이클에 전부 0
  태그는 valid=0이면 어차피 무시되므로 리셋 불필요 → SRAM OK

6. 주소 헬퍼 함수

주소에서 각 필드를 뽑는 함수들. 단일 진실 공급원.

function automatic set_t get_set(input logic [ADDR_WIDTH-1:0] addr_in);
    return addr_in[OFFSET_BITS +: SET_BITS];       // addr[4 +: 6] = addr[9:4]
endfunction

function automatic tag_t get_tag(input logic [ADDR_WIDTH-1:0] addr_in);
    return addr_in[ADDR_WIDTH-1 -: TAG_BITS];      // addr[31 -: 22] = addr[31:10]
endfunction

function automatic word_t get_word(input logic [ADDR_WIDTH-1:0] addr_in);
    return addr_in[BYTE_BITS +: WORD_BITS];        // addr[2 +: 2] = addr[3:2]
endfunction

+: 와 -: 문법

+: = "시작 비트부터 위로 N비트"
addr[4 +: 6] = addr[4], addr[5], ... addr[9] = addr[9:4]

-: = "시작 비트부터 아래로 N비트"
addr[31 -: 22] = addr[31], addr[30], ... addr[10] = addr[31:10]

왜 이 문법? 폭(TAG_BITS 등)이 파라미터라
          addr[31:10] 처럼 못 씀 (숫자 고정)
          → +:/-: 로 "시작점 + 폭"으로 표현

⚠️ 주석의 XSim 함정 (매우 중요)

// the formal argument names are deliberately verbose. Short names
// like `a`, `t`, `i` collide with ordinary loop/local variables at call
// sites, and xsim was observed evaluating the actual argument expression
// in the callee's scope when the names matched — silently passing 0.

XSim 버그:
  함수 인자 이름이 호출부의 변수 이름과 같으면
  → XSim이 엉뚱한 스코프에서 값을 읽음
  → 조용히 0이 전달됨! (에러 없이)

예: get_set(a) 호출 시 인자 이름도 a면 충돌

해결: addr_in처럼 긴 이름 사용
  → 짧은 이름(a, t, i)이 루프 변수와 겹치는 걸 회피

→ AXI SVA의 vacuous assertion과 같은 종류의 XSim 함정
→ "조용히 틀린 값" = 가장 위험한 버그

이건 면접에서 좋은 이야깃거리예요. "시뮬레이터의 조용한 버그를 어떻게 피했나".

라인 주소 헬퍼

// addr가 속한 라인의 시작(word 0) 주소
function automatic logic [ADDR_WIDTH-1:0] get_line_addr(input logic [ADDR_WIDTH-1:0] addr_in);
    return {addr_in[ADDR_WIDTH-1 : OFFSET_BITS], {OFFSET_BITS{1'b0}}};
endfunction

offset 비트를 0으로 만들어 라인 시작 주소 계산

addr = 0x...1234 (offset=0100 = word 1, byte 0)
  → 상위 비트 유지 + 하위 4비트 0
  → 0x...1230 (라인 시작)

{상위, {4{1'b0}}} = 상위 비트 + 0000 이어붙이기

이건 AXI ref_model의 word_base = a - (a % 4)와 같은 원리예요 (경계 정렬). 여기선 16B 라인 정렬.

// 태그+set으로 라인 주소 재구성
function automatic logic [ADDR_WIDTH-1:0] make_line_addr(input tag_t tag_in, input set_t set_in);
    return {tag_in, set_in, {OFFSET_BITS{1'b0}}};
endfunction

// set+word로 데이터 배열 주소
function automatic data_addr_t make_data_addr(input set_t set_in, input word_t word_in);
    return {set_in, word_in};
endfunction

make_line_addr: {tag, set, 0000} → 라인 주소 조립
  (victim을 메모리에 쓸 때 주소 계산 등)

make_data_addr: {set, word} → 데이터 배열 인덱스
  (SRAM 접근 주소)

7. Tree-PLRU 함수 (핵심)

앞서 개념으로 배운 tree-PLRU의 실제 코드.

localparam int PLRU_BITS = 3;                 // 4-way → 3비트
typedef logic [PLRU_BITS-1:0] plru_t;

3비트 트리 구조

        [bit0]  ← root: 왼쪽{0,1} vs 오른쪽{2,3}
        /      \
   [bit1]    [bit2]
   0 vs 1    2 vs 3

bit0 = 0 → ways{0,1}이 더 오래됨 (victim 후보)
bit0 = 1 → ways{2,3}이 더 오래됨
bit1 → way 0 vs 1 선택
bit2 → way 2 vs 3 선택

victim 선택

function automatic way_t plru_victim(input plru_t plru_in);
    return plru_in[0] ? (plru_in[2] ? way_t'(3) : way_t'(2))
                      : (plru_in[1] ? way_t'(1) : way_t'(0));
endfunction

루트부터 화살표 따라 내려가며 victim 결정:

plru[0]=0 → 왼쪽으로
  plru[1]=0 → way 0
  plru[1]=1 → way 1
plru[0]=1 → 오른쪽으로
  plru[2]=0 → way 2
  plru[2]=1 → way 3

way_t'(3) = 3을 way_t 타입으로 캐스트

예시

plru = 3'b101 (bit0=1, bit1=0, bit2=1)

plru[0]=1 → 오른쪽
plru[2]=1 → way 3

→ victim = way 3

PLRU 갱신 (접근 시)

function automatic plru_t plru_update(input plru_t plru_in, input way_t way_in);
    plru_t nxt = plru_in;
    nxt[0] = ~way_in[1];
    if (way_in[1] == 1'b0) nxt[1] = ~way_in[0];
    else                   nxt[2] = ~way_in[0];
    return nxt;
endfunction

"방금 접근한 way의 반대로 화살표를 돌림"
(그 way를 victim에서 멀어지게 = 최근 사용 표시)

way_in을 이진수로 보면:
  way 0 = 00, way 1 = 01, way 2 = 10, way 3 = 11
  way_in[1] = 상위 비트 (왼쪽/오른쪽)
  way_in[0] = 하위 비트 (쌍 안에서)

nxt[0] = ~way_in[1]:
  way 0,1 접근(way_in[1]=0) → nxt[0]=1 (오른쪽 가리킴, 0/1 보호)
  way 2,3 접근(way_in[1]=1) → nxt[0]=0 (왼쪽 가리킴, 2/3 보호)

if 분기:
  왼쪽 쌍(0,1) 접근 → nxt[1] 갱신
  오른쪽 쌍(2,3) 접근 → nxt[2] 갱신
  → 해당 쌍 안에서도 접근한 것 반대로

예시로 따라가기

초기 plru = 000, way 2에 접근

way 2 = 10 → way_in[1]=1, way_in[0]=0

nxt[0] = ~way_in[1] = ~1 = 0  (왼쪽 가리킴, way 2,3 보호)
way_in[1]=1이므로 else 분기:
  nxt[2] = ~way_in[0] = ~0 = 1  (way 3 가리킴, way 2 보호)

결과 plru = 3'b100 (bit2=1, bit0=0)

이제 victim 찾으면:
  plru[0]=0 → 왼쪽 → plru[1]=0 → way 0
  → way 2를 방금 썼으니 way 0이 victim (오래된 것) ✅

왜 이 파일이 중요한가

이 패키지 하나가 캐시 전체의 기반:

주소 분해   → 컨트롤러가 hit/miss 판정하는 근거
FSM 상태    → 컨트롤러 동작의 뼈대
PLRU 함수   → victim 선택 로직
헬퍼 함수   → 모든 파일이 공유하는 주소 계산

→ 여기가 정확해야 캐시 전체가 정확
→ "단일 진실 공급원"이라 버그가 여기 있으면 전체 영향

한 줄 요약

l1_cache_pkg = 캐시의 설계도 상수 + 도구 모음

① geometry: 4-way, 64 set, 16B line = 4KB
② 주소 분해: [tag 22 | set 6 | word 2 | byte 2]
③ typedef: set_t, tag_t, way_t 등 (의미 있는 타입)
④ FSM: IDLE→WB_READ→WB_SEND→FILL_REQ→FILL_RCV→COMPLETE
⑤ tag 배열: 태그만 SRAM, valid/dirty는 플롭(리셋용)
⑥ 헬퍼: get_set/tag/word, +:/-: part-select
⑦ tree-PLRU: 3비트로 4-way victim 선택/갱신

핵심 디테일:
  - ST_COMPLETE 분리 → 구조적 충돌 해결 (combinational loop 맥락)
  - 긴 인자 이름 → XSim의 조용한 0 전달 버그 회피
  - valid/dirty 플롭 → 한 사이클 캐시 무효화

다음 편 예고

이 패키지의 정의들이 실제로 쓰이는 곳:

• 캐시 컨트롤러 (FSM 구현, hit/miss 판정)
• 데이터 배열 / 태그 배열 (SRAM)
• UVM 검증 환경 (golden model이 이 주소 분해를 독립 구현)

특히 이력서의 combinational loop 버그는 컨트롤러의 stall 경로에서 나오는데, 그때 이 FSM과 주소 헬퍼가 어떻게 얽히는지가 핵심이 됩니다.

DV Intern interview preparation Speak these out loud until they feel natural. Keep answers ~30-60 seconds each.

How to use this

• Bold = the one-sentence answer (lead with this)
• Then 2-3 supporting sentences
• ⭐ = high priority, almost certain to be asked

Part 1: UVM Architecture

Q1. ⭐ Why are UVM components split into phases? What is the order and direction of build / connect / run?

Phases give every component a synchronized, predictable lifecycle, so construction, connection, and execution never overlap.

build_phase runs top-down — the test builds the env, the env builds the agent, the agent builds the driver and monitor. This order matters because a parent must create and configure a child before the child builds itself. connect_phase runs bottom-up and wires the TLM ports together, for example connecting the driver's seq_item_port to the sequencer's export. run_phase is the only time-consuming phase, where the actual stimulus runs. Splitting these prevents a component from trying to connect to something that doesn't exist yet.

Q2. ⭐ Why do we need config_db? What happens without it?

config_db is how the testbench passes configuration and the virtual interface down the hierarchy without hard-coding dependencies.

The classic use is the virtual interface: tb_top sets it into config_db, and the driver and monitor get it in their build phase. Without config_db, I'd have to manually pass handles through every constructor, which breaks encapsulation and makes the environment rigid. It also lets me override behavior — like changing max_outstanding from a test — without touching the agent or driver code.

The key pattern is set at a higher level and get at a lower level, matched by a string key like "vif" or "cfg".

Q3. ⭐ Why use the factory? What's the difference between new and type_id::create?

The factory lets me swap component or object types at runtime without editing the code that instantiates them.

new constructs a fixed, hard-coded type — whatever class name I wrote. type_id::create asks the factory which type to build, so a test can override it, for example replacing the base sequence item with an error-injecting subclass. For sequence items and components I always use create; new would defeat the purpose of the factory. In my environment, the derived tests rely on this — they override get_seq() to return different sequence types, all through the factory.

Q4. ⭐ How do the driver and sequencer communicate?

Through a TLM pull port — the driver pulls sequence items from the sequencer one at a time.

The driver calls get_next_item(), which blocks until a sequence produces an item; it drives that item onto the pins, then calls item_done(). On the sequence side, start_item and finish_item are the matching handshake. In my pipelined driver, the twist is that I call item_done() immediately after queuing the burst, not after it finishes on the bus — that's what lets the sequence run ahead and create multiple outstanding transactions.

Q5. Why is the monitor separate from the driver?

Because they answer different questions: the driver drives the protocol, the monitor passively observes what actually happened on the pins.

If the monitor reused the driver's internal knowledge, it would check the testbench's intent against itself, not against the DUT. Keeping it separate means the monitor reconstructs transactions purely from pin activity, so it can catch cases where the DUT did something different from what the driver sent. It also makes the monitor reusable in passive mode, where there's no driver at all.

Q6. Why is the analysis port 1:N?

So one observed transaction can fan out to multiple subscribers that each analyze it differently.

In my environment the monitor's analysis port connects to both the scoreboard and the coverage collector. The scoreboard asks "was it correct?" and coverage asks "did we exercise it?" — two independent questions on the same data. A 1:N port means I can add more subscribers, like a second coverage model or a logger, without changing the monitor at all.

Q7. ⭐ What happens if you don't raise an objection?

The run phase ends immediately, so the simulation finishes before the stimulus even runs.

Objections tell UVM "I still have work to do, don't end the phase." I raise one before starting the sequence and drop it after draining. Without it, run_phase would return right away. This is also why draining matters in my pipelined driver — I have to keep the objection raised until the driver goes idle, otherwise the last bursts get cut off mid-flight and the scoreboard never checks them.

Part 2: Verification Methodology

Q8. ⭐ How does the scoreboard know the correct answer?

It doesn't know in advance — it records observed writes into an independent reference model, then predicts read data from that model.

When the monitor reports a write burst, the scoreboard applies it to the reference model, storing the written bytes at spec-correct addresses. When a read comes back, the scoreboard asks the model what those addresses should contain and compares byte by byte. So the "answer" comes from the write values I actually observed, while the addressing rules come from the AXI spec — specifically the beat_addr() function that implements correct FIXED/INCR/WRAP addressing.

Q9. ⭐ Why build the reference model independently of the DUT?

If the model copies the DUT's implementation, it inherits the DUT's bugs, and both agree while both are wrong.

I wrote the model from the AXI spec, not from the RTL. That's exactly why it caught the WRAP bug: the model wraps addresses correctly per spec, while the DUT incremented them linearly. Because the two derive the address differently, they disagreed, and the scoreboard flagged it. A model built by reading the DUT code would have made the same mistake and passed silently.

Q10. ⭐ Does 100% functional coverage mean verification is done?

No — coverage only means I exercised those scenarios, not that they were correct.

Coverage answers "did I stimulate this?" while the scoreboard and assertions answer "was it right?" You can hit 100% coverage with a weak checker and still miss bugs. In fact I hit exactly this problem earlier in another project: my regression passed while an assertion was silently not firing — high coverage, blind checker. So coverage is necessary to show completeness, but it's meaningless without strong checking behind it.

Q11. ⭐ When do you use ignore_bins? What's the risk of overusing it?

I use it to exclude bins that are structurally unreachable, so they don't hold coverage below 100% forever.

For example, on a 32-bit bus a transfer size above 4 bytes can never happen, and a single-beat WRAP burst is illegal by spec, so those bins are ignored. The rule I follow is that every ignore must be justified — I can explain why it's physically impossible. The risk of overuse is hiding a real hole: if I ignore a bin just because it's hard to hit, I'm claiming coverage I don't actually have. That turns 100% into a lie.

Q12. ⭐ What's the difference between SVA and the scoreboard? Why didn't SVA catch the WRAP bug?

SVA checks protocol rules cycle by cycle; the scoreboard checks data correctness per transaction. They operate at different levels.

My assertions check things like VALID staying asserted until READY, payload stability, and WLAST landing on the right beat. The WRAP bug wasn't a protocol violation — every handshake was legal, WLAST was in the right place, the burst was well-formed. The bytes just landed at the wrong addresses. That's a data-correctness question, which only the scoreboard's byte-level comparison against the reference model could catch. So they're complementary: SVA guards the protocol, the scoreboard guards the data.

Q13. Can bugs remain even at 100% coverage?

Yes — coverage is only as complete as the coverage model I wrote.

If I never defined a coverpoint or cross for some condition, hitting 100% says nothing about it. Coverage measures what I chose to measure. A scenario I didn't think to model is invisible to the coverage number. That's why coverage, scoreboard, and assertions are three separate axes — no single one is sufficient.

Part 3: AXI Protocol

Q14. ⭐ What are the handshake rules? When can VALID be deasserted?

A transfer happens on any rising clock edge where both VALID and READY are high. VALID must stay asserted until that handshake completes.

The key rules: the source may assert VALID without waiting for READY — waiting on both sides would deadlock. Once VALID is high, it cannot drop until READY is seen. READY, on the other hand, can change freely. So VALID can only be deasserted after the handshake, never before. My assertions enforce exactly this — VALID held until READY, and payload stable while stalled.

Q15. Why does the 4KB boundary rule exist?

Because memory is managed in 4KB pages, and a single burst crossing a page could hit two regions with different properties or permissions.

A page boundary might separate cached from uncached memory, or valid from unmapped addresses. If one burst spanned that line, the slave couldn't handle it coherently. So AXI forbids a single burst from crossing a 4KB boundary. In my sequence item, a constraint enforces that the start offset plus the total transfer size stays within the page.

Q16. Why are WRAP lengths limited to 2, 4, 8, or 16 beats?

Because the wrap boundary is implemented by masking address bits, which only works cleanly when the window size is a power of two.

WRAP is used for cache-line fills, where the critical word is fetched first and the address wraps within the aligned line. To wrap, the hardware computes base = addr & ~(total-1), and that masking is only valid if total is a power of two — which forces the beat count to 2, 4, 8, or 16. In my item, a constraint restricts WRAP bursts to lengths 1, 3, 7, 15, which encode those beat counts.

Q17. In a narrow transfer, how is wstrb determined?

By the address and size — the active byte lanes are the ones the current beat's address maps to within the bus width.

If the transfer is narrower than the bus, only some lanes are valid each beat, and which lanes shift as the address increments. In my item, lane_mask() computes this: it takes the beat address modulo the bus width to find the starting lane, then sets size bytes from there. Randomized strobes are masked down to these legal lanes — deasserting some is still legal, but driving lanes outside the addressed range is not.

Q18. How does a slave support outstanding transactions?

By accepting a new address before the previous transaction's response is sent, usually with an internal queue that tracks in-flight requests by ID.

A single-outstanding slave holds AWREADY low until it finishes the current burst. A multi-outstanding slave buffers several accepted addresses and processes them in order or by ID. In my environment, the v2 DUT has an outstanding depth of 4, and my driver proves it reached the DUT using peak-concurrency counters — the single-outstanding v1 can never push those above 1.

Part 4: Project-Specific

Q19. ⭐ Why did you separate AW and W in the driver?

So the address and data channels run independently, which is what allows multiple bursts to overlap on the bus.

If I drove AW then W then waited for B in a single loop, a second address could never be issued while the first burst's data was still going — no outstanding transactions, so the slave's outstanding logic never gets exercised. Running AW, W, and B as separate threads lets the address channel keep issuing while data and responses proceed in parallel. That's the whole point of a pipelined driver.

Q20. ⭐ In a pipelined driver, how do you stop a read from overtaking a write?

I run writes and reads as separate passes with a drain in between, because the AXI read and write channels are independent.

If I mixed them freely, a read could reach the slave before an earlier write to the same address had completed, and I'd read stale data — a false failure. So in my outstanding test, phase one issues all the writes and drains until the driver is idle, then phase two issues the reads. That guarantees every write has landed before any read-back, preserving ordering across the independent channels.

Q21. ⭐ What symptom appears if the monitor can't keep up with outstanding transactions?

The monitor silently drops bursts, and the scoreboard reports false mismatches or missing transactions that look like DUT bugs.

This actually happened in my project — I saw 48 scoreboard failures and initially suspected the DUT. Root-causing it, the problem was the monitor: under overlapping traffic it lost track of a burst because it wasn't correlating address and data phases correctly. The fix was a channel-parallel monitor with FIFO-based correlation, one queue per phase, so it can reconstruct transactions no matter how many are in flight. The lesson was that a scoreboard failure isn't always a DUT bug — the environment can be wrong too.

Q22. ⭐ How did you confirm the assertions actually work?

With negative testing — I deliberately introduced a failing condition and confirmed the assertion fired.

This mattered especially because of a simulator quirk: Vivado XSim silently ignores assertions with untyped property arguments or dynamic arrays, which makes the whole checker vacuous with no error at all. So "no assertion failures" could mean the checks are passing, or it could mean they're not running. I proved they were live by writing a self-test assertion that must fail and confirming it did. That's the same principle as fixing a blind pass criterion — I verify that the checker fails when it should, not just that it passes.

Part 5: Deeper UVM (frequently asked follow-ups)

Q23. ⭐ What is a virtual interface and why is it needed?

It's a handle that lets dynamic UVM class objects reach the static hardware pins, which they otherwise can't touch.

UVM components are class objects created at runtime, but the DUT and interface are static hardware elaborated at time zero. A class can't directly connect to a physical signal. The virtual interface is a pointer to the actual interface instance, passed in through config_db, so the driver can drive vif.master_cb.awvalid and the monitor can sample it. Without it, there's no bridge between the object world and the pin world.

Q24. ⭐ What's the difference between a sequence and a sequence item?

A sequence item is one transaction — the data; a sequence is the program that generates a stream of them — the behavior.

The item, my axi4_seq_item, holds the address, length, size, burst type, and data for a single burst. The sequence's body() task decides how many items to create, with what constraints, and in what order — for example write-then-read-back, or a directed corner-case sweep. The same item is reused by every sequence; only the generation logic changes. That separation is why I can have one item class and a dozen sequences.

Q25. What is the difference between uvm_component and uvm_object?

Components are permanent and live in the hierarchy with phases; objects are transient data that flow through the components.

Driver, monitor, scoreboard, and agent are components — they're built once, have a parent, and run through build/connect/run phases. Sequence items and the reference model are objects — they're created and discarded freely and have no phases. A quick test: if it has a fixed place in the testbench tree and a lifecycle, it's a component; if it's data being passed around or randomized, it's an object.

Q26. ⭐ Walk me through what happens from run_test() to the first pin wiggle.

run_test builds the test, the test builds the environment top-down, ports connect bottom-up, then run_phase starts the sequence which feeds the driver.

run_test creates the test via the factory. The test's build phase creates the cfg, pulls the virtual interface from config_db, and builds the env. The env builds the agent, scoreboard, and coverage; the agent builds the sequencer, driver, and monitor. In connect phase, the driver's port binds to the sequencer's export and the monitor's analysis port binds to the scoreboard and coverage. Then run_phase raises an objection, starts the sequence, the sequence produces an item, the driver pulls it with get_next_item, and drives it onto vif — that's the first pin wiggle.

Q27. How does UVM know when to end the simulation?

When all raised objections have been dropped, the run phase ends and UVM moves to the cleanup phases.

Every component that has ongoing work raises an objection; the phase stays alive as long as any objection is outstanding. In my test, I raise one before the sequence and drop it after draining the pipeline. Once dropped and no one else is holding one, UVM proceeds to extract, check, and report phases, where the scoreboard and coverage print their final results.

Q28. Why randomize with constraints instead of just writing directed tests?

Constrained-random explores combinations I wouldn't think to write by hand, while constraints keep every generated case legal.

Directed tests only cover what I explicitly code, so I'll miss unexpected corners. Constrained-random generates legal-but-surprising combinations and, with enough seeds, fills coverage far faster. But randomness alone plateaus — in my project it stalled at 98.3%. So the real strategy is both: constrained-random for breadth, then directed sweeps to close the specific bins randomness kept missing. Constraints are what make the random stimulus legal in the first place.

Part 6: Debugging & Pressure Questions

Q29. ⭐ A test is failing. Walk me through how you debug it.

First I decide whether it's a DUT bug or an environment bug, because those lead to completely different fixes.

I start from the scoreboard error — it tells me the beat, lane, address, expected value, and actual value. I check whether the reference model's prediction is right by hand for that one transaction; if the model is wrong, it's an environment bug. If the model is right, I look at the waveform at that exact address and time to see what the DUT actually drove. I also check whether the monitor reconstructed the transaction correctly, because I've been burned before by the monitor dropping bursts and masquerading as a DUT bug. Only once I've localized it do I fix — and I re-run to confirm the fix and confirm I didn't mask something else.

Q30. ⭐ How do you know your testbench itself is correct?

I verify that it fails when it should — a checker that never fails is worthless, and a passing test proves nothing on its own.

Two concrete ways I did this. First, negative testing on the assertions: I injected a deliberately failing self-test and confirmed it fired, because XSim silently ignores certain assertion forms and would otherwise pass vacuously. Second, running the regression against a known-buggy DUT revision — it must fail on v1 and pass on v2. If a testbench passes on buggy hardware, the testbench is broken. That's the same lesson as fixing a blind pass criterion: I check that failure is detectable, not just that success is reported.

Q31. Your reference model and the DUT disagree. How do you know which one is wrong?

I work out the correct answer from the spec by hand for that single case, independent of both.

The reference model and the DUT are both just implementations that could be wrong. So I go back to the AXI spec and manually compute what should be at that address for that burst. Whichever matches the spec is right. In the WRAP case, I traced the wrap window by hand — base address, window size, wrap point — and the reference model matched the spec while the DUT didn't. That confirmed it was a real DUT bug, not a modeling error.

Q32. What would you add if you had more time on this project?

Error-response testing and out-of-order ID handling — two things the current DUT and environment don't exercise.

The DUT hardwires responses to OKAY, so I ignore the error-response bins today; with a DUT that can signal SLVERR or DECERR, I'd add stimulus and checks for those. I'd also test out-of-order completion by ID, which a more capable slave supports and my current single-ID-per-burst approach doesn't stress. On the environment side, I'd add random backpressure on the master's READY signals to exercise the slave's response-buffering under stall, which my always-ready driver doesn't cover today.

Q33. How would this environment scale to multiple masters or a full interconnect?

I'd instantiate multiple agents, make the scoreboard interconnect-aware, and add ID-based routing checks.

Each master becomes its own active agent with its own sequencer and driver, all reusing the same item and interface. The scoreboard has to become aware of which master owns which transaction — typically by ID or by a per-master address map — so it predicts and checks per source. I'd also add assertions for interconnect properties like ID uniqueness and response routing. The agent/env structure is built for this: adding an agent doesn't change the existing components.

Q34. What's the hardest part of verifying outstanding transactions specifically?

Correlation — matching each response back to the right outstanding request when several are in flight at once.

On the driving side it's easy to just keep issuing addresses. The hard part is the monitor and scoreboard: when responses can come back while multiple bursts are still open, the monitor has to correlate the address phase with the correct data and response phase. I solved it with one FIFO per phase, moving a transaction from queue to queue as each phase completes. If that correlation is even slightly wrong, transactions get mismatched and you get false failures that look exactly like DUT bugs.

Rapid-fire summary (one-liners to memorize)

build_phase        → top-down (parent builds child)
connect_phase      → bottom-up (wire TLM ports)
config_db          → set high, get low, by string key
factory/create     → runtime type override
virtual interface  → bridges class objects to static pins
get_next_item      → driver pulls from sequencer
analysis port 1:N  → one transaction, many subscribers
objection          → keeps run_phase alive; all dropped → sim ends
component vs object → hierarchy+phases vs transient data
sequence vs item   → behavior (program) vs data (transaction)
reference model    → independent, spec-based (not DUT-based)
coverage 100%      → "exercised", not "correct"
ignore_bins        → unreachable only, must justify
SVA                → protocol, cycle-level
scoreboard         → data, transaction-level
4KB boundary       → pages have different properties
WRAP 2/4/8/16      → power-of-two for bit masking
AW/W split         → enables outstanding
drain between W/R  → prevents read overtaking write
negative test      → proves assertions aren't vacuous
debug first step   → DUT bug or environment bug?
outstanding hard   → correlation, one FIFO per phase

The three stories that tie it together

If an interviewer asks an open-ended "tell me about a hard bug," these three carry the whole interview:

1. The WRAP bug (data correctness) Independent reference model wrapped correctly, DUT incremented linearly. A symmetric WRAP-write / WRAP-read hid it because the DUT was consistently wrong on both sides. I designed an asymmetric WRAP-write / INCR-read cross-check that exposed 24 byte-level mismatches.

2. The 48 false failures (environment vs DUT) Scoreboard reported failures I first blamed on the DUT. Root cause was the monitor silently dropping bursts under outstanding traffic. Taught me a scoreboard failure can be an environment bug.

3. The vacuous checker (verifying the verification) XSim silently ignored assertions with untyped arguments — the checker looked like it passed but wasn't running. I proved liveness with a deliberately failing self-test. Same principle as fixing a blind regression pass criterion.

Common thread: I don't just find bugs — I understand why they stayed hidden, and I change the verification method to expose them.

시리즈: ... · sequences · coverage · SVA

SVA란

SVA = SystemVerilog Assertions
    = "프로토콜 규칙을 매 사이클 자동으로 감시하는 감시자"

스코어보드/커버리지가 "완성된 버스트"를 사후 검사한다면,
SVA는 "매 클록마다" 프로토콜 위반을 실시간 감시

앞서 배운 VALID/READY 골든 룰을 코드로 자동 감시하는 게 이 파일이다. 이력서의 "~25 bind-based SVA protocol assertions"의 실제 구현.

스코어보드/커버리지와 다른 위치

스코어보드: "완성된 버스트가 맞나?" (트랜잭션 단위, 사후)
커버리지:   "이 조합을 봤나?" (트랜잭션 단위, 사후)
SVA:        "지금 이 클록에 프로토콜 위반했나?" (사이클 단위, 실시간)

예: VALID를 올렸다가 READY 전에 내리면
  → 스코어보드는 모름 (데이터만 봄)
  → SVA는 그 순간 즉시 에러! ✅

flowchart LR
    BUS["AXI 버스<br/>매 클록 신호"]
    BUS -->|매 사이클 감시| SVA["SVA<br/>프로토콜 위반?<br/>(실시간)"]
    BUS -->|완성된 버스트| SB["Scoreboard<br/>데이터 맞나?<br/>(사후)"]
    BUS -->|완성된 버스트| COV["Coverage<br/>조합 봤나?<br/>(사후)"]

bind — RTL을 안 건드리고 주입

// Written as a standalone module and `bind`-ed into tb_top, so the
// checks are injected without touching the interface, the testbench
// or the RTL.

이게 SVA의 핵심 설계 패턴이다.

bind = 별도 모듈을 기존 모듈에 "붙이는" 문법

axi4_sva를 독립 모듈로 작성
→ bind로 tb_top에 주입
→ 인터페이스/테스트벤치/RTL 코드를 하나도 안 건드림!

장점 (실무 표준):
  프로토콜 체커가 설계 밖에 존재
  → 자유롭게 붙였다 뗐다 가능
  → +define+AXI4_NO_SVA로 통째로 제거 가능

왜 tb_top에 bind하나 (interface가 아니라)

// a module may not be instantiated inside an interface
// (XSim rejects that with VRFC 10-3535). Binding at tb_top gives one
// checker instance that works with either DUT.

interface 안에는 module을 못 넣음 (XSim 제약)
→ tb_top에 bind
→ 두 DUT(v1/v2) 다 같은 인터페이스에 연결되므로
  체커 하나가 양쪽 다 커버

bind tb_top axi4_sva u_axi4_sva (
    .clk     (clk),
    .awid    (axi.awid),
    ...
);

"tb_top 안에 axi4_sva를 u_axi4_sva라는 이름으로 붙여라"
신호는 tb_top의 axi 인터페이스 신호에 연결

⚠️ XSim 제약 — 이 파일의 숨은 고생

주석 곳곳에 XSim(Vivado 시뮬레이터)의 함정이 기록돼있다. 이게 이력서의 "validated assertion liveness via negative testing"의 배경이다.

함정 1 — untyped property argument가 조용히 무시됨

// properties with *untyped* formal arguments are silently ignored by
// Vivado XSim — "untyped port "valid" found ... It will be ignored."
// which makes the whole checker vacuous without any error.

문제:
  파라미터화된 property를 쓰면
  XSim이 조용히 무시함 (에러도 없이!)
  → 체커가 아무것도 안 하는데 "통과"로 보임 (vacuous = 공허한)

이게 앞서 배운 blind pass criterion과 같은 위험!
  → 체커가 눈멀어있는데 아무도 모름

해결:
  파라미터 property 대신 매크로로 인라인 확장
  → 각 assertion을 직접 펼침

함정 2 — dynamic array가 assertion에서 무시됨

// XSim cannot evaluate dynamic arrays/queues inside a concurrent
// assertion ("Dynamic array inside concurrent assertion. It will be
// ignored." — silently vacuous!). So the outstanding-address tracker is
// a STATIC circular buffer.

문제:
  outstanding 추적에 queue를 쓰고 싶은데
  XSim이 assertion 안의 dynamic array를 무시 → 또 vacuous

해결:
  static circular buffer(고정 크기 원형 버퍼)로 구현
  → assertion은 거기서 뽑은 scalar만 참조

그래서 negative testing으로 검증

// the checker was validated with a deliberately failing self-test assertion.

체커가 "진짜 동작하는지" 확인하려고
일부러 실패하는 assertion을 넣어봄
→ 정말 FAIL 나는지 확인
→ "vacuous가 아니라 실제로 감시 중"임을 증명

= assertion liveness 검증 (체커를 검증하는 것)

매크로 — 인라인 확장

`define AXI_VALID_HELD(nm, vld, rdy)                                     \
    nm: assert property (@(posedge clk) disable iff (rst)                 \
        ((vld) && !(rdy)) |=> (vld))                                      \
        else $error("AXI-SVA: %s - VALID de-asserted before READY", `"nm`");

`define AXI_STABLE(nm, vld, rdy, sig)                                    \
    nm: assert property (@(posedge clk) disable iff (rst)                 \
        ((vld) && !(rdy)) |=> $stable(sig))                               \
        else $error("AXI-SVA: %s - payload changed while stalled", `"nm`");

매크로 = property를 파라미터화하는 대신 텍스트로 펼치기
  (XSim의 untyped argument 함정 회피)

nm  = assertion 이름
vld = VALID 신호
rdy = READY 신호
sig = 안정성 체크할 payload

`"nm`" = 매크로 인자를 문자열로 (에러 메시지용)

assertion 종류별 정리

1. VALID 유지 (골든 룰 2)

`AXI_VALID_HELD(a_awvalid_held, awvalid, awready)
`AXI_VALID_HELD(a_wvalid_held,  wvalid,  wready)
`AXI_VALID_HELD(a_bvalid_held,  bvalid,  bready)
`AXI_VALID_HELD(a_arvalid_held, arvalid, arready)
`AXI_VALID_HELD(a_rvalid_held,  rvalid,  rready)

규칙: VALID를 올렸으면 READY 올 때까지 못 내림

((vld) && !(rdy)) |=> (vld)
  = "VALID인데 READY 아직 안 옴" → "다음 사이클에도 VALID"

|=> = "다음 클록에" (overlapping이 아닌 next-cycle implication)

5개 채널 전부 감시 → 앞서 배운 골든 룰 2의 자동화

2. Payload 안정 (골든 룰)

`AXI_STABLE(a_awaddr_stable,  awvalid, awready, awaddr)
`AXI_STABLE(a_awlen_stable,   awvalid, awready, awlen)
...
`AXI_STABLE(a_wdata_stable,   wvalid,  wready,  wdata)
...

규칙: 전송이 stall된 동안 payload가 바뀌면 안 됨

((vld) && !(rdy)) |=> $stable(sig)
  = "VALID인데 READY 안 옴" → "다음 사이클에 sig가 그대로"

$stable(sig) = 이전 값과 같은지 (안 바뀌었는지)

→ VALID 올려놓고 주소/데이터를 바꾸는 위반 감지
  awaddr, awlen, awsize, awburst, awid,
  wdata, wstrb, wlast, araddr..., bresp, rresp, rlast 전부

3. 예약/불법 인코딩

a_awburst_legal: assert property (@(posedge clk) disable iff (rst)
    awvalid |-> awburst != 2'b11)
    else $error("AXI-SVA: AWBURST uses the reserved encoding 2'b11");

a_awsize_fits: assert property (@(posedge clk) disable iff (rst)
    awvalid |-> ((1 << awsize) <= STRB_WIDTH))
    else $error("AXI-SVA: AWSIZE exceeds the data bus width");

burst 2'b11 = 예약값 (사용 금지) → 쓰면 위반
size가 버스 폭 초과 → 위반 (32비트 버스에 8B 전송 불가)

|-> = "즉시" implication (같은 사이클)
disable iff (rst) = 리셋 중엔 검사 안 함

4. X/Z 감지

a_aw_known: assert property (@(posedge clk) disable iff (rst)
    awvalid |-> !$isunknown({awaddr, awlen, awsize, awburst, awid}))
    else $error("AXI-SVA: X/Z on the AW channel while AWVALID");

VALID인데 payload에 X/Z가 있으면 위반

$isunknown(sig) = sig에 X나 Z가 있나?
!$isunknown(...) = X/Z가 없어야 함

{a, b, c} = 신호들을 이어붙여서 한 번에 검사

→ 앞서 배운 "X 전파" 문제를 프로토콜 레벨에서 감지
  (VALID일 때는 값이 확정돼야 함)

5. 리셋 중 응답 금지

a_no_resp_in_reset: assert property (@(posedge clk)
    rst |-> (!bvalid && !rvalid))
    else $error("AXI-SVA: BVALID/RVALID asserted during reset");

리셋 중엔 BVALID/RVALID가 뜨면 안 됨

rst |-> (!bvalid && !rvalid)
  = "리셋이면" → "bvalid도 rvalid도 0"

이건 disable iff (rst)가 없음! (리셋 중을 검사하는 게 목적이니까)

이게 이력서의 "cycle-accurate SVA catching reset-phase violations"와 연결되는 부분이에요.

6. WLAST/RLAST 위치 (가장 복잡)

버스트 beat 개수와 LAST 위치가 맞는지 검사. outstanding까지 지원하려고 tracker를 쓴다.

localparam int SVA_QDEPTH = 16;
int unsigned aw_len_mem [SVA_QDEPTH];   // static 배열 (dynamic 금지)
int unsigned aw_wr, aw_rd, ar_wr, ar_rd;
int unsigned w_beats, r_beats;

wire aw_pending = (aw_wr != aw_rd);     // 대기 중인 AW 있나
wire [31:0] aw_head = aw_len_mem[aw_rd]; // 가장 오래된 AWLEN

static circular buffer로 outstanding 주소 추적:
  AW 수락되면 → awlen을 버퍼에 저장 (aw_wr++)
  WLAST 오면 → 버퍼에서 제거 (aw_rd++)

w_beats = 현재 몇 번째 W beat인가 카운트
aw_head = 지금 처리 중인 버스트의 예상 길이(AWLEN)

always @(posedge clk) begin
    if (rst) begin ... 리셋 ... end
    else begin
        if (awvalid && awready) begin       // AW 수락
            aw_len_mem[aw_wr] <= awlen;
            aw_wr <= (aw_wr + 1) % SVA_QDEPTH;
        end
        if (wvalid && wready) begin          // W beat
            if (wlast) begin
                w_beats <= 0;
                if (aw_wr != aw_rd) aw_rd <= (aw_rd + 1) % SVA_QDEPTH;
            end
            else w_beats <= w_beats + 1;
        end
        ...
    end
end

% SVA_QDEPTH = 원형 버퍼 (16 넘으면 0으로 되돌아감)

WLAST 위치 검사:

a_wlast_position: assert property (@(posedge clk) disable iff (rst)
    (wvalid && wready && wlast && aw_pending) |-> (w_beats == aw_head))
    else $error("AXI-SVA: WLAST on beat %0d but AWLEN implies beat %0d",
                w_beats, aw_head);

"WLAST가 떴을 때 → 현재 beat 번호가 AWLEN과 같아야"

w_beats == aw_head
  = "지금까지 센 beat 수" == "예상 길이"
  → WLAST가 너무 일찍/늦게 뜨면 위반!

overrun 검사도 있음:
a_w_no_overrun: !wlast일 때 w_beats < aw_head
  = "아직 마지막 아닌데 예상 길이 넘으면" 위반

전체 어서션 지도

합계 33개 (이력서의 "25"는 대략치)

+define+AXI4_NO_SVA — 통째로 끄기

`ifndef AXI4_NO_SVA
    // ... 모든 assertion ...
`endif

+define+AXI4_NO_SVA로 컴파일하면
→ 모든 assertion이 사라짐
→ 체커 없이 순수 시뮬레이션

용도: 디버깅 시 체커 노이즈 제거, 성능 측정 등
bind 패턴 덕에 이런 on/off가 자유로움

SVA vs Scoreboard vs Coverage — 검증의 3축

세 개가 상호보완:
  SVA        → 프로토콜을 어겼는지 (핸드셰이크, 타이밍)
  Scoreboard → 데이터가 틀렸는지 (값)
  Coverage   → 충분히 테스트했는지 (범위)

→ 셋 다 있어야 "규칙 지키고, 정확하고, 빠짐없이" 검증

한 줄 요약

SVA = 프로토콜 규칙을 매 사이클 실시간 감시하는 어서션 체커

bind 패턴:
  독립 모듈로 작성 → tb_top에 주입 → RTL/TB 안 건드림
  +define+AXI4_NO_SVA로 통째로 on/off

감시 항목 (~25+):
  VALID 유지, payload 안정, 불법 인코딩,
  X/Z 감지, 리셋 중 응답 금지, WLAST/RLAST 위치

XSim 함정 (실무 교훈):
  untyped property, dynamic array가 조용히 무시됨 (vacuous)
  → 매크로 인라인 + static buffer로 회피
  → negative testing으로 "진짜 감시 중"임을 증명

검증 3축:
  SVA(규칙) + Scoreboard(정확성) + Coverage(완결성)

시리즈 완결 — 검증의 3축 완성

이제 AXI4 UVM 환경의 정말 모든 파일을 다뤘습니다.

                        tb_top
                            │
                    test → sequence → seq_item
                            │
              cfg/agent/env ─ driver ─ interface ─ DUT
                            │
                        monitor
              ┌─────────────┼─────────────┐
        scoreboard      coverage        SVA
        (맞았나?)       (봤나?)     (규칙 지켰나?)
              │             │             │
          ref_model    covergroup    assertions
              └─────────────┼─────────────┘
                     검증의 3축 완성

검증의 세 가지 질문에 모두 답합니다:

• 정확성: scoreboard가 데이터를 ref_model과 비교 → "맞았나?"
• 완결성: coverage가 시나리오를 추적 → "봤나?"
• 준수성: SVA가 프로토콜을 실시간 감시 → "규칙 지켰나?"

이 셋이 만나 "규칙을 지키며, 정확하고, 빠짐없이 검증했다"는 완전한 신뢰를 만듭니다. 이것으로 AXI4-Full UVM 검증 환경 시리즈를 마칩니다.

시리즈: ... · base_test · sequences · coverage

Coverage란

"우리가 실제로 무엇을 검증했나?"를 추적하는 컴포넌트

스코어보드와는 다른 질문을 던짐:
  스코어보드: "맞았나?" (correctness)
  커버리지:   "이 시나리오를 실행했나?" (completeness)

env에서 monitor의 analysis port에 스코어보드와 함께 연결됐던 그 커버리지다. 같은 트랜잭션을 받아서 "어떤 조합을 봤는지" 체크리스트를 채운다.

• Code Coverage: which lines/branches/states executed (what the RTL DID)
• Functional Coverage: which spec requirements were exercised (What the RTL was supposed to do)
• Assertion Coverage: which assertions actually fired

왜 커버리지가 필요한가

스코어보드만 있으면:
  "실행한 것"은 다 맞는지 확인함
  근데 "무엇을 안 실행했는지"는 모름!

예:
  WRAP 버스트를 한 번도 안 보냈으면?
  → 스코어보드는 "통과"만 보고함 (WRAP 관련 검증 0)
  → "우리가 WRAP을 검증했나?" 답을 못 함

커버리지:
  "WRAP 봤음/안 봤음"을 체크리스트로 추적
  → 안 본 시나리오(구멍)를 드러냄
  → 검증의 완결성(completeness) 측정

이게 이력서의 "100% functional coverage"가 측정하는 것이다.

클래스 선언 — uvm_subscriber

class axi4_coverage extends uvm_subscriber #(axi4_seq_item);
    `uvm_component_utils(axi4_coverage)

    axi4_seq_item   tr;
    axi_strb_kind_e strb_kind;
    int unsigned    n_sampled;

uvm_subscriber — analysis port 받는 전용 베이스

uvm_subscriber #(T):
  → 내장 analysis_export를 가짐
  → write() 함수만 구현하면 트랜잭션을 받음

스코어보드는 uvm_analysis_imp를 수동 선언했는데
커버리지는 uvm_subscriber라 analysis_export가 이미 내장

env의 연결:
  agent.mon.ap.connect(cov.analysis_export);  ← 이 export가 내장된 것

uvm_subscriber = "analysis port 하나만 받으면 되는 컴포넌트"용 축약형
  → write() 하나만 구현하면 끝

strb_kind enum — 파생 값

typedef enum { STRB_NONE, STRB_PARTIAL, STRB_FULL } axi_strb_kind_e;

write strobe의 "전체 모양"을 3가지로 분류:
  STRB_NONE    : 아무 lane도 안 씀
  STRB_PARTIAL : 일부만 씀
  STRB_FULL    : 모든 유효 lane을 다 씀

→ covergroup이 이 분류를 커버 (strobe 다양성 측정)

covergroup — 커버리지 정의 (핵심)

covergroup axi_cg;
    option.per_instance = 1;
    option.name         = "axi4_functional_coverage";
    ...
endgroup

covergroup = "무엇을 추적할지" 정의하는 묶음
  coverpoint = 개별 추적 항목
  cross      = 항목들의 조합 추적
  bins       = 각 항목의 세부 카테고리

option.per_instance = 1 → 인스턴스별로 커버리지 따로 집계

Where should covergroups be sampled? => Monitor

coverpoint 하나씩

cp_dir — 방향

cp_dir: coverpoint tr.dir {
    bins rd = {AXI_READ};
    bins wr = {AXI_WRITE};
}

읽기와 쓰기를 각각 봤나?
  bins rd → 읽기 트랜잭션이 오면 체크
  bins wr → 쓰기 트랜잭션이 오면 체크
둘 다 체크돼야 100%

cp_burst — 버스트 타입

cp_burst: coverpoint tr.burst {
    bins fixed = {AXI_FIXED};
    bins incr  = {AXI_INCR};
    bins wrap  = {AXI_WRAP};
}

FIXED/INCR/WRAP 각각 봤나?
→ WRAP bin은 wrap_seq/cov_seq에서만 채워짐 (일반 시퀀스는 WRAP 제외)

cp_size — 전송 크기 (ignore_bins 등장)

cp_size: coverpoint tr.size {
    bins bytes1 = {0};
    bins bytes2 = {1};
    bins bytes4 = {2};
    ignore_bins too_wide = {[3:7]};   // impossible on a 32-bit bus
}

size 0(1B)/1(2B)/2(4B) 각각 봤나?

ignore_bins too_wide = {[3:7]}
  → size 3~7은 32비트 버스에서 불가능 (8B 이상)
  → "일부러 무시" → 커버리지 계산에서 제외
  → 안 그러면 영원히 100% 못 채움 (도달 불가능한데 카운트되니까)

이게 ignore_bins의 핵심 용도예요.

ignore_bins = "구조적으로 도달 불가능한 것을 명시적으로 제외" → 커버리지 구멍이 아니라 "일부러 뺀 것"임을 문서화

cp_len — 버스트 길이

cp_len: coverpoint tr.len {
    bins single   = {0};            // 1 beat
    bins len_2_4  = {[1:3]};
    bins len_5_8  = {[4:7]};
    bins len_9_16 = {[8:15]};
    ignore_bins beyond = {[16:255]}; // stimulus is constrained to <=16 beats
}

길이를 클래스로 묶어서 추적:
  single / 2-4 / 5-8 / 9-16 beats

ignore_bins beyond = {[16:255]}
  → 자극이 16 beats 이하로 제약됨 → 그 위는 안 나옴 → 무시

범위 bins:
  {[1:3]} = 1,2,3 중 아무거나 오면 이 bin 체크

cp_resp — 응답 (문서화된 DUT 한계)

cp_resp: coverpoint tr.resp {
    bins okay = {AXI_OKAY};
    ignore_bins unreachable = {AXI_EXOKAY, AXI_SLVERR, AXI_DECERR};
}

주석: "The DUT hardwires bresp/rresp to OKAY, so error responses are
       unreachable by construction."

DUT가 항상 OKAY만 응답 → 에러 응답은 절대 안 나옴
→ ignore_bins으로 제외 (DUT 한계를 문서화)
→ "커버리지 구멍이 아니라 의도된 것"

cp_region — 주소 영역

cp_region: coverpoint tr.addr[15:12] {
    bins region[16] = {[0:15]};
}

addr[15:12] = 상위 4비트 = 4KB 영역 구분 (64KB / 4KB = 16개)

bins region[16] = {[0:15]}
  → 16개 bin 자동 생성 (region[0]~region[15])
  → 각 4KB 영역에 접근했나 추적

[15:12] 뽑는 이유:
  64KB 공간을 4KB로 나누면 상위 4비트가 영역 번호
  0x0xxx→0, 0x1xxx→1, ..., 0xFxxx→15

cp_strb — strobe 모양 (조건부 커버)

cp_strb: coverpoint strb_kind iff (tr.dir == AXI_WRITE) {
    bins none    = {STRB_NONE};
    bins partial = {STRB_PARTIAL};
    bins full    = {STRB_FULL};
}

iff (tr.dir == AXI_WRITE)
  = "쓰기일 때만 이 coverpoint를 샘플"
  → 읽기는 strobe가 의미 없으니 (읽기는 전부 1로 채움) 제외

none/partial/full 각각 봤나 → strobe 다양성 측정

iff = 조건부 커버리지 (이 조건일 때만 카운트)

Cross Coverage

x_burst_size : cross cp_burst, cp_size;

x_burst_len  : cross cp_burst, cp_len {
    ignore_bins wrap_single = binsof(cp_burst.wrap) && binsof(cp_len.single);
}

x_dir_burst  : cross cp_dir,   cp_burst;

cross = 두 coverpoint의 "조합"을 추적

• x_burst_size: burst 3종 × size 3종 = 9개 조합 다 봤나?
• x_burst_len: burst × length 조합
• x_dir_burst: 방향 × burst 조합

→ 개별로는 다 봤어도 "조합"으로는 안 봤을 수 있음 예: INCR도 봤고 size1도 봤지만 "INCR+size1"은 안 봤을 수 있음 → cross가 이걸 잡음

Cross coverage tracks combinations of coverpoints. If coverpoint A has 4bins and coverpoint B has 3bins, the cross has 4x3=12bins

State space explosion: Crossing a 32 bit address(4B bins) with a 32 bit data(4B bins) creates 1.8x10^19 bins -> simulator crashes. -> alwasy reduce coverpoints to rchitecturally siginificant bins before crossing.

cross의 ignore_bins

ignore_bins wrap_single = binsof(cp_burst.wrap) && binsof(cp_len.single);

주석: "A WRAP burst must be 2,4,8,16 beats, so a single-beat WRAP
       cannot exist."

WRAP + single(1 beat) 조합은 불가능 (WRAP은 최소 2 beats)
  binsof(cp_burst.wrap) && binsof(cp_len.single)
  = "burst가 wrap이면서 len이 single인" 교차 bin
  → ignore로 제외 (도달 불가능)

binsof(...) = 특정 bin을 지칭하는 문법

이게 이력서의 "formally justifying structurally unreachable bins via ignore_bins"예요.

커버리지 구조 시각화

new() & write()

function new(string name, uvm_component parent);
    super.new(name, parent);
    axi_cg = new();          // covergroup 인스턴스화
endfunction

function void write(axi4_seq_item t);
    tr        = t;
    strb_kind = classify_strb(t);
    axi_cg.sample();         // 커버리지 샘플!
    n_sampled++;
endfunction

write() = monitor가 ap.write(tr) 하면 자동 호출

1. tr에 받은 트랜잭션 저장 (covergroup이 tr을 읽음)
2. strb_kind 계산 (파생 값)
3. axi_cg.sample() → 현재 tr 값으로 모든 coverpoint 체크!
4. 카운트 증가

axi_cg = new() 필수:
  covergroup은 선언만으로 인스턴스 안 됨 → new()로 생성해야 샘플 가능

sample()이 하는 일:
  현재 tr.dir, tr.burst, tr.size... 값을 보고
  해당하는 bin을 체크 (예: tr.burst=INCR이면 cp_burst.incr 체크)

classify_strb() — strobe 분류

protected function axi_strb_kind_e classify_strb(axi4_seq_item t);
    bit all_full = 1;
    bit all_zero = 1;
    foreach (t.strb[i]) begin
        if (t.strb[i] !== t.lane_mask(i)) all_full = 0;
        if (t.strb[i] !== '0)             all_zero = 0;
    end
    if (all_zero) return STRB_NONE;
    if (all_full) return STRB_FULL;
    return STRB_PARTIAL;
endfunction

각 beat의 strobe를 검사:

all_full: 모든 beat가 자기 유효 lane을 다 켰나?
  strb[i] == lane_mask(i) → 그 beat는 full
  하나라도 아니면 all_full = 0

all_zero: 모든 beat가 아무것도 안 켰나?
  strb[i] == 0 → 그 beat는 empty
  하나라도 아니면 all_zero = 0

판정:
  전부 0 → STRB_NONE
  전부 full → STRB_FULL
  그 외 → STRB_PARTIAL

lane_mask(i) = seq_item의 그 함수! (유효 lane 계산)

coverage_report() — 자체 리포트

function string coverage_report();
    coverage_report = {
        "=========== AXI4 functional coverage ===========\n",
        $sformatf("  bursts sampled : %0d\n", n_sampled),
        $sformatf("  %-14s %7.2f %%\n", "cp_dir", axi_cg.cp_dir.get_inst_coverage()),
        ...
        $sformatf("  %-14s %7.2f %%\n", "TOTAL", axi_cg.get_inst_coverage())
    };
endfunction

주석에 중요한 실무 이유가 있다:

// Vivado's external report generator (xcrg) needs a PRO license tier,
// which the free BASIC tier does not have — so we build the report
// from the SystemVerilog coverage API instead.

Vivado 무료 버전은 커버리지 리포트 생성기(xcrg)가 없음
→ SystemVerilog 커버리지 API로 직접 리포트 작성
→ 어떤 시뮬레이터에서도 동작, 무료

get_inst_coverage() = 그 coverpoint/cross의 현재 커버리지 %
  cp_dir.get_inst_coverage() → cp_dir이 몇 % 채워졌나
  axi_cg.get_inst_coverage() → 전체 covergroup 몇 %

출력 예:

=========== AXI4 functional coverage ===========
  bursts sampled : 351
  ---------------------------------------------
  cp_dir          100.00 %
  cp_burst        100.00 %
  cp_size         100.00 %
  cp_len          100.00 %
  cp_resp         100.00 %
  cp_region       100.00 %
  cp_strb         100.00 %
  ---------------------------------------------
  x_burst_size    100.00 %
  x_burst_len     100.00 %
  x_dir_burst     100.00 %
  =============================================
  TOTAL           100.00 %
===============================================

이게 이력서의 "100% functional + cross coverage" 증거 출력이에요.

report_phase()

function void report_phase(uvm_phase phase);
    super.report_phase(phase);
    `uvm_info("COV", coverage_report(), UVM_LOW)
endfunction

시뮬레이션 끝에 커버리지 리포트 출력
→ 스코어보드의 report_phase(미스매치 개수)와 나란히 로그에 찍힘

두 개를 같이 보면:
  스코어보드: "다 맞았나?" (0 mismatch)
  커버리지:   "다 봤나?" (100%)
  → 둘 다 만족해야 검증 완료

스코어보드 vs 커버리지 — 두 질문

왜 둘 다 필요한가 (매우 중요)

커버리지 100%인데 스코어보드 약함:
  → 다 실행했지만 틀린 걸 못 잡음 (체커 부실)

스코어보드 강한데 커버리지 낮음:
  → 실행한 건 정확히 검증하지만 안 본 게 많음 (자극 부족)

→ 둘 다 있어야 "많이 실행하고(coverage) 정확히 검증한다(scoreboard)"

이력서의 blind pass criterion 버그가 이 교훈:
  커버리지는 높은데 체커가 눈멀어있었음
  → coverage ≠ correctness

한 줄 요약

Coverage = "우리가 무엇을 검증했나"를 추적하는 수집기

uvm_subscriber로 monitor의 ap를 받아
  covergroup을 sample() → 각 조합을 봤는지 체크리스트 채움

coverpoint: dir/burst/size/len/region/strb 개별 추적
cross:      조합 추적 (burst×size, burst×len, dir×burst)
ignore_bins: 도달 불가능한 것 제외 (구멍 아니라 의도)

스코어보드와 다른 질문:
  스코어보드 = "맞았나?"
  커버리지   = "봤나?"
  → 둘 다 만족해야 검증 완료

시리즈 완결 — 전체 UVM 환경

이제 AXI4 UVM 환경의 모든 파일을 다뤘습니다.

                        tb_top (조립 & 시작)
                            │
                    test (지휘, get_seq)
                            │
                    sequence (자극 생성)
                            │
                    seq_item (트랜잭션 단위)
                            │
        cfg/agent/env (계층) ─ driver (구동)
                            │
                    interface (신호+clocking)
                            │
                          DUT
                            │
                    monitor (관찰)
                            │
              ┌─────────────┴─────────────┐
        scoreboard (맞나?)          coverage (봤나?)
              │                           │
         ref_model                   covergroup
              └─────────────┬─────────────┘
                       pass/fail + 100%

검증의 두 축이 완성됩니다:

• 정확성(correctness): scoreboard가 ref_model과 비교
• 완결성(completeness): coverage가 모든 조합을 추적

이 둘이 만나서 "많이 실행하고, 정확히 검증했다"는 신뢰를 만듭니다.

시리즈: ... · agent_cfg/agent/env · base_test · sequences

Sequence란

"어떤 트랜잭션을 어떤 순서로 만들지"를 정의하는 자극 프로그램

test가 get_seq()로 고르는 그 시퀀스들
→ 실제로 아이템(axi4_seq_item)을 randomize해서 시퀀서에 밀어넣음

지금까지: test가 "어떤 시퀀스 쓸지" 골랐다면, 이 파일은 그 시퀀스가 실제로 뭘 하는지다.

전체 구조

axi4_base_seq (부모)
    ├── num 필드 (몇 개 만들지)
    └── wr_then_rd() 헬퍼 (쓰고 같은 영역 읽기)

    ↓ 상속

axi4_write_seq    : N개 랜덤 쓰기
axi4_read_seq     : N개 랜덤 읽기
axi4_rand_seq     : N개 랜덤 (읽기/쓰기 섞임)
axi4_wr_rd_seq    : 쓰고 → 같은 영역 읽기 (self-checking, 기본 시퀀스)
axi4_os_*_seq     : outstanding용 (고정 주소 8개)
axi4_cov_seq      : 커버리지 채우기 (모든 조합 sweep)
axi4_directed_seq : 손으로 고른 코너 케이스
axi4_wrap_seq     : WRAP 버그 재현 (FAIL 예상)

⭐ 가장 중요한 설계 결정 — WRAP 격리

// the general-purpose sequences deliberately exclude AXI_WRAP so
// the normal regression is clean.

일반 시퀀스들은 일부러 AXI_WRAP을 제외함!

이유:
  DUT가 WRAP을 선형 증가로 처리하는 버그가 있음
  → 일반 시퀀스에 WRAP을 넣으면 정상 회귀도 FAIL
  → WRAP은 별도 시퀀스/테스트로 격리해서 "일부러" 버그 시연

→ 그래서 대부분 시퀀스에 burst inside {AXI_INCR, AXI_FIXED}
  (WRAP 빠짐)

이건 실무에서 중요한 판단이에요. "알려진 버그"를 정상 회귀에서 분리해서, 회귀는 clean하게 유지하고 버그는 별도로 문서화/추적하는 방식.

Part 1: axi4_base_seq — 부모 & 헬퍼

class axi4_base_seq extends uvm_sequence #(axi4_seq_item);
    `uvm_object_utils(axi4_base_seq)
    rand int unsigned num = 5;   // how many transactions / pairs

    function new(string name = "axi4_base_seq");
        super.new(name);
    endfunction

uvm_sequence #(axi4_seq_item) 상속
  → axi4_seq_item 타입 아이템을 생성/전달하는 시퀀스

num = 생성할 트랜잭션 개수 (기본 5)
  → test에서 s.num = 40 처럼 바꿀 수 있음 (cov_test에서 봤던 것)

wr_then_rd() 헬퍼 — 핵심 도구

task wr_then_rd(bit [AXI_ADDR_WIDTH-1:0] a,
                bit [7:0]                l,
                bit [2:0]                s,
                axi_burst_e              b);
    axi4_seq_item wr, rd;

    wr = axi4_seq_item::type_id::create("wr");
    start_item(wr);
    if (!wr.randomize() with { dir == AXI_WRITE; addr == a;
                               len == l; size == s; burst == b; })
        `uvm_error("RAND", "directed write randomize() failed")
    finish_item(wr);

    rd = axi4_seq_item::type_id::create("rd");
    start_item(rd);
    if (!rd.randomize() with { dir == AXI_READ; addr == a;
                               len == l; size == s; burst == b;
                               id == wr.id; })
        `uvm_error("RAND", "directed read randomize() failed")
    finish_item(rd);
endtask

"쓰고 → 정확히 같은 영역 읽기" 한 세트

같은 addr/len/size/burst로:
  1. 쓰기 아이템 생성 → 랜덤 데이터로 씀
  2. 읽기 아이템 생성 → 같은 영역 읽음
  → 스코어보드가 "쓴 값 == 읽은 값" 비교 → self-checking

정상 DUT면 데이터 일치해야 함

start_item / finish_item — 시퀀스-드라이버 핸드셰이크

start_item(wr)   → "이 아이템 보낼게, 시퀀서 준비되면 알려줘"
                   (드라이버가 get_next_item 할 때까지 대기)
wr.randomize()   → 제약 안에서 랜덤화
finish_item(wr)  → "완성됐어, 드라이버로 보내"
                   (드라이버가 item_done 할 때까지 대기)

→ driver의 get_next_item() / item_done()과 짝을 이루는 반대편!

randomize() with { ... } — 인라인 제약

randomize() with { dir == AXI_WRITE; addr == a; ... }

= "이번 랜덤화는 이 조건들을 지켜라"
  dir는 WRITE로 고정
  addr는 인자 a로 고정
  나머지(data, strb)는 seq_item 제약 안에서 랜덤

→ seq_item의 constraint(c_4k, c_align 등)는 그대로 적용되면서
  추가로 이 조건들을 얹음

읽기가 id == wr.id 하는 이유

읽기 아이템의 id를 쓰기와 같게 맞춤
→ 같은 트랜잭션 쌍임을 ID로 표시
→ (outstanding 환경에서 매칭에 도움)

Part 2: 기본 랜덤 시퀀스들

write / read / rand — 거의 동일

class axi4_write_seq extends axi4_base_seq;
    task body();
        repeat (num) begin
            req = axi4_seq_item::type_id::create("req");
            start_item(req);
            if (!req.randomize() with { dir == AXI_WRITE;
                                        burst inside {AXI_INCR, AXI_FIXED}; })
                `uvm_error("RAND", "write item randomize() failed")
            finish_item(req);
        end
    endtask
endclass

body() = 시퀀스의 메인 (test가 seq.start() 하면 실행됨)

repeat (num) → num개 생성
req = built-in 핸들 (uvm_sequence가 제공)

세 시퀀스 차이는 dir 제약만:
  write_seq: dir == AXI_WRITE
  read_seq:  dir == AXI_READ
  rand_seq:  dir 제약 없음 (읽기/쓰기 랜덤 혼합)

공통: burst inside {AXI_INCR, AXI_FIXED}  ← WRAP 제외!

wr_rd_seq — 기본 시퀀스 (base_test가 씀)

class axi4_wr_rd_seq extends axi4_base_seq;
    task body();
        repeat (num) begin
            axi4_seq_item wr, rd;

            wr = axi4_seq_item::type_id::create("wr");
            start_item(wr);
            if (!wr.randomize() with { dir == AXI_WRITE; burst == AXI_INCR; })
                `uvm_error("RAND", "write randomize() failed")
            finish_item(wr);

            rd = axi4_seq_item::type_id::create("rd");
            start_item(rd);
            if (!rd.randomize() with { dir == AXI_READ; burst == AXI_INCR;
                                       addr == wr.addr; len == wr.len;
                                       size == wr.size; id == wr.id; })
                `uvm_error("RAND", "read randomize() failed")
            finish_item(rd);
        end
    endtask
endclass

랜덤 쓰기 → 같은 영역 읽기 (wr_then_rd와 비슷하지만 주소도 랜덤)

wr는 완전 랜덤 (addr/len/size 랜덤)
rd는 wr를 따라감 (addr == wr.addr, len == wr.len, ...)
→ 랜덤한 위치에 쓰고 그 위치를 읽어서 검증

이게 base_test의 기본 자극 → "환경이 제대로 도나" 확인

Part 3: outstanding 시퀀스

고정 주소 계획

class axi4_os_base_seq extends axi4_base_seq;
    localparam int OS_COUNT = 8;
    // 0x5000, 0x5100, ... 0x5700
    function bit [AXI_ADDR_WIDTH-1:0] os_addr(int i);
        return 16'h5000 + (i * 16'h0100);
    endfunction
endclass

8개 버스트를 고정된 겹치지 않는 주소에 배치
  0x5000, 0x5100, 0x5200, ... 0x5700
  각 4 beat × 4B, 전부 4KB 안전

왜 고정 주소? outstanding은 "여러 개 동시 진행"을 봐야 하는데
            주소가 겹치면 검증이 복잡 → 겹치지 않게 미리 계획

write / read 분리

class axi4_os_write_seq extends axi4_os_base_seq;
    task body();
        for (int i = 0; i < OS_COUNT; i++) begin
            req = axi4_seq_item::type_id::create("req");
            start_item(req);
            if (!req.randomize() with { dir   == AXI_WRITE;
                                        burst == AXI_INCR;
                                        addr  == os_addr(i);
                                        len   == 3;
                                        size  == 3'd2;
                                        foreach (strb[j])
                                            strb[j] == {AXI_STRB_WIDTH{1'b1}}; })
                `uvm_error("RAND", "outstanding write randomize() failed")
            finish_item(req);
        end
    endtask
endclass

write와 read가 별도 시퀀스인 이유:
  test에서 사이에 drain을 넣어야 함
  → 읽기가 아직 안 끝난 쓰기를 추월하면 안 됨
  → (AXI 읽기/쓰기 채널 독립)

foreach (strb[j]) strb[j] == {AXI_STRB_WIDTH{1'b1}}
  = 모든 strobe 비트를 1로 (전체 바이트 쓰기)
  {N{1'b1}} = 1을 N번 반복 = 전부 1

이게 outstanding_test에서 봤던 "phase 1 쓰기 → drain → phase 2 읽기"의 시퀀스 쪽 구현이에요.

Part 4: cov_seq — 커버리지 채우기

// this sequence allows AXI_WRAP, so it can legitimately surface
// the DUT's WRAP addressing bug as scoreboard mismatches.

가장 복잡한 시퀀스. 세 단계로 커버리지를 채운다.

task body();
    foreach_burst_size();   // 모든 (burst × size) 조합
    burst_len_sweep();      // 모든 (burst × length class) 조합
    repeat (num) begin      // 넓은 랜덤 (length/region/strobe bin 채우기)
        req = axi4_seq_item::type_id::create("req");
        start_item(req);
        if (!req.randomize())
            `uvm_error("RAND", "coverage item randomize() failed")
        finish_item(req);
    end
endtask

왜 sweep이 필요한가

랜덤만으로는 특정 조합이 안 채워짐 (plateau)
  FIXED/WRAP은 가중치가 낮아서 (dist 8:1:1)
  → burst × length 교차 bin에 구멍이 남

해결: deterministic sweep으로 모든 조합을 명시적으로 방문
  → 랜덤이 못 가는 코너를 확정적으로 채움

이게 이력서의 "constrained-random (plateau 98.3%) + directed sweeps"의 실제 코드예요.

foreach_burst_size — 모든 (버스트 × 크기)

task foreach_burst_size();
    axi_burst_e blist[3] = '{AXI_FIXED, AXI_INCR, AXI_WRAP};
    bit [AXI_ADDR_WIDTH-1:0] a = 16'h2000;
    foreach (blist[b]) begin
        for (int s = 0; s <= 2; s++) begin
            automatic bit [7:0] l = (blist[b] == AXI_WRAP) ? 8'd3 : 8'd2;
            wr_then_rd(a, l, s[2:0], blist[b]);
            a += 16'h0100;
        end
    end
endtask

3가지 burst × 3가지 size = 9개 조합 전부 방문
  각각 wr_then_rd로 쓰고 읽음

WRAP일 때만 len=3 (4 beats, WRAP 합법)
나머지는 len=2

automatic = 각 반복마다 새 변수 (루프 변수 캡처 문제 방지)

burst_len_sweep — 모든 (버스트 × 길이)

task burst_len_sweep();
    bit [7:0] lens[4] = '{8'd0, 8'd2, 8'd6, 8'd12};  // 각 길이 클래스 대표

    foreach (lens[i]) begin
        wr_then_rd(a, lens[i], 3'd2, AXI_FIXED); a += 16'h0100;
        wr_then_rd(a, lens[i], 3'd2, AXI_INCR);  a += 16'h0100;
    end
    // WRAP은 2/4/8/16 beats만 합법
    wr_then_rd(a, 8'd1,  3'd2, AXI_WRAP); ...
    wr_then_rd(a, 8'd3,  3'd2, AXI_WRAP); ...
    wr_then_rd(a, 8'd7,  3'd2, AXI_WRAP); ...
    wr_then_rd(a, 8'd15, 3'd2, AXI_WRAP);
endtask

길이 클래스: single(0) / 2-4(2) / 5-8(6) / 9-16(12)
  각 클래스 대표값으로 FIXED, INCR 방문

WRAP은 합법 길이(1/3/7/15 = 2/4/8/16 beats)만 별도로

Part 5: directed_seq — 코너 케이스

task body();
    //          addr      len   size  burst        what it exercises
    wr_then_rd(16'h0000, 8'd0,  3'd2, AXI_INCR);  // single beat, full width
    wr_then_rd(16'h0100, 8'd15, 3'd2, AXI_INCR);  // max 16-beat burst
    wr_then_rd(16'h0FC0, 8'd15, 3'd2, AXI_INCR);  // ends exactly at 4KB edge
    wr_then_rd(16'h0200, 8'd7,  3'd0, AXI_INCR);  // narrow: 1 byte/beat
    wr_then_rd(16'h0300, 8'd3,  3'd1, AXI_INCR);  // narrow: 2 bytes/beat
    wr_then_rd(16'h0400, 8'd3,  3'd2, AXI_FIXED); // FIXED: same address
endtask

손으로 고른 위험한 코너들:

single beat     : len=0 → 1 beat (경계값)
max burst       : len=15 → 16 beats (최대)
4KB edge        : 0x0FC0 + 16beat×4B = 0x1000 딱 경계
narrow 1B/beat  : size=0 → lane_mask가 토글하는 케이스
narrow 2B/beat  : size=1
FIXED           : 같은 주소 반복

→ 랜덤이 잘 안 만드는 경계값을 확정적으로 테스트

이게 directed_test가 쓰는 시퀀스. 주석에 각 케이스가 뭘 테스트하는지 다 적혀있어요.

Part 6: wrap_seq — 버그 재현 (핵심)

// The reference model wraps correctly, the DUT does not,
// so this sequence is EXPECTED to raise scoreboard mismatches.

왜 WRAP write + INCR read인가 (가장 중요)

task wrap_write_incr_read(bit [AXI_ADDR_WIDTH-1:0] a,
                          bit [7:0]                l,
                          bit [2:0]                s);
    axi4_seq_item wr, rd;
    int unsigned nbytes = 1 << s;
    int unsigned total  = (l + 1) * nbytes;          // wrap window size
    bit [AXI_ADDR_WIDTH-1:0] base = a - (a % total); // window base

    // WRAP으로 쓰기 (window 중간에서 시작 → 실제로 wrap 발생)
    wr = axi4_seq_item::type_id::create("wr_wrap");
    start_item(wr);
    if (!wr.randomize() with { dir == AXI_WRITE; addr == a;
                               len == l; size == s; burst == AXI_WRAP;
                               foreach (strb[j])
                                   strb[j] == {AXI_STRB_WIDTH{1'b1}}; })
        `uvm_error("RAND", "wrap write randomize() failed")
    finish_item(wr);

    // INCR로 window 전체 읽기
    rd = axi4_seq_item::type_id::create("rd_incr");
    start_item(rd);
    if (!rd.randomize() with { dir == AXI_READ; addr == base;
                               len == l; size == s; burst == AXI_INCR; })
        `uvm_error("RAND", "incr read-back randomize() failed")
    finish_item(rd);
endtask

주석이 핵심을 설명한다:

// Why not a plain WRAP write + WRAP read?  Because that hides the
// bug: the DUT is consistently wrong on both sides, so it reads
// from the same (wrong) places it wrote to and the data matches.
// Only an INCR read exposes where the bytes actually landed.

왜 WRAP 쓰기 + WRAP 읽기가 아니라 WRAP 쓰기 + INCR 읽기?

WRAP write + WRAP read (대칭):
  DUT가 쓸 때도 틀리고 읽을 때도 똑같이 틀림
  → 틀린 위치에 쓰고, 그 틀린 위치에서 읽음
  → 데이터는 일치! → 버그 숨겨짐 ❌

WRAP write + INCR read (비대칭):
  DUT: WRAP 쓰기를 틀린(선형) 위치에 씀
  INCR 읽기: 올바른 순서로 window 전체를 읽음
  → "바이트가 실제로 어디 떨어졌나" 드러남
  → 예상과 불일치 → 버그 노출! ✅

이게 이력서의 "asymmetric WRAP-write / INCR-read cross-check that surfaced 24 mismatches"의 정확한 코드예요.

body — 실제 실행

task body();
    // len 1/3/7/15 -> 2/4/8/16 beats
    wrap_write_incr_read(16'h0A08, 8'd3, 3'd2);  // window 0x0A00..0x0A0F
    wrap_write_incr_read(16'h0B10, 8'd7, 3'd2);  // window 0x0B00..0x0B1F
endtask

0x0A08에서 WRAP 쓰기 시작 (window 0x0A00~0x0A0F 중간)
  → 0x0A08부터 쓰다가 0x0A0F 넘으면 0x0A00으로 되돌아와야 함 (정상)
  → DUT는 안 되돌아오고 계속 직진 (버그)

base(0x0A00)부터 INCR로 window 전체 읽기
  → 실제로 어디 썼는지 드러남 → 미스매치!

전체 시퀀스 지도

한 줄 요약

Sequence = 어떤 트랜잭션을 어떤 순서로 만들지 정의하는 자극 프로그램

axi4_base_seq: 부모, wr_then_rd() 헬퍼 (쓰고 같은 영역 읽기)

핵심 설계:
  1. 일반 시퀀스는 WRAP 제외 → 정상 회귀 clean 유지
  2. WRAP은 wrap_seq로 격리 → 비대칭(WRAP write + INCR read)으로
     버그를 "일부러" 노출
  3. cov_seq는 deterministic sweep으로 랜덤 plateau의 구멍을 채움

start_item/finish_item = driver의 get_next_item/item_done과 짝
randomize() with {...} = seq_item 제약 위에 추가 조건

시리즈 마무리 — 전체 데이터 경로

이제 AXI4 UVM 환경의 모든 파일을 봤습니다.

tb_top          → 조립 & 시작
cfg/agent/env   → 계층 빌드
base_test       → 지휘 (get_seq로 시퀀스 선택)
sequence        → 자극 생성 (이 글!)  ← randomize()
    ↓
seq_item        → 트랜잭션 단위
    ↓
driver          → 핀 구동
    ↓ (인터페이스 = 신호 + clocking block)
DUT
    ↓
monitor         → 관찰 & 재조립
    ↓
scoreboard      → ref_model과 비교 → pass/fail

자극이 생성(sequence)되어 아이템(seq_item)으로 만들어지고, 드라이버가 핀을 흔들어 DUT에 전달하고, 모니터가 관찰해서 스코어보드가 정답지와 비교하는 — 검증의 전체 순환이 완성됩니다.

이 문서 하나로 공부할 수 있게 방법 + 내용을 모두 담았다.

• Part 0~1 — 어떻게, 어떤 순서로 공부할지
• Part 2 — 실제 학습 내용 (핵심)
• Part 3~7 — 확인·연습·면접 대비

Part 0. 공부 3원칙

① 캐시는 "구조"보다 "타이밍"이다. 4-way, PLRU, write-back 같은 용어는 하루면 외운다. 이 프로젝트에서 진짜 배울 건 어느 사이클에 무엇이 유효한가 다. 배열 read가 registered라는 사실 하나가 파이프라인 구조·포워딩·FSM을 전부 결정한다. 사이클을 못 세면 아무것도 이해 못 한 것이다.

② 파일 순서가 아니라 "요청 하나의 일생"을 따라가라. ls 순서로 읽으면 죽는다. CPU 요청 하나가 태어나서(seq) → 핀을 흔들고(driver) → S1/S2를 통과하고(DUT) → 관측되고(monitor) → 검사받는(scoreboard) 경로를 따라가면 30개 파일이 하나의 이야기로 연결된다.

③ "PASS"를 믿지 마라 — 이 프로젝트의 핵심 교훈. 이 저장소의 역사는 통과하는데 아무것도 검증하지 않던 테스트벤치를 고친 기록이다 (Part 4). 그러니 공부할 때도 같은 태도로: "이 체크가 실제로 발화한 적이 있나?"를 계속 물어라. 이게 이 프로젝트에서 얻어갈 가장 값비싼 습관이다.

Part 1. 학습 경로 (3개 레이어)

🟦 Layer A — 큰 그림 + 캐시 기본

🟩 Layer B — DUT 타이밍 ⭐ (질문의 절반)

🟨 Layer C — UVM 배선 + 검증 장치

Part 2. 학습 내용 정리 ⭐

2.1 캐시 기본기 — 이 DUT 기준으로

3C miss 분류 — 스코어보드가 실제로 이 분류를 만들어 커버리지로 보낸다 (l1_cache_item::victim_e):

이걸 핀에서는 못 본다. 그래서 커버리지를 모니터가 아니라 스코어보드에서 샘플한다.

2.2 주소 분할 — 반드시 손으로 계산

addr[31:10] = TAG   (22b)   → 4-way 비교 대상
addr[ 9: 4] = SET   ( 6b)   → 64 set 선택
addr[ 3: 2] = WORD  ( 2b)   → 라인 안 4워드 중 선택
addr[ 1: 0] = BYTE  ( 2b)   → 미사용 (be[3:0] 가 바이트 선택)

정의는 rtl/l1_cache_pkg.sv:74~97 한 곳뿐이고 RTL과 TB가 같은 함수를 쓴다. 스코어보드가 get_set() 을 직접 호출한다(l1_cache_scoreboard.sv:123) — 주소 분할이 어긋날 수 없는 구조다.

1. 먼저 "왜" 쪼개는지 — 사물함 비유

캐시를 사물함이라고 생각하세요.

캐시 = 사물함 64칸  (칸 = set)
칸 하나 = 서랍 4개   (서랍 = way)
서랍 하나 = 물건 4개  (물건 = word)
CPU가 "0x1234 주소 줘"라고 하면 캐시는 이렇게 움직입니다:

주소 하나에 이 세 정보가 다 들어있어야 하죠. 그래서 32비트를 잘라 쓰는 겁니다.

addr[31:10] = TAG   ← 이름표 (서랍이 진짜 내 것 맞나?)
addr[ 9: 4] = SET   ← 몇 번 칸?
addr[ 3: 2] = WORD  ← 서랍 안 몇 번째 물건?
addr[ 1: 0] = BYTE  ← 안 씀

2. 계산 3단계

십진수 변환 필요 없습니다. hex 마지막 한 글자가 열쇠예요.

┌─────────────────────────────────────────────┐
│ ① 마지막 hex 글자 → ÷4 하면 word 번호            │
│                                              │
│ ② 마지막 글자를 뗀 나머지 → 64로 나눈다             │
│      몫    = tag                             │
│      나머지 = set                             │
│                                             │
│ ③ 마지막 글자를 0으로 → line base 주소           │
└─────────────────────────────────────────────┘

왜 이렇게 되나 (한 번만 이해하면 됨) hex 한 글자 = 4비트입니다. 그런데 word(2비트) + byte(2비트) = 4비트 → 마지막 hex 글자 하나가 딱 word+byte예요. 그래서 떼어내면 됩니다. 마지막 글자를 떼면 남는 건 {tag, set}이 붙어있는 수입니다. set이 6비트 = 64가지니까, 64로 나누면 나머지가 set, 몫이 tag입니다.

3. 0x0000_1234 직접 해보기

① word 구하기

0x1234  →  마지막 글자 = 4
           4 ÷ 4 = 1
                        → word 1

② tag / set 구하기

0x1234  →  마지막 글자 떼면  0x123

0x123 을 십진수로:  1×256 + 2×16 + 3 = 291

291 ÷ 64 = 4 … 나머지 35
           ↑         ↑
          tag       set

③ line base 주소

0x1234  →  마지막 글자를 0으로  →  0x1230

정리해서 읽으면 35번 칸으로 가서, 서랍의 이름표가 4인지 확인하고, 맞으면 그 서랍의 1번 물건을 꺼낸다. 없으면(miss) 메모리에 0x1230부터 4개를 달라고 한다.

4. 연습 2 — "같은 라인인가?"

이건 훨씬 쉬워요. hex 마지막 한 글자만 빼고 같으면 같은 라인입니다.

0x1230  →  앞부분 "123"
0x1234  →  앞부분 "123"   ← 같다! → 같은 라인 ✅
0x1238  →  앞부분 "123"   ← 같다!
0x123C  →  앞부분 "123"   ← 같다!

0x1240  →  앞부분 "124"   ← 다르다 → 다른 라인 ❌

한 라인 = 주소 16개(4워드)

0x1230  word 0  ┐
0x1234  word 1  │  이 4개가 한 덩어리 (16 B)
0x1238  word 2  │  메모리에서 한 번에 4 beat로 가져옴
0x123C  word 3  ┘

그래서 l1_cache_line_seq가 하는 일:

0x1234 읽기  →  miss!  →  0x1230,34,38,3C 4개 전부 가져옴
0x1230 읽기  →  hit 여야 함  ✅
0x1238 읽기  →  hit 여야 함  ✅
0x123C 읽기  →  hit 여야 함  ✅

hit: 찾는게 캐시에 있었다 miss: 찾는게 캐시에 없었다 -> 메모리 가서 가져옴 miss는 에러가 아니라 그냥 "아직 없음" 상태예요. 처음 접근하는 주소는 당연히 miss입니다 (아무것도 없는 빈 캐시니까). 캐시는 "두 번째부터 빨라지는" 장치입니다.

miss 났을 때 캐시가 "요청한 워드 1개"만 가져온다고 생각하고 계실 거예요. 실제로는 4개를 통째로 가져옵니다.

한 번 miss 났으면 나머지 3개는 무조건 hit여야 합니다. 여기서 miss가 나면 → burst로 가져온 4개가 서랍 안 제자리에 안 들어갔다는 뜻이에요.

핵심: 가지러 갈 때 4개를 들고 온다 사물함 비유로 다시 갈게요.

[1] CPU: "0x1234 줘"
    35번 칸 열어봄 → 이름표 4인 서랍 없음 → MISS ❌
    창고(메모리)로 감
      ↓
    ⚠️ 여기가 포인트: 물건 1개만 안 가져온다
       "0x1230부터 4개 다 줘"  ← 4-beat burst
      ↓
    beat 0 → 0x1230 의 값
    beat 1 → 0x1234 의 값
    beat 2 → 0x1238 의 값
    beat 3 → 0x123C 의 값
      ↓
    서랍에 4개 다 넣고 이름표 "4" 붙임
    서랍 상태:  [ 0x1230 | 0x1234 | 0x1238 | 0x123C ]
                  word0    word1    word2    word3
    CPU한테는 0x1234 값만 돌려줌

이제 그 다음:

[2] CPU: "0x1230 줘"  →  35번 칸, 이름표 4, word0 → 이미 있음 → HIT ✅
[3] CPU: "0x1238 줘"  →                    word2 → 이미 있음 → HIT ✅
[4] CPU: "0x123C 줘"  →                    word3 → 이미 있음 → HIT ✅
한 번 창고에 갔을 때 4개를 다 들고 왔으니까, 나머지 3개는 갈 필요가 없는 겁니다.

0x1240은?

0x1240  →  마지막 글자 떼면  0x124
           0x124 = 1×256 + 2×16 + 4 = 292
           292 ÷ 64 = 4 … 나머지 36
                              ↑
                          set 36  (0x1234는 set 35)
→ 다른 칸입니다. 서로 아무 상관 없는 라인이에요.

5. 직접 풀어보기

문제 1. 0x0000_2008 을 분해하라

① 마지막 글자 8  →  8 ÷ 4 = 2        →  word 2
② 떼면 0x200 = 2×256 = 512
   512 ÷ 64 = 8 … 나머지 0           →  tag 8, set 0
③ line base = 0x2000
→ 0번 칸에서 이름표 8인 서랍의 2번 물건

문제 2. 0x0000_00FC 를 분해하라

문제 3. ⭐ 0x0000_1234 와 0x0000_5234 는 같은 칸(set)인가?

6. 한 장 요약 (외울 것)

   addr = 0x . . . . . . . X
                        ↑
                 마지막 hex 한 글자
   
   X ÷ 4        = word 번호  (0,4,8,C → 0,1,2,3)
   X를 0으로     = line base 주소
   X를 뗀 값 ÷64 = 몫이 tag, 나머지가 set
   앞부분이 같으면 → 같은 라인
   set이 같고 tag가 다르면 → conflict (way를 나눠 씀)

2.3 registered SRAM + 2-stage 파이프라인 ⭐

이 설계의 모든 것이 여기서 출발한다.

// rtl/sram_macro.sv:30
always_ff @(posedge clk) begin
    rdata <= mem[raddr];      // 이 엣지의 write보다 "먼저" 샘플됨
    if (we) mem[waddr] <= wdata;
end

읽기 포트가 registered = N 사이클에 주소를 주면 N+1 사이클에 데이터가 나온다. → 파이프라인이 자연스럽게 2단이 된다:

read hit 연속 2건 타이밍

→ hit throughput = 1 요청/사이클. latency는 2 사이클이지만 파이프라이닝되어 있다.

왜 조합형 read면 안 되나 (⭐ 단골 질문)

assign rdata = mem[raddr] 로 하면 배열 주소 mux가 pipeline_stall 로 선택되므로:

pipeline_stall → tag_raddr → tag_rdata → cache_hit → pipeline_stall

닫힌 조합 루프가 된다. registered read면 tag_rdata 가 플롭 출력이라 루프가 끊긴다. (README "History" 의 첫 번째 항목이 바로 이 버그다.)

배열 주소 mux (l1_cache_core.sv:136~149)

세 가지 경우를 구분한다:

if (!pipeline_stall && cpu_req_valid)  // 정상: S1 주소
else if (state == ST_WB_READ)          // victim 라인을 워드 단위로 훑는다
else                                    // stall 중 or S1 idle: S2 주소를 유지

세 번째 분기가 중요하다. 드라이버는 idle일 때 버스에 X를 park하므로 (l1_cache_cpu_driver.sv::drive_idle), 그대로 인덱싱하면 배열이 X로 접근된다.

2.4 read-during-write 포워딩 ⭐

registered read의 대가. 배열 read 포트는 같은 엣지의 write를 못 본다.

사이클 N: write(addr=A, data=D) 와 read(addr=A) 가 동시에 걸림 → 사이클 N+1 에 나오는 rdata 는 D 이전의 옛날 값

그래서 코어가 배열 바깥에서 우회시킨다 (l1_cache_core.sv:175~210):

// 직전 사이클의 write 주소 vs 직전 사이클에 "실제로 발행한" read 주소
safe_data_rdata[w][b*8 +: 8] =
    (prev_data_we[w] && (prev_data_waddr == prev_data_raddr) && prev_data_wbe[b])
    ? prev_data_wdata[b*8 +: 8]
    : data_rdata[w][b*8 +: 8];

꼭 짚어야 할 두 가지:

1. 비교 대상이 s2_* 가 아니라 prev_*_raddr — ST_WB_READ 중에는 read 주소가 라인을 훑고 있어서 s2_word 가 아니다. "지난 사이클에 실제로 뭘 읽으라고 했나"가 정답.
2. data는 byte 단위 포워딩 — store가 일부 lane만 썼을 수 있다. 워드 통째로 포워딩하면 안 건드린 lane까지 덮어쓴다. → 이걸 잡는 게 l1_cache_be_seq + l1_cache_be_test (idle gap 0 으로 돌려서 부분 write 바로 다음 사이클에 read가 오게 만든다).
3. 1 사이클 깊이면 충분 — 그 다음 사이클부터는 배열 자체가 새 값을 갖고 있다.

✍️ 연습 3

0x100 에 be=4'b0011 로 0xAAAA_BBBB 를 쓰고, 바로 다음 사이클 같은 주소를 읽는다. 원래 값이 0x1111_2222 였다면 정답은? 포워딩이 워드 단위였다면 뭐가 나오나?

2.5 miss FSM — 사이클을 세어라

ST_IDLE ──miss, clean victim───────────────────────────▶ ST_FILL_REQ
   │                                                          │
   └─miss, dirty victim─▶ ST_WB_READ ─▶ ST_WB_SEND ───────────┘
                          (버퍼로 복사)   (메모리로 전송)        │
                                                               ▼
   ST_IDLE ◀──────────────────────── ST_COMPLETE ◀────── ST_FILL_RCV

각 상태는 정확히 하나의 일만 한다. 상태별 사이클 수:

ST_WB_READ가 왜 4가 아니라 5인가 — l1_cache_core.sv:307~312:

registered read의 한 박자 지연이 정확히 한 사이클의 오버헤드로 드러난 자리다.

✍️ 연습 4 — dirty miss 총 사이클

memory latency = 3, backpressure 없음일 때 miss 감지부터 CPU 응답까지 몇 사이클?

ST_COMPLETE 는 왜 있나 (⭐ 단골 질문)

miss 당 1 사이클 손해지만, 마지막 fill beat 의 배열 write 와 대기 중이던 store의 배열 write 가 같은 사이클에 충돌하는 구조적 해저드를 없앤다. 그리고 tag/valid/dirty/PLRU 커밋 지점이 한 곳으로 모인다.

여기서 stall을 푸는 이유(l1_cache_core.sv:432~433)도 중요하다. ST_COMPLETE 에서 pipeline_stall=0 이라야 이 사이클 끝에 파이프라인이 전진한다. 안 그러면 다음 사이클 ST_IDLE 에서 S2가 같은 요청을 그대로 들고 있어서 두 번 응답한다.

응답 조건식 (l1_cache_core.sv:262~265)

assign cpu_rsp_valid = ((state == ST_IDLE)     && s2_valid && cache_hit && !s2_rw)
                    || ((state == ST_COMPLETE) && s2_valid &&              !s2_rw);
assign cpu_rsp_rdata = (state == ST_COMPLETE) ? fill_data : safe_data_rdata[hit_way];

읽어낼 것 3개:

• write는 응답이 없다. read만 rsp_valid 를 받는다 → 모니터도 read만 큐에 넣는다.
• miss 응답은 배열이 아니라 fill_data 에서 나온다 (fill 중에 요청 워드를 따로 잡아둠, l1_cache_core.sv:325).
• ST_COMPLETE 에는 cache_hit 조건이 없다 — 방금 채운 라인이니 당연히 맞다.

2.6 tree-PLRU

3 bit로 4-way를 근사한다 (l1_cache_pkg.sv:99~121).

bit[0] : root       0 → {way0,way1} 쪽이 오래됨,  1 → {way2,way3} 쪽
bit[1] : 왼쪽 leaf  (way0 vs way1)
bit[2] : 오른쪽 leaf (way2 vs way3)

victim = plru[0] ? (plru[2] ? 3 : 2)
                 : (plru[1] ? 1 : 0);

// 방금 쓴 way의 "반대쪽"을 가리키게 갱신
nxt[0] = ~way[1];
if (way[1] == 0) nxt[1] = ~way[0];
else             nxt[2] = ~way[0];

victim 선택 순서: invalid way가 있으면 그쪽 먼저(l1_cache_core.sv:245~255), 전부 valid일 때만 PLRU 트리를 따른다. 스코어보드도 똑같은 순서로 예측한다 (l1_cache_scoreboard.sv:150~153) — 안 맞으면 매 miss마다 way가 어긋난다.

✍️ 연습 5 — set이 꽉 찬 상태에서 4번 연속 miss. victim 순서는?

2.7 요청 하나의 일생

seq          item.randomize()  →  start_item / finish_item
  ↓ (TLM)
sequencer    ← driver.seq_item_port.get_next_item()
  ↓
driver       cb_cpu 로 valid/rw/addr/be/wdata 구동 → ready 대기 → item_done()
  ↓ (핀)
DUT          S1 (배열 주소 인가) → S2 (hit 판정) → hit면 즉시 응답 / miss면 FSM
  ↓ (핀)
monitor      cb_cpu_mon 으로 preponed 샘플
             ├─ req_ap : valid && ready 인 순간 = 수락된 요청 (read+write, 발행 순서)
             └─ rsp_ap : rsp_valid 인 순간 = read 응답 + 실제 rdata
  ↓ (analysis port, 1→N)
scoreboard   write_req(): 골든 모델 갱신 + 기대값 스냅샷 + 기대 버스트 push
             write_rsp(): 스냅샷과 실제 rdata 비교
             write_mem(): 관측된 버스트를 기대 큐와 순서대로 대조
  ↓ cov_ap
coverage     hit/way/victim 이 채워진 item 을 샘플

드라이버의 진짜 back-to-back (l1_cache_cpu_driver.sv): gap이 0이면 item_done() 직후 버스를 놓지 않고 try_next_item() 으로 다음 아이템을 받아 그 자리에서 payload만 교체한다. 그래서 cpu_req_valid 가 accept 사이에 안 떨어진다. 매 아이템마다 VALID를 내리면 "back-to-back 테스트"가 이름만 back-to-back이 된다 (README History 에 실제로 있던 버그).

2.8 스코어보드 = 골든 캐시 모델 ⭐⭐

이 프로젝트의 심장. 메모리만 모델링하는 흔한 스코어보드와 다르다.

// l1_cache_scoreboard.sv:55~62 — DUT 내부를 통째로 미러링
tag_t      m_tag   [SETS][WAYS];
bit        m_valid [SETS][WAYS];
bit        m_dirty [SETS][WAYS];
bit [31:0] m_data  [SETS][WAYS][WORDS_PER_LINE];
plru_t     m_plru  [SETS];
bit [31:0] main_mem [int];    // 예측된 DRAM

write_req() 하나가 요청 1건에 대해 전부 예측한다:

그리고 write_mem() 이 관측된 버스트를 exp_mem_q 와 순서대로 대조한다. → 없어야 할 버스트, 있어야 하는데 없는 버스트, 주소·방향·길이·데이터 오류가 전부 잡힌다.

메모리 모델이 두 벌인 이유: mem_driver.main_mem(실제 응답값)과 scoreboard.main_mem(예측값)이 따로 있다. 둘이 같은 소스를 공유하면 서로를 검증하지 못한다. "아직 아무도 안 쓴 주소"의 기본값만 tb_classes.svh 의 L1_MEM_DEFAULT(a) 매크로로 공유하는데, 주소 의존적인 값(32'hDEAD_0000 | addr[15:0])인 게 포인트다. 상수였다면 fill burst의 4 beat가 전부 똑같아서 워드 선택 버그가 안 보인다.

check_phase (:308~317) — 조용한 PASS 방지장치: 트래픽 0건 / 응답 못 받은 read / 예측했는데 안 일어난 버스트 / mismatch 누적 → 전부 실패.

2.9 순서 문제: analysis port가 왜 2개인가 ⭐

증상이었던 것: DUT가 파이프라인이라 read miss가 retire 되는 바로 그 사이클에 다음 요청이 수락될 수 있다. 모니터를 "write는 accept 때, read는 응답 때" 한 포트로 보내면, 이 겹침에서 write가 스코어보드에 먼저 도착해 이미 전진해버린 모델과 read를 비교한다 → 매 런마다 가짜 실패 2건.

해결:

read의 기대값은 발행 시점에 스냅샷(rd_q 에 push)해두고, 응답이 오면 그 스냅샷과 비교한다. 모든 요청이 발행 순서로 req_ap 를 지나가므로, 시뮬레이터가 같은 타임스텝 안에서 두 모니터 스레드를 어떤 순서로 스케줄하든 프로그램 순서가 보존된다.

이 구조는 in-order 응답을 전제로 한다. 그래서 README "Not done yet" 의 MSHR (hit-under-miss)이 "RTL만이 아니라 TB 재설계"라고 적혀 있는 것 — 응답이 순서를 벗어나면 큐 매칭 자체가 성립하지 않고 response ID가 필요해진다. "왜 MSHR 안 했나"에 이렇게 답하면 만점이다.

2.10 메모리 responder — reactive agent

l1_cache_mem_driver 는 stimulus를 만드는 게 아니라 DUT의 요청에 반응한다. 시퀀스(l1_cache_mem_rsp_seq)는 데이터가 아니라 타이밍을 공급한다:

l1_cache_stress_test 는 latency 10~50, 60% 의 버스트에 최대 6사이클 backpressure, 양쪽 채널 모두에 gap — 이 조건에서 통과해야 handshake를 진짜로 지킨 것이다.

disable fork 를 안 쓴 이유 ⭐

리셋으로 전송을 끊어야 하는데, get_next_item() 과 item_done() 사이에서 disable fork 를 쓰면 시퀀서가 내부적으로 spawn한 프로세스까지 죽는다. → 나중에 "Get_next_item called twice" / "item_done() with no outstanding requests" 로 터진다.

대신 모든 대기 지점을 tick() 한 곳으로 모으고 aborted 플래그를 검사한다:

virtual task tick();
    @(vif.cb_mem);
    if (vif.rst_n !== 1'b1) aborted = 1'b1;
endtask

이렇게 하면 리셋이 어느 지점에서 끊든 get/item_done 쌍은 항상 균형을 유지한다.

2.11 리셋 검증과 poisoning

리셋 에이전트가 rst_n 을 소유한다 (tb_top의 initial 블록이 아니라). 그래야 테스트가 트래픽 중간에 리셋을 다시 걸 수 있다.

동기화 포인트: 리셋 드라이버는 vif.assert_reset() 을 부르기 직전에 analysis port로 스코어보드에 알린다 (l1_cache_reset_agent.sv). 스코어보드가 모델을 DUT와 같은 순간에 flush 하도록.

poisoning (l1_cache_scoreboard.sv:101~102): 리셋 시점에 exp_mem_q 에 남아있던 write-back 예측의 주소를 poisoned[] 에 표시한다. 그 라인의 DRAM 내용은 모델이 재구성할 수 없기 때문. 데이터 비교만 건너뛰고 프로토콜·순서·burst 길이 검사는 전부 유지된다. 리셋당 최대 1라인, 개수는 report에 찍힌다.

"검사를 껐다"가 아니라 "모델이 원리적으로 알 수 없는 부분만, 범위를 한정해서, 개수를 보고하면서 껐다" — 이 구분을 설명할 수 있으면 검증 엔지니어답게 들린다.

2.12 커버리지 2종

왜 스코어보드에서 샘플하나 — hit/miss, 어느 way, victim이 dirty였는지는 핀에 없다. 골든 모델 안에만 존재한다. 모니터에서 샘플하려면 커버리지 코드가 캐시를 또 모델링해야 한다.

왜 bind 인가 — FSM state, victim_way, pipeline_stall 도 핀에 없다. bind 는 RTL을 손대지 않고 검증 모듈을 계층 안으로 주입한다 (tb_top.sv:87). 합성 대상 코드에 검증용 코드가 섞이지 않는다.

illegal_bins vs ignore_bins:

• illegal_bins = "일어나면 에러" — FSM의 불법 전이 12종
• ignore_bins = "도달 불가하니 분모에서 빼자" — 예: x_rw_evict 에서 no_evict 쪽

커버리지 100%의 의미: "그 시나리오를 자극했다"이지 "맞다"가 아니다. 정답 판정은 스코어보드와 SVA가 한다. 그리고 커버리지 모델 자체가 빠뜨린 구멍은 커버리지로 못 찾는다.

per-test 수치가 낮은 건 정상 — 각 테스트가 좁은 시나리오를 노린다. regress.bat 가 11테스트 × 4시드를 돌려 xcrg 로 머지한 값이 100%다.

2.13 SVA — 스코어보드와 역할이 다르다

tb/l1_cache_if.sv:83~241 에 어서션 15개 (파일에 1~13번으로 번호가 붙은 것 + burst 회계 2개).

역할 분담:

• SVA = 프로토콜. "언제/어떻게" 신호가 움직이는가. 매 사이클, 국소적.
• 스코어보드 = 데이터·의미. "무엇이" 맞는가. 트랜잭션 단위, 전역 상태 필요.

cover property 4개도 있지만 xsim은 무시한다(XSIM 43-4127). 문법은 유효하고 Questa에서는 수집된다.

Part 3. 로그로 확인하는 체크리스트

cd sim\vivado
run.bat l1_cache_eviction_test 42

run.bat 이 마지막에 뽑아주는 줄들을 하나씩 해석할 수 있어야 한다:

직접 부숴보기 (가장 빠른 학습법): l1_cache_core.sv 의 plru_update 호출을 지워보면 → Way utilisation 이 한쪽으로 쏠리고 cp_way 커버리지가 25% 근처에서 멈춘다. 어느 체크가 먼저 우는지 관찰하면 각 장치의 담당 범위가 몸으로 이해된다. (실험 후 반드시 되돌릴 것.)

Part 4. 반드시 외울 버그 스토리 3개 ⭐

면접관은 문법보다 검증적 사고를 본다. 각각 30초 안에 설명할 수 있어야 한다.

1. 조합형 SRAM read 모델이 파이프라인과 모순이었다 — 설계 감각

배열을 assign rdata = mem[raddr] 로 모델링해놨는데, 파이프라인은 S1에서 주소를 주고 S2에서 쓰는 구조였다. allocate→hit 전환 시점에 코어가 다음 요청의 index를 읽어 엉뚱한 라인 데이터를 돌려줬다 → read mismatch 675건. 게다가 stall → raddr → rdata → hit → stall 이 닫힌 조합 루프였다. 읽기 포트를 registered로 바꿔 둘 다 해결하고, 그 대가로 생긴 read-during-write 해저드는 byte 단위 포워딩 경로를 추가해 막았다.

교훈: 메모리 모델은 "동작하는 코드"가 아니라 타이밍 계약이다. 계약이 틀리면 RTL 전체가 틀린다.

2. SVA 실패가 회귀에 안 잡히고 있었다 — 검증 환경도 검증 대상

어서션이 $error 를 쓰고 있었는데, 이건 UVM_ERROR 를 증가시키지 않는다. 어서션이 줄줄이 깨지는 런도 UVM_ERROR : 0 으로 PASS 로 보고됐다. uvm_report_error 로 바꾸고, 일부러 깨지는 어서션을 넣어 685개 에러가 찍히고 런이 FAIL로 분류되는 걸 확인해서 증명했다.

교훈: 어서션이 "통과"하는 것과 어서션이 "존재"하는 것은 다르다. 체커는 발화시켜서 증명해야 한다.

3. 통과하는 테스트가 아무것도 검증하지 않고 있었다 — PASS는 증거가 아니다

두 가지가 겹쳐 있었다. (a) for 루프 본문의 선언 초기화(bit [31:0] base = f(i);)를 xsim이 한 번만 평가해서, 24개의 서로 다른 캐시 라인이 조용히 1개로 붕괴했다 — passive 테스트가 191 hit / 1 miss 를 찍고 "PASS" 였다. (b) 주소 헬퍼가 get_index(a) 처럼 한 글자 인자명을 써서, 호출부에 같은 이름의 지역변수가 있으면 xsim이 실인자를 callee 스코프에서 평가해 조용히 0을 넘겼다 — eviction_test 가 eviction을 0건 만들면서 PASS 였다. 둘 다 로그의 Dirty evictions / Way utilisation 통계를 보고서야 발견했다.

교훈: 테스트가 통과했다는 건 자극이 도달했다는 뜻이 아니다. 커버리지와 통계로 "자극이 실제로 갔는가"를 따로 확인해야 한다.

보너스 — disable fork 가 시퀀서 핸드셰이크를 깨뜨린 건 (Part 2.10) UVM 내부 동작을 아는지 보여주는 소재. 여유 있으면 네 번째로 준비.

Part 5. 능동 학습 연습

1. 백지 구조도 — OVERVIEW.svg 를 보지 않고 4블록 + 화살표 그리기
2. 주소 분해 3회 — 연습 1·2를 다른 주소로 (0xDEAD_BEEF 추천)
3. PLRU 손계산 — 연습 5의 표를 백지에서 재현
4. 사이클 세기 — dirty miss / clean miss / read hit 각각 (연습 4)
5. 코드 덮고 재현 — 포워딩 로직(l1_cache_core.sv:196~210) 을 백지에 써보기. 막히는 곳이 정확히 약점이다
6. 일부러 부수기 — Part 3의 실험. plru_update 제거 / byte enable 무시 / 포워딩 제거, 각각 어느 체크가 먼저 우는지 기록
7. 버그 3개 소리 내어 설명 — 각각 30초, 타이머 켜고
8. README "History" 표 읽기 — 코드만 봐선 안 보이는 의사결정 기록이다. "왜 이렇게 했나" 질문의 답이 여기 다 있다

Part 6. 추천 일정 (하루 1~2시간)

Part 7. 예상 질문

캐시 기본

• direct-mapped / set-assoc / full-assoc 차이와 트레이드오프는?
• write-back vs write-through, write-allocate vs no-write-allocate?
• 3C miss는? 이 프로젝트에서 각각 어떻게 구분해서 커버리지로 잡았나?
• 라인 크기를 32B로 키우면 뭐가 좋아지고 뭐가 나빠지나?
• true LRU 대신 tree-PLRU를 쓴 이유는? 4-way에서 몇 bit 차이인가?

이 설계 고유 ⭐

• SRAM read를 왜 registered로 만들었나? 조합형이면 뭐가 터지나?
• read-during-write 해저드를 어떻게 처리했나? 왜 byte 단위인가?
• 포워딩 비교 대상이 왜 s2_* 가 아니라 prev_*_raddr 인가?
• ST_COMPLETE 는 왜 있나? 한 사이클 손해 아닌가? 여기서 stall을 푸는 이유는?
• ST_WB_READ 가 왜 4가 아니라 5 사이클인가?
• valid/dirty/PLRU를 SRAM이 아니라 플롭에 둔 이유는?
• hit throughput은? latency는? 둘의 차이는?
• back-to-back에서 VALID를 안 내린다는 게 무슨 뜻인가? 어떻게 구현했나?

검증 방법론 ⭐

• 스코어보드가 정답을 어떻게 아는가? 왜 메모리 모델이 아니라 캐시 모델인가?
• 파이프라인 DUT에서 응답 순서 문제를 어떻게 풀었나? 왜 analysis port가 2개인가?
• 커버리지를 왜 모니터가 아니라 스코어보드에서 샘플하나?
• bind 는 뭐고 왜 썼나?
• illegal_bins 와 ignore_bins 의 차이는? 후자를 남용하면?
• 커버리지 100%면 검증이 끝난 건가?
• 시드를 여러 개 도는 이유는? 커버리지는 어떻게 합치나?
• 리셋 검증은 어떻게 했나? poisoning은 뭐고 왜 그 범위인가?
• passive agent는 왜 만들었고 어떻게 검증했나?
• RAL은 왜 안 썼나? (함정 — DUT에 memory-mapped register가 없다. CSR 블록을 먼저 설계해야 RAL이 의미를 갖는다. 기법 과시용으로 레지스터를 만들어내지는 않았다)
• SVA와 스코어보드의 역할 차이는?

SystemVerilog / UVM

• clocking block을 왜 쓰나? @(posedge clk); #1ps; 와 뭐가 다른가?
• uvm_analysis_imp_decl 은 왜 필요한가?
• soft constraint 는 언제 쓰나?
• objection과 drain time은?
• disable fork 가 왜 위험한가? 이 프로젝트에서 뭘 깨뜨렸나?
• procedural 블록 안의 선언 초기화가 왜 함정인가? (static — 시간 0에 한 번만)

약점 방어

• non-blocking miss(MSHR)는 왜 없나? (TB 재설계가 필요 — Part 2.9 참고. 반쯤 하다 마느니 미룬 것)
• critical-word-first는? write buffer는? 파라미터화는?
• code coverage / X-propagation / gate-level / formal 은?

가장 중요한 조언

이 프로젝트의 진짜 가치는 "동작하는 캐시 컨트롤러"가 아니라 "통과하는데 아무것도 검증하지 않던 테스트벤치"를 찾아내고 고친 과정이다.

코드 100줄 외우는 것보다 Part 4의 세 문장을 자기 말로 설명하는 게 훨씬 강력하고, 그 앞에 Part 2.3~2.5의 사이클 계산을 손으로 할 수 있으면 "AI가 만들어준 프로젝트"와 "내가 이해한 프로젝트"의 차이가 명확해진다.

시리즈: ... · tb_top · agent_cfg/agent/env · base_test

Test란

"어떤 환경을 만들고, 어떤 자극(sequence)을 흘려보낼지" 결정하는 최고 지휘자
run_test()가 부르는 바로 그 클래스

지금까지 흐름의 시작점이다. tb_top의 run_test("axi4_base_test")가 이 파일을 깨운다.

전체 구조

axi4_base_test (부모 — 뼈대)
    │
    ├── build_phase   : env 생성, vif 받기
    ├── run_phase     : sequence 실행 + drain
    ├── drain()       : 파이프라인 배출 대기
    └── get_seq()     : 어떤 sequence 쓸지 (override 대상!)

    ↓ 상속 (get_seq만 바꿈)

axi4_write_test / read_test / rand_test / directed_test / ...
    → 각자 다른 sequence를 선택

핵심 설계: 부모가 뼈대를 다 만들고, 자식은 get_seq() 하나만 바꿔서 다른 테스트가 됨

Part 1: axi4_base_test — 뼈대

build_phase — 환경 조립

function void build_phase(uvm_phase phase);
    super.build_phase(phase);

    cfg = axi4_agent_cfg::type_id::create("cfg");
    if (!uvm_config_db#(virtual axi4_if)::get(this, "", "vif", cfg.vif))
        `uvm_fatal("NOVIF", "virtual interface 'vif' was not set by tb_top")
    cfg.is_active = UVM_ACTIVE;

    uvm_config_db#(axi4_agent_cfg)::set(this, "env", "cfg", cfg);
    env = axi4_env::type_id::create("env", this);
endfunction

단계별

1. cfg 객체 생성 (아직 비어있음)

2. tb_top이 넣어둔 vif를 꺼내서 cfg에 담기
   ⭐ 여기가 하드웨어-UVM 연결의 완성점!
   tb_top: config_db::set(null, "*", "vif", axi)   ← 넣음
   test:   config_db::get(this, "", "vif", cfg.vif) ← 꺼냄
   → axi 인터페이스가 cfg.vif에 담김
   → cfg를 내려보내면 driver/monitor가 하드웨어 접근 가능

3. active 모드 설정 (sequencer+driver 생성)

4. cfg를 env에 전달 + env 생성
   cfg 전달 체인 시작: test → env → agent → driver/monitor

end_of_elaboration_phase — 계층 출력

function void end_of_elaboration_phase(uvm_phase phase);
    super.end_of_elaboration_phase(phase);
    uvm_top.print_topology();
endfunction

모든 컴포넌트가 만들어진 후 계층 구조를 로그에 출력

print_topology() 출력 예:
  uvm_test_top
    env
      agent
        sqr
        drv
        mon
      sb
      cov

→ "내가 만든 환경이 제대로 조립됐나" 확인용 (디버깅에 유용)
end_of_elaboration_phase = build/connect 다음 (모든 게 생성+연결된 후)

get_seq — 자극 선택 (override 포인트)

virtual function axi4_base_seq get_seq();
    axi4_wr_rd_seq s = axi4_wr_rd_seq::type_id::create("seq");
    return s;
endfunction

virtual 함수 = 자식이 오버라이드할 수 있음!

기본값: axi4_wr_rd_seq (쓰기+읽기 시퀀스)

이게 핵심 설계:
  부모는 "어떤 sequence든 실행"하는 뼈대만 제공
  자식은 get_seq만 바꿔서 다른 sequence 선택
  → polymorphism + factory 패턴!

반환 타입이 axi4_base_seq (부모 타입):
  실제로는 자식 시퀀스를 반환해도 됨 (polymorphism)
  → run_phase는 axi4_base_seq로 받아서 실행 → 어떤 시퀀스든 동일 처리

run_phase — 실행

task run_phase(uvm_phase phase);
    axi4_base_seq seq = get_seq();
    phase.raise_objection(this, "stimulus running");
    `uvm_info("TEST", $sformatf("starting sequence '%s' (num=%0d)",
                                seq.get_type_name(), seq.num), UVM_LOW)
    seq.start(env.agent.sqr);
    drain();
    phase.drop_objection(this, "stimulus done");
endtask

objection 메커니즘

objection = "나 아직 할 일 있어, 끝내지 마" 신호

raise_objection → "시뮬레이션 끝내지 마"
drop_objection  → "이제 끝내도 돼"

모든 objection이 drop되면 → run_phase 종료 → 시뮬레이션 끝

왜 필요? 이거 없으면 run_phase가 바로 끝나버림
        → 시퀀스 실행 전에 시뮬레이션 종료

sequence 실행

seq.start(env.agent.sqr);

get_seq()로 만든 시퀀스를 시퀀서에서 실행!

env.agent.sqr = agent가 만든 시퀀서
→ 시퀀스가 여기에 아이템을 밀어넣음
→ 드라이버가 seq_item_port로 받아서 구동

전체 연결:
  seq.start(sqr) → sqr → drv.seq_item_port → 버스 구동

drain — 파이프라인 배출 (매우 중요)

protected task drain();
    int unsigned guard = 0;
    while (!env.agent.drv.is_idle() && guard < 10000) begin
        #100ns;
        guard++;
    end
    if (guard >= 10000)
        `uvm_error("DRAIN", "driver did not go idle - transactions stuck?")
    #200ns;   // let the final response propagate through the monitor
endtask

주석이 왜 필요한지 설명한다:

// The driver is pipelined: item_done() returns as soon as a burst is
// queued, not when it finishes on the bus.

왜 drain이 필요한가

파이프라인 드라이버의 함정:
  item_done()이 큐에 넣자마자 반환
  → 시퀀스가 "다 보냈다" 생각하고 끝남
  → 근데 버스엔 아직 버스트가 날아다니는 중!

drain 없이 끝내면:
  마지막 버스트들이 응답 못 받고 잘림
  → 스코어보드가 미완료 상태로 종료 → 검증 누락!

drain 동작

while (!env.agent.drv.is_idle() && guard < 10000) begin ... end
  드라이버가 idle 될 때까지 대기
  is_idle() = 큐 비었고 + inflight 0  (driver에서 배운 함수!)

guard = 무한루프 방지 안전장치
  10000번(100ns × 10000 = 1ms) 넘으면 강제 탈출 + 에러
  → 트랜잭션이 멈춰서 영원히 안 끝나는 상황 방지

#200ns = 마지막 응답이 모니터 → 스코어보드까지 도달할 시간 확보

Part 2: 파생 테스트들 — get_seq만 바꿈

단일 방향 테스트 3종

class axi4_write_test extends axi4_base_test;
    virtual function axi4_base_seq get_seq();
        axi4_write_seq s = axi4_write_seq::type_id::create("seq");
        return s;
    endfunction
endclass

write_test → 쓰기만
read_test  → 읽기만
rand_test  → 랜덤

세 클래스 전부 get_seq() 하나만 다름!
나머지(build/run/drain)는 부모 것 그대로 상속
→ 코드 중복 최소화, 뼈대 재사용

polymorphism의 실전 활용:

부모 run_phase에서:
  axi4_base_seq seq = get_seq();  ← virtual이라 자식 버전 호출!

write_test 실행 시 → write_test의 get_seq() → axi4_write_seq
read_test 실행 시  → read_test의 get_seq()  → axi4_read_seq

directed_test — 코너 케이스

directed = 특정 코너를 직접 겨냥
  single beat (len=0), max burst (len=15), 4KB 경계 근처,
  narrow transfer (size < 버스폭), FIXED 버스트

→ "랜덤이 plateau에서 못 가는 코너를 directed로 채움"

cov_test — 커버리지 채우기

class axi4_cov_test extends axi4_base_test;
    virtual function axi4_base_seq get_seq();
        axi4_cov_seq s = axi4_cov_seq::type_id::create("seq");
        s.num = 40;              // extra random traffic after the sweep
        return s;
    endfunction
endclass

커버리지 bin을 채우기 위한 넓은 자극
s.num = 40 → sweep 후 추가 랜덤 40개

주석: "May report WRAP mismatches - those are true positives"
  → WRAP 버그로 인한 미스매치가 나올 수 있고 그건 진짜 버그(true positive)

get_seq에서 시퀀스 필드(num)를 조정하는 것도 가능!

Part 3: 특수 테스트들 (구조가 다름)

outstanding_test — 파이프라인 검증

get_seq가 아니라 build_phase와 run_phase를 직접 오버라이드한다.

class axi4_outstanding_test extends axi4_base_test;

    function void build_phase(uvm_phase phase);
        super.build_phase(phase);
        cfg.max_outstanding = 4;    // ⭐ 파이프라인 깊이 설정
    endfunction

max_outstanding 설정 타이밍이 핵심

super.build_phase(phase);       // 부모가 cfg 만듦
cfg.max_outstanding = 4;        // 그 cfg를 수정

주석: "The driver's build_phase runs after ours, so it picks this up."

순서 (UVM build_phase는 top-down):
  1. test.build_phase → cfg 생성, max_outstanding=4로 수정
  2. env.build_phase (나중)
  3. agent.build_phase (더 나중)
  4. driver.build_phase (가장 나중) → cfg.max_outstanding=4를 읽음

→ test가 먼저 실행되니 cfg 수정이 driver보다 앞섬 → driver가 4를 받음 ✅

run_phase — 쓰기/읽기 분리 pass

task run_phase(uvm_phase phase);
    axi4_os_write_seq wr = ...;
    axi4_os_read_seq  rd = ...;
    phase.raise_objection(this, "outstanding stimulus");

    wr.start(env.agent.sqr);
    drain();                     // 모든 쓰기가 끝나야 읽기 시작

    rd.start(env.agent.sqr);
    drain();

    phase.drop_objection(this, "done");
endtask

주석: "read must not overtake a write that has not completed yet"

왜 분리?
  AXI 읽기/쓰기 채널은 독립적
  → 파이프라인으로 섞으면 읽기가 쓰기를 추월할 수 있음
  → "아직 안 쓴 데이터를 읽는" 상황 → 잘못된 검증

해결:
  phase 1: 쓰기 전부 → drain (다 완료 대기)
  phase 2: 읽기 전부 → drain
  → 쓰기가 확실히 끝난 후 읽기 → 순서 보장

목적: peak 카운터로 파이프라인 동작 증명
  axi_ram(v1)    → peak 1 (한 번에 하나)
  axi_ram_v2     → peak >1 (outstanding 지원)

wrap_test — 일부러 실패하는 테스트

class axi4_wrap_test extends axi4_base_test;
    virtual function axi4_base_seq get_seq();
        axi4_wrap_seq s = axi4_wrap_seq::type_id::create("seq");
        return s;
    endfunction

    function void start_of_simulation_phase(uvm_phase phase);
        super.start_of_simulation_phase(phase);
        `uvm_info("TEST",
            "axi4_wrap_test: UVM_ERRORs below are EXPECTED - they demonstrate the DUT's WRAP-burst bug",
            UVM_LOW)
    endfunction
endclass

이 테스트는 "일부러 실패"함!

목적:
  DUT의 WRAP 버그를 문서화하고 재현
  → 회귀 테스트에는 포함 안 됨 (clean regression 아님)

start_of_simulation_phase:
  시뮬 시작 시 "아래 에러들은 예상된 것"이라고 미리 알림
  → 로그 보는 사람이 "진짜 실패"로 오해 안 하게

negative testing의 일부:
  "버그가 있으면 정말 FAIL 하는가"를 증명하는 테스트

전체 테스트 계층

테스트를 어떻게 고르나 — 커맨드라인

test를 바꾸는 건 코드 수정이 아니라 실행 옵션이다.

# 기본 (base_test)
run_xsim.bat +UVM_TESTNAME=axi4_base_test

# WRAP 버그 재현
run_xsim.bat +UVM_TESTNAME=axi4_wrap_test

# 파이프라인
run_xsim.bat +UVM_TESTNAME=axi4_outstanding_test

한 번 실행 = test 하나 = 시퀀스 하나
여러 개 다 돌리기 = regression 스크립트가 여러 번 자동 실행

전체 흐름 완성

tb_top
  → config_db::set(vif)
  → run_test("axi4_base_test")
        ↓
test.build_phase → cfg 생성, vif를 cfg에 담기 → env 생성
        ↓
env → agent → driver/monitor 생성 (cfg 계속 전달)
        ↓
test.run_phase → get_seq()로 시퀀스 선택 → start → drain
        ↓
sequence → sequencer → driver → 버스 구동
        ↓
DUT 동작 → monitor 관찰 → ap → scoreboard/coverage
        ↓
scoreboard: ref_model과 비교 → pass/fail

한 줄 요약

Test = UVM 계층 최상단, "환경 + 자극"을 결정하는 지휘자

axi4_base_test (뼈대):
  build_phase → cfg 만들고 vif 받고 env 생성
  run_phase   → get_seq()로 시퀀스 선택 → start → drain
  drain()     → 파이프라인 드라이버 배출 대기 (핵심!)
  get_seq()   → virtual, 자식이 오버라이드 (polymorphism)

파생 테스트:
  대부분 get_seq()만 바꿔서 다른 자극 (재사용)
  outstanding → build/run 오버라이드 (max_outstanding=4)
  wrap → 일부러 FAIL (버그 재현)

핵심: 뼈대 하나 만들고 get_seq만 바꿔 수십 개 테스트 생성
     +UVM_TESTNAME으로 런타임에 선택

시리즈: ... · tb_top · agent_cfg/agent/env · base_test

전체 그림 — UVM 계층의 조립

이 세 파일은 UVM 컴포넌트들을 계층으로 묶는 골격이다. 개별 부품(driver, monitor, scoreboard)이 여기서 조립된다.

                    Test (다음 편)
                       │ 생성
                       ↓
        ┌──────────── env ────────────┐
        │                             │
     agent                    scoreboard + coverage
        │                             ↑
  ┌─────┼─────┐                       │
  sqr  drv   mon ───── ap.connect ────┘
  │     │     │
  └─sequencer │
     driver   monitor

cfg (설정 객체) → 모든 컴포넌트에 전달되어 "어떻게 동작할지" 지시

Part 1: axi4_agent_cfg — 설정 객체

역할

"이 agent가 어떻게 동작해야 하는지"를 담은 작은 설정 상자
부품에 붙이는 "사용 설명서" 같은 것

코드

class axi4_agent_cfg extends uvm_object;

    virtual axi4_if         vif;
    uvm_active_passive_enum is_active = UVM_ACTIVE;
    int unsigned max_outstanding = 1;

    `uvm_object_utils(axi4_agent_cfg)

    function new(string name = "axi4_agent_cfg");
        super.new(name);
    endfunction
endclass

3개의 설정값(knob)

1. vif — 하드웨어 핸들

virtual axi4_if vif;

DUT 핀에 접근하는 virtual interface 핸들

tb_top의 config_db::set으로 넘어온 axi 인터페이스가 결국 여기 vif에 담김
→ driver가 cfg.vif로 꺼내서 신호 구동
→ monitor가 cfg.vif로 꺼내서 관찰

2. is_active — 능동/수동 선택

uvm_active_passive_enum is_active = UVM_ACTIVE;

UVM_ACTIVE  → sequencer + driver + monitor 생성 (버스 구동 + 관찰)
UVM_PASSIVE → monitor만 생성 (관찰만)

언제 PASSIVE?
  이미 다른 마스터가 버스를 구동하고 있고 우리는 지켜보기만 할 때
  (예: 실제 CPU가 구동하는 버스를 모니터링)

기본값 UVM_ACTIVE = 우리가 직접 구동

3. max_outstanding — 파이프라인 깊이

int unsigned max_outstanding = 1;

드라이버에서 봤던 그 값!

1  → 직렬 (한 번에 하나씩) = 안전한 기본값
     write-then-read-back 순서 보장
>1 → 파이프라인 (여러 개 동시)
     axi_ram_v2의 outstanding 지원을 검증하려면 필요

driver의 item_thread가 이 값으로 throttle:
  while (n_inflight >= cfg.max_outstanding) @(vif.master_cb);

왜 cfg 객체로 묶나

// Passing knobs via a cfg object (instead of many config_db entries)
// is the standard, scalable UVM style.

❌ 나쁜 방법: 설정마다 config_db 따로
  config_db::set(..., "vif", axi)
  config_db::set(..., "is_active", ...)
  config_db::set(..., "max_outstanding", ...)
  → set/get 호출 폭발, 관리 어려움

✅ 좋은 방법: cfg 객체 하나에 다 담아서 전달
  cfg.vif = ...
  cfg.is_active = ...
  cfg.max_outstanding = ...
  config_db::set(..., "cfg", cfg)  ← 한 번만!
  → 설정 추가해도 cfg에 필드만 늘리면 됨 (확장성)

Part 2: axi4_agent — 컴포넌트 컨테이너

역할

하나의 AXI 인터페이스를 담당하는 UVM 컴포넌트 묶음
sequencer + driver + monitor를 한 상자에 담고 서로 연결

typedef — 시퀀서 정의

typedef uvm_sequencer #(axi4_seq_item) axi4_sequencer;

시퀀서는 특별할 게 없음 → uvm_sequencer를 그대로 사용
우리 아이템 타입(axi4_seq_item)만 지정하면 끝

typedef = 짧은 별명 붙이기 → 따로 클래스 작성 불필요, 한 줄로 해결

왜 driver/monitor는 직접 만드는데 sequencer는 안 만드나?
  driver/monitor: 프로토콜별 로직 필요 → 직접 구현
  sequencer: 아이템을 driver로 전달만 함 → 기본 기능으로 충분

멤버

class axi4_agent extends uvm_agent;
    axi4_agent_cfg cfg;
    axi4_sequencer sqr;
    axi4_driver    drv;
    axi4_monitor   mon;

build_phase — 자식 생성

function void build_phase(uvm_phase phase);
    super.build_phase(phase);
    if (!uvm_config_db#(axi4_agent_cfg)::get(this, "", "cfg", cfg))
        `uvm_fatal("NOCFG", "axi4_agent_cfg not found for agent")

    // 자식에게 cfg 전달
    uvm_config_db#(axi4_agent_cfg)::set(this, "drv", "cfg", cfg);
    uvm_config_db#(axi4_agent_cfg)::set(this, "mon", "cfg", cfg);

    // 모니터는 항상, 시퀀서/드라이버는 active일 때만
    mon = axi4_monitor::type_id::create("mon", this);
    if (cfg.is_active == UVM_ACTIVE) begin
        sqr = axi4_sequencer::type_id::create("sqr", this);
        drv = axi4_driver::type_id::create("drv", this);
    end
endfunction

단계별

1. cfg 받기 (env가 넣어준 것)
   없으면 fatal (설정 없이 동작 불가)

2. 자식(drv, mon)에게 cfg 다시 전달
   "drv" → 이 agent 밑의 drv에게만
   "mon" → 이 agent 밑의 mon에게만
   → driver/monitor의 build_phase에서 get으로 받는 그 cfg!

3. 컴포넌트 생성
   모니터: 항상 (관찰은 언제나 필요)
   시퀀서+드라이버: UVM_ACTIVE일 때만 (구동할 때만)
   → PASSIVE 모드면 모니터만 존재 → 순수 관찰

connect_phase — 드라이버↔시퀀서 연결

function void connect_phase(uvm_phase phase);
    super.connect_phase(phase);
    if (cfg.is_active == UVM_ACTIVE)
        drv.seq_item_port.connect(sqr.seq_item_export);
endfunction

드라이버와 시퀀서를 TLM 포트로 연결

drv.seq_item_port  → 드라이버의 "아이템 달라" 요청 포트
sqr.seq_item_export → 시퀀서의 "아이템 줄게" 제공 포트

connect로 이 둘을 연결
→ driver의 seq_item_port.get_next_item()이 동작하는 근거!

연결 그림:
  Sequence → Sequencer ──seq_item_export──┐
                                           │ connect
  Driver ──seq_item_port──────────────────┘
    get_next_item() → 시퀀서에서 아이템 받음
    item_done()     → 완료 알림

왜 connect_phase에서?
  build_phase: 컴포넌트 생성 / connect_phase: 생성된 것들을 연결
  → UVM phase 순서 (build 다음 connect)

Part 3: axi4_env — 최상위 환경

역할

agent + scoreboard + coverage를 담는 최상위 컨테이너
모니터가 관찰한 걸 scoreboard와 coverage에 뿌리는 연결까지 담당

멤버

class axi4_env extends uvm_env;
    axi4_agent      agent;
    axi4_scoreboard sb;
    axi4_coverage   cov;
    axi4_agent_cfg  cfg;

build_phase — 자식 생성 & cfg 전달

function void build_phase(uvm_phase phase);
    super.build_phase(phase);
    if (!uvm_config_db#(axi4_agent_cfg)::get(this, "", "cfg", cfg))
        `uvm_fatal("NOCFG", "axi4_agent_cfg not found for env")

    uvm_config_db#(axi4_agent_cfg)::set(this, "agent", "cfg", cfg);
    agent = axi4_agent::type_id::create("agent", this);
    sb    = axi4_scoreboard::type_id::create("sb", this);
    cov   = axi4_coverage::type_id::create("cov", this);
endfunction

1. test가 넣어준 cfg 받기
2. agent에게 cfg 전달 (set with "agent" 경로)
3. agent, scoreboard, coverage 생성

cfg 전달 체인:
  test → env → agent → driver/monitor (계층을 따라 내려가며 전달)

connect_phase — 브로드캐스트 연결 (핵심)

function void connect_phase(uvm_phase phase);
    super.connect_phase(phase);
    agent.mon.ap.connect(sb.ap_imp);
    agent.mon.ap.connect(cov.analysis_export);
endfunction

monitor의 ap.write(tr)가 어디로 가는지의 답이 여기다.

모니터의 analysis port(ap)를 두 곳에 연결:

agent.mon.ap → sb.ap_imp              (스코어보드)
agent.mon.ap → cov.analysis_export    (커버리지)

→ 모니터가 ap.write(tr) 하면 스코어보드와 커버리지 둘 다 동시에 받음! (브로드캐스트)

주석 설명:
  checker (is it correct?)  → 스코어보드: 맞는지 검사
  coverage (did we exercise it?) → 커버리지: 뭘 실행했나 기록
  한 트랜잭션 → 두 관점으로 동시 분석

전체 계층 & cfg 흐름

컴포넌트 계층

env
├── agent
│   ├── sequencer (active only)
│   ├── driver    (active only)
│   └── monitor   (always)
├── scoreboard
└── coverage

cfg 전달 체인

tb_top: config_db::set(vif=axi)
   ↓
test: cfg 생성, cfg.vif 채움, config_db::set(cfg)
   ↓
env: get(cfg) → set(agent, cfg)
   ↓
agent: get(cfg) → set(drv, cfg), set(mon, cfg)
   ↓
driver/monitor: get(cfg) → cfg.vif로 하드웨어 접근!

두 방향의 흐름

cfg는 위→아래로 전달 (test→env→agent→driver/monitor)
데이터는 아래→위로 흐름 (monitor→ap→scoreboard/coverage)

한 줄 요약

axi4_agent_cfg = "어떻게 동작할지" 담은 설정 상자
                 (vif, is_active, max_outstanding)

axi4_agent = sqr+drv+mon 묶음
             cfg를 자식에 전달, driver↔sequencer 연결
             active면 전부, passive면 monitor만

axi4_env = agent+scoreboard+coverage 묶음
           monitor의 ap를 SB와 cov에 브로드캐스트 연결

핵심 흐름:
  cfg는 위→아래로 전달 (test→env→agent→driver/monitor)
  데이터는 아래→위로 흐름 (monitor→ap→scoreboard/coverage)

시리즈: ... · ref_model/scoreboard · tb_top · agent_cfg · agent · env · base_test

tb_top이란

지금까지 본 모든 부품(인터페이스, DUT, UVM 환경)을
실제로 연결하고 클록을 돌려서 시뮬레이션을 시작하는 "조립 공장"

driver, monitor, scoreboard, ref_model이 어디서 시작되는지가 여기다.

전체 구조 한눈에

┌─────────────────────── tb_top ────────────────────────┐
│                                                       │
│  ① 클록/리셋 생성                                        │ 
│     clk (100MHz), rst (10사이클 유지)                    │
│                                                       │
│  ② 인터페이스 인스턴스                                     │
│     axi4_if axi(.clk, .rst)                           │
│         ↕ (신호 연결)                                   │
│  ③ DUT 인스턴스                                         │
│     axi_ram dut(.s_axi_awid(axi.awid), ...)           │
│                                                       │
│  ④ UVM에 인터페이스 전달 + 테스트 시작                       │
│     config_db::set(vif) → run_test()                  │
│                                                       │
│  ⑤ 파형 덤프                                            │
└───────────────────────────────────────────────────────┘

0. 헤더 — DUT 선택 스위치

`ifdef DUT_V2
    `define DUT_MODULE axi_ram_v2
`else
    `define DUT_MODULE axi_ram
`endif

이게 "v1에서 fail, v2에서 pass"를 가능하게 하는 핵심이다.

컴파일 옵션에 따라 DUT가 바뀜:

기본:            axi_ram     (WRAP 버그 있는 원본)
+define+DUT_V2:  axi_ram_v2  (WRAP 수정 + outstanding 지원)

두 DUT의 포트 목록이 완전히 동일 → 모듈 이름만 바뀜
→ 같은 테스트벤치로 두 버전 검증 가능!

v1에 돌리면 → 스코어보드가 WRAP 미스매치 잡음 → FAIL
v2에 돌리면 → 수정됐으니 → PASS
→ "버그가 있으면 FAIL, 없으면 PASS" 증명 (테스트 신뢰성)

1. 패키지 import

module tb_top;
    import uvm_pkg::*;
    `include "uvm_macros.svh"
    import axi4_pkg::*;

uvm_pkg          → UVM 클래스들 (uvm_test, uvm_config_db 등)
uvm_macros.svh   → `uvm_info, `uvm_error 같은 매크로
axi4_pkg         → 우리가 만든 것들
                   (axi4_seq_item, AXI_DATA_WIDTH, axi_burst_e 등)

2. 파라미터 — 버스 폭

localparam int DATA_WIDTH = 32;
localparam int ADDR_WIDTH = 16;
localparam int STRB_WIDTH = DATA_WIDTH/8;   // = 4
localparam int ID_WIDTH   = 8;

주석: "must match axi4_pkg + the DUT instance below"
  → 이 값이 패키지, 인터페이스, DUT 세 곳에서 일치해야 함
  → 안 맞으면 신호 폭이 어긋나서 데이터 손실!

localparam = 지역 상수 (외부에서 못 바꿈) → 실수 방지

3. 클록 & 리셋 생성

클록

logic clk;
initial clk = 0;
always #5 clk = ~clk;                 // 100 MHz

initial clk = 0;      → 시작할 때 0
always #5 clk = ~clk; → 5ns마다 반전(toggle)

5ns HIGH + 5ns LOW = 10ns 주기 = 100MHz
1초 / 10ns = 100,000,000 = 100MHz

     ┌──┐  ┌──┐  ┌──┐
─────┘  └──┘  └──┘  └──
     5ns  10ns 15ns 20ns

리셋

logic rst;
initial begin
    rst = 1'b1;                    // 리셋 ON
    repeat (10) @(posedge clk);    // 10 클록 유지
    rst = 1'b0;                    // 리셋 OFF (해제)
end

  ┌────────────────┐
──┘                └──────────
  0    10클록(100ns)

왜 10클록? DUT 내부 모든 FF/상태가 확실히 초기화되도록

이게 driver/monitor에서 봤던 @(negedge vif.rst)가 기다리던 그 신호다. 100ns 시점에 rst가 1→0으로 떨어지면 드라이버와 모니터가 깨어나 동작 시작.

4. 인터페이스 인스턴스

axi4_if #(
    .DATA_WIDTH(DATA_WIDTH),
    .ADDR_WIDTH(ADDR_WIDTH),
    .STRB_WIDTH(STRB_WIDTH),
    .ID_WIDTH(ID_WIDTH)
) axi (
    .clk(clk),
    .rst(rst)
);

axi4_if를 "axi"라는 이름으로 실체화
.clk(clk), .rst(rst) → 위에서 만든 클록/리셋 주입

→ 인터페이스가 "clk, rst를 포트로 받는다"던 부분이 여기서 실제 주입됨!
→ 이제 axi.awvalid, axi.wdata 등 모든 AXI 신호가 존재
  드라이버가 vif.master_cb로 흔들고, 모니터가 vif.monitor_cb로 관찰할 대상

5. DUT 인스턴스 — 신호 연결

`DUT_MODULE #(
    .DATA_WIDTH(DATA_WIDTH), ...
) dut (
    .clk(clk),
    .rst(rst),
    .s_axi_awid(axi.awid),
    .s_axi_awaddr(axi.awaddr),
    ...
);

`DUT_MODULE → axi_ram (또는 axi_ram_v2)로 컴파일 시점에 치환

신호 연결:
.s_axi_awid(axi.awid)
//  ↑ DUT 포트       ↑ 인터페이스 신호

DUT는 plain Verilog라 개별 신호로 직접 연결한다 (interface를 못 받는 순수 모듈).

     인터페이스 axi                    DUT
   ┌──────────────┐              ┌──────────────┐
   │ axi.awvalid  │─────────────→│ s_axi_awvalid│
   │ axi.awaddr   │─────────────→│ s_axi_awaddr │
   │ axi.awready  │←─────────────│ s_axi_awready│
   │ axi.rdata    │←─────────────│ s_axi_rdata  │
   └──────────────┘              └──────────────┘

방향은 인터페이스 신호가 결정:
  드라이버가 axi.awvalid 구동 → DUT의 s_axi_awvalid로 전달
  DUT가 s_axi_awready 구동 → axi.awready로 → 드라이버가 읽음

6. UVM에 인터페이스 전달 + 테스트 시작 (핵심)

initial begin
    uvm_config_db#(virtual axi4_if)::set(null, "*", "vif", axi);
    run_test("axi4_base_test");
end

이 두 줄이 하드웨어 세계와 UVM 세계를 연결하는 다리다.

config_db::set — 인터페이스 넘기기

uvm_config_db#(virtual axi4_if)::set(null, "*", "vif", axi);
//                                    │    │    │      │
//                                    │    │    │      └ 넘길 값 (실제 인터페이스)
//                                    │    │    └ 키 이름 "vif"
//                                    │    └ 경로 "*" (모든 컴포넌트)
//                                    └ 시작점 null (전역)

"axi 인터페이스를 'vif'라는 이름으로 UVM 전체에 등록"

→ driver/monitor의 build_phase에서:
    uvm_config_db#(...)::get(this, "", "vif", ...)
  가 여기서 set한 걸 꺼내는 것!

set(여기서 넣음) ─────→ get(driver/monitor에서 꺼냄)

run_test — 테스트 시작

run_test("axi4_base_test");

UVM 테스트를 시작하는 함수

"axi4_base_test" → 기본 테스트 이름
  → 이 테스트가 env를 만들고 → agent → driver/monitor/sequencer
  → 전체 UVM 계층이 여기서 생성됨!

override 방법:
  +UVM_TESTNAME=axi4_wrap_test (커맨드라인)
  → 코드 수정 없이 다른 테스트 실행

run_test가 하는 일:
  1. +UVM_TESTNAME 확인 (없으면 인자값 사용)
  2. 그 이름의 test 클래스를 factory로 생성
  3. build → connect → run → ... phase 순서로 실행
  4. 모든 phase 끝나면 시뮬레이션 종료

7. 파형 덤프

initial begin
    $dumpfile("waves.vcd");
    $dumpvars;
end

$dumpfile → 파형 저장할 파일 이름
$dumpvars → 모든 신호를 기록
→ waves.vcd 생성 → GTKWave 등으로 파형 디버깅

전체 연결 관계

flowchart TB
    subgraph TB["tb_top (최상단)"]
        CLK["clk 생성<br/>#5 반전 = 100MHz"]
        RST["rst 생성<br/>10클록 유지 후 해제"]
        IF["axi4_if axi<br/>인터페이스 인스턴스"]
        DUT["DUT 인스턴스<br/>axi_ram / axi_ram_v2"]
        CFG["config_db::set(vif, axi)"]
        RUN["run_test()"]
    end

    UVM["UVM 환경<br/>test→env→agent→<br/>driver/monitor/sequencer"]

    CLK --> IF
    RST --> IF
    CLK --> DUT
    RST --> DUT
    IF <-->|s_axi_* 개별 연결| DUT
    IF -.config_db.-> CFG
    CFG -.vif 전달.-> UVM
    RUN -->|테스트 시작| UVM
    UVM -.vif.get.-> IF

지금까지 배운 것과 연결

tb_top이 만든 것 → 어디서 쓰이나

clk, rst        → driver/monitor의 @(negedge vif.rst)가 기다림
axi (인터페이스) → driver가 master_cb로 구동, monitor가 monitor_cb로 관찰
config_db::set  → driver/monitor의 build_phase에서 get으로 꺼냄
run_test        → test→env→agent→driver/monitor/sequencer/scoreboard 생성
DUT_V2 스위치   → v1(버그)/v2(수정) 전환 → 회귀로 버그 증명

한 줄 요약

tb_top = 모든 부품을 조립하고 시뮬레이션을 시작하는 최상단

① 클록/리셋 생성 (100MHz, 10클록 리셋)
② 인터페이스 실체화 (axi)
③ DUT 연결 (s_axi_* 개별 신호 매핑)
④ config_db로 인터페이스를 UVM에 전달 + run_test로 테스트 시작
⑤ 파형 덤프

핵심 다리:
  config_db::set(vif) → driver/monitor가 get으로 받아 하드웨어 접근
  DUT_V2 define → 같은 TB로 버그/수정 버전 둘 다 검증

시리즈: 아이템 · 인터페이스 · 드라이버 · 모니터 · 관계 · ref_model/scoreboard

전체 그림 — 검증의 심판대

모니터가 관찰한 트랜잭션이 최종적으로 "맞는지 틀린지" 판정되는 곳이다.

Monitor가 관찰한 트랜잭션
        │ ap.write(tr)
        ↓
   ┌─────────────────────────────────────┐
   │          Scoreboard (심판)           │
   │                                     │
   │  WRITE → ref_model.apply_write()    │  "이렇게 됐어야 해"
   │  READ  → check_read()               │  "실제로 맞나 비교"
   │              │                      │
   │              ↓                      │
   │  ┌────────────────────────┐         │
   │  │  Reference Model        │         │
   │  │  (골든 모델 = 정답지)    │         │
   │  │  byte 단위 sparse memory │         │
   │  └────────────────────────┘         │
   └─────────────────────────────────────┘

핵심 분업:

• Reference Model = "메모리가 이렇게 됐어야 한다"를 계산하는 정답지
• Scoreboard = 정답지와 DUT 실제 결과를 비교하는 심판

Part 1: axi4_ref_model — 골든 메모리 모델

설계 철학 (주석이 핵심)

// Deliberately independent of the DUT's implementation
// The DUT increments the address linearly even for WRAP bursts, so
// a WRAP write/read pair will disagree with this model — that is a
// real DUT bug, not a modelling error.

이 주석이 "골든 모델 독립 구현" 원칙의 실제 구현이다.

DUT 코드를 보고 만들면:
  DUT가 WRAP을 INCR처럼 처리 → 골든 모델도 똑같이 처리
  → 둘 다 틀렸는데 일치 → PASS → 버그 놓침 ❌

스펙만 보고 독립 구현:
  골든 모델은 beat_addr()로 "올바른" WRAP 주소 계산
  DUT는 "틀린" 선형 증가
  → 둘이 불일치 → 버그 노출 ✅

→ 이 파일이 WRAP 버그를 잡을 수 있었던 근본 이유

핵심 오해 먼저 풀기

❌ 오해: ref_model이 스펙 문서를 읽어서 미리 정답을 다 적어둔다
✅ 진실: ref_model은 모니터가 관찰한 "실제 트랜잭션"을 받아서
        그때그때 계산한다

"스펙 문서로 보고 만든다"는 건 코드를 짤 때 얘기다. 실행 중에 문서를 읽는 게 아니라, 개발자가 스펙대로 beat_addr() 같은 계산 규칙을 코드에 박아둔 것이다.

정리하면:

• 정답의 값은 관찰한 쓰기에서 온다 (0xAB를 쓰는 걸 보면 0xAB를 기억)
• 정답의 위치(주소)만 스펙을 따른다 (beat_addr가 WRAP/INCR를 스펙대로 계산)

클래스 선언 & 메모리 구조

class axi4_ref_model extends uvm_object;
    `uvm_object_utils(axi4_ref_model)

    protected bit [7:0] mem [bit [AXI_ADDR_WIDTH-1:0]];

왜 uvm_component가 아니라 uvm_object인가

uvm_object 상속:
  → 계층 구조(hierarchy)에 안 들어감
  → phase(build/run/report)가 없음
  → 그냥 "데이터를 담는 객체"

이유:
  ref_model은 스코어보드가 소유하고 호출하는 도구
  독립적으로 phase를 돌 필요 없음 → 가벼운 uvm_object가 적합

mem — Associative Array (연관 배열)

protected bit [7:0] mem [bit [AXI_ADDR_WIDTH-1:0]];
//         ↑ 값: 1바이트   ↑ 키: 주소

이게 "byte-granular sparse memory"다.

byte-granular (바이트 단위):
  값이 bit[7:0] = 1바이트 → 주소 하나당 1바이트 저장
  → write strobe를 정확히 모델링 가능 (특정 바이트만 쓰는 걸 그대로 반영)

sparse (희소):
  associative array = 실제로 쓴 주소만 저장
  → 64KB 전체를 배열로 잡지 않음 (메모리 절약)
  → mem[0x1000] 쓰면 그 주소만 생김

일반 배열 vs 연관 배열:

bit [7:0] mem [65536];        ← 64KB 전부 할당 (안 써도)
bit [7:0] mem [bit[15:0]];    ← 쓴 주소만 (sparse)

함수 3개만 이해하면 끝

1. read_byte — "이 주소 값 뭐야?"

function bit [7:0] read_byte(bit [AXI_ADDR_WIDTH-1:0] a);
    return mem.exists(a) ? mem[a] : 8'h00;
endfunction

mem.exists(a): 이 주소에 값이 있나?
  있으면 → mem[a] 반환
  없으면 → 8'h00 반환

왜 없으면 0?
  DUT가 시작 시 메모리를 0으로 초기화 → 안 쓴 주소는 0이어야 함
  → 모델도 안 쓴 주소를 0으로 예측 → DUT와 일치

2. apply_write — "쓰기를 정답지에 반영" (핵심)

DUT가 쓰기를 하면, 정답지에도 똑같이 써놓는 함수.

function void apply_write(axi4_seq_item tr);
    bit [AXI_ADDR_WIDTH-1:0] a, word_base;
    foreach (tr.data[i]) begin
        a         = tr.beat_addr(i);
        word_base = a - (a % AXI_STRB_WIDTH);
        for (int lane = 0; lane < AXI_STRB_WIDTH; lane++)
            if (tr.strb[i][lane])
                mem[word_base + lane] = tr.data[i][8*lane +: 8];
    end
endfunction

구체적 숫자로 따라가보면:

상황: 0x1000에 데이터 0xDDCCBBAA 쓰기, strb = 4'b1010

strb = 1010 의미:
  bit0=0 → 바이트0 안 씀
  bit1=1 → 바이트1 씀
  bit2=0 → 바이트2 안 씀
  bit3=1 → 바이트3 씀

데이터 0xDDCCBBAA를 바이트로 쪼개면:
  바이트0=0xAA, 바이트1=0xBB, 바이트2=0xCC, 바이트3=0xDD

strb에 따라 1번, 3번만 저장:
  mem[0x1001] = 0xBB   (바이트1)
  mem[0x1003] = 0xDD   (바이트3)
  (0x1000, 0x1002는 안 씀 → 사전에 안 생김)

이게 "write strobe를 정확히 반영"한다는 뜻이다. DUT가 특정 바이트만 썼으면, 정답지도 그 바이트만 쓴다.

beat_addr(i)가 버그를 잡는 지점

a = tr.beat_addr(i);   ← 여기가 핵심!

beat_addr는 seq_item의 함수로 WRAP/INCR/FIXED 주소를 "올바르게" 계산

DUT는 WRAP을 틀리게 계산하는데
ref_model은 여기서 올바르게 계산
→ 나중에 둘이 안 맞아서 버그 노출

word_base = a - (a % AXI_STRB_WIDTH) — 버스 폭 정렬

주소 a를 버스 폭(4바이트) 배수로 내림 = "a가 속한 워드의 시작 주소"

a = 0x1006:
  0x1006 % 4 = 2
  word_base = 0x1006 - 2 = 0x1004

DUT는 메모리를 워드(4바이트) 단위로 다룸 (mem[addr>>2])
→ ref_model도 워드 시작을 알아야 바이트 레인을 정확히 매핑

[8*lane +: 8] 문법

+: = "이 위치부터 N비트" (part-select)

data[8*lane +: 8] = data[8*lane]부터 8비트
  lane=0: data[7:0]    ← 바이트 0
  lane=1: data[15:8]   ← 바이트 1
  lane=2: data[23:16]  ← 바이트 2
  lane=3: data[31:24]  ← 바이트 3

왜 이 문법? data[8*lane+7 : 8*lane]처럼 쓰면 lane이 변수라 에러
           +: 는 시작점이 변수여도 됨 (폭은 상수)

3. expected_beat — "읽으면 뭐가 나와야 해?"

apply_write의 역방향. 읽기 검증 시 "정답"을 알려준다.

function bit [AXI_DATA_WIDTH-1:0] expected_beat(axi4_seq_item tr, int i);
    bit [AXI_ADDR_WIDTH-1:0] a, word_base;
    a         = tr.beat_addr(i);
    word_base = a - (a % AXI_STRB_WIDTH);
    for (int lane = 0; lane < AXI_STRB_WIDTH; lane++)
        expected_beat[8*lane +: 8] = read_byte(word_base + lane);
endfunction

apply_write:   data → mem (쓰기)
expected_beat: mem → 예상 data (읽기)

한 beat에 대해:
  1. beat_addr(i)로 올바른 주소 계산
  2. word_base로 정렬
  3. 4개 레인의 바이트를 mem에서 읽어 32비트 워드 조립

왜 전체 워드를 조립하나:

DUT는 읽기 시 32비트 워드 전체를 반환 (narrow transfer라도 워드 전체)
→ 모델도 워드 전체를 조립
→ 그중 유효한 레인만 스코어보드가 mask로 비교

세 함수의 관계

쓸 때:   apply_write로 mem 채움
읽을 때: expected_beat로 "정답" 만들어서 스코어보드에 줌
        → 스코어보드가 DUT 실제 값과 비교

Part 2: axi4_scoreboard — 심판

역할

"DUT가 준 답"과 "정답지(ref_model)"를 비교해서
맞았는지 틀렸는지 판정하는 채점관

클래스 선언 & analysis port

class axi4_scoreboard extends uvm_scoreboard;
    `uvm_component_utils(axi4_scoreboard)

    uvm_analysis_imp #(axi4_seq_item, axi4_scoreboard) ap_imp;
    axi4_ref_model ref_model;

    int unsigned n_writes, n_reads, n_beats, n_mismatch;

uvm_analysis_imp — 모니터의 반대편

Monitor:     uvm_analysis_port  #(...)  ap;      ← 보내는 쪽
Scoreboard:  uvm_analysis_imp   #(...)  ap_imp;  ← 받는 쪽

imp = implementation → analysis port로 들어온 데이터를 받는 포트

#(axi4_seq_item, axi4_scoreboard) 파라미터

uvm_analysis_imp #(T, IMP)
  T   = axi4_seq_item     ← 받을 데이터 타입
  IMP = axi4_scoreboard   ← write() 함수를 가진 클래스 (나 자신!)

imp는 데이터를 받으면 IMP의 write() 함수를 자동 호출
→ 그래서 스코어보드에 write() 함수를 반드시 구현해야 함

통계 카운터

n_writes    : 쓰기 버스트 개수
n_reads     : 읽기 버스트 개수
n_beats     : 검사한 beat 개수
n_mismatch  : 바이트 미스매치 개수 ← 이게 0이 아니면 버그!

new() & build_phase()

function new(string name, uvm_component parent);
    super.new(name, parent);
    ap_imp = new("ap_imp", this);           // analysis imp 생성
endfunction

function void build_phase(uvm_phase phase);
    super.build_phase(phase);
    ref_model = axi4_ref_model::type_id::create("ref_model");
endfunction

ap_imp = new(...)          → new()에서 (TLM 포트라 Factory 아님)
ref_model = create(...)    → build_phase에서 (Factory로, override 가능)

포트는 계층 연결에 필요 → 생성자에서 즉시
ref_model은 factory override 대상 → build_phase에서

write() — 진입점

function void write(axi4_seq_item tr);
    if (tr.dir == AXI_WRITE) begin
        ref_model.apply_write(tr);      // 모델 업데이트
        n_writes++;
    end
    else begin
        check_read(tr);                 // 비교!
        n_reads++;
    end
endfunction

모니터가 ap.write(tr) 하면 → 이 함수가 자동 호출됨

WRITE 버스트: "메모리가 이렇게 됐어야 해" → 모델에 반영 (정답지 갱신)
READ 버스트:  "실제로 맞나?" → check_read로 비교 (채점)

순서가 중요 — write 먼저, read 나중

시퀀스: 0x1000에 쓰고 → 0x1000 읽기
  1. write(0x1000) → apply_write → 모델 갱신
  2. write(0x1000) → check_read → 모델과 비교

→ 쓰기가 먼저 반영돼야 읽기 비교가 정확
→ 모니터가 in-order로 보내는 게 전제

check_read() — 실제 비교 (핵심)

protected function void check_read(axi4_seq_item tr);
    bit [AXI_DATA_WIDTH-1:0] exp;
    bit [AXI_STRB_WIDTH-1:0] mask;
    foreach (tr.data[i]) begin
        exp  = ref_model.expected_beat(tr, i);   // 예상값
        mask = tr.lane_mask(i);                   // 유효 레인
        n_beats++;
        for (int lane = 0; lane < AXI_STRB_WIDTH; lane++) begin
            if (!mask[lane]) continue;            // lane not addressed
            if (tr.data[i][8*lane +: 8] !== exp[8*lane +: 8]) begin
                n_mismatch++;
                `uvm_error("SB_MISMATCH", $sformatf(
                    "READ mismatch @beat %0d lane %0d: addr=0x%04h burst=%s size=%0d len=%0d | expected 0x%02h, got 0x%02h",
                    i, lane, tr.beat_addr(i), tr.burst.name(), tr.size, tr.len,
                    exp[8*lane +: 8], tr.data[i][8*lane +: 8]))
            end
        end
    end
endfunction

단계별 흐름

exp  = ref_model.expected_beat(...)  → 정답지에게 "이 주소 읽으면 뭐가 나와야 해?"
mask = tr.lane_mask(i)               → "이 beat에서 실제로 볼 바이트가 어디야?"

mask로 유효 레인만 비교 (매우 중요)

// Only the byte lanes that the beat actually addresses are compared:
// for a narrow transfer the other lanes are don't-care in AXI, so
// checking them would produce false failures on a different slave.

narrow transfer(부분 전송)에서:
  버스는 32비트인데 실제로는 일부 레인만 유효
  나머지 레인은 AXI상 don't-care (아무 값이나 와도 됨)

모든 레인을 비교하면?
  → don't-care 레인의 쓰레기 값 때문에 false failure

→ mask[lane]이 1인 레인만 비교 → 유효한 데이터만 검사 → false failure 방지

!== 4-state 비교

!== : 4-state 비교 (X/Z까지 정확히)

왜 != 아니고 !== ?
  DUT가 X를 반환하면:
    != → 결과 X (불확실) → if가 애매하게 동작
    !== → 명확히 "다름" → 미스매치로 확실히 잡음

→ seq_item do_compare의 === 와 같은 원리, X 전파 버그를 놓치지 않음

에러 메시지 — 디버깅 정보 총동원

미스매치 시 출력:
  @beat i, lane      → 어느 beat, 어느 바이트에서
  addr=beat_addr(i)  → 정확한 주소 (WRAP이면 계산된 주소!)
  burst=WRAP         → 어떤 버스트 타입에서
  size, len          → 전송 크기/길이
  expected vs got    → 기대값 vs 실제값

→ WRAP 버그 발생 시:
  addr가 "올바른 WRAP 주소"로 찍히고, DUT는 그 주소에 다른 값을 넣음
  → 버그 위치 특정 가능

report_phase() — 최종 성적표

function void report_phase(uvm_phase phase);
    super.report_phase(phase);
    `uvm_info("SB", $sformatf(
        "scoreboard: %0d write bursts, %0d read bursts, %0d beats checked, %0d byte mismatches",
        n_writes, n_reads, n_beats, n_mismatch), UVM_LOW)
endfunction

시뮬레이션 끝에 출력:
  scoreboard: 42 write bursts, 40 read bursts, 269 beats checked, 0 byte mismatches

n_mismatch = 0 → 모든 읽기가 예상과 일치 ✅
n_mismatch > 0 → 버그! (uvm_error가 이미 났을 것)

이력서의 "24 byte-level mismatches"가 바로 이 n_mismatch
→ WRAP 버그 있을 때 이 숫자가 24로 나왔던 것

Part 3: 전체 데이터 흐름

Write 경로 & Read 경로 (버그 검출)

왜 이 구조가 WRAP 버그를 잡았나

1. ref_model이 beat_addr()로 "올바른" WRAP 주소 사용
   → DUT의 "틀린" 선형 주소와 다름

2. 비대칭(WRAP write + INCR read):
   ref_model: WRAP write를 올바른 주소에 반영
   DUT:       WRAP write를 틀린 주소에 씀
   INCR read: 양쪽 다 올바른 주소로 읽음
   → DUT가 틀린 곳에 썼으니 그 주소엔 원하는 값 없음
   → 미스매치 노출!

전체 판정 흐름도

한눈에 정리

핵심:
  ref_model = "관찰한 쓰기 값"을 "스펙대로의 주소"에 기억해뒀다가
              읽기 검증 때 정답으로 제시하는 장부
              (값은 관찰에서, 주소 규칙은 스펙에서)

  scoreboard = DUT 답을 정답지와 비교하는 채점관
               자기가 직접 메모리 계산 안 함 → ref_model에게 물어보고 비교만

인터뷰 대비 예상 질문

Q. 왜 골든 모델을 byte 단위로 만들었나?
A. write strobe를 정확히 모델링하기 위해. AXI는 바이트 레인 단위로
   선택적 쓰기가 가능한데, 워드 단위 모델이면 이걸 표현 못 함.

Q. sparse memory를 쓴 이유는?
A. 64KB 전체를 배열로 잡으면 낭비. 연관 배열로 쓴 주소만 저장하고,
   안 쓴 주소는 DUT 초기값 0x00으로 예측.

Q. narrow transfer에서 왜 mask로 걸러 비교하나?
A. narrow transfer는 일부 레인만 유효하고 나머지는 AXI상 don't-care.
   전부 비교하면 don't-care 레인 때문에 false failure가 남.

Q. ref_model은 정답을 어디서 아나?
A. 미리 아는 게 아님. 모니터가 관찰한 쓰기 트랜잭션이 지나갈 때
   그 값을 저장. 주소만 스펙(beat_addr)대로 계산.

Q. 이 구조가 어떻게 WRAP 버그를 잡았나?
A. ref_model이 beat_addr()로 올바른 WRAP 주소를 쓰는데 DUT는 선형
   증가시킴. 비대칭 WRAP-write/INCR-read로 두 주소 계산이 갈라지게
   해서 미스매치를 노출.

시리즈 마무리: 아이템 · 인터페이스 · 드라이버 · 모니터가 어떻게 맞물리나

네 파일의 관계

                    axi4_seq_item (아이템)
              "AXI 버스트 하나"의 공통 표현
         ┌──────────────────────────────────────┐
         │ Sequence가 randomize → Driver가 구동  │
         │ Monitor가 재조립 → Scoreboard가 비교  │
         └──────────────────────────────────────┘
                          ▲   ▲
          같은 객체 타입을 │   │ 공유
                          │   │
┌────────────────────────────────────────────────────────┐
│                     axi4_if.sv                          │
│   master_cb (드라이브)      monitor_cb (샘플)           │
│   #1step / #1               #1step only                 │
└──────────┬────────────────────────┬────────────────────┘
           │ vif.master_cb          │ vif.monitor_cb
    ┌──────▼──────┐          ┌──────▼─────┐
    │ axi4_driver │          │axi4_monitor│
    │             │          │            │
    │ 큐: 보낼 것 │          │ 큐: 본 것  │
    │ aw_q,w_q,   │          │ aw_q,      │
    │ ar_q        │          │ w_done_q,  │
    │             │          │ ar_q       │
    │ pop → 구동  │          │ [0]참조→채움│
    │ item_done() │          │ ap.write() │
    │  즉시!      │          │            │
    └──────┬──────┘          └─────┬──────┘
           │                        │
           │   axi4_seq_item        ▼
           └───────┬─────────→ Scoreboard
                              (do_compare로 판정)

flowchart LR
    ITEM["axi4_seq_item<br/>(아이템)<br/>버스트 1개 표현"]

    SEQ["Sequence"] -->|randomize| ITEM
    ITEM -->|beat_addr 공유| REF["Reference Model"]
    ITEM --> DRV["axi4_driver"]
    IF["axi4_if<br/>(clocking block)"] -.master_cb.-> DRV
    IF -.monitor_cb.-> MON["axi4_monitor"]
    DRV -->|핀 구동| BUS["AXI 버스"]
    BUS -->|핀 관찰| MON
    MON -->|재조립한 아이템| SB["Scoreboard"]
    REF -->|예측한 아이템| SB
    SB -->|do_compare| RESULT["pass / fail"]

역할 대비표

파라미터 일관성

아이템:     AXI_DATA_WIDTH, AXI_ADDR_WIDTH, AXI_STRB_WIDTH (패키지)
인터페이스: DATA_WIDTH=32, ADDR_WIDTH=16, STRB_WIDTH=4

이 둘이 다르면:
  seq_item.data는 64비트인데 vif.wdata는 32비트
  → 상위 비트 잘림 → 조용한 데이터 손실!

해결: package의 파라미터를 인터페이스 default로 사용해 단일 소스화

네 파일이 함께 만드는 이슈

아이템 규칙: WRAP은 len {1,3,7,15}, 4KB 경계 준수 (constraint)
드라이버:    beat_addr()로 WRAP 주소 계산해 구동
      +
드라이버 이슈: W가 AW보다 먼저 나갈 수 있음 (채널 독립)
      +
모니터 가정: AW를 먼저 봤다고 가정 (aw_q[0]에 채움)
      ↓
특정 backpressure 패턴에서 모니터가 W beat를 놓침!

→ 둘 중 하나를 고쳐야 함
   (드라이버: AW 핸드셰이크 후 w_q push / 모니터: W 버퍼링)

부록: 레쥬메 표현 예시

Item (seq_item):

Encoded AXI4 protocol legality (4KB boundary, size/address alignment, WRAP beat-count rules) directly into SystemVerilog constraints, and implemented burst-accurate address prediction shared by driver and reference model — exposing a DUT bug where WRAP bursts incremented linearly.

Interface:

Designed a parameterized AXI4 SystemVerilog interface with separate driver/monitor clocking blocks (sample/drive skews) and direction-enforcing modports, eliminating clock-edge race conditions at compile time.

Driver:

Built a pipelined AXI4 master driver with per-channel threads and configurable outstanding depth, instrumented with peak-concurrency counters that quantitatively prove multi-outstanding traffic reached the DUT — the same driver degrades to strictly serialized behavior against single-outstanding slaves without code changes.

Monitor:

Architected an outstanding-aware, channel-parallel AXI4 monitor using per-phase FIFO correlation, preventing transaction loss under multi-outstanding traffic.

인터뷰 대비 예상 질문

1. 왜 clocking block을 두 개 만들었나? 마스터는 드라이브+샘플이 섞여있고 모니터는 순수 샘플만 해야 하는데, 하나의 CB로는 두 역할의 방향을 동시에 표현할 수 없어서.

2. blocking 드라이버와 pipelined 드라이버의 차이는? item_done()을 언제 부르냐. 즉시 부르면 시퀀스가 버스보다 앞서 달려 Outstanding이 생김.

3. wr_peak 카운터는 왜 필요한가? Outstanding 미지원 슬레이브는 이 값을 1 이상 못 올림. 따라서 이 카운터가 "파이프라인이 실제로 동작했다"는 증거.

4. 모니터가 aw_q[0]을 pop하지 않고 참조만 하는 이유는? Handle 복사로 큐 안 객체를 직접 채우기 위해. WLAST에서야 pop.

5. W가 AW보다 먼저 나가면 무슨 일이 생기나? AXI상 합법이지만 이 모니터는 AW를 먼저 봤다고 가정 → beat 유실 가능.

6. 시퀀스가 seq_item을 재사용하면 왜 위험한가? 파이프라인 드라이버는 큐에 Handle을 저장 → 원본 재랜덤화 시 큐 내용도 변경. Deep copy 또는 매번 create로 방지.

7. do_compare에서 == 대신 ===를 쓰는 이유는? ==는 2-state라 X/Z가 있으면 결과가 X(불확실). ===는 4-state로 X까지 정확히 비교 → DUT가 X를 뱉는 버그를 명확히 불일치로 잡음.

8. WRAP 버스트를 어떻게 검증했나? beat_addr()가 정확한 WRAP window 계산을 하고, DUT는 WRAP을 INCR처럼 선형 증가시키는 버그가 있어 스코어보드에서 미스매치로 포착됨.

시리즈: 아이템 · 인터페이스 · 드라이버 · 모니터

axi4_monitor — 채널 병렬 옵저버

전체 구조

        AXI 버스 (5채널)
             │
   ┌─────┬───┼───┬─────┬─────┐
   ↓     ↓   ↓   ↓     ↓     ↓
mon_aw mon_w mon_b mon_ar mon_r   ← 5개 스레드 병렬
   │     │     │     │     │
   └──aw_q──w_done_q──┘     │
         (write 파이프)      │
                    ar_q ────┘
                          │
                          ↓
                    ap.write(tr) → Scoreboard / Coverage

핵심: 채널마다 독립 스레드 + 큐(FIFO)로 phase를 이어붙임 (드라이버가 "구동"을 채널 병렬로 했듯, 모니터는 "관찰"을 채널 병렬로)

왜 이 구조인가

순차 "AW → W → B" 루프의 함정:

T=0: AW #1 잡음
T=1: AW #2 발생 → W beat 수집 중이라 못 봄! ❌
...

→ Outstanding 발생 순간 조용히 데이터 유실 (에러도 안 남)

채널 병렬:
  mon_aw는 오직 AW만 감시 → 절대 안 놓침
  큐로 phase 연결 → Outstanding depth 몇이든 캡처 ✅

큐 3개 — 모니터의 심장

protected axi4_seq_item aw_q[$];      // AW 봤음, W 아직 안 끝남
protected axi4_seq_item w_done_q[$];  // W 끝남, B 기다리는 중
protected axi4_seq_item ar_q[$];      // AR 봤음, R 아직 안 끝남

Write 생애:  AW핸드셰이크 → [aw_q] → (WLAST) → [w_done_q] → (B) → ap.write()
Read 생애:   AR핸드셰이크 → [ar_q] → (RLAST) → ap.write()
             (읽기는 R에 RRESP 같이 오므로 B 단계 불필요)

run_phase() — 5개 스레드

task run_phase(uvm_phase phase);
    @(negedge vif.rst);      // 리셋 해제 대기 (X 관찰 방지)
    fork
        mon_aw();  mon_w();  mon_b();  mon_ar();  mon_r();
    join                     // 전부 forever → 시뮬 끝까지 유지
endtask

join 선택 이유: 5개 태스크 전부 forever → 절대 안 끝남
              → join이 영원히 블록 → run_phase가 시뮬 끝까지 유지
              (join_none이면 phase 종료로 판단해 스레드가 죽을 수 있음)

모니터는 objection을 걸지 않음 (Driver/Sequence가 관리)

mon_aw() — 쓰기 주소 관찰

task mon_aw();
    axi4_seq_item tr;
    forever begin
        @(vif.monitor_cb);
        if (vif.monitor_cb.awvalid && vif.monitor_cb.awready) begin  // 핸드셰이크
            tr       = axi4_seq_item::type_id::create("mon_wr");
            tr.dir   = AXI_WRITE;
            tr.id    = vif.monitor_cb.awid;
            tr.addr  = vif.monitor_cb.awaddr;
            tr.len   = vif.monitor_cb.awlen;
            tr.size  = vif.monitor_cb.awsize;
            tr.burst = axi_burst_e'(vif.monitor_cb.awburst);   // enum cast
            tr.data  = new[tr.len + 1];      // 배열 미리 할당
            tr.strb  = new[tr.len + 1];
            aw_q.push_back(tr);
        end
    end
endtask

@(vif.monitor_cb): Clocking Block의 #1step 덕에 race-free 샘플링
awvalid && awready: 골든 룰 4 → 핸드셰이크 성립 = 주소 전송 완료
enum cast: awburst(2'b01) → AXI_INCR → 로그 가독성 & 비교 편의
new[len+1]: AWLEN=3 → 4 beat → 배열 크기 4

mon_w() — 쓰기 데이터 관찰 (핵심)

task mon_w();
    axi4_seq_item tr;
    int unsigned  beat = 0;      // forever 반복 사이에 값 유지
    forever begin
        @(vif.monitor_cb);
        if (vif.monitor_cb.wvalid && vif.monitor_cb.wready) begin
            if (aw_q.size() == 0)
                `uvm_warning("MON", "W beat with no outstanding AW - ignored")
            else begin
                tr = aw_q[0];            // ⚠️ pop 안 함! 참조만!
                if (beat <= tr.len) begin
                    tr.data[beat] = vif.monitor_cb.wdata;
                    tr.strb[beat] = vif.monitor_cb.wstrb;
                end
                if (vif.monitor_cb.wlast) begin
                    void'(aw_q.pop_front());     // 이제 제거
                    w_done_q.push_back(tr);      // B 대기로 이동
                    beat = 0;
                end
                else beat++;
            end
        end
    end
endtask

핵심 트릭: tr = aw_q[0] (pop 아님!)
  tr은 Handle 복사 → tr 수정 = 큐 안 객체 수정 (의도된 동작!)
     aw_q[0] ──┐
                ├──→ [같은 Object]
     tr ───────┘
  tr.data[beat]=... → 큐 안 객체가 직접 채워짐 ✅

범위 가드 (beat <= tr.len): WLAST 안 오고 beat 계속 오면
  배열 범위 밖 접근 방지

void'(): pop_front() 반환값 안 쓴다는 표시 (경고 억제)

mon_b() — 쓰기 응답 관찰

task mon_b();
    forever begin
        @(vif.monitor_cb);
        if (vif.monitor_cb.bvalid && vif.monitor_cb.bready) begin
            if (w_done_q.size() == 0)
                `uvm_warning("MON", "B response with no completed write burst")
            else begin
                tr      = w_done_q.pop_front();
                tr.resp = axi_resp_e'(vif.monitor_cb.bresp);
                ap.write(tr);        // Scoreboard/Coverage로 발행! 🎉
            end
        end
    end
endtask

B 핸드셰이크 = 쓰기 완료 → w_done_q에서 pop → resp 저장 → ap.write()

ap.write(tr)는 Handle 전달
→ 모니터는 매번 create()로 새 객체 → 재사용 안 함 → 안전
→ 단, Scoreboard가 저장할 땐 copy()로 독립 복사본 필수

mon_ar() / mon_r() — 읽기 채널

// mon_ar: mon_aw와 거의 동일, 유일한 차이:
foreach (tr.strb[j]) tr.strb[j] = '1;   // 읽기는 STRB 없음 → 전부 1

// mon_r: mon_w와 구조 같지만 2가지 차이
tr.resp = axi_resp_e'(vif.monitor_cb.rresp);   // 차이1: 응답이 R에 함께
if (vif.monitor_cb.rlast) begin                // 차이2: RLAST에서 바로 발행
    void'(ar_q.pop_front());
    ap.write(tr);        // B 대기 없이 즉시!
    beat = 0;
end

차이 1 — 응답이 데이터 채널에 함께
  읽기는 별도 응답 채널 없음 → RLAST 시점에 바로 ap.write()

차이 2 — RRESP는 beat마다 옴 (⚠️ 이슈)
  tr.resp = ... 를 매 beat 덮어씀
  → 중간 beat의 SLVERR가 마지막 OKAY에 덮여 사라질 수 있음

타임라인 — Outstanding 2개

사이클  버스 이벤트     큐 상태
─────  ─────────────  ─────────────────────
 1     AW #1          aw_q=[tr1]
 2     AW #2          aw_q=[tr1, tr2]   ← 순차 구현이면 유실!
 3     W beat (tr1)   aw_q=[tr1, tr2]
 4     W WLAST (tr1)  aw_q=[tr2], w_done_q=[tr1]
 5     W beat (tr2)   aw_q=[tr2], w_done_q=[tr1]
 6     W WLAST (tr2)  aw_q=[], w_done_q=[tr1, tr2]
 7     B #1           w_done_q=[tr2]  → tr1 발행
 8     B #2           w_done_q=[]     → tr2 발행

모니터 구조 다이어그램

스레드 구조 & 데이터 흐름

채널마다 독립 스레드로 관찰하고, 큐로 phase를 이어붙여 Outstanding 트랜잭션을 유실 없이 캡처.

Write 트랜잭션 생애 (큐 이동)

읽기는 더 단순 (B 단계 없음):
AR 핸드셰이크 → ar_q → R beats 채움 → RLAST에서 바로 ap.write()
(R 채널에 RRESP가 같이 오므로 별도 응답 채널 불필요)

mon_w 내부 로직 (가장 복잡한 스레드)

핵심 트릭: tr = aw_q[0] (pop 아님!)
  → Handle 복사라 tr 수정 = 큐 안 객체 직접 채움
  → WLAST에서야 pop_front()로 제거

드라이버 vs 모니터 큐 방향 대비

드라이버: 큐 → 버스  (pop 후 구동)
모니터:   버스 → 큐  ([0] 참조하며 채우고 발행)
방향이 정확히 반대

전체 마인드맵

mindmap
  root((axi4_monitor))
    설계철학
      채널 병렬 관찰
      순차 루프는 Outstanding 유실
      passive - monitor_cb만 사용
    5개 스레드
      mon_aw - 쓰기 주소
      mon_w - 쓰기 데이터
      mon_b - 쓰기 응답
      mon_ar - 읽기 주소
      mon_r - 읽기 데이터
    3개 상관 큐
      aw_q - AW봤음 W채우는중
      w_done_q - W끝남 B대기
      ar_q - AR봤음 R채우는중
    핵심 트릭
      "[0] 참조 - pop 안 함"
      Handle 복사로 직접 채움
      WLAST/RLAST에서 발행
    이슈
      같은 사이클 AW+W 레이스
      RRESP 덮어쓰기
      ID 재정렬 미지원

시리즈: 아이템 · 인터페이스 · 드라이버 · 모니터

axi4_driver — 파이프라인 마스터 드라이버

전체 구조

              Sequencer
                  │ get_next_item()
                  ↓
         ┌── item_thread ──┐  ← item_done()을 "즉시" 호출
         │                 │     (파이프라인의 핵심!)
         ↓                 ↓
    [aw_q][w_q]         [ar_q]
       │    │              │
       ↓    ↓              ↓
   aw_thread w_thread   ar_thread    ← 각 채널 독립 드라이브
       │    │              │
       └────┴──── AXI 버스 ┴────┐
                  │             │
             b_thread      r_thread  ← 응답 수집 + 카운터 감소

왜 이 구조인가 — Blocking과 비교

❌ 전형적인 Blocking 드라이버

forever begin
    seq_item_port.get_next_item(req);
    drive_transaction(req);        // AW → W → B 전부 대기
    seq_item_port.item_done();     // 버스에서 끝난 후에야 호출
end

→ 버스가 놀아도 다음 트랜잭션이 안 들어옴
→ Outstanding 절대 발생 안 함
→ 슬레이브의 Outstanding 지원 로직이 검증 안 됨!

✅ 이 드라이버

task item_thread();
    forever begin
        seq_item_port.get_next_item(req);
        aw_q.push_back(req);
        w_q.push_back(req);
        n_inflight++;
        seq_item_port.item_done();     // ← 즉시 호출!
    end
endtask

→ 시퀀스가 버스보다 앞서 달림 → 버스에 여러 버스트 동시 존재 ✅

item_done()을 "언제" 부르느냐가 blocking과 pipelined를 가르는 유일한 차이

헤더 주석의 설계 의도

max_outstanding = 1  → blocking 드라이버와 동일
max_outstanding = >1 → pipelined
→ 같은 코드로 두 모드 커버, 회귀에서 둘 다 검증 가능

Outstanding 미지원 슬레이브:
  AWREADY를 낮게 유지 → aw_thread가 while에서 자동 블록
  → 드라이버 수정 없이 자동 적응 (graceful degradation)

멤버 변수

class axi4_driver extends uvm_driver #(axi4_seq_item);

uvm_driver #(T) 상속 시 자동 생성:
  T req;                              ← 요청 아이템 (built-in)
  uvm_seq_item_pull_port #(T) seq_item_port;  ← 시퀀서 연결

채널별 작업 큐

protected axi4_seq_item aw_q[$];   // AW 발행 대기
protected axi4_seq_item w_q[$];    // W beat 전송 대기
protected axi4_seq_item ar_q[$];   // AR 발행 대기

모니터 큐와 방향 정반대:
  모니터: 관찰한 것을 쌓아 완성되면 발행
  드라이버: 보낼 것을 쌓아 하나씩 꺼내 구동

같은 트랜잭션이 aw_q, w_q에 동시에 들어감 (Handle 2개, Object 1개)
→ aw_thread는 주소만, w_thread는 데이터만 읽어 충돌 없음

Inflight & 계측 카운터

protected int unsigned n_inflight;          // 시퀀서 기준 진행 중
int unsigned wr_outstanding, wr_peak;       // 버스 기준 진행 중
int unsigned rd_outstanding, rd_peak;

n_inflight     = "시퀀서에서 받은 것" (큐 포함)
wr_outstanding = "버스에서 진행 중" (AW 수락 ~ B 응답)

차이가 중요:
  큐에 10개 쌓여도 슬레이브가 AWREADY 안 올리면
  n_inflight=10, wr_outstanding=1

wr_peak >= 2 → "진짜 파이프라인 동작" 증거!
→ 검증 환경 자체를 검증하는 계측 (인터뷰 어필 포인트)

is_idle() — Drain 판정

function bit is_idle();
    return (aw_q.size() == 0) && (w_q.size() == 0) &&
           (ar_q.size() == 0) && (n_inflight == 0);
endfunction

문제: 파이프라인 드라이버는 마지막 item_done() 후에도
      버스에 버스트가 남아있음 → 그냥 끝내면 응답 유실!

해결 (테스트에서):
  seq.start(sequencer);
  wait (env.agent.driver.is_idle());   // 드레인 대기
  phase.drop_objection(this);

4개 조건 전부 체크:
  큐(3개) == 0     → 대기 중인 게 없음
  n_inflight == 0  → 버스에서 진행 중인 게 없음

run_phase() & reset_signals()

task run_phase(uvm_phase phase);
    reset_signals();
    @(negedge vif.rst);
    @(vif.master_cb);       // 한 클록 더 대기
    fork
        item_thread();  aw_thread();  w_thread();
        b_thread();     ar_thread();  r_thread();
    join
endtask

reset_signals() — 페이로드가 리셋 안 되는 이슈

리셋되는 것:  awvalid/wvalid/arvalid (VALID 계열),
              bready/rready (READY 계열),
              awlock/awcache/awprot 등 사이드밴드

리셋 안 되는 것: awid/awaddr/awlen/awsize/awburst,
                 wdata/wstrb, arid/araddr/... → 첫 트랜잭션 전까지 X!

AXI상 합법 (VALID=0일 때 페이로드 don't-care)
하지만 실무: 파형 X 가득 → 디버깅 어려움, X 전파 위험
→ "X-state propagation guard"와 같은 맥락
→ 개선: awaddr <= '0; wdata <= '0; 등 명시적 초기화

item_thread() — 파이프라인의 심장

task item_thread();
    forever begin
        seq_item_port.get_next_item(req);
        while (n_inflight >= cfg.max_outstanding) @(vif.master_cb);  // throttle
        if (req.dir == AXI_WRITE) begin
            aw_q.push_back(req);
            w_q.push_back(req);      // same order -> AXI write-data order
        end
        else ar_q.push_back(req);
        n_inflight++;
        seq_item_port.item_done();   // 즉시!
    end
endtask

while (n_inflight >= cfg.max_outstanding) @(vif.master_cb);  // throttle

진행 중인 트랜잭션(In-flight) 개수가 허용치(Max Outstanding)에 도달하면, 빈자리가 날 때까지 클락을 기다려라

@(vif.master_cb);의 실제 의미

@ : 기다려라 (Wait for event) vif : 저기 연결된 인터페이스를 타고 들어가서 .master_cb : 거기에 정의된 클락킹 블록을 참조해라.

// 하드웨어와 연결되는 실제 인터페이스 정의

interface axi_if(input logic clk, input logic rst_n);

    // Interface

    // 신호들 선언
    logic [31:0] awaddr;
    logic        awvalid;
    logic        awready;
    // ...

    // 클락킹 블록 선언: "나는 clk의 상승 엣지(posedge)를 기준으로 동작하겠다"
    clocking master_cb @(posedge clk);
        default input #1step output #1ns; // 셋업/홀드 타임 정의 (Race Condition 방지)
        output awaddr, awvalid;           // 내가(Master가) 쏠 신호들
        input  awready;                   // 내가(Master가) 읽을 신호들
    endclocking

위의 인터페이스 코드에서 master_cb 옆에 @(posedge clk)라고 기준을 명시해 두었죠? 따라서 @(vif.master_cb);는 컴파일러가 볼 때 사실상 @(posedge clk);과 똑같이 동작하게 됩니다. 즉, "이 클락킹 블록의 기준이 되는 클락 엣지(상승 엣지)가 한 번 칠 때까지 멈춰서 기다려라"라는 의미가 됩니다.

그렇다면 왜 굳이 복잡하게 master_cb를 쓸까? 그냥 직관적으로 @(posedge vif.clk); 라고 쓰면 편할 텐데, 굳이 클락킹 블록을 참조하는 이유는 Race Condition(경쟁 상태)이라는 치명적인 버그를 막기 위해서입니다.

Throttle — Outstanding depth 제한

max_outstanding=4:
  n_inflight 0→1→2→3→4 통과, 4에서 블록 (4>=4)
  B 응답 → n_inflight=3 → 통과

throttle이 get_next_item 뒤에 있는 이유:
  대기 중 item_done() 안 불림 → 시퀀스도 블록
  → 백프레셔가 시퀀스까지 자연스럽게 전달 ✅

aw_q와 w_q에 같은 순서로 push

AXI4에 WID 없음 → W beat는 AW와 같은 순서로 나가야 함
두 큐 같은 순서 채우고 둘 다 FIFO 소비 → 순서 보장 ✅

⚠️ 숨은 함정 — 시퀀스가 객체 재사용 시

// 위험한 시퀀스
axi4_seq_item tr = create("tr");   // 한 번만 생성!
repeat(10) begin
    start_item(tr);
    tr.randomize();      // 같은 객체 다시 랜덤화!
    finish_item(tr);
end

드라이버 큐:
  1회차: aw_q=[tr]      tr.addr=0x1000
  2회차: tr.randomize() → tr.addr=0x2000  ← 큐 안의 것도 바뀜!
         aw_q=[tr,tr]   둘 다 0x2000!

→ "Queue에 Object 넣고 원본 수정" 문제 그대로
→ Blocking이면 안 생김, 파이프라인에서만 터지는 버그!

해결:
  - 시퀀스에서 매번 create (권장)
  - 또는 드라이버에서 req.clone()으로 deep copy

aw_thread() / ar_thread() — 주소 채널

task aw_thread();
    axi4_seq_item tr;
    forever begin
        while (aw_q.size() == 0) @(vif.master_cb);   // 폴링 대기
        tr = aw_q.pop_front();

        vif.master_cb.awid    <= tr.id;
        vif.master_cb.awaddr  <= tr.addr;
        vif.master_cb.awlen   <= tr.len;
        vif.master_cb.awsize  <= tr.size;
        vif.master_cb.awburst <= tr.burst;
        vif.master_cb.awvalid <= 1'b1;              // ① VALID 올림
        @(vif.master_cb);                            // ② 한 클록
        while (!vif.master_cb.awready) @(...);        // ③ READY 대기 (VALID 유지)
        vif.master_cb.awvalid <= 1'b0;              // ④ 완료 후 내림
        wr_outstanding++;
        if (wr_outstanding > wr_peak) wr_peak = wr_outstanding;
    end
endtask

골든 룰 준수 확인

룰 1 (Deadlock 방지): ①에서 awready 확인 없이 바로 VALID 올림 ✅
룰 2 (VALID 유지):    ③의 while 동안 awvalid=1 유지 ✅
룰 4 (전송 조건):     ③의 awready 감지 = 핸드셰이크 성립 ✅

연속 AW 발행 시 거동

핸드셰이크 후:
  awvalid <= 0   (T=21ns 예약)
  loop → pop → awvalid <= 1  (T=21ns 예약, 같은 시각!)
  → NBA 규칙: 나중 할당 승리 → awvalid=1 유지
  → back-to-back AW (AXI상 정상) ✅

카운터 시점

wr_outstanding++ : AW 핸드셰이크 성립 후 (버스에 나갔을 때)
wr_outstanding-- : BVALID 수신 (b_thread)
n_inflight와 시점 다름 → 두 카운터 차이 = 큐 대기 개수

ar_thread는 aw_thread와 구조 완전 동일. 읽기는 데이터를 보낼 필요가 없어 (AR + R, 2채널) 쓰기(AW + W + B, 3채널)보다 단순.

w_thread() — 쓰기 데이터 채널

task w_thread();
    axi4_seq_item tr;
    forever begin
        while (w_q.size() == 0) @(vif.master_cb);
        tr = w_q.pop_front();
        foreach (tr.data[i]) begin
            vif.master_cb.wdata  <= tr.data[i];
            vif.master_cb.wstrb  <= tr.strb[i];
            vif.master_cb.wlast  <= (i == tr.len);   // 마지막 beat
            vif.master_cb.wvalid <= 1'b1;
            @(vif.master_cb);
            while (!vif.master_cb.wready) @(vif.master_cb);
            vif.master_cb.wvalid <= 1'b0;
            vif.master_cb.wlast  <= 1'b0;
        end
    end
endtask

WLAST 생성

vif.master_cb.wlast <= (i == tr.len);

len=3: i=0→0, i=1→0, i=2→0, i=3→1  (마지막만 1) ✅

wlast는 매 beat 후 0으로 내림 → 안 내리면 다음 버스트 첫 beat에
wlast=1 → 프로토콜 위반!

⚠️ 방어 부족: data.size()가 len+1이 아니면 WLAST 위치 틀림
   더 안전: (i == tr.data.size()-1)

⚠️ 큰 이슈 — W가 AW보다 먼저 나갈 수 있음

aw_thread와 w_thread가 완전 독립:

슬레이브가 AWREADY를 오래 낮게 유지 + WREADY는 높음
  → aw_thread: AW #1 대기 (블록)
  → w_thread:  W beats #1, #2 전부 전송!
  → AW #1도 안 나갔는데 W #2 데이터가 나감

AXI상 합법이지만 이 모니터와 충돌:
  mon_w: aw_q.size()==0 → "W beat with no AW - ignored" → beat 유실!

→ 개선: aw_thread에서 핸드셰이크 후 w_q에 push
        또는 모니터가 W-before-AW 버퍼링

b_thread() / r_thread() — 응답 채널

task b_thread();
    vif.master_cb.bready <= 1'b1;               // always ready
    forever begin
        @(vif.master_cb);
        if (vif.master_cb.bvalid) begin
            if (n_inflight > 0)     n_inflight--;
            if (wr_outstanding > 0) wr_outstanding--;
        end
    end
endtask

task r_thread();
    vif.master_cb.rready <= 1'b1;
    forever begin
        @(vif.master_cb);
        if (vif.master_cb.rvalid && vif.master_cb.rlast) begin  // RLAST!
            if (n_inflight > 0)     n_inflight--;
            if (rd_outstanding > 0) rd_outstanding--;
        end
    end
endtask

b_thread vs r_thread 차이

쓰기: B 응답은 버스트당 1개 → bvalid만 체크
읽기: R beat는 여러 개 → RLAST로 버스트 끝 판단!

len=3 읽기: rlast=0,0,0,1 → 마지막에만 카운터--

설계 특징 & 이슈

✅ always ready (bready/rready=1) → 응답 지연 안 시킴, 코드 단순
✅ > 0 가드 → int unsigned 언더플로 방지 (0에서 -- → 거대한 수)

⚠️ BRESP/RDATA 안 읽음 → item_done() 이미 호출해서 시퀀스에 못 돌려줌
   → 검증은 Monitor+Scoreboard 담당 (일관된 철학)
⚠️ backpressure 미검증 → READY 항상 1이라 마스터 지연 시나리오 없음
   → 개선: 랜덤 bready/rready 지연 주입

계측이 증명하는 것

function void report_phase(uvm_phase phase);
    `uvm_info("DRV", $sformatf(
        "peak writes = %0d, peak reads = %0d (max_outstanding = %0d)",
        wr_peak, rd_peak, cfg.max_outstanding), UVM_LOW)
endfunction

출력: peak writes = 4 → 파이프라인 동작 ✅
      peak writes = 1 → 파이프라인 안 됨 (backpressure or 트래픽 부족)

개선: max_outstanding>1인데 peak<=1이면 uvm_warning 자동 발생

inflight & max_outstanding — 용어 심화

두 개념 모두 "지금 처리 중인 트랜잭션"과 관련되지만 미묘하게 다르다.

inflight 뜻

in flight = "비행 중" = "출발했지만 아직 착륙(완료) 안 한"

트랜잭션이 "출발했지만 아직 응답을 못 받은 상태"

택배 비유:
  주문함 → [inflight: 배송 중!] → 도착 완료
  n_inflight = 지금 배송 트럭에 실려 오는 택배 개수

protected int unsigned n_inflight;
// ++  : item_thread에서 큐에 넣을 때 (출발!)
// --  : b_thread(BVALID) 또는 r_thread(RLAST)에서 (도착!)

시퀀서 → [큐] → AXI 버스 → 응답
         └──── 이 구간에 있는 것들이 inflight ────┘

n_inflight = 3 → "지금 3개 버스트가 처리 중 (응답 안 온 것 3개)"

max_outstanding 뜻

outstanding = "미결/미처리된" (금융의 "미상환 대출"과 같은 뉘앙스)
max_outstanding = "동시에 진행 중일 수 있는 최대 개수" (설정값)

while (n_inflight >= cfg.max_outstanding) @(vif.master_cb);
// cfg = agent config 객체, max_outstanding = 그 안의 설정값
// "inflight가 max에 도달하면 더 안 보내고 대기"

둘의 관계 — 주차장 비유

max_outstanding = 주차장 전체 자리 수 (예: 4칸, 고정)
n_inflight      = 지금 주차된 차 수 (0~4, 변동)

n_inflight ≤ max_outstanding  ← 항상 유지

4칸 다 차면 → 나가는 차(응답) 있을 때까지 새 차 대기

동작:
  n_inflight 0→1→2→3→4 통과, 4에서 블록 (4>=4)
  B 응답 도착 → n_inflight=3 → 다시 통과

왜 제한을 두나

max_outstanding = 1  → 한 번에 하나씩 = blocking 드라이버
max_outstanding = 4  → 최대 4개 동시 = pipelined

→ 같은 드라이버 코드로 설정값만 바꿔
  "직렬 모드"와 "파이프라인 모드"를 둘 다 테스트!

⚠️ n_inflight vs wr_outstanding — 시점이 다름

n_inflight     : 시퀀서에서 받는 순간 ++ (큐에 있을 때부터)
wr_outstanding : AW가 버스에서 수락된 순간 ++ (실제 버스에 나갔을 때)

큐에 5개 쌓였는데 슬레이브가 AWREADY를 안 올리면:
  n_inflight = 5      (받긴 다 받음)
  wr_outstanding = 1  (실제 버스엔 하나만)

→ 차이 = 큐에서 대기 중인 개수
→ wr_peak >= 2 가 "진짜 파이프라인 동작" 증거

드라이버 구조 다이어그램

스레드 구조 & 데이터 흐름

item_thread가 큐에 넣고 item_done()을 즉시 부르기 때문에, 시퀀스가 버스보다 앞서 달려서 여러 버스트가 동시에 진행된다.

카운터 흐름 (트랜잭션 생애)

n_inflight     : 큐에 있을 때부터 셈 (시퀀서 기준)
wr/rd_outstanding : 실제 버스에 나갔을 때부터 셈 (버스 기준)
차이 = 큐 대기 개수,  peak >= 2 = 파이프라인 증거

Throttle 메커니즘 (max_outstanding 제한)

aw_thread 핸드셰이크 상세 (골든 룰)

룰 1 (Deadlock 방지) : ①에서 awready 확인 없이 바로 VALID 올림
룰 2 (VALID 유지)    : ③의 while 동안 awvalid=1 유지
룰 4 (전송 조건)     : ③의 awready 감지 = 핸드셰이크 성립

Write 버스트 생명주기 시퀀스

전체 마인드맵

시리즈: 아이템 · 인터페이스 · 드라이버 · 모니터

axi4_if — 인터페이스

전체 구조

┌─────────────────────────────────────────────────────────┐
│                    interface axi4_if                     │
│                                                          │
│  파라미터: DATA_WIDTH, ADDR_WIDTH, STRB_WIDTH, ID_WIDTH │
│  포트:     clk, rst  (외부에서 주입)                     │
│                                                          │
│  ┌────────────────────────────────────────────────┐     │
│  │  raw 신호 5채널 (AW / W / B / AR / R)           │     │
│  └────────────────────────────────────────────────┘     │
│         ↑                          ↑                     │
│  ┌──────┴───────┐          ┌──────┴───────┐            │
│  │  master_cb   │          │  monitor_cb  │            │
│  │(드라이브+샘플)│          │  (샘플 전용) │            │
│  └──────┬───────┘          └──────┬───────┘            │
│         │                          │                     │
│   modport master            modport monitor             │
└─────────┼──────────────────────────┼────────────────────┘
          ↓                          ↓
    axi4_driver                axi4_monitor

핵심: 같은 신호를 두 개의 clocking block이 다른 방향/역할로 바라봄

파라미터

interface axi4_if #(
    parameter int DATA_WIDTH = 32,
    parameter int ADDR_WIDTH = 16,
    parameter int STRB_WIDTH = (DATA_WIDTH/8),
    parameter int ID_WIDTH   = 8
) (
    input logic clk,
    input logic rst
);

ADDR_WIDTH=16과 4KB 규칙

2^16 = 64KB, 4KB 페이지 = 16개
0x0000~0x0FFF, 0x1000~0x1FFF, ..., 0xF000~0xFFFF

→ seq_item의 c_4k constraint가 이 16개 경계를 지키게 함
→ 주소 공간이 작아서 경계 위반 시나리오가 자주 발생 (좋은 검증 환경)

STRB_WIDTH가 파생 파라미터인 이유

DATA_WIDTH만 바꾸면 STRB_WIDTH가 자동으로 따라옴
DATA_WIDTH=32 → STRB=4,  DATA=64 → STRB=8

→ 두 개를 따로 지정하다 실수로 안 맞추는 버그 방지
→ 다만 localparam으로 선언하면 오버라이드까지 막을 수 있어 더 안전

clk, rst가 포트인 이유

인터페이스는 클록을 생성하지 않음! TB Top에서 만들어 주입.
인터페이스 안에서 만들면 인스턴스마다 클록이 생겨 동기화 문제 발생.

rst 극성: monitor의 @(negedge vif.rst) → Active-HIGH 리셋

5채널 신호 — AXI 버전 정보가 드러나는 지점

AW 채널 폭에서 읽는 AXI4 시그니처

awlen [7:0]  ← 8비트
  AXI3: AWLEN[3:0]  (최대 16 beats)
  AXI4: AWLEN[7:0]  (최대 256 beats)  ✅

awlock [0:0] ← 1비트
  AXI3: AWLOCK[1:0]  (normal/exclusive/locked)
  AXI4: AWLOCK       (locked 삭제)  ✅

→ 이 인터페이스는 정확히 AXI4 스펙

W 채널 — WID가 없는 게 포인트!

AXI3: WID 존재 → 쓰기 데이터 인터리빙 가능
AXI4: WID 제거! → 인터리빙 금지, W beat는 AW와 같은 순서로 연속

→ 그래서 monitor의 mon_w()가 aw_q[0](가장 오래된 것) 하나만
  보고 데이터를 채워도 안전한 것!
→ 드라이버가 aw_q와 w_q에 같은 순서로 push하는 것도 이 때문

쓰기 vs 읽기 비대칭

        쓰기                       읽기
   ┌──────────┐              ┌──────────┐
   │ AW 채널  │              │ AR 채널  │
   └──────────┘              └──────────┘
   ┌──────────┐              ┌──────────────────┐
   │ W  채널  │              │ R 채널           │
   │ (데이터) │              │ (데이터 + rresp) │
   └──────────┘              └──────────────────┘
   ┌──────────┐                    ↑
   │ B  채널  │              별도 응답 채널 없음
   │ (응답)   │
   └──────────┘

쓰기: W(데이터) + B(응답) = 2채널
읽기: R(데이터+rresp)     = 1채널

→ rresp는 beat마다 존재 → monitor mon_r()의 덮어쓰기 이슈 원인

빠진 optional 신호

없는 것: awqos/arqos, awregion/arregion, awuser/aruser, wuser/buser/ruser
→ 스펙상 optional, 작은 환경에서는 생략 합리적
→ QoS 기반 아비터를 검증하려면 추가 필요

master_cb — 드라이버용 Clocking Block

clocking master_cb @(posedge clk);
    default input #1step output #1;
    // AW
    output awid, awaddr, awlen, awsize, awburst,
           awlock, awcache, awprot, awvalid;
    input  awready;
    // W
    output wdata, wstrb, wlast, wvalid;
    input  wready;
    // B
    input  bid, bresp, bvalid;
    output bready;
    // AR
    output arid, araddr, arlen, arsize, arburst,
           arlock, arcache, arprot, arvalid;
    input  arready;
    // R
    input  rid, rdata, rresp, rlast, rvalid;
    output rready;
endclocking

skew 해석

input #1step  → 엣지 직전 안정된 값 읽기 (Preponed 영역)
output #1     → 엣지 후 1ns에 드라이브

        T=10ns (posedge)
             │
    ─────────┼──────┬──────
       ↑     │      │
    #1step   │    output #1
    (읽기)   │    (쓰기 T=11ns)

⚠️ output #1은 절대 시간(1ns). 클록 주기 10ns면 10%로 안전하지만, 2ns 클록이면 50%, 1ns 클록이면 충돌. 고속 클록에서는 재조정 필요.

방향 설계 — AXI 마스터 역할

패턴:
  데이터 나가는 채널(AW,W,AR) → 마스터가 VALID 드라이브
  데이터 들어오는 채널(B,R)   → 마스터가 READY 드라이브

→ VALID는 보내는 쪽, READY는 받는 쪽이 올림 (골든 룰 구조)

컴파일 타임 안전장치

vif.master_cb.awready <= 1'b1;   // ❌ 컴파일 에러!
// awready는 input으로 선언됨 → 드라이브 불가

monitor_cb — 모니터용 Clocking Block

clocking monitor_cb @(posedge clk);
    default input #1step;
    input awid, awaddr, ..., awvalid, awready;
    input wdata, wstrb, wlast, wvalid, wready;
    input bid, bresp, bvalid, bready;
    input arid, araddr, ..., arvalid, arready;
    input rid, rdata, rresp, rlast, rvalid, rready;
endclocking

master_cb와의 차이 3가지

차이 1 — output이 하나도 없음
  default input #1step;  ← output skew조차 없음
  → 물리적으로 어떤 신호도 드라이브 불가 → 진짜 passive 보장 ✅
  vif.monitor_cb.awvalid <= 1;  // ❌ 컴파일 에러

차이 2 — VALID와 READY를 둘 다 봄
  input awvalid, awready;  ← 둘 다!
  → 그래서 if(awvalid && awready)로 핸드셰이크 감지 가능
  → 모니터가 트랜잭션을 감지하는 원리의 근거

차이 3 — 마스터/슬레이브 구분 없음
  모든 신호를 평등하게 input → 어디에 붙여도 동작 → 재사용성 ✅

두 CB가 같은 신호를 써도 괜찮은 이유

awvalid: master_cb=output(드라이브), monitor_cb=input(샘플)
→ 드라이버 1개, 샘플러 1개 → 충돌 없음 ✅
(monitor_cb에 output이 없어서 multiple driver 문제 없음)

Modport

modport master  (clocking master_cb,  input clk, rst);
modport monitor (clocking monitor_cb, input clk, rst);

각 modport가 노출하는 것:
  ✅ 해당 clocking block
  ✅ clk, rst (읽기 전용)
  ❌ raw 신호 직접 접근 불가!

목적: raw 신호로 clocking block을 우회하는 실수를 컴파일 타임에 차단
  vif.awvalid <= 1;             // ❌ (스큐 우회 = race 위험)
  vif.master_cb.awvalid <= 1;   // ✅ 이것만 허용

⚠️ 현재 UVM 클래스는 virtual axi4_if vif;로 modport 없는 순수 타입을 씀. virtual axi4_if.monitor vif;처럼 modport를 명시하면 안전성이 올라감.

slave modport가 없는 이유: DUT가 plain Verilog라 개별 신호로 직접 연결. UVM Slave Agent를 만들려면 modport slave 추가 필요.