요즘 주변의 반도체 취업 준비생과 주니어 엔지니어에게 반복해서 듣는 고민이 있습니다. “디지털 검증 직무를 준비하려면 UVM부터 공부해야 하나요?” 특정 개인의 이야기가 아니라, 실명·학교·회사 정보를 모두 걷어내고 공통된 고민만 일반화해 답합니다.
한 줄 답: UVM부터 시작하지 마세요. RTL 이해 → self-checking testbench → AXI 같은 프로토콜 → assertion·coverage → UVM 순서가 훨씬 빠릅니다.
UVM은 중요합니다. 하지만 UVM은 검증의 기초라기보다, 이미 이해한 검증 요소를 재사용 가능한 구조로 조직하는 프레임워크에 가깝습니다. DUT가 어떤 사이클에 어떤 값을 내야 하는지 설명하지 못한 채 factory와 sequence 문법부터 외우면, 구조는 그럴듯하지만 버그를 찾지 못하는 테스트벤치가 되기 쉽습니다.
검증 조직이 실제로 어떤 일을 하는지 먼저 보고 싶다면 Design Verification 팀 가이드를 함께 읽어보세요. 이 글은 그다음 단계인 “무엇을 어떤 순서로 준비할 것인가”에 집중합니다.
왜 UVM보다 RTL이 먼저인가
검증 엔지니어는 설계 코드를 대신 작성하는 사람이 아닙니다. 하지만 버그가 생길 수 있는 상태 공간을 상상하려면 RTL의 시간축을 읽을 수 있어야 합니다.
- 조합 논리와 순차 논리는 어디에서 갈리는가
- reset 직후 모든 상태가 정의되는가
valid가 올라간 뒤ready가 늦어지면 데이터는 유지되는가- 파라미터나 데이터 폭이 바뀌었을 때 비교식이 깨지지 않는가
- 동시에 들어온 요청의 우선순위와 starvation 조건은 무엇인가
이 질문에 답할 수 있어야 stimulus와 checker를 설계할 수 있습니다. UVM class를 많이 아는 것과 검증할 대상을 이해하는 것은 다른 능력입니다.
현직자가 권하는 6주 학습 순서
1주차: 작은 RTL 블록을 직접 설계한다
카운터보다 한 단계 복잡한 블록을 고르세요. FIFO, round-robin arbiter, register file, 간단한 interrupt controller 정도가 좋습니다. 코드를 쓰기 전에 요구사항 표와 타이밍 다이어그램을 먼저 만드세요.
포트폴리오의 출발점은 “동작하는 RTL”이 아니라 “무엇이 맞는 동작인지 설명할 수 있는 명세”입니다.
2주차: 파형 확인을 self-checking test로 바꾼다
파형을 눈으로 보고 맞다고 판단하는 테스트는 반복 실행과 회귀 검증이 어렵습니다. 최소한 다음 요소를 분리하세요.
- 입력을 만드는 stimulus
- DUT 핀을 구동하는 driver
- 출력을 수집하는 monitor
- 기대값을 만드는 reference model
- 실제값과 기대값을 비교하는 scoreboard
시뮬레이션 마지막에는 사람이 파형을 열지 않아도 pass/fail과 실패 원인이 나와야 합니다.
3주차: AXI4-Lite 한 조각을 제대로 이해한다
처음부터 AXI4 전체를 외우지 마세요. AXI4-Lite slave 하나를 설계하고 검증하면서 독립 채널과 backpressure부터 이해하는 편이 낫습니다.
VALID는 상대의READY를 기다렸다가 올리는 신호가 아닙니다.- 주소와 데이터 채널이 항상 같은 순서로 도착한다고 가정하면 안 됩니다.
- 응답이 지연될 때 다음 요청을 받을 수 있는지 명세가 분명해야 합니다.
- reset, 연속 전송, backpressure, 잘못된 주소를 따로 시험해야 합니다.
AMD는 Vivado에 SystemVerilog 기반 AXI Verification IP를 추가 비용 없이 포함한다고 설명합니다. 예제 테스트벤치와 protocol checker를 이용하면 직접 만든 테스트가 놓친 규칙을 확인하기 좋습니다.
4주차: assertion과 functional coverage를 붙인다
좋은 assertion은 구현 코드를 다시 쓰지 않습니다. 인터페이스가 지켜야 할 계약을 표현합니다. 예를 들어 valid && !ready 동안 payload가 안정적이어야 한다는 규칙, FIFO가 full일 때 write pointer가 움직이지 않아야 한다는 규칙이 여기에 해당합니다.
coverage도 숫자부터 보지 마세요. 먼저 검증 계획을 만드세요.
| 기능 | 정상 조건 | 경계·오류 조건 | 확인 방법 |
|---|---|---|---|
| AXI write | 단일·연속 쓰기 | backpressure, invalid address | scoreboard + assertion |
| AXI read | 단일·연속 읽기 | 응답 지연, unmapped address | reference model |
| reset | idle 중 reset | transaction 중 reset | directed test + assertion |
5주차: SystemVerilog class로 리팩터링한다
이제 transaction, generator, driver, monitor, scoreboard를 class로 분리하세요. interface와 virtual interface, mailbox가 왜 필요한지 “이미 겪은 문제”와 연결해 이해할 수 있습니다.
6주차: 마지막에 UVM으로 옮긴다
앞서 만든 요소를 UVM 구조로 매핑합니다.
- transaction →
uvm_sequence_item - generator → sequence / sequencer
- driver →
uvm_driver - monitor →
uvm_monitor - scoreboard →
uvm_scoreboard - 연결과 설정 → agent / env / config DB
이 순서로 가면 phase와 factory가 암기 항목이 아니라 재사용과 configuration 문제에 대한 답으로 보입니다.
취업 포트폴리오에서 면접관이 보고 싶은 것
저장소 첫 화면에서 다음 다섯 가지가 보여야 합니다.
- 블록 명세와 타이밍 다이어그램
- 요구사항과 테스트를 연결한 검증 계획
- 한 명령으로 실행되는 regression과 pass/fail 로그
- assertion과 functional coverage 결과
- 실제로 발견한 버그의 재현·원인·수정·재발 방지 기록
면접에서 강한 문장은 “UVM을 공부했습니다”가 아닙니다. “주소와 데이터 채널의 순서를 고정해 가정한 버그를 random delay와 assertion으로 찾았고 regression에 재발 방지 테스트를 추가했습니다”에 가깝습니다.
자주 묻는 질문
Q. 학부생도 UVM을 해야 하나요?
하면 좋지만 완성도 낮은 UVM 프로젝트 하나보다, 작은 RTL을 명세부터 coverage까지 끝낸 프로젝트가 더 강합니다. UVM은 마지막 리팩터링 단계로 넣으세요.
Q. C++이나 Python을 먼저 공부해야 하나요?
언어 자체보다 DUT와 protocol 이해가 먼저입니다. Python·cocotb는 빠른 실험과 reference model에 유용하고, C++은 DPI나 성능 모델링에서 강합니다. 하지만 RTL의 cycle-level 동작을 모르면 어느 언어를 써도 checker 품질이 올라가지 않습니다.
Q. 코드 커버리지 100%면 검증이 끝난 건가요?
아닙니다. 코드 커버리지는 실행된 구조를 보여줄 뿐 요구사항이 맞는지 보장하지 않습니다. functional coverage, assertion, scoreboard 결과와 함께 봐야 합니다.
Q. 프로젝트는 몇 개가 적당한가요?
얕은 프로젝트 여러 개보다 하나를 명세·검증 계획·자동화·버그 기록까지 닫는 편이 낫습니다. 시간이 남으면 같은 구조를 다른 protocol이나 UVM으로 확장하세요.
마무리
UVM은 목적지가 맞습니다. 다만 출발점은 아닙니다. RTL의 시간축을 읽고, protocol 계약을 이해하고, 기대값을 자동 비교하는 습관이 먼저입니다. 그 위에 UVM을 올려야 프레임워크가 실력을 가리지 않고 실력을 확장합니다.
공개 출처
- Accellera UVM Community
- Accellera UVM standard downloads
- AMD AXI Verification IP
- AMD Vivado Verification
편집 원칙: 이 글은 주변에서 반복해서 들은 익명 고민을 일반화해 작성했습니다. 개별 인물·학교·회사·사례를 특정할 수 있는 정보는 사용하지 않았습니다.
