路科验证(Rocker IC)专注于验证系统思想和前沿工程资讯,拥有一支活跃的技术原创团队,著有《芯片验证漫游指南》一书,致力为高校微电子相关专业学生与IC从业人员提供技术食粮。 您可以在手机移动端同步关注微信订阅号“路科验证”或是登录网页www.rockeric.com了解澳门皇冠APP资讯。如果您需要联系我们,请发送邮件至 rocker.ic@vip.163.com 。

UVM序列篇之四:sequencer和driver

上一篇 / 下一篇  2018-02-04 14:15:17 / 个人分类:验证系统思想

我们之前在《新手上路》中谈过,driver同sequencer之间的TLM通信采取了get模式,即由driver发起请求,从sequencer一端获得item,再由sequencer将其传递至driver。按照TLM通信模式的描述, TLM通信可以绘制为下图:


作为driver,它往往是一个“永动机”,胃口很大的家伙,永远停不下来,只要它可以从sequencer获取item,它就能一直跳下去,根本停不下来。这同我们之前《sequence和item》中树立的思想一致,即sequencer和item只应该在合适的时间点产生需要的数据,而至于数据怎么被处理,则应该由driver来实现。为了便于item传输,UVM专门定义了匹配的TLM端口供sequencer和driver使用:

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

  • uvm_seq_item_pull_export #(type REQ=int, type RSP=REQ)

  • uvm_seq_item_pull_imp #(type REQ=int, type RSP=REQ, type imp=int)


由于driver是请求发起端,所以在driver一侧例化了下面的两种端口:

  • uvm_seq_item_pull_port #(REP, RSP) seq_item_port

  • uvm_analysis_port #(RSP) rsp_port


而sequencer一侧则为请求的响应端,在sequencer一侧例化了与上面对应的两种端口:

  • uvm_seq_item_pull_imp #(REQ, RSP, 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)完成。而这一种类型的TLM接口主要支持如下的方法:

  • task get_next_item(output REQ req_arg):采取blocking的方式等待从sequence获取下一个item。

  • task try_next_item(output REQ req_arg):采取nonblocking的方式从sequencer获取item,如果立即返回的结果req_arg为null,则表示sequence还没有准备好。

  • function void item_done(input RSP rsp_arg=null):用来通知sequence当前的sequence item已经消化完毕,可以有选择性地传递RSP参数,返回状态值。

  • task wait_for_sequences():等待当前的sequence直到产生下一个有效的item。

  • function bit has_do_available():如果当前的sequence准备好而且可以获取下一个有效的item,则返回1,否则返回0。

  • function void put_response(input RSP rsp_arg):采取nonblocking方式发送response,如果成功返回1,否则返回0。

  • task get(output REQ req_arg):采用get方式获取item。

  • task peek(output REQ req_arg):采用peek方式获取item。

  • task put(input RSP rsp_arg):采取blocking方式将response发送回sequence。


上面的这一类接口功能是主要用来做request获取和response返回的。读者们在这里需要了解的是,关于REQ和RSP类型的一致性。由于uvm_sequencer与uvm_driver实际上都是参数化的类:

  • uvm_sequencer #(type REQ=uvm_sequence_item,RSP=REQ)

  • uvm_driver #(type REQ=uvm_sequence_item, RSP=REQ)


用户在自定义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)来完成。


接下来,我们就sequencer和driver的这一典型的item传输给出一段例码,帮助读者理解整个传输过程的起点、各个重要节点以及最后的终点。读者一旦理解了这其中的朴素原理,那么这两个组件之间的握手也就不再那么神秘了。



输出结果:


