스킬캠퍼스

오늘 끝나면

검증과 성능 측정

  • 검증과 성능 측정의 핵심 문제를 한 문장으로 설명한다
  • 오른쪽 실습에서 검증과이 어떻게 움직이는지 관찰한다
  • 다음 강의와 이어지는 한계를 말할 수 있다

실습 미션

reference model·test vector·성능 카운터로 비교 이 문장이 실제로 무슨 뜻인지 실습에서 한 번 손으로 확인한다.

성공 조건

  • 실습의 기본값을 먼저 관찰
  • 입력값이나 모드를 한 번 이상 바꿔 결과 비교
  • 왜 결과가 바뀌었는지 한 문장으로 설명

반도체 설계 · 23

검증과
성능 측정

설계가 맞는지는 믿음으로 정하지 않는다.
정답 CPU(reference)와 결과를 한 줄씩 맞대 본다.
맞으면 cycle·stall·miss를 세어 얼마나 빠른지까지 잰다.

P.01반도체 설계 · 23

맞는지 어떻게 아나, reference model

혼자 돌려보고 결과가 나왔다고 옳다는 증명이 되지는 않는다. 기준이 필요하다.

같은 프로그램을 확실히 맞는 reference model(정답 CPU)에도 돌린다. reference는 빠를 필요 없이 맞기만 하면 된다. 보통 단순한 명령어 해석기(소프트웨어 모델)로 만든다.

그다음 두 결과를 맞댄다. 같은 입력에 두 CPU의 레지스터와 메모리가 끝까지 같으면 통과(pass)다. 한 군데라도 어긋나면 그 순간이 버그다.
내 결과 == 정답 결과, 이게 검증의 뼈대다.

정답 CPU와 내 CPU를 나란히
같은 프로그램 · 두 CPU 결과 비교
레지스터
reference (정답)
내 CPU
R1
0007
0007=
R2
000C
000C=
R3
0013
0011≠ 버그
PC
0008
0008=
한 칸이라도 ≠ 면 그게 버그다. reference는 빠를 필요 없이 맞기만 하면 된다
P.02반도체 설계 · 23

무엇으로 두드리나, test vector

두 CPU를 맞대려면 먼저 입력을 줘야 한다. 그 입력 묶음을 test vector라 한다.

손으로 고른 케이스부터 넣는다. 0, 1, 최댓값, 음수, 캐리 나는 덧셈, 0으로 나누기 같은 경계다. 버그는 평범한 값보다 가장자리에 잘 숨기 때문에 극단값을 일부러 골라 넣는다.

손 케이스만으론 빈틈이 남아 랜덤 테스트를 얹는다.seed 하나로 난수를 뽑아 명령과 값을 섞어 수천 번 두드린다. seed를 적어두면 같은 랜덤 묶음을 그대로 재현해 디버깅할 수 있다.
경계를 잡는 손 케이스와 넓이를 채우는 랜덤, 둘을 합쳐야 커버리지가 채워진다.

정해진 케이스 + 랜덤 케이스
손 케이스(경계) + 랜덤(넓이)
손으로 고른 경계 케이스
0, 00 경계
65535 + 1캐리·오버플로
−1 (음수)부호 처리
x / 00으로 나누기
랜덤, seed로 재현 가능
seed 42
19
7
250
0
88
134

같은 seed면 같은 입력 묶음이다. 버그를 잡았을 때 그 seed만 적어두면 그대로 재현된다.

P.03반도체 설계 · 23

맞으면 끝?, 성능 카운터

결과가 맞는다고 다 끝난 게 아니다. 같은 일을 몇 박자 만에 해냈는지가 성능이다.

칩 안에 성능 카운터를 박아 사건을 센다.
cycle은 클럭이 몇 번 똑딱였는지, 곧 총 걸린 시간이다.
stall은 해저드로 파이프라인이 멈춰 버블을 넣은 횟수다(22강).
miss는 캐시에서 못 찾아 메모리까지 다녀온 횟수다(24강에서 다룬다).

핵심 지표는 IPC = instructions / cycles, 또는 그 역수인 CPI다.
명령 수가 같아도 stall과 miss가 많으면 cycle이 늘어 느려진다.
맞는지는 reference로 보고 빠른지는 카운터로 본다. 둘은 다른 질문이다.

cycle · stall · miss를 세다
성능 카운터로 사건을 센다
cycle1,420총 클럭 박자 = 걸린 시간
instr1,000실행한 명령 수
stall318해저드로 멈춘 버블
miss102캐시에서 못 찾음

