MCDF的UVM验证

MCDF验证思路

DUT描述

设计结构

MCDF设计结构，主要分为一下几个部分：
• 上行数据的通道从端（Channel Slave）：负责接收上行数据，并存储到其FIFO中。
• 仲裁器（Arbiter）：选择不同的FIFO中读取数据，并将数据进一步传送至整形器（F0rmatter）。
• 整形器（formatter）：将数据按照一定的接口时序送至下行接收端。
• 控制寄存器（Control Registers）：有专用的寄存器读写接口，负责接收命令并修改MCDF的功能。

接口描述

系统信号接口
• CLK（0）：时钟信号。
• RSTN（0）：复位信号，低位有效。
通道从端接口
• CHx_DATA (31:0)：通道数据输入。
• CHx_VALID (0)：通道数据有效标志信号，高位有效。
• CHx_READY (0)：通道数据接收信号，高位表示接收成功。
整形器接口
• FMT_CHID (1:0)：整形数据包的通道ID号。
• FMT_LENGTH (4:0)：整形数据包长度信号。
• FMT_REQ (0)：整形数据包发送请求。
• FMT_GRANT (0)：整形数据包被允许发送的接收标识。
• FMT_DATA (31:0)：数据输出端口。
• FMT_START (0)：数据包起始标识。
• FMT END (0)：数据包结束标识。
控制寄存器接口
• CMD (1:0)：寄存器读写命令。
• CMD ADDR (7:0)：寄存器地址。
• CMD_DATA_IN (31:0)：寄存器写入数据。
• CMD_DATA_OUT (31:0)：寄存器读出数据。

接口时序

通道从端接口时序见图6.3。当valid为高时，表示写入数据。该时钟周期ready为高， 表示已经将数据写入；该时钟周期ready为低，需等到ready为高的时钟周期才可以将数据写入。

整形器接口时序见图6.4。整形器是按照数据包的形式发送数据的，数据包的可选长度有4、8、16和32。整形器必须完整发送某一个通道的数据包后，才可以转而准备发送下一个数据包，在发送数据包期间，fmt_chid和fint_length应保持不变，直到数据包发送完毕。

整形器准备发送数据包时，首先应该将fmt_req置为高，同时等待接收端的fmt_grant。 当fmt_grant变为高时,应在下一个周期将fmt_req置为低。fmt_start也必须在接收到fint_grant高有效的下一个时钟被置为高，且维持一个时钟周期。在fmt_start被置为高有效的同一个周期，数据开始传送，数据之间不允许有空闲周期，即应连续发送数据，直到发送完最后一个数据，也应被置为高并保持一个时钟周期。
相邻数据包之间应至少有一个时钟周期的空闲，即fmt_end从高位被拉低以后，至少需经一个时钟周期fmt_req才可以被再次置为高。
控制寄存器接口时序见图6.5。在控制寄存器接口上，需要在每一个时钟解析cmd。当cmd为写指令时，需要把数据cmd_data_in写入到cmd_addr对应的寄存器中；当emd为读指令时，即需要从cmd_addr对应的寄存器中读取数据，并在下一个周期，将数据驱动至cmd_data_out 接口。

寄存器描述

地址0x00通道1控制寄存器32 bit读写寄存器：
• bit (0)：通道使能信号。1为打开，0为关闭。复位值为1。
• bit (2:1)：优先级。0为最高，3为最低。复位值为3。
• bit (5:3)：数据包长度，解码对应表为，0对应长度4, 1对应长度8, 2对应长度16, 3对应长度32,其他数值(4〜7)均暂时对应长度32。复位值为0。
• bit (31:6)：保留位，无法写入。复位值为0。
地址0x04通道2控制寄存器32 bit读写寄存器：同通道1控制寄存器描述。
地址0x08通道3控制寄存器32 bit读写寄存器：同通道1控制寄存器描述。
地址0x10通道1状态寄存器32 bit只读寄存器：
• bit (7:0)：上行数据从端FIFO的可写余量，同FIFO的数据余量保持同步变化。复位值为FIFO的深度数。
• bit (31:8)：保留位，复位值为0。
地址0x14通道2状态寄存器32 bit只读寄存器：同通道1状态寄存器描述。
地址0x18通道3状态寄存器32 bit只读寄存器：同通道1状态寄存器描述。
至此我们将MCDF的功能描述完毕，从下一节开始，我们将分析如何给出激励、检测以及比较数据，同时从验证效率的角度考虑，如何同时为各个模块构建模块验证平台，并最终组合为一个子系统验证平台，来完成MCDF的验证。

