지노랩 /JinoLab

4.10.1 커버리지 방식 선택구분 정의 장점 한계명시적(Explicit) 커버리지사용자가 covergroup / coverpoint / cross 등을 만들어 “목표·수집 시점”을 명확히 기재목표 충족 여부가 직관적 → 검증 종료 기준으로 활용 쉽다목표를 놓치면 구멍(coverage hole) 이 드러나지 않는다암시적(Implicit) 커버리지시뮬레이터가 자동 산출하는 코드·표현식·FSM 커버작성 부담 ↓, RTL 변경 시 자동 갱신추상 기능 ↔ 커버리지의 매핑이 난해, 고수준 이벤트·동시성 체크 불가실무 권고명시적 모델로 “기능 사양”을 그대로 반영이후 암시적 커버리지를 돌려 안전망으로 삼고, 코드 라인이 안 덮인다면 명시적 모델을 보완한다.Functional 100 % 이지만 Code 4.10.2 ..

1. 스코어보드란?정의 : DUT가 내놓은 트랜잭션/데이터를 레퍼런스 모델(황금 모델)과 비교해 기능적 합 불합을 판단하는 UVM 컴포넌트.위치 : 반드시 패시브 도메인(모니터 뒤)에서 동작 → 자극(Driver)과 분리돼야 재사용·신뢰성 확보.형태 : 대부분 uvm_scoreboard 파생 + 하나 이상의 TLM analysis_export(또는 imp)를 지님.2. UBus 데모용 스코어보드 예(메모리 동작 검증)목표 : 주소 A에 write한 데이터 D가, 나중에 read A 하면 동일 D로 반환되는지 검사.3. 스코어보드 제작 절차3-1 컴포넌트 정의class ubus_example_scoreboard extends uvm_scoreboard; // (1) Analysis imp 선언 uvm_..

1. 왜 ‘자동 체크’가 중요한가?상태 도달은 절반 — 레지스터를 써서 기능을 켰다고 끝이 아니다.반응 검증이 핵심 — DUT가 규격대로 응답했는지까지 확인해야 “기능 완료(verified)” 를 선언할 수 있다.사람 눈 대신 툴 — 수십만 개 랜덤 패턴을 사람이 파형으로 볼 수 없으므로 자동 체크가 필수.2. 두 가지 자동 체크 기판종류 역할 특징 작성 위치a) Assertion(어설션)타이밍·프로토콜 규칙 준수신호 레벨 집중, 즉각 에러 탐지 (fatal, error)• DUT RTL 내 임베드• UVM Monitor 내부b) Data Checker / Scoreboard기능적·데이터 무결성 검사트랜잭션·패킷·프레임 단위 비교• Passive Monitor → Scoreboard(reference m..

4.7.0 왜 가상 시퀀스가 필요한가?블록-레벨에서는 한 개 Agent만 다루므로 시퀀서 하나면 충분.시스템-레벨에서는 Ethernet, CPU-Bus, DDR, SPI 등이 동시에 트래픽을 만들어야 한다.타이밍 · 데이터 상호작용(“CPU가 레지스터 쓰자마자 Ethernet DMA 시작”)을 중앙 집중식으로 제어하려면 가상 시퀀스 + 가상 시퀀서 구조가 필수.4.7.1 가상 시퀀서(Virtual Sequencer) 만들기단계 설명① 파생 선언class my_vseqr extends uvm_sequencer; (driver와 연결되지 않음)② 서브 시퀀서 핸들cpu_sequencer cpu_seqr; eth_sequencer eth_seqr; 등 참조 변수 선언③ 연결상위 환경(connect_phase)..

4.6.0 왜 ‘의도적’ 테스트가 필요할까?순수 랜덤 → 시드만 바꿔도 수천 가지 패턴을 만들 수 있다.그러나 커버리지 빈틈·코너 케이스는 “우연히” 나타나지 않는다.따라서 데이터 값을 제약(Constraint) 하거나 시퀀스로 순서를 제어 해 기획형 패턴을 만들어야 한다. → 이번 절에서는 “데이터 값 수준” 제어법(4.6.1 ~ 4.6.3)을 다룬다. → “아이템 순서” 제어는 다음 절(4.7) Sequence에서 설명.4.6.1 데이터 아이템 제약하기 (Constrain Items)단계 할 일 설명a)아이템 클래스 파악VIP 문서에서 uvm_sequence_item 파생 클래스를 찾고, 어떤 필드가 랜덤인지 확인b)파생(derived) 클래스 작성기존 제약 + 추가/수정 제약을 선언c)환경에 새 타..

