UVM工厂机制

UVM 工厂Factory机制的核心是注册→创建→覆盖用集中管控与动态绑定实现 “接口声明、实现可替换”是 UVM 实现高复用、易扩展验证环境的基石。下面从原理、核心组件、使用方法、典型场景与源码本质逐层详解。一、核心设计思想工厂本质是单例模式 依赖反转IoC解耦创建与使用不硬编码new()而是通过工厂请求对象创建逻辑由工厂统一管理。运行时动态替换无需修改原有代码用派生类替换基类实例实现 “同一环境、不同行为”。全局唯一管控整个验证环境只有一个uvm_factory实例集中管理所有注册类型与覆盖规则。传统 new () 与工厂 create () 对比// 硬编码写死类型无法替换 my_driver drv new(drv, this); // 工厂方式声明接口实现由工厂决定 my_driver drv my_driver::type_id::create(drv, this);二、三大核心组件1. 全局工厂单例uvm_factory全局唯一实例通过uvm_factory::get()获取。维护两张表类型注册表记录所有注册类、覆盖映射表记录类型 / 实例替换规则。2. 类型注册宏UVM 通过宏自动注册类到工厂分两类宏用途适用类uvm_component_utils(T)注册组件有层次、生命周期uvm_component派生类driver/monitor/envuvm_object_utils(T)注册对象无层次、数据 / 配置uvm_object派生类transaction/config注册示例class my_driver extends uvm_driver#(my_transaction); uvm_component_utils(my_driver) // 注册到工厂 // ... endclass宏展开后会定义type_iduvm_object_registry单例。实现get_type()/create()等方法供工厂查找与创建实例。3. 类型代理uvm_object_registry#(T)每个注册类对应一个type_id是工厂与类之间的代理接口。核心方法create()触发工厂创建、set_type_override()设置类型覆盖。三、工厂工作全流程注册→覆盖→创建1. 注册Registration编译期uvm_*_utils宏将类信息类型名、创建函数存入uvm_factory的类型表。关键只有注册过的类工厂才能创建或替换。2. 覆盖Override动态替换规则覆盖分两种均在创建前设置通常在build_phase。1类型覆盖Type Override全局替换所有实例// 所有base_driver实例 → 替换为enhanced_driver base_driver::type_id::set_type_override(enhanced_driver::get_type()); // 或全局工厂调用 uvm_factory::get().set_type_override_by_type( base_driver::get_type(), enhanced_driver::get_type() );2实例覆盖Instance Override仅替换特定路径实例// 仅替换env.agent.drv这一个实例 uvm_factory::get().set_inst_override_by_type( base_driver::get_type(), debug_driver::get_type(), env.agent.drv // 实例路径通配符*支持模糊匹配 );3. 创建Creation工厂按规则实例化调用type_id::create()时工厂执行查覆盖表是否有当前类型 / 实例的替换规则。选实际类型有覆盖则用替换类无则用原类。实例化调用替换类 / 原类的new()返回句柄。创建示例// 工厂创建若有base_driver→enhanced_driver覆盖实际返回enhanced_driver实例 my_driver drv my_driver::type_id::create(drv, this);四、关键使用规则与注意事项继承要求替换类必须是基类的派生类满足多态。宏一致性基类与派生类都必须用uvm_*_utils注册。覆盖时机覆盖必须在创建前设置build_phase早于connect_phase。路径匹配实例覆盖路径需与get_full_name()完全一致支持*通配符。覆盖优先级实例覆盖 类型覆盖局部规则优先于全局。五、典型应用场景1. 功能扩展用增强驱动替换基础驱动基类base_driver基础功能。派生类perf_driver增加性能统计、debug_driver增加日志。测试中通过覆盖切换同一环境跑不同功能。2. 环境复用同一 ENV 适配不同 DUT基类base_transaction通用激励。派生类dut1_transaction/dut2_transaction适配不同 DUT 时序。工厂覆盖动态切换激励类型ENV 无需修改。3. 调试与错误注入替换正常组件为故障组件用error_inject_driver替换正常driver无需修改原有代码即可注入错误验证 DUT 容错性。六、源码本质简化理解1.uvm_factory核心逻辑class uvm_factory; static uvm_factory inst; // 单例 uvm_type_info type_table[string]; // 类型注册表 uvm_override_info type_override_table[uvm_type_info]; // 类型覆盖表 uvm_override_info inst_override_table[string]; // 实例覆盖表 virtual function uvm_object create_object(uvm_type_info type, string name, string inst_path); // 1. 查实例覆盖 if (inst_override_table.exists(inst_path)) type inst_override_table[inst_path].new_type; // 2. 查类型覆盖 else if (type_override_table.exists(type)) type type_override_table[type].new_type; // 3. 创建实例 return type.create(name); endfunction endclass2.uvm_object_registry代理class uvm_object_registry#(T) extends uvm_type_info; static uvm_object_registry#(T) inst; // 单例type_id virtual function uvm_object create(string name); return new T(name); // 实际创建 endfunction endclass七、总结UVM 工厂机制是 **“接口抽象 动态绑定”** 的典范注册让工厂 “认识” 类纳入统一管理。覆盖运行时动态调整类型映射实现无代码修改的功能切换。创建工厂按规则实例化解耦创建与使用提升环境复用性。掌握工厂机制是写出高复用、易维护、可扩展UVM 验证环境的核心。