UVM 이란 무엇인가?

 

 

 

UVM 이란 무엇인가? 

UVM이란 Universal Verification Methodology의 약자로, 검증을 위한 프레임워크이다.

검증을 위한 언어라고 많이들 착각하고 있으나, 검증 관련 언어는 systemverilog이다.

UVM은 systemverilog로 작성된 클래스들의 패키지이다.

(프레임워크란 어떠한 목적을 달성하기 위해 복잡하게 얽혀있는 문제를 해결하기 위한 구조이다. 소프트웨어 개발에 있어 하나의 뼈대 역할을 한다.)

 

UVM의 전신은 OVM(Open Verification Methodology)이라고 한다.

과거에는 EDA vendor사(시놉시스, 케이던스, 멘토)들이 독립적으로 검증 방법론을 개발해 왔던 것과 달리,

UVM은 Accellera standard로서, 여러 벤더사들이 공동 지원하고 있다.

 

(cf Accellera는 Accelleray Systems Initiative로 EDA(Electronic Design Automation)과 IC(Integrated Circuit) 디자인에 관한 표준 기관이다. 여러 벤더들 간의 개발 표준을 제정한다. IEEE보단 제약이 적다.)

 

 

 

 

 

제가 처음 검증팀에 입사를 했을 때 누군가가 UVM을 공부해보라고 했었던 게 UVM과의 첫 인연이었습니다.

당시에는 제 손으로 Testbench를 짜 본적도 없어서 UVM을 왜 공부해야 하는지도 모르겠어 너무나도 답답했었습니다.

한차례 이직을 하고 직접 testbench를 작성해 검증을 해보니, UVM이란 정말 강력한 검증 프레임워크라는 것을 비로소 깨달았습니다.

검증 테스트벤치의 통일성, 확장성을 최대화하여 테스트벤치의 퀄리티를 향상시킵니다.

UVM의 어떤 특징과 기능들이 이런 장점을 극대화시키는지... 저와 함께 살펴보시죠 ㅎㅎ

지금으로서 생각나는 것은, UVM factory와 UVM macro들입니다.

이 또한 이해하기까지 꽤 오랜 시간이 걸렸습니다.

불과 2019~2020년도까지만 해도 한국어로 작성된 페이지가 없어 영어로만 공부했어야 했거든요.

그리고 반도체 산업 현업에서 사용되다 보니까, 다양한 예제가 없는 것도 큰 고난이었어요.

요즘에는 구글에서 찾을 수 있는 한국어 문서와 예제가 다양해서 예전보다 훨씬 공부하기 쉬워진 것 같습니다.

 

 

 

UVM의 정신

UVM의 정신은 다음으로 정리 가능하다

1. SystemVerilog OOP의 개념을 활용하다( 그것도 아주 잘 똑똑하게! )

2. 오브젝트들이 시뮬레이션 런타임동안에 동적으로 생성되었다가 사라진다.

    --> 따라서 recompile 할 필요 없이 테스트와 테스트벤치 아키텍처를 지정할 수 있다. 

3. Agent, Driver, Monitor, Bus Functional Model들과 같은 계층적 테스트벤치 컴포넌트들을 사용한다. 

    --> 지금 못 알아들어도 쫄지 마시라! 테스트벤치 구조를 구성하는 성분(컴포넌트라고 부른다)이며, 지금은 이런 게 있다~라고 알고만 넘어가자.  

4. Transaction-Level Communication을 한다.

    --> Transaction이란 데이터와 데이터의 메타정보를 담은 클래스 정도로 이해하자.

    --> UVM 오브젝트들은 이 트랜잭션을 주고받으면서 서로 통신을 한다.

5. Testbench Stimulus (UVM sequences)는 테스트벤치 구조와 분리된 개념이다.

  --> 영어 공부를 열심히 하자. 따라서 웬만하면 영어로 바로 이해할 수 있도록... 

  --> 이상하게 전공 관련 내용들은 한국어로 정말 번역했을 때 의미가 이상해진다.

  --> Stimulus를 직역하면 자극제인데.. 자극제라고 번역하자니 본래 의미가 왜곡되어 버린다.

  --> stimulus란, DUT(검증하려는 대상 하드웨어디자인)에 가해지는 입력 인풋(과 인풋을 인가하는 규칙) 정도로 생각하자. 

 