UVM验证结构

UVM验证主要组件

uvm_driver

uvm_driver类从uvm_sequencer中获取事务(transaction),经过转化在接口中对DUT进行时序激励。需要注意的是，任何继承于uvm_driver的类都是参数化类，在定义时需声明参数的类型。首先看uvm_driver类的定义：

	class uvm_driver #(type REQ=uvm_sequence_item, type RSP=REQ) extends uvm_component; 

在定义新的driver类时，应声明该类所要获取的事务参数REQ类型。默认情况下，RSP参数类型与REQ类型保持一致。uvm_driver在uvm_component基础上未扩展新的函数，只扩展了一些用来通信的端口和变量：

	uvm_seq_item_pull_port #(REQ, RSP) seq_item_port;
	uvm_analysis_port #(RSP) rsp_port; 
	REQ req; RSP rsp; 

driver类与sequencer类之间的通信就是为了获取新的事务对象，这一操作是通过pull的方式实现的：

	driver . seq_item_port. connect (sequencer. seq_item_export);
	driver.rsp_port.connect(sequencer.rsp_export)

uvm_monitor

这个类是为了监测接口数据，任何需用户自定义数据监测行为的monitor都应继承于该类。虽然uvm_monitor与其父类相比并未增添新的成员和方法，但将新定义的monitor类继承于uvm_monitor类有助于实现父类uvm_monitor的方法和特性。

uvm_sequencer

uvm_sequencer就像一个管道，从中传送连续的激励事务，并最终通过TLM端口送至driver 一侧。如果需要，uvm_sequencer也可以从uvm_driver那里获取随后的RSP对象以得知数据通信是否正常。从uvm_sequencer类的定义看，它与uvm_driver 一样是一个参数类，需在定义sequencer时声明REQ的类型。

sequencer 既管理着 sequence, 同时将 sequence 中产生的transaction item传送到driver一侧，可以说是整个激励环节中的“路由器"。

uvn_agent

uvm_agent本身不具备什么神技，但它是一个标准的验证环境“单位”。这样的标准单位通常包含一个driver一个monitor和一个sequencero这三个小伙伴经常聚在一起，组成一个小团伙agento同时为了复用，有时uvm_agent中只需包含一个monitor,而不需driver和sequencer,这就需要通过一个变量来进行有条件的例化。

	uvm_active_passive_enum is_active = UVM_ACTIVE; 

is_active是agent的一个成员，默认值是UVM ACTIVE,这表示处在active模式的agent需要例化driver，monitor 和 sequencer； is_active 的值是 UVM_PASSIVE 则表示 agent 是 passive模式，只可以例化monitor。active模式的agent既有激励功能也有监测功能，passive模式的agent只具有监测功能。active模式对应着DUT的接口暴露给agent且需要激励的场景，而passive模式对应着DUT的接口已经与其他设计连接而只需要监测的场景。通过is_active变量,agent需要在build_phase()和connect_phase()等函数中通过选择语句来对driver和sequencer进行有条件的例化和连接。

uvm_scoreboard

进行数据比对和报告。uvm scoreboard本身没有添加额外的成员变量和方法，但UVM建议用户将自定义的scoreboard类继承于uvm_scoreboard类，这便于子类在日后自动继承于可能被扩充到uvm scoreboard类中的成员。在实际环境中，uvm_scoreboard接收来自于多个monitor的监测数据，进行比对和报告。

uvm_env

从环境层次结构而言，uvm_env可能包含多个uvm_agent和其他component,这些不同的组件共同构成完整的验证环境，而这个环境在将来复用中可以作为子环境被进一步集成
到更高的环境中。比如图11.3就定义了一个高层的环境，其中包含sub_env、agent和scoreboard 等。

