1. The UVM Factory (공장 시스템)

객체 지향 프로그래밍(OOP)에서 객체를 만들 때 보통 new()라는 생성자(Constructor)를 씁니다. 하지만 UVM에서는 절대 new()를 쓰지 않고 create()를 씁니다. 그 이유가 바로 Factory 때문입니다.

Factory의 존재 이유 (Why Factory?):

• 기존의 코드를 단 한 줄도 수정하지 않고, 실행 시점(Runtime)에 원래 쓰려던 컴포넌트 대신 다른 컴포넌트를 바꿔치기(Override) 하기 위해서입니다.
• 예시: 기본 AXI_Driver 코드가 환경에 다 연결되어 있는데, 에러를 주입하는 테스트를 하고 싶습니다. 코드를 다 뜯어고치는 대신, 테스트 파일에서 Factory에게 "야, 앞으로 AXI_Driver 달라고 하면 내가 만든 AXI_Error_Driver로 내보내"라고 지시만 하면 됩니다.

사용 방법 (How to use):

• Registration (등록): 클래스를 만들 때 uvm_component_utils() 또는 uvm_object_utils() 매크로를 써서 공장에 이 도면을 등록합니다.
• Creation (생성): new() 대신 type_id::create("name", this)라는 UVM 전용 문법을 씁니다.
• Override (바꿔치기): Test의 build_phase에서 set_type_override() 또는 set_inst_override()를 써서 바꿔치기를 지시합니다. (특정 인스턴스만 바꾸는 것이 전체 타입을 바꾸는 것보다 우선순위가 높습니다.)

2. Configuration Database (uvm_config_db)

UVM 트리가 거대해지면, 꼭대기에 있는 Test가 저 밑바닥에 있는 Driver에게 데이터(예: Virtual Interface 핸들이나 딜레이 설정값)를 전달해야 할 때가 있습니다. 이걸 C언어처럼 함수 인자로 계속 넘겨주면 코드가 지저분해집니다. 그래서 사용하는 것이 UVM 전용 우체국, uvm_config_db입니다.

작동 원리 (How it works):

• set(): 데이터를 주는 쪽(Parent)에서 "이 주소(경로)에 사는 애한테 이 상자를 줘!" 하고 우체국에 맡깁니다.
• get(): 데이터를 받는 쪽(Child)의 build_phase에서 "우체국아, 내 이름으로 온 상자 있니?" 하고 찾아옵니다.

Top-down Rule (하향식 우선순위):

• UVM은 항상 위에서 아래로(Top-down) 지어집니다. 만약 Environment가 X=3으로 set하고, 그 위의 Test가 X=4로 set했다면? 더 높은 계층인 Test의 설정값(X=4)이 이깁니다.

가장 중요한 용도 (Passing Virtual Interfaces):

• 칩 설계(DUT)는 Verilog의 세계(Hardware)에 있고, UVM은 클래스의 세계(Software)에 있습니다. 이 둘을 연결하는 다리가 바로 virtual interface입니다.
• Testbench의 가장 최상단 tb_top 모듈(Hardware)에서 핀들을 묶은 virtual interface를 uvm_config_db::set()으로 우체국에 넣고, 저 밑의 Agent 안에 있는 Driver(Software)가 get()으로 꺼내와서 직접 핀 신호를 조작합니다.

3. Tom's Golden Rules (현업 주의사항)

• Performance Hit (성능 저하): uvm_config_db는 문자열 경로(String path)를 검색해서 데이터를 찾는 방식이라서 시뮬레이션 속도를 엄청나게 깎아먹습니다.

• 해결책 (Config Object): 값 하나하나를(예: delay_val, error_rate) 따로따로 set/get 하지 마세요. 설정값 10개를 묶어서 하나의 Configuration Object (예: axi_env_config) 클래스로 만든 다음, 이 뭉텅이 1개를 딱 한 번만 set/get 하는 것이 성능상 훨씬 좋습니다.