위 다섯 가지 중에서 내가 중요하게 생각하는 것은, 

1과 2와 5이다.

1은 그냥 중요하고

2는 UVM Factory라는 새로운 개념을 접할 것이며

3은 당신으로 하여금 UVM이 아주 영리한 프레임워크라고 느끼게 할 것이다. 

 

 

UVM의 필요성

UVM 없이 systemverilog만으로 검증 업무를 해온 분들에게 UVM이란 큰 도전과제이다. 

어쩌면 도전과제가 아니라 귀찮은 일 중 하나라고 여겨지는 경우도 종종 보았다.

systemverilog만으로 작성된 전통 테스트벤치도 잘 동작을 하는데 UVM으로 굳이 옮겨갈 이유가 없다고들 말한다.

 

UVM은 왜 필요할까?

그리고 왜 많은 회사들에서 UVM을 사용할까?

 

나의 경우에는 .. UVM 공부하면 해외 취업 잘된다고 (^^) 얼핏 들었어서 겁나 열심히 공부했다. 하하

근데 지금 생각해 보면 검증인이라면 누구나 다 쓸 줄 알아야하는 펀더멘탈 같은 느낌이더라. ㅎㅎ

마치 파이썬 할 줄 안다고 IT회사 그냥 취직할 수 있는 거 아닌 것처럼.. ㅎㅎ

 

 

UVM의 주된 장점은, UVM이라는 방법론이 verilog testbench를 작성할 때 꽤나 구체적인 가이드라인을 제시해 준다는 것이다.

 

 

서로 다른 Verification Team 간의 테스트벤치 통일성을 높이고,

IP와 standalone environment integration 간의 상호 호환성을 높인다.

즉, 테스트벤치가 유연해지고 유지보수가 용이해진다. 

 

 

 

더 쉽게 풀자면..

엔지니어 a와 엔지니어 b가 시스템베릴로그만으로 자유롭게 작성한 테스트벤치 사이의 공통분모보다,

엔지니어 c와 엔지니어 d가 UVM으로 자유롭게 작성한 테스트벤치 사이 공통분모가 더 크다는 것이다.

 

 

c와 d는 서로의 테스트벤치를 이해하기 쉽다.

UVM가이드라인에 따라서 작성했으므로, 구조적으로 통일감을 갖는다.

 

 

 

a와 b는 서로의 테스트벤치를 이해하기 어렵다.

아니 이해하고 싶지 않다.

남의 코드를 맨땅에 헤딩해 가며 읽는다는 건... 회사 짬밥 좀 먹으면 이제 지긋지긋한 일이다.. 

 

 

이러한 공통적인 지식체계가 엔지니어들 사이에서만 문제가 될까?

UVM은 Accellera 표준이다.

모든 벤더사에서 지원한다.

여러 회사에서 사용한다.

국제적으로 통용된다.

왜 해외 취직할 때 도움이 된다고 하셨는지 약간 이해가 될 것 같기도..? ㅋㅋ

 

 

UVM은 어떻게 유용할까?

UVM은 테스트벤치 작성에 유용한 여러 편의 기능들을 미리 코딩해 놓은 꾸러미와 같다.

 

1. 테스트벤치 구성에 필요한 컴포넌트들의 베이스클래스 ( 이를 derive 하여 사용한다.)가 미리 작성되어 제공된다.

모든 verification testbench는 driver, monitor, stimulus generator, scoreboard와 같은 주요 컴포넌트들을 포함한다.

이 컴포넌트들에 대한 base class를 제공하며, instantiation, connect, build와 같은 여러 function들을 표준화하여 제공한다.

 

 

cf) 컴포넌트와 시퀀스

테스트벤치 컴포넌트는, 도시(테스트벤치) 구성하는 빌딩(컴포넌트)들과 같다. 늘 그 자리에 있는다. 시뮬레이션 동안 도시 속 빌딩들처럼 그저 존재해 있다. 

