1. UVM是一个以System Verilog类库为主体的验证平台开发框架。也就是基于SV语言写的用于验证的代码库和对应的验证规范。
2. UVM验证环境整体结构
(验证平台要模拟DUT的各种真实使用情况,就要给DUT施加各种激励,激励的功能则是由Driver实现的; 验证平台要根据DUT的输出来判断DUT的行为是否符合预期,这一步就由scoreboard来完成; 判断就需要涉及两方面:判断什么?很明显是判断DUT的输出,另外判断标准是什么?标准通常就是最初想达到的预期。(DUT有自己的一套设计,但在验证DUT是否符合预期时,验证平台也需要自己运行一套设计,完成这个过程的就是Reference Model 参考模型)
而参考模型是怎么形成的呢?是由monitor采集激励然后传送给RM的,而此时这个激励是哪来的呢?是sequencer从外部接收到sequence发来的数据,然后driver按照协议驱动数据 给DUT施加激励。
验证平台要收集DUT的输出并把它们传递给scoreboard,这一步由monitor完成。(框架一右半部)终于理清了。。
总结:验证平台要模拟DUT的各种真实使用情况,就要给DUT施加各种激励,激励由driver完成,当driver申请数据时,sequencer就把sequence生成的数据发送给driver,driver就按照协议驱动数据到DUT端口上,此时就需要monitor从DUT接收数据,并将其转换成transaction,一个monitor将数据发送到RM参考模型,RM模仿DUT完成与DUT相同的功能,另一个monitor将数据发送到scoreboard,scoreboard比较monitor和RM两边发来的数据来判断DUT是否正确工作!
完整的UVM树
1. 使用UVM的第一条原则:验证平台中所有的组件都应派生自UVM中的类。
2. component和object是UVM中最基本的两个概念
uvm_object是UVM中最基本的类,几乎全部的类都是由uvm_object类派生出来,其中也包含uvm_component。
uvm_object提供的核心方法 主要是提供与数据操作相关的服务,Copy、Clone、Compara、Print、pack/unpack
uvm_component有两大特性是uvm_object所没有的,
! 一是通过在new的时候指定parent参数来形成一种树形的组织结构;
! 二是有phase的自动执行特点
下图为UVM中常用类的继承关系
所有UVM树的结点都是由uvm_component组成的,只有基于uvm_component派生的类才有可能成为UVM树的结点;最左边分支的类或者说直接派生自uvm_object的类,是不可能成为UVM树的结点的。
!!uvm_component的限制:由于uvm_component是作为UVM树的结点存在的,这个特性使它失去某些uvm_object 的特征。 在uvm_object中有clone函数,用于分配一块内存空间,并把另一个实例复制到这块新的内存空间中,而clone函数无法用于uvm_component中,因为一旦使用后,新clone出来的类,它的parent参数无法指定。
另外一个限制:位于同一个父结点下的不同的component,在例化时不能使用相同的名字,否则会出错。
uvm_sequence_item:所有transaction都派生自uvm_sequence_item。transaction就是封装了一定信息的一个类。(driver从sequencer中得到transaction,并将其转换成端口上的信号)
虽然UVM中有一个uvm_transaction的类,但是不能从uvm_transaction派生出transaction,而是要从uvm_sequence_item产生。
uvm_sequence:sequence就是sequence_item的组合。当driver向sequencer索要数据时,sequencer会检查是否有sequence要发送数据,当发现有sequence_item待发送时,会把sequence_item交给driver。
config: config的主要功能就是规范验证平台的行为方式。其实就是config把所有的参数放在一个object中,再通过config_db设置给所有需要这些参数的component。
uvm_phase:派生自uvm_object,主要作用是控制uvm_component的行为方式,使得uvm_component平滑的在各个不同的phase之间依次运转。
uvm_driver: driver的功能就是向sequencer索要sequence_item(其实是sequence_item中派生的transaction),然后将transaction驱动到DUT的端口上,这里完成了从transaction级别到DUT能接受的端口级别的信息的转换。
uvm_sequencer: 主要功能是管理sequence,当driver索要数据时,它就把sequence生成的sequence_item转发给driver。
uvm_monitor: monitor从DUT的pin上接收数据,并且把接收到的数据转换成transaction级别的sequence_item,然后把转换后的数据发送给scoreboard。
uvm_scoreboard: 比较reference model 和monitor发来的数据,根据自动比对结果判断DUT是否正确工作。
reference model: RM一般是派生自uvm_component,功能就是模仿DUT,完成与DUT相同的功能。
uvm_agent: 功能只是把driver和monitor封装在一起,根据参数值来决定是只例化monitor还是同时例化driver和monitor。 使用agent是从可重用性的角度出发的。
uvm_env: (environment) env将验证平台上用到的固定不变的component都封装在一起(除了DUT),当下一次运行其他的测试用例时,只需要在测试用例中例化此env即可。
uvm_test: 所有的测试用例派生自uvm_test 或其派生类,任何一个测试用例中,都要例化env,这样,在测试用例运行时,才能把数据正常发给DUT。