IPC = 1000 / 1420 = 0.70 · CPI = 1.42

stall과 miss가 줄면 cycle이 줄어 IPC가 1에 가까워진다

P.04반도체 설계 · 23

직접 두드린다, 테스트벤치

테스트벤치는 같은 프로그램을 정답 CPU와 내 CPU에 동시에 태워 한 cycle씩 맞댄다.

fault를 끼우면 이 프로그램이 깨질지 먼저 예측하고, STEP으로 한 박자씩 돌리며 두 레지스터 파일이 갈라지는 첫 cycle을 찾는다. 그 지점이 오류 지점이다.

test vector를 바꾸거나 seed로 랜덤 프로그램을 새로 뽑아 다시 두드릴 수 있다. 어떤 fault는 이 프로그램으론 안 걸리기도 한다. 그래서 한 케이스 통과가 정답을 뜻하진 않는다. 이 테스트벤치 한 세트가 최종 MyChip의 검증 스위트로 들어간다.

test vector · seed · fault 삽입 → pass/fail
테스트벤치 · reference vs 내 CPU
test vector, 무엇으로 두드릴까
fault 삽입, 내 CPU에 결함 끼우기

내 CPU가 명세대로 동작, 모두 통과해야 정상

프로그램, 실행 중인 줄만 진하게
0MOVI R1, 3← 다음
1MOVI R2, 4
2ADD R3, R1, R2
3SHL R4, R3
4SUB R5, R4, R1
예측 먼저, 이 fault로 이 프로그램은?
근거 패널, 레지스터 파일 비교 (갈린 칸만 빨강)
reg
reference
내 CPU
=
R0
0000
0000
=
R1
0000
0000
=
R2
0000
0000
=
R3
0000
0000
=
R4
0000
0000
=
R5
0000
0000
=
R6
0000
0000
=
R7
0000
0000
=
성능 카운터 (reference 기준)
cycle
0
instr
0
stall
0
miss
0

IPC = instr / (cycle+stall) =

맞는가는 위 비교표(reference)로, 빠른가는 이 카운터로, 다른 질문이다. 이 한 세트가 최종 MyChip 검증 스위트로 들어간다.

P.05반도체 설계 · 23

통과해도 못 잡는 것, 커버리지

테스트가 다 통과해도 ‘버그 없음’은 아니다. 안 두드려 본 경로엔 버그가 그냥 남아 있다.

그래서 커버리지를 같이 본다. 명령어를 다 써봤는지, 분기의 양쪽(taken·not taken)을 다 밟았는지, 캐시 hit과 miss를 둘 다 일으켰는지 확인한다.
안 밟은 줄이 많으면 통과 숫자가 높아도 믿을 게 못 된다.

그래서 순서가 정해진다. reference로 맞는지를 먼저 보고, 그다음 카운터로 빠른지를 보고, 마지막에 커버리지로 충분히 두드렸는지를 본다.
이 세 질문을 다 통과한 설계만 테이프아웃으로 넘어간다.

Q. 내가 만든 CPU가 맞는지 어떻게 아나?정답은 확실히 맞는 reference(정답) 모델에 같은 프로그램을 돌려 결과를 한 줄씩 비교하는 것이다.
같은 test vector를 넣었을 때 두 CPU의 레지스터와 메모리가 끝까지 같으면 통과, 어긋나는 첫 지점이 버그다.
reference는 빠를 필요 없이 맞기만 하면 된다. 속도(cycle·stall·miss)는 그다음 카운터로 따로 잰다.
안 두드린 칸엔 버그가 숨는다
커버리지, 안 두드린 칸엔 버그가 숨는다
ADD
SUB
AND
OR
XOR
SHL
SHR
MOV
LD
ST
CMP
JMP
JZ
JNZ
CALL
RET
16개 중 9개 명령 실행7칸은 한 번도 안 두드렸다
통과 숫자가 높아도 흐린 칸엔 버그가 그대로 남는다. 두드려야 검증된다

3줄 요약

  1. 1reference model·test vector·성능 카운터로 비교
  2. 2검증과 성능 측정은 비트·게이트 → ALU → 시간·메모리 → 나만의 CPU → 메모리·GPU·SoC 흐름 안의 한 칸이다.
  3. 3개념을 외우는 것보다 입력을 바꾸면 무엇이 달라지는지 보는 것이 우선이다.

완료 전 점검

복습 카드

검증과

reference model·test vector·성능 카운터로 비교

ALU

산술·논리 연산을 하는 회로

ISA

CPU가 이해하는 명령어 집합과 인코딩