이 게시물은 Verilog/SystemVerilog에 기본 지식을 가진 엔지니어를 대상으로 UVM(Universal Verification Methodology)을 쉽게 이해할 수 있도록 작성되었습니다. 아래에서 UVM의 정의, 필요성, 작동 방식, 클래스 계층 및 주요 카테고리에 대해 자세히 알아보세요.
What is UVM ?
SystemVerilog는 Verilog와 유사한 언어로 자체 구문과 기능을 갖추고 있습니다. 그러나 UVM은 완전한 기능의 테스트벤치를 구축할 수 있도록 하는 SystemVerilog 클래스 기반의 프레임워크입니다. UVM을 배우기 위한 유일한 전제 조건은 SystemVerilog이며, 이는 UVM의 기반이 됩니다.
SystemVerilog 개념을 다시 확인하려면 클릭하세요!(추가예정)
Why do we need UVM ?
UVM의 주요 장점은 테스트벤치 제작을 위한 가이드라인을 제공한다는 점입니다. 이를 통해 다양한 검증 팀 간 테스트벤치의 일관성, IP와 독립 환경 간의 상호 운용성, 그리고 테스트벤치 유지보수의 용이성이 보장됩니다.
예를 들어, 디스플레이 메시지 출력이나 경고, 오류, 디버그와 같은 설정을 다양한 방식으로 구현할 수 있지만, UVM에서는 표준화된 보고 메커니즘을 제공하여 엔지니어가 디자인 검증에 집중할 수 있도록 합니다. 또한, sequencer-driver 핸드셰이크 메커니즘이 내부적으로 처리되어 stimulus 작성에만 집중할 수 있으므로 테스트벤치 구조 설정 시간을 크게 단축시킵니다.
How does UVM help ?
모든 검증 테스트벤치는 driver, monitor, stimulus generator, scoreboard 등의 주요 구성 요소를 포함합니다. UVM은 이러한 각 구성 요소에 대해 인스턴스화, 연결, 테스트벤치 환경 구축을 위한 표준화된 함수를 제공하는 기본 클래스를 제공합니다.
이 구성 요소들은 시뮬레이션 동안 존재하는 정적 엔티티(components)로, 도시의 건물과 같이 환경 전반에 존재합니다. 구성 요소들은 사람과 차량처럼 흐르는 데이터를 처리하며, 이 데이터 또는 트랜잭션은 objects 또는 sequence items라고 불립니다.
What is the UVM class hierarchy ?
UVM은 상속을 통해 더 복잡한 클래스를 구축할 수 있는 기본 클래스 집합을 제공합니다.
예를 들어, AXI 버스 프로토콜을 위한 새로운 driver 클래스는 UVM 기본 클래스인 uvm_driver를 확장하여 만들 수 있으며, 해당 프로토콜의 stimulus는 uvm_sequence_item를 확장하여 작성할 수 있습니다.
이 sequence가 어떻게 구성되어 driver에게 전달되는지는 UVM 프레임워크가 내부적으로 처리합니다.
uvm_object는 동일 클래스의 두 객체를 복사, 비교, 출력하는 공통 함수를 정의하는 주요 클래스입니다.
UVM 클래스 계층 구조는 두 가지 분기로 나뉩니다:
- uvm_component: driver, monitor, agent 등 검증 구성 요소를 정의하는 클래스
- uvm_transaction: 검증 구성 요소가 소비하고 조작하는 데이터 객체를 정의하는 클래스
Major UVM class categories
UVM Objects
UVM의 기본 아이디어는 유연성을 높이고 코드를 재사용하여 동일한 테스트벤치를 다양한 방식으로 구성하고, 다양한 stimulus를 제공하는 것입니다.
따라서 사용자 정의 설정 클래스는 uvm_object를 상속하는 것이 권장됩니다.
예를 들어, 테스트벤치 환경을 구성하는 설정 값을 담은 클래스 객체를 작성할 수 있습니다.
UVM Sequence
UVM은 실제 stimulus를 담는 컨테이너 역할을 하는 sequence 개념을 도입합니다.
서로 다른 stimulus를 개별 sequence에 넣으면 무작위 순서로 재사용하여 더 높은 커버리지와 검증 결과를 얻을 수 있습니다.
모든 사용자 정의 stimulus 클래스는 uvm_sequence를 상속하는 것이 권장됩니다.
각 sequence는 다른 sequence 내에서 사용되어 다양한 시나리오를 생성할 수 있습니다. 예를 들어, "read"와 "write" 트랜잭션에 대해 개별 sequence를 생성하고 이를 조합하여 R→W→R→W, R→R→R→W, W→W→R→R 등 다양한 패턴을 수행할 수 있습니다.
UVM Sequence Items
DUT에 전달되어야 하는 데이터 객체는 일반적으로 sequence items라 불리며, uvm_sequence_item를 상속하는 것이 권장됩니다.
예를 들어, APB 트랜잭션의 address, write/read data, access type 등을 정의하는 sequence item 클래스를 작성하여 APB driver에 전달할 수 있습니다.
UVM Components
모든 주요 테스트벤치 구성 요소는 해당 기본 클래스를 상속하여 생성됩니다.
예를 들어, 모든 사용자 정의 driver 클래스는 uvm_driver를, monitor 클래스는 uvm_monitor를 상속하는 것이 권장됩니다.
아래 표는 각 UVM 구성 요소의 역할을 간략히 정리한 내용입니다.
| Component | Purpose |
|---|---|
uvm_driver |
DUT에 신호를 구동 |
uvm_monitor |
DUT 출력 포트의 신호 모니터링 |
uvm_sequencer |
다양한 테스트 패턴 생성 |
uvm_agent |
Sequencer, Driver, Monitor를 포함 |
uvm_env |
기타 모든 검증 구성 요소 포함 |
uvm_scoreboard |
테스트 합격/실패 판단 검사기 |
uvm_subscriber |
다른 구성 요소의 활동 구독 |
UVM Component에 대해 더 알아보기(추가예정)
Register Layer
디지털 설계는 소프트웨어로 제어 가능한 레지스터를 지원하는데, 이는 각 프로젝트마다 별도의 클래스를 구축해야 했던 어려움이 있었습니다. UVM은 이 작업을 단순화하기 위한 광범위한 클래스를 제공하며, 이를 register model이라 부릅니다. 이는 다양한 SoC 설계에서 재사용 가능한 IP 검증에 매우 유용합니다.
UVM Register Layer에 대해 더 알아보기(추가예정)
TLM Connections
또 다른 똑똑한 기능은 System C의 **TLM**을 사용하는 것입니다. TLM은 트랜잭션과 class 객체 형태로 구성 요소 간 데이터를 전송하며, 특정 채널을 생성하고 연결할 필요 없이 패킷을 리스너에게 브로드캐스트할 수 있도록 합니다.
UVM Phases
UVM 구성 요소는 uvm_component를 상속받음으로써 Phasing 기능을 사용할 수 있습니다.
이를 통해 각 구성 요소는 다음 단계로 진행하기 전 서로 동기화할 수 있습니다.
모든 구성 요소는 build 단계에서 인스턴스화되고, connect 단계에서 연결되며, run 단계에서 시뮬레이션이 진행되고, 마지막으로 final 단계에서 함께 종료됩니다.
Summary
아래 표는 UVM의 주요 클래스와 각 클래스의 역할을 간략히 정리한 내용입니다.
| Class | Description |
|---|---|
uvm_object |
copy, compare, print 등 공통 작업 메서드 정의. 테스트벤치 및 testcase 설정에 사용 |
uvm_component |
driver, monitor, scoreboard 등 모든 테스트벤치 구성 요소의 기본 클래스 |
uvm_sequence_item |
driver로 전달되어 버스에 구동되는 모든 sequence items의 기본 클래스 |
uvm_sequence |
stimulus 또는 testcase를 정의하는 모든 sequence의 기본 클래스 |
이와 같이 UVM은 테스트벤치의 표준화, 효율성 및 유지보수를 용이하게 하여 디자인 검증의 핵심 도구로 활용됩니다.
관련 글: UVM 자세히 알아보기