【UVM基础】5、sequence、sequencer、item、driver

主要是了解sequence item、sequence、sequencer、driver 的作用，以及之间是怎么相互联系的。

 在上面这张图中，sequence会产生不同目标数量的sequence item对象，不同主要依托于SV的随机化，是的每个sequence item 的数据内容都不同；产生的sequence item经过sequencer在流向driver，driver对得到的每个sequence item进行数据解析，将数据写入接口上，写入的时候需要注意时序（接口协议），对DUT形成有效激励。

在必要的时候，driver在解析完每个sequence item后，会将最后的状态信息写回sequence item 返回给sequencer，然后最终抵达sequence对象一侧。

sequence item是driver与DUT每一次互动的最小粒度内容,driver往往是一个Sequence item消化完，报告 给sequencer和sequence，同时再请求消化下一个sequence item。

uvm_sequence_item 和uvm_sequence都是基于uvm_object，这是不同于uvm_component的地方，所以可以在uvm环境中的任何地方进行创建和配置。uvm_component只应当在build_phase阶段进行创建和配置。

 

sequence 和 item

这里的sequence指的是uvm_sequence类，而item指的是 uvm_sequence_item类，我们简称其为sequence和item。对于激励生成和场景控，是由sequence来编织的，而对于激励所要的具体数据和控制要求，则是从item的成员数据得来的。

item

item是基于uvm_object类，这表明了它具备UVM核心基类所必要的数据操作方法，例如：copy（）、clone（）、compare（）、record（）。item通常应该具备控制类、负载类、配置类和调试类这些数据类型。

item使用特点

如果需要用来做驱动，那么用户应考虑定义为rand类型,同按照驱动协议给出合适的constraint 。

由于item本身的数据属性,为了充分利用UVM域声明的特性,我们建议将必要的数据成员都通过'uvm_field_XXX宏来声明，以便日后uvm"object 基本数据方法自动实现。