上面这段例码给出了从item定义,到sequence定义,最后到sequencer与driver的连接。这段精简的代码对于读者理解driver从sequencer获取item,经过时序处理,再返回给sequence很有帮助。为此,我们做出详细的分析,帮助读者理清例码中的关键处理:

  • 在定义sequencer时,默认了REQ类型为uvm_sequence_item类型,这与稍后定义driver时采取默认REQ类型保持一致。

  • flat_seq作为动态创建的数据生成载体,在它的主任务flat_seq::body()中做了如下的几件事情。

    • 通过方法create_item()创建request item对象。

    • 调用start_item()准备发送item。

    • 在完成发送item之前对item进行随机处理。

    • 调用finish_item()完成item发送。

    • 有必要的情况下可以从driver那里获取response item。

  • 在定义driver时,在它的主任务driver::run_phase()中也应通常做出如下的处理:

    • 通过seq_item_port.get_next_item(REQ)从sequencer获取有效的request item。

    • 从request item中获取数据,进而产生数据激励。

    • 对request item进行克隆生成新的对象response item。

    • 修改response item中的数据成员,最终通过seq_item_port.item_done(RSP)将response item对象返回给sequence。

  • 对于uvm_sequence::get_response(RSP)和uvm_driver::item_done(RSP)这种成对的操作,是可选的而不是必须的,即用户可以选择uvm_driver不返回response item,同时sequence也无需获取response item。

  • 在高层的环境中,应该在connect phase中完成driver到sequencer的TLM端口连接,比如在例码中drv.seq_item_port.connect(sqr.seq_item_export)。

  • 在完成了flat_seq、sequencer、driver和env的定义之后,到了test1层,除了需要考虑挂起objection防止退出,便可以利用uvm_sequence类的方法uvm_sequence::start(SEQUENCER)来实现sequence到sequencer的挂载。


上面是对于例码重点的详细解释,在介绍flat_seq::body()时,例码实际上是将以往的`uvm_do等常用的宏进行了拆解,这些常用的sequence/item的宏和主要方法我们也将在下一节《sequencer和sequence》中为大家介绍。


无论是sequence还是driver,它们与之通话的对象都是sequencer。多个sequence都试图要挂载到同一个sequencer上时,涉及sequencer的仲裁功能,这也会在下一节谈到。我们本节重点分析sequencer作为sequence与driver之间握手的桥梁,是如何扮演好这一角色的。在下面的图中,我们将抽取去这三个类的主要方法,利用时间箭头演示出完整的TLM通信过程。


在这张图中,读者们可以结合上面的例码,找到各个关键节点的处理方式。

  • 对于sequence而言,无论是flat sequence还是hierarchical sequence,再进一步切分的话,流向sequencer的都是sequence item,所以就每个item的“成长周期”来看,它起始于create_item(),继而通过start_item()尝试从sequencer获取可以通过的权限。

  • 对于sequencer的仲裁机制和使用方法我们暂且略过,而driver一侧将一直处于“吃不饱”的状态,如果他没有了item可以使用,将调用get_next_item()来尝试从sequencer一侧获取item。

  • 在sequencer将通过权限交给某一个底层的sequence前,目标sequence中的item应该完成随机化,继而在获取sequencer的通过权限后,执行finish_item()。

  • 接下来,sequence中的item将穿过sequencer,到达driver一侧,这个重要节点标志这第一次sequencer充当桥梁的角色已经完成。driver在得到新的item之后,会提取有效的数据信息,将其驱动到与DUT连接的接口信号上面。

  • 在完成驱动后,driver应当通过item_done()来告知sequence已经完成传送,而sequence在获取该消息后,就表示正式完成了这一次item的握手传输。在这次传递中,driver可以选择将RSP作为状态返回值传递给sequence,而sequence也可以选择调用get_response(RSP)等待从driver一侧获取返回的数据。


最后,在结束本节之前,是我们关于sequencer与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的方式定义子类,同时在顶层通过factory override的方式用新的sequence item替换原有的sequence item类型。


下一节课《sequencer和sequence》,我们将为读者们提供常用的sequence/item挂载sequencer的方法/宏,同时探讨sequencer的arbitration机制。


谢谢你对路科验证的关注,也欢迎你分享和转发真正的技术价值,你的支持是我们保持前行的动力。


5

5

TAG:

 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

路科验证

路科验证

路科验证(Rocker IC)专注于验证系统思想和前沿工程资讯,拥有一支活跃的技术原创团队,为高校微电子相关专业学生与IC从业人员提供技术食粮。 您可以在手机移动端同步关注微信订阅号“路科验证”。如果您需要联系我们,请发送邮件至 rocker.ic@vip.163.com 。

日历

« 2018-08-17  
   1234
567891011
12131415161718
19202122232425
262728293031 

数据统计

  • 访问量: 145446
  • 日志数: 243
  • 建立时间: 2016-06-25
  • 更新时间: 2018-08-14

RSS订阅

Open Toolbar
博聚网