UVM实战读书笔记-UVM各个组件介绍
uvm_monitor
作用
验证平台必须监测DUT的行为,用于收集DUT的端口数据,并将其转换成transaction交给后续的组件,所以monitor需要一个虚拟接口。
特性
所有的monitor类应该派生自uvm_monitor;它是一个component,要使用uvm_component_utils宏注册
实现方式
由于monitor需要时刻收集数据,永不停歇,所以在main_phase中使用while(1)循环来实现这一目的。
uvm_driver
作用
因为driver只负责驱动transaction,而不负责产生,只要有transaction就驱动,所以必须做成一个无限循环的形式。
实现方式
通过get_next_item任务来得到一个新的req,并且驱动它,驱动完成后调用item_done通知sequencer。
reference model
作用:
reference model的作用就是模仿DUT,完成与DUT相同的功能。
特性:
UVM中并没有针对reference model定义一个类。所以通常来说,reference model都是直接派生自uvm_component。
实现:
DUT是用Verilog写成的时序电路,而reference model则可以直接使用SystemVerilog高级语言的特性,同时还可以通过DPI等接口调用其他语言来完成与DUT相同的功能。
uvm_agent:
作用:
它只是把driver和monitor封装在一起,根据变量is_active来决定是只实例化monitor还是要同时实例化driver和monitor
其类型为
特性:
所有的agent要派生自uvm_agent。
uvm_sequencer:
作用:
sequencer的功能就是组织管理sequence,当driver要求数据时,它就把sequence生成的sequence_item转发给driver。
特性:
所有的sequencer都要派生自uvm_sequencer。
uvm_scoreboard
scoreboard的功能就是比较reference model和monitor分别发送来的数据,根据比较结果判断DUT是否正确工作。
特性
一般的scoreboard都要派生自uvm_scoreboard。
uvm_env
env将验证平台上用到的固定不变的component都封装在一起。这样,当要运行不同的测试用例时,只要在测试用例中实例化此env即可。
特性
所有的env(environment的缩写)要派生自uvm_env。
uvm_test
特性:
所有的测试用例要派生自uvm_test或其派生类,不同的测试用例之间差异很大,所以从uvm_test派生出来的类各不相同。
实现方式
任何一个派生出的测试用例中,都要实例化env,只有这样,当测试用例在运行的时候,才能把数据正常地发给DUT,并正常地接收DUT的数据。
内容摘自张强《UVM实战》,将一些内容进行集中性处理。