uvm_driver:所有的driver都要派生自uvm_driver。driver的功能就是向sequencer索要sequence_item(transaction),并把sequence_item里的信息驱动到DUT的接口上,这相当于完成了从transaction级别到dut能够接受的pin级别的信息的转变。
uvm_monitor:所有的monitor都要派生自uvm_monitor。monitor做的事情与driver先锋干,driver向DUT的pin上发送数据,而monitor则是从DUT的pin上接收数据,并且把接收到的数据转换成transaction级别的sequence_item,并且把转换后的数据发送给scoreboard,共scoreboard比较。
uvm_sequencer:所有的sequencer都要派生自uvm_sequencer。sequencer的功能就是组织管理sequence,当driver要求数据时,它就把sequence生成的sequence_item转发给driver。
uvm_scoreboard:一般的scoreboard都要派生自uvm_scoreboard。scoreboard的功能就是比较reference model和monitor分别发送来的数据,根据比较结果判断DUT是否正确工作。
reference model:reference model直接派生自uvm_component。refence model的作用就是模仿DUT,完成与DUT相同的功能。DUT是用Verilog写成的时序电路,而reference model则可以直接使用systemverilog高级语言的特性,同时还可以通过DPI等接口调用其他语言来完成与DUT相同的功能。
uvm_agent:所有的agent要派生自uvm_agent。与前面几个比起来,uvm_agent的作用并不是那么明显,它只是把driver和monitor封装在一起,根据参数值来确定只是例化monitor还是要例化driver和monitor,这个主要从可重用性的角度来考虑。
uvm_env:所有的env要派生自uvm_env。env是environment的缩写,env把验证平台上用到的固定不变的component都封装在一起,这样,当跑不同的case时,只要在case中例化一个env就可以了。
uvm_test:所有的case要派生自uvm_test。case与case之间差异很大,所以从uvm_test派生出来的类各不相同。任何一个派生出来的case中,都要实例化env,只有这样,才能把数据正常的发给DUT,并正常接受DUT。
uvm_sequence_item:所有的transaction都要从uvm_sequence_item派生。transaction就是封装了一定信息的一个类,如一个mac transaction就是把一个mac帧封装在了一起,包括目的地址、源地址、帧类型、帧数据、FCS校验和等。driver从sequencer中得到transaction,并且把其转换成pin级别的信号。
uvm_sequence:所有的sequence要从uvm_sequence派生一个。sequence就是sequence_item的组合。sequencer直接与sequencer打交道,当driver向sequencer索要数据的时候,sequencer会转而向sequence要数据,sequence发现有sequence_item时,会把此sequence_item传递给sequencer,并最终发送给driver。
config:所有的config一般直接从uvm_object派生。config的主要功能就是规范验证平台的行为方式。如CPU的driver在读取总线时地址信号要持续几个时钟,片选信号从什么时候开始有效等等。