4.5.1 Base Test(기준 테스트) 만들기1) 왜 Base Test가 필요한가?공통 작업 중앙화 – Top-level Environment 인스턴스화, 기본 파라미터 세팅, 공통 리포트 옵션 등을 한 곳에 모아둔다.파생(derivative) Test 재사용 – 시나리오만 바꿔도 동일 토폴로지를 그대로 활용할 수 있다.2) 예제 – ubus_example_base_testclass ubus_example_base_test extends uvm_test; `uvm_component_utils(ubus_example_base_test) ubus_example_env ubus_example_env0; // Top-env 핸들 // 생성자 function new(string name="ubus_..

4.4.1 검증 컴포넌트의 “설정 가능 파라미터”구분 표준(Standard) 파라미터 의미·용도Agent 모드is_active : UVM_ACTIVE / UVM_PASSIVE• Active : 트래픽을 발생해 DUT를 자극• Passive : DUT 라인을 스noop하며 체크·커버리지만 수행Monitor 옵션coverage_enable · checks_enable커버리지 수집·어썰션 체크를 개별적으로 ON/OFFTopologynum_masters, num_slaves, has_bus_monitor 등버스·인터페이스별 기본 구조 정의실무 간단 규칙에뮬레이션용 가짜 디바이스 = Active AgentRTL DUT의 외부 포트 감시 = Passive Agent사용자 정의(User-defined) 파라미터 예A..

1 | uvm_test 클래스가 맡는 일책임 세부 내용시나리오 정의어떤 시퀀스를 언제·얼마나 돌려서 어떤 기능·커버리지를 확인할지 결정환경 선택top_env 같은 최상위 환경 클래스를 인스턴스화구성(override)uvm_config_db::set, Factory Override로 환경·VIP 파라미터를 수정데이터 생성인라인 constraint, user-defined sequence로 트랜잭션 생성목표 설정커버리지 옵션, 메시지 필터, 시드 고정 등 런타임 세팅즉 “테스트=시뮬레이션 한 회(run)의 의도와 목표를 캡슐화한 클래스”입니다.2 | 클래스 기반 구조 – 상속과 재사용Base Test: 공통 토폴로지·기본 설정 담당Derived Test: Base Test를 상속해 시나리오별 차이(시퀀스·파..

1. 개요 – “환경 통합자”가 하는 일목표: 여러 테스트에서 재활용할 수 있는 top-level environment를 정의방법: build_phase() 안에서 VIP를 팩토리 create로 생성하고, uvm_config_db::set()으로 토폴로지 파라미터를 미리 주입이점Test Writer는 VIP 구성 방법을 몰라도 된다.토폴로지가 바뀌어도 environment 클래스 한 곳만 수정하면 된다.파생 클래스(확장 VIP, 커스터마이즈 Scoreboard)로 override해도 코드 변경 최소화.2. 예제 코드 뜯어보기class ubus_example_env extends uvm_env; `uvm_component_utils(ubus_example_env) // 서브-환경(VIP)과 스코어보드 ..

1. 왜 Top-Level Environment가 필요할까?테스트마다 VIP(Verification IP)를 직접 인스턴스한다면 다음과 같은 문제가 생깁니다.복잡한 설정 지식 요구Test Writer가 is_active, addr_width, has_crc 같은 파라미터를 전부 알아야 함.토폴로지 변경 시 유지보수 폭증인터페이스 한 개만 늘어도 수십 개의 테스트 파일을 열어 수정해야 함.재사용성 저하테스트 코드가 “특정 배선 구조”에 하드코딩돼 있으므로 다른 프로젝트나 변형된 DUT에 옮겨쓰기가 힘듦.Top-Level Environment는 이 모든 문제를 ‘한 곳’에서 해결하는 컨테이너 역할을 합니다.2. Top-Level Environment의 정의구분 내용무엇인가?VIP 인스턴스, 서브 Enviro..

1. 왜 ‘재사용 컴포넌트’인가?개발 기간 단축 : 이미 검증된 VIP를 가져다 쓰면 RTL 변경분만 반영하면 되므로 새 코드를 거의 쓰지 않습니다.일관성-유지 : 팀·프로젝트 간 코딩 스타일이 달라도 UVM 프레임워크(phase, factory, config-DB)가 동일하니 유지보수가 쉽습니다.품질 향상 : VIP에는 커버리지 모델·어썰션·버그 패턴이 이미 녹아 있어서 처음부터 ‘구멍 난’ 테스트벤치를 만들 위험이 작습니다.2. 두 가지 역할역할 핵심 책임 보통 직무Testbench IntegratorVIP를 인스턴스·연결하고 환경 전역 파라미터를 세팅Verification Lead, Platform ArchitectTest Writer준비된 testbench를 이용해 시나리오·시퀀스를 작성Block..