UVM要求item的创建和随机化都应该发生在sequence的body(任 务中，而不是在equencer或者driver中。

按照item对象的生命周期来区分，它的生命应该开始于sequence的body中，而后经历了随机化并穿越sequencer最终到达driver，直到被driver 消化之后,它的生命一般来讲才会结束。之所以要突出这一点，是因为一些用户在使用中会不恰当地直接操作item对象，直接修改其中的数据，或将它的句柄发送给其它组件使用，这会无形中修改item的数据基因或者延长item对象的寿命。这种不合适的对象操作方式是需要注意的， 可以取代的方式则是合理利用copy()和clone()等数据方法。

sequence定义分类

扁平类（flat sequence）：这一类往往只用来组织更细小的粒度，即item实例构成的组

除此之外还需要更多的信息来完善他所需要具备的激励场景，包含：sequence item +constraint 、item的时序信息、在需要我握手的时候等待monitor做出反应。

 flat_seq类可以看作是一个更长的数据包，数据包的具体内容、长度、 地址等信息都包含在flat_seq中。在生成item过程中，通过将自身随机变量作为constraint内容来限定item随机变量，这是flat Sequence的大致处理方法.

层次类（hierarchical sequence）：这一类是由更高层的sequence用来组织底层的sequence，进而让这些sequence或者按照顺序方式，或者按照并行方式挂载到同一sequencer上。

Hierarchical sequence区别于flat sequence的地方在于，它可以使用其他sequence，当然还有item,这么做是为了创建更丰富的激励场景通过层次嵌套关系，可以让hierarchical sequence使用其它 hierarhical sequence、flat sequence和sequence item,这也 就意味着，如果底层的sequemce item和flat sequence的粒度得当，那么用户就可以充分复用这些sequence item来构成形式更加多样的hierarchical sequence 

虚拟类（virtual sequence）：这一类则是最终控制整个测试场景的方式，鉴于整个环境 往往存在不同种类的sequencer和其对应的sequence，我们需要一个虚拟的sequence 来协调顶页层的测试场景。之所以称这个方式为virtual sequence是因为该序列本身并不会固定挂载于某一种sequencer类型上。而是将其内部不同类型sequence最终挂载到不同的目标Seguencer上面。这也是virtual sequence不同于hierarchical sequence的最大一点。

sequencer 和 driver 

 driver同sequencer之间的TLM通信采取了get模式，即由driver 发起请求，从sequencer一端获得item，再由sequemncer将其传递至driver，为什么不用put模式，是因为get模式更加有效率。sequencer和item只应该在合适的时间点产生需要的数据，而于怎么处理数据，则会由driver来实现

端口和方法

为了方便item的传输，ssequencer和driver拥有自己专门的TLM端口：

uvm_seq_item_pull_port#(type REQ=int, type RSP=REQ)

uvm_seq_item_pul_export#(type REQ=int, type RSP=REQ)

uvm_seq_item_pulL_imp #(type REQ=int, type RSPQ, type imp=int)

get模式，由于driver是请求端，所以在driver端例化了两种端口：

uvm_seq_item_pull_port#(REQ,PS)seq_item_port 

uvm_analysis_port #(RSP)rsp_port

对应的sequencer一端作为响应端，相同的也对应了两种的端口：

uvm_seq_item_pull_imp #(REQ,RS, this_type) seq_item _export

uvm_analysis_export #(RSP) rsp_export

一般情况下，用户可以通过匹配第一对TLM端口完成item完整的传送：driver::seq_item_port 和sequencer::seq_item_export。顶层中连接方法：driver::seq_item_port.connect(sequencer::seq_item_export)，主要实现的腮红能是driver与sequencer的request的获取和response的返回

端口支持的方法如下：

REQ和RSP的一致性

由于uvm_sequencer与uvm_driver实际上都是参数化的类，用户在自定义sequencer或者driver的时候， 它们可以使用缺省类型type
REQ=uvm_sequence_item， 以及RSP与REQ类型保持一致。
uvm_sequencer#(type REQ=uvm_sequence_item， RSP=REQ)
uvm_driver#(type REQ=uvm_sequence_item， RSP=REQ)
这有一个潜在的类型转换要求， 即driver得到REQ对象在进行下一步处理时， 需要进行动态的类型转换， 将REQ转换为uvm_sequence_item的子类型才可以从中获取有效的成员数据。
另外一种可行的方式是在自定义sequencer和driver时就标明了其传递的具体item类型， 这样就不用再进行额外的类型转换了。

这样做的好处就是便于统一管理，方便item对象的拷贝、修改和操作。

driver返回response的方法

driver消化完当前的request后，可以通过 item_done(input RSP rsp_arg=null)方法来告知sequence 此次传输已经结束，参数中的RSP可以选择填入，返回相应的状态值；

 driver也可以通过put_response()或者put()方法来单独发送response 。此外发送response还可以通过成对的uvm_driver::rsp_port和uvm_driver::rsp_export端口来完成，方法为um_driver::rsp_port::write(RSP)。

 事务传输过程

在定义sequencer时， 默认了REQ类型为uvm_sequence_item类型， 这与稍后定义driver时采取默认REO类型保持一致。
flat_seq作为动态创建的数据生成载体它的主任务flat_seq：：body(做了如下的几件事情：
1：通过方法create_item() 创建request item对象。
2：调用start_item() 准备发送item。
3：在完成发送item之前对item进行随机处理。
4：调用finish_item() 完成item发送。
5：有必要的情况下可以从driver那里获取response item。

高层环境中还应该进行连接。

通信时序

 sequencer作为sequence和driver之间的桥梁，可以通过sequencer的仲裁功能来解决多个sequence师徒挂载到sequencer的情况。

图中微米可以看出，流向sequencer的都是sequence item，item产生于create_item()，然后通过start_item()，完成随机化以后在获取sequencer的通过权以后，就会执行finish_item()，接下来sequence中的item将穿过sequence人到达driver一侧。driver提取有效信息之后将驱动到DUT上面，完成驱动之后会通过item_done来告诉sequence已经完成了一次传输，完成了一次握手，可以选择将RSP返回给sequence，sequence 也可以调用get_response来等待从driver中获取返回的数据对象。

在多个sequence同时向sequencer发送item的时候，就需要用ID来进行信息表明了，ID信息在sequence创建item的时候就已经赋值了。