지노랩 /JinoLab

[UVM] 5.5.1 필드 타입(Field Type) ― 레지스터 필드를 객체로 “정의·제약·확장”하는 방법 본문

UVM(Universal Verification Methodology)/5. Register Layer Class 사용하기

[UVM] 5.5.1 필드 타입(Field Type) ― 레지스터 필드를 객체로 “정의·제약·확장”하는 방법

지노랩/JinoLab 2025. 5. 7. 09:10

 

1 | 필드 타입이 언제 필요한가?

  • 대부분의 필드는 uvm_reg_field 인스턴스만으로 충분.
  • 그러나 다음이 필요할 때 전용 타입 클래스를 확장해 쓴다.
    1. 고유 제약 : 값 제한·랜덤 분포·상태 의존성
    2. 사용 규칙 : Write-once, 보호 모드, 동적 유효성 검사
    3. 콜백 기반 동작 커스터마이즈 : pre/post read·write 핸들링

2 | 필드 타입 클래스 기본 골격

class my_fld_type extends uvm_reg_field;
  `uvm_object_utils(my_fld_type)

  // 2-1. (선택) 상태 변수·제약
  constraint VALID_C { value inside {0,1,2,4,8,16,32}; }

  // 2-2. 생성자 – super.new() 호출
  function new(string name = "my_fld_type");
    super.new(name);
  endfunction
endclass
  • uvm_object_utils 매크로 필수 → 팩터리·rand 지원
  • 제약 블록 이름은 보기 쉽게 VALID_C, REASONABLE_C 처럼 대문자 사용 권장
  • post_randomize()를 오버라이드할 경우 super.post_randomize() 호출 잊지 말 것.

3 | 레지스터 build()에서 타입 인스턴스화

class cfg_reg extends uvm_reg;
  my_fld_type MODE;
  uvm_reg_field EN;

  function void build();
    configure(null, 32, "RW", 0);

    MODE = my_fld_type ::type_id::create("MODE");
    MODE.configure(this, 3, 0, "RW", 0, 0, 1, 1, 0);

    EN   = uvm_reg_field::type_id::create("EN");
    EN.configure(this, 1, 3, "RW", 0, 0, 1, 1, 0);
  endfunction
endclass

한 클래스당 한 종류 타입 — 자동 생성기는 필드 속성 조합이 같으면 동일 타입 클래스로 묶어 코드 중복을 줄인다.


4 | 사전 정의 Access Policy (Table 7 요약)

키 의미 Write 영향 Read 영향

RO Read-Only X X
RW Read/Write 쓰기값 저장 X
RC Read-Clear X 읽으면 0
W1C Write-1-Clear 1만 0으로 X
W1SRC W1 Set, R Clear 1⇒1 · 읽으면 0
  • 추가 정책이 필요하면 define_access("PROT") 로 비트 값 등록 후, 콜백이나 클래스 확장으로 동작 정의.

5 | 사용자 정의 Access Policy 예

class protected_field extends uvm_reg_field;
  local static bit PROT = define_access("PROT");
  uvm_reg_field protect_mode;

  virtual task pre_write(uvm_reg_item rw);
    if (protect_mode.get())
      rw.value = value;          // 보호모드 ON → 쓰기 무효화
  endtask
endclass
  • 또는 콜백 패턴 — class protected_field_cb extends uvm_reg_cbs 로 정의 후
    uvm_callbacks#(my_fld_type, uvm_reg_cbs)::add(fld, cb);

6 | “필드 동작” vs. “필드 사용 규칙”

  • Access 정책하드웨어 물리 동작을 미러가 예측하도록 함.
  • “소프트웨어에서 한 번만 써야 한다” 같은 용도 제약은 별도 로직으로 구현해야 하며,
    mirror 갱신은 막지 않는다 (실제 HW 동작을 왜곡 X).
class config_once_field extends uvm_reg_field;
  bit m_written = 0;
  virtual task pre_write(uvm_reg_item rw);
    if (m_written)
      `uvm_error(get_full_name(), "Written twice!");
    m_written = 1;
  endtask

  virtual function reset(string kind="HARD");
    if (has_reset(kind)) m_written = 0;
    super.reset(kind);
  endfunction
endclass

7 | IP-XACT → UVM 정책 매핑 가이드 (표 8~12)

  • Generator가 access, modifiedWriteValue, readAction 조합을 해석해
    Table 8–12에 맞춰 UVM 정책 상수로 매핑 (RW, W1C 등).
  • 매핑이 애매하거나 문서대로 구현할 수 없는 조합은 User-defined Policy 로 생성.

8 | Reserved 필드 처리

  • 단순히 “예약(reserved)”이라고 해도 실제 HW 행동에 따라 RO 0, RS, WC 등으로 모델링.
  • 테스트 제외하려면 NO_REG_TESTS 애트리뷰트 또는 set_compare(0) 사용.


 

본 내용은
accellera에서 공개한
Universal Verification Methodology
(UVM) 1.2 User's Guide
를 바탕으로 작성된 글입니다.