IC验证学霸笔记4—UVM-Sequencer和driver
1 Sequencer和Driver
sequencer和item只在合适的时间点产生需要的数据，至于怎么处理数据，则由driver来实现。为了便于item传输，UVM专门定义了匹配的TLM端口供sequencer和driver使用：
由于driver是请求发起端，所以在driver 一侧例化了下面两种端口：
而sequencer 一侧则为请求的响应端，在sequencer 一侧例化了对应的两种端口：
通常情况下，用户可以通过匹配的第 一对 TLM 端口 完成item 的完整传送，即driver::seq_ item_port和sequencer::seq_ item_ export。这一对端口在连接时同其他端口连接方式一样，即通过 driver::seq_item_port.connect(sequencer::seq_item_export)完成。这一种类型的TLM端口支持如下方法：
上面这一类端口功能主要用来实现 driver 与 sequencer 的 request 获取和 response 返回。读者在这里需要了解关于 REQ 和 RSP 类型的一致性， 由于 uvm_sequencer 与 uvm_driver 实际上都是参数化的类：
自定义 sequencer或driver 时， 可以使用默认类型 type REQ = uvm_sequence_item, 以及 RSP 与 REQ 类型保持一致。 这会带来一个潜在的类型转换要求，即 driver 得到 REQ 对象 (uvm_sequence_item) 在进行下一步处理时， 需要进行动态的类型转换， 将 REQ 转换为 uvm_sequence_item 的子类型才可以从中获取有效的成员数据；而另一种可行的方式是在自定义 sequencer 和 driver 时就标明其传递的具体 item 类型， 这样就不用再进行额外的类型转换了。 通常情况下 RSP 类型与 REQ 类型保持一致， 这么做的好处是便于统一处理， 方便 item 对象的复制、 修改等操作。
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端口来完成，方法为 uvm_driver::rsp_port::write (RSP)。
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端口来完成，方法为 uvm_driver::rsp_port::write (RSP)。
事务传输实例：
上面这段例码展示了从 item 定义，到 sequence 定义， 最后到 sequencer 与 driver 的连接。这段精简的代码对于大家理解 driver 从 sequencer 获取 item, 经过时序处理再返回给 sequence 的握手过程很有帮助。 为此做出详细的分析， 帮助大家理清例码中的关键处理：
通信时序
sequence 与 driver 之间握手的代码建议：
• 在多个 sequence 同时向 sequencer 发送 item 时，就需要有 ID 信息表明该 item 从哪个sequence 来， 这个 ID 信息在 sequence 创建 item 时就赋值了，而在到达 driver 以后， 这个 ID 也可以用来跟踪它的 sequence 信息，这就像食品加工从源头就标记二维码一样， 可使运输和使用更加安全。 这个 ID 信息在稍后 driver 返回 response item 时， 需要给定正确的信息，如上面例码通过函数 set_sequence _id()来标记， 这也就使得sequencer 可以根据 ID 信息来分发这些 response item 返回至正确的 sequence 源头。
• 建议在 driver 中通过 clone()方式单独创建 response item, 保证 request item 和 response item 两个对象的独立性。也许有的用户为了 “ 简便 “，使用 request item 后直接修改它的数据并作为要返回给 sequence 的 response item。这么做看来似乎节能环保，但实际一上可能埋下隐患， 一方面延长了本来应该丢进垃圾桶的 request item 寿命， 另一方面无法对 request item 原始生成数据做出有效记录。 所以讲到这里，请大家记住一点， clone()和 copy()是个好习惯，虽然多了那么几行代码， 但无形中却提高了你的代码稳健性，这种代码方式可以帮助减少一些可能的隐患。
• 为了统一，可以不在定义 sequence 或 driver 时指定 sequence item 类型，使用默认类型 REQ = uvm_sequence_item, 但要注意， 在 driver 侧的类型转换， 例如对get_ next_item(REQ)的返回值 REQ 句柄做出动态类型转换，待得到正确类型之后再进行接下来的操作。
• 有的时候如果要复用一些验证 IP, 用户需要修改原有的底层 sequence item。从处于验证复用的角度， 我们建议通过继承于原有 sequence item 的方式定义新的 item 子类， 同时在顶层通过 factory override 的方式用新的 item 类型替换原有的 item 类型。
• 建议在 driver 中通过 clone()方式单独创建 response item, 保证 request item 和 response item 两个对象的独立性。也许有的用户为了 “ 简便 “，使用 request item 后直接修改它的数据并作为要返回给 sequence 的 response item。这么做看来似乎节能环保，但实际一上可能埋下隐患， 一方面延长了本来应该丢进垃圾桶的 request item 寿命， 另一方面无法对 request item 原始生成数据做出有效记录。 所以讲到这里，请大家记住一点， clone()和 copy()是个好习惯，虽然多了那么几行代码， 但无形中却提高了你的代码稳健性，这种代码方式可以帮助减少一些可能的隐患。
• 为了统一，可以不在定义 sequence 或 driver 时指定 sequence item 类型，使用默认类型 REQ = uvm_sequence_item, 但要注意， 在 driver 侧的类型转换， 例如对get_ next_item(REQ)的返回值 REQ 句柄做出动态类型转换，待得到正确类型之后再进行接下来的操作。
• 有的时候如果要复用一些验证 IP, 用户需要修改原有的底层 sequence item。从处于验证复用的角度， 我们建议通过继承于原有 sequence item 的方式定义新的 item 子类， 同时在顶层通过 factory override 的方式用新的 item 类型替换原有的 item 类型。
注：优秀验证学员随堂笔记，已经征求到学生的同意，会持续给牛友们分享！
大家看完记得 一键三连！多多支持
