---

新手上路

• 在UVM世界利用其核心特性，在创建了组件和顶层环境并完成组件之间的TLM端口连接以后，接下来就可以使得整个环境开始运转了；经过一番实践掌握了组件之间的TLM通信方式，开辟了建筑之间的道路、桥梁和河道以后，就可以进入紧张繁忙的物流期了。运转的必要条件是组件之间有事务（transaction）传送，这就同管道连接好需要引入水流一样。
• 如果按交通道路的车流打比方，sequence就是道路，sequence item是道路上行驶的货车，sequencer是目的地的关卡，而driver便是最终卸货的地方。从软件实施层面，货车从sequence一端出发，经过sequencer最终抵达driver；经过driver的卸货，每辆货车也就完成了它的使命。driver对每件到站的货物经过扫描处理，将它们分解为更小的信息量，提供给DUT。

序列组件的互动

• 在这个过程中，不同的角色之间会进行下面这些互动：
  • sequence对象会产生目标数量的sequence item对象。借助于SV的随机化和sequence item对随机化的支持，使得产生的每个sequence item对象中的数据内容都不相同。
  • 产生的sequence item会经过sequencer再流向driver；driver陆续得到的每个sequence item经过数据解析，将数据按照与DUT的物理接口协议写入到接口上，对DUT形成有效激励。
  • 有必要时，driver在每解析并消化完一个sequence item后，它会将最后的状态信息写回sequence item对象再返回给sequencer，最终抵达sequence一侧。
  • 其目的在于，有时sequence需要得知driver与DUT互动的状态，这就需要driver有一个回路将更新过的sequence item对象写回至sequence一侧。
• sequence item是driver与DUT每一次互动的最小粒度内容。
• DUT如果是slave端，driver扮演master去访问DUT的寄存器，那么sequence item需定义的数据信息至少包括访问地址、命令码、数据和状态值，这样的信息在driver取得后，会通过时序方式在interface一侧发起激励送至DUT。
• 按照一般总线做寄存器访问的习惯，这种访问在时序上大致会保持几个时钟周期直至数据传送完毕，而由driver再准备发起下一次操作。
• 用户除了可以在声明sequence item时添加必要的成员变量，也可以添加对这些成员变量进行操作的成员方法。这些添加的成员变量，需充分考虑在通过sequencer传递到driver前是否需要随机化。
• 对于sequence，它会产生多个sequence item，也可产生多个sequence。从产生层次来看，sequence item是最小粒度，它可以由sequence生成，而相关sequence也可以进一步组织继而实现层次化，最终由更上层的sequence进行调度。sequence可以看做是产生激励内容的载体。
• 在sequence与driver之间起到桥梁作用的是sequencer。由于sequencer与driver均是component组件，它们之间的通信也是通过TLM端口实现。
• driver与sequencer之间的TLM通信参数即sequence item类。由于这一限制，使得sequencer到driver的传输数据类型不能改变，同时与sequencer挂载的sequence创建的sequence item类型也应为指定类型。
• 激励驱动链的最后关卡是driver；常见用法是driver消化完一个sequence item报告给sequencer和sequence，同时再请求消化下个sequence item。
• driver看起来永远喂不饱，同时还又很挑食。在消化每个sequence item之前，该item中的数据是已经随机化好的，所以每个item内容一般都各不相同。
• driver自己并不会轻易修改item中的值，它会把item中的数据按照与DUT的物理协议时序关系驱动到接口上面。
• 例如对一个标准的写操作，driver不但需按照时序依次驱动地址总线、命令码总线和数据总线，还应该等待从端的返回信号和状态值，这样才算完成一次数据写传输。

继承关系

• uvm_sequence_item和uvm_sequence都基于uvm_object，它们不同于uvm_component只应在build阶段作为UVM环境的“不动产”进行创建和配置，而可以在任何阶段创建。
• 这种类的继承带来的UVM应用区别在于：
  • 由于无法判定环境在run阶段什么时间会创建sequence和将其挂载到sequencer上，所以无法通过UVM环境结构或phase机制识别sequence的运行阶段。
  • 由于uvm_object独立于build阶段之外，这使得用户可以有选择地、动态地在合适时间点挂载所需要的sequence和item。
  • 考虑到uvm_sequence和uvm_sequence_item不处于UVM结构中，所以顶层做配置时，无法按照层次关系直接配置到sequence中。
  • sequence一旦活动起来则必须挂载到一个sequencer上，这样sequence可依赖于sequencer的结构关系，间接通过sequencer获取顶层的配置和更多信息。

提示

• 常规的认知中，用户可能更愿意将时序控制的交由sequence。这种从sequence产生item，将item通过sequencer推送给driver的方式，实际上有一些“越俎代庖”的嫌疑。
• 如果明确划分责任的话，sequence应该只负责生成item的内容，而不应该控制item消化的方式和时序，而驱动激励时序的任务应当由driver来完成。
• item的生成和传送，并不表示最终的接口驱动时序，决定因素还包括sequencer和driver。sequencer之所以作为“路由”管道设立在sequence和driver之间，看重的是它的两个特点：
  • sequencer作为一个组件，它可以通过TLM端口与driver传送item对象。
  • sequencer在面向多个并行sequence时，它有充分的仲裁机制来合理分配和传送item，继而实现并行item数据传送至driver的测试场景。

总结

• 数据传送机制采用的是get模式而不是put模式。在TLM传输中介绍过两种典型的数据传送场景，如果是put模式，那么应该是sequencer将数据put至driver；如果是get模式，那么应当是driver从sequencer获取item。
• 之所以选择get模式，UVM是基于下面的考虑：
  • 如果是get模式，那么当item从sequence产生，穿过sequencer到达driver时就可以结束该传输（假如不需要返回值的话）。而如果是put模式，则必须是sequencer将item传送至driver，同时必须收到返回值才可以发起下一次的传输。这从效率上看，是有差别的。
  • 如果需要让sequencer拥有仲裁特性，可以使多个sequence同时挂载到sequencer上面，那么get模式更符合“工学设计”。因为driver作为initiator，一旦发出get请求，它会先通过sequencer继而获得仲裁后的item。