从这个例子可以看出，uvm_env的角色是一个结构化的容器，它可以容纳其他组件，同时可以作为子环境在更高层的集成中被嵌入。在实际使用中，用户容易混淆uvm_env与uvm_agent之间的嵌套关系，而且容易在创建对象阶段出现错误。建议的嵌套关系是：
• uvm_agent作为一个标准单元，在更上层的集成中应该被例化到uvm_env。
• uvm_env在更高层的复用中，可以被其他uvm_env所嵌套。

uvm_test

uvm_test类本身没有什么新成员，但是作为测试用例的“代言人”，它不但决定着环境的结构和连接关系，也决定着使用哪一个测试序列。如果没有这个代言人，整个环境无从建立,所以uvm test是验证环境建立的唯一入口，只有通过它才能正常运转UVM的phase机制。 我们从下面的示例看到，在一个顶层test中可以例化多个组件，如uvm_env或uvm_agent,而在仿真时通过uvm_test可以实现验证环境的运转。我们推荐在uvmjest中只例化一个顶层uvm_env,这便于提供一个唯一环境节点以形成树状的拓扑结构，而这种树状环境结构对应着一种树状配置结构。

apb接口对寄存器进行访问配置，四个数据通道将数据发送到各自的FIFO中，arbiter采用轮训的仲裁算法接收各个通道的数据，然后formatter通过读取寄存器中的配置信息，将读取的数据进行打包，将打包的数据送到scoreboard中，数据通道端的monitor通过监控数据，将数据送入scoreboard中，然后在refmod中讲数据打包，将两边打包数据进行比较。

TLM通信端口分析

mcdf_checker继承于uvm_scoreboard，主要作用是用来比对数据的正确与否。在mcdf项目中，其作用是接收来自各个chanl的数据，再将数据传入reference中进行整形，得到标准整形数据包，然后将此数据包与从整形器传来的数据包进行比对，以确认整形器功能正确。具体做法如下：
各个chanl_agent中的monitor中声明uvm_blocking_put_port端口，fmt_agent中的monitor声明uvm_blocking_put_port端口，reg_agent中的monitor声明uvm_blocking_put_port端口和uvm_analysis_port端口，其中uvm_analysis_port端口是为了和predictor连接传输数据。
checker中声明各个chanl、reg、fmt 的uvm_blocking_put_imp端口，它们与上述port端口连接。checker中还声明了各个chanl的uvm_blocking_get_peek_imp，为了和mcdf_refmod内部port端口连接。checker中还声明了五个mailbox，目的是存放从各个agent传来的数据（利用imp端实现put（）、get（）、peek（）任务的方式将数据放入mailbox和从mailbox取出）。
mcdf_refmod声明在checker内部。refmod里面声明了四个port端口，三个uvm_tlm_fifo，三个fifo用来存放从各个chanl传来数据整形之后的数据，并与checker中声明的三个port端口相连（三个fifo自带port、export、imp端口，不必再声明，同时不用在target端实现get（）方法）。
各个chanl_agent将数据put到checker中的各个mailbox中去，refmod从mailbox中获取数据，并将数据做标准整形之后存放在out_tlm_fifo中，等待checker中的port端口获取。fmt_agent将经过DUT整形后的数据put到checker中的mailbox，checker从此mailbox中获取数据并从refmod的fifo中获取数据，将这两个数据做对比从而验证整形器（formattter）的整形结果的正确性。

UVM序列分析

整体序列结构如上图所示
在mcdf_base_test中的run_phase任务中有虚方法run_top_virtual_sequence()；三个test子类继承于base_test并重写其中的run_top_virtual_sequence()虚方法，在重写的虚方法中例化test对应的sequence，并利用sequence.start(sequencer)方法挂载到顶层virtual sequencer上。运行test时候，会运行相应的sequence，由于在sequence中已经重写了三个do_任务，而在重写的方法中运用了uvm宏发送sequence和挂载sequencer。具体挂载对应在图中标出。

各部分分析

各部分

四级标题

五级标题