一、类库地图
- 在SV模块中,验证环境整体的构建,是从底层模块的验证组件搭建到通信和激励生成
- 这些元素无论是软件对象的创建、访问、修改、配置,还是组件之间的通信等都是通过用户自定义的方式来实现的。
- UVM验证方法学作为之前所有方法学的融合版本,从自身初衷而言,就是将验证过程中可以重用和标准化的部分都规定在其方法学的类库当中,通过标准化的方式减轻了验证人员构建环境的负担。
对验证环境的共同需求:
- 组件的创建和访问
- 环境的结构创建、组件之间的连接和运行
- 不同阶段的顺序安排
- 激励的生成、传递和控制
- 测试的报告机制
UVM世界
UVM类库地图按照UVM的核心机制将地图进行了分块 - 1.核心基类(uvm_object)
- 2.工厂(factory)类
- 3.事务(transaction)和序列(sequence)类
- 4.结构创建(structure creation)类
- 5.环境组件(environment component)类
- 6.通信管道(channel)类
- 7.信息报告(message report)类
- 8.寄存器模型(register model)类
- 9.线程同步(thread synchronization)类
- 10.事务接口(transaction interface)类
二、工厂机制
工厂(factory)机制是UVM的真正魅力所在。
- 工厂的意义
UVM的存在就是为了更方便的替换验证环境中的实例或者注册的类型,同时工厂的注册机制也带来了配置的灵活性。
这里的实例或者类型替代,在UVM中称作覆盖(override),而被用来替换的对象或者类型,应该满足注册(registration)和多态(polymorphism)的要求。
UVM的验证环境构成可以分为两部分,一部分构成了环境的层次,这部分代码是通过uvm_component类完成的。
另一部分构成了环境的属性和数据传输,这一部分是通过uvm_object类完成的。
**工厂可以创建对象,创建对象前先要把类型注册**
uvm_component和uvm_object
参考SV模块学习组件概念,验证环境的不动产,包含generator、stimulator、monitor、agent等这些组件在uvm_component的子类中均有对应的组件。环境组件
SV中非固定资产,即那些TLM transaction,从generator到stimulator的数据包由uvm_object表示。测试场景,动态产生。
uvm_{component,object}的例化
class comp1 extends uvm_component;
`uvm_component_utils(comp1) //注册
function new(string name = “comp1” , uvm_component parent = null);
super.new(name,parent);
d
i
s
p
a
l
y
(
dispaly(
dispaly(sformatf(" %s is created" ,name ));
endfunction:new
function void build_phase(uvm_phase phase);
super.build_phase(phase);
endfunction:build_phase
endclass
class obj1 extends uvm_obiect;
`uvm_object_utils( obj1 ) //注册
function new(string name = “obj1” );
super.new(name);
d
i
s
p
a
l
y
(
dispaly(
dispaly(sformatf(" %s is created" ,name ));
endfunction:new
endclass
comp1 c1,c2;
obj1 o1,o2;
initial begin
c1 = new (" c1 “); // SV 创建方式
o1 = new (” o1 ");
c2 = comp1::type_id::creat(“c2”,null); // UVM 创建方式
o2 = obj1::type_id::creat(“o2”);
end
uvm_coreservice_t 既不是component也不是object类型,比如其中factory,factory是用来注册object和component,如果本身是object或者component类型的,就有矛盾。