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实战》，将一些内容进行集中性处理。