빌딩 안과 빌딩 사이를 지나다니는 사람들과 차량이 있다. 이는 테스트벤치에서 사용되는 데이터들이다.

테스트벤치는 인풋 스티뮬리를 생성해 내고(내가 테스트하고자 하는 특성에 맞게), 가공하고, DUT에 인가한다. 그리고 DUT로 받은 아웃풋 시그널들을 캡처하고, 가공해서 해석한다. 

이런 데이터의 흐름들이 시퀀스(sequence)와 시퀀스 아이템(sequence item)이다.  

이들은 시뮬레이션 시간 동안에 생겨났다가 사라지기도 하는 동적인 개체(dynamic entity)이다.  

 

 

2. 여러 편리한 매크로, 메커니즘들을 제공한다.

예를 들어 메시지 디스플레이와 verbosity 컨트롤( verbosity란.. 로그를 찍을 때 hierarchy를 부여하는 것을 말한다. verbosity를 높이면 로그를 마구마구 찍고, verbosity를 낮추면 진짜 필요한 로그만 찍도록 컨트롤할 수 있다.), 을 구현하는 방법은 검증 엔지니어들 사이에서 참으로 다양할 수 있다.  

하지만 UVM은 표준화된 reporting mechanism을 제공하여 검증 엔지니어들이 이런 건 구현할 필요 없이, 진짜 중요한 일들에만 집중할 수 있도록 해준다. 

 

또 다른 예로 sequencer driver handshaking도 있다.

UVM에서는 시퀀서와 드라이버간의 handshaking을 내부적으로 구현하여, 사용자는 갖다 쓰기만 하면 된다.

따라서 엔지니어는 DUT에 인가할 stimulus만 작성하면 된다. 

 

 

 

UVM은 systemverilog 클래스들을 엮어놓은 패키지라고 했다.

실제로 사용할 때도 import uvm_pkg::*처럼 패키지를 임포트 하여 사용한다.

 

그럼 UVM 클래스들은 어떤 구조를 가졌을까? 

 

 

 

 

UVM Class의 계층적 구조

 

 

UVM은 uvm 오브젝트들에 대한 base class를 제공하므로, 우리는 이 베이스 클래스를 상속하여 입맛에 맞게 기능을 추가할 수 있다.

 

따라서 이 베이스 클래스들은 테스트벤치 작성을 위한 툴키트들. 빌딩 블록. 

모든 오브젝트들에 공동적으로 지원해야 할 기능들이 포함되어 있다.

 

예를 들어 uvm_driver라는 클래스를 상속해서 AXI bus protocol을 위한 새로운 driver class를 만들 수도 있다.

uvm_driver 클래스는 드라이버 컴포넌트 구현을 위한 완전 기본 중에 기본만 담은 클래스일 것이다.

 

사용자가 이를 상속하여 AXI bus protocol 드라이버를 만들면, 이 드라이버는 axi protocol에 맞게 signal driving을 할 줄 아는 driver가 되는 것이다. 

 

AXI protocol을 위한 stimulus는 uvm_sequence_item을 extend 하여 만들 수 있다.   

이 시퀀스가 어떻게 생성되며, 드라이버에게는 어떻게 전달되는지 등에 관한 내부 동작은 UVM framework 내부에 이미 구현되어 있는 기능이므로, 우리는 크게 상관할 바가 아니게 된다.

 

UVM object는 print, copy, compare 등기초초적인 기능이 구현된 UVM main class이다.  

메인 클래스라고요! 아시겠어요?

모든 uvm 객체들은 uvm object의 자녀 손자예요.

 

print, copy, compare는 말 그대로 object의 내용을 프린트하거나, object 간의 copy 혹은 compare를 수행해요. 

 

 

UVM object의 계층 트리는 크게 두 갈래로 나뉜다.

하나는 uvm_component이고, 하나는 uvm_transaction이다.

 

uvm_component는 driver, monitor, agents들과 같은 테스트벤치 컴포넌트들을 정의하며,

uvm_transaction는 테스트벤치 컴포넌트들에 의해 동작하고 소비되는 data 오브젝트들을 정의한다.   

 

 

각각의 오브젝트들은 UVM testbench component를 소개할 때 설명하기로 한다.