下冰雹 · 9月22日 · 北京市

SystemVerilog | UVM | Sequence的仲裁和锁定,还有要避开UVM的bug

作者:JK ZHAN,本文首发于微信公众号“芯片学堂”(ID:HelloICTalking),芯片技术文章分享平台。

该系列前面的几篇文章介绍了driver和sequencer的握手机制、sequence的基本使用方法、sequence_item的产生、sequence的启动、多个sequence的执行控制、virtual sequence以及sequence library的应用等,欢迎读者翻阅。

image.png

本文依然是比较多的干货,也偏保姆级,介绍Sequence之间发生竞争的时候,我们需要或者说可以做些什么,包括如何配置sequence的仲裁算法和优先级、如何让sequence占用sequencer(这个地方UVM 1.2有个bug),以及如何中断sequence的执行。

01 Arbitrary

在UVM中,多个sequence可以同时被绑定到相同的sequencer并启动。这种测试场景在实际中是存在的,比如在模拟同一个总线master口上的不同类型的数据流时,可以将符合这些不同类型的数据流的sequence绑定到同一个sequencer,并启动它们,以构造出复杂的测试场景。
image.png
这样一来,在验证环境运行中就会出现竞争的问题,当多个sequence同时企图向下游发transaction的时候,sequencer需要能够决定处理这些transaction的顺序。而给出答案的,是sequencer内建的仲裁机制。

下面给出一个简单的UVM例程:例程同时启动三个sequence(seq_0, seq_1, seq_2),它们会往同一个sequencer发transaction,并且在启动的时候还分配了权重值(start方法的第三个参数),每个sequence会循环发送4个transaction。在Env中例化sequencer和driver,并完成连接。例程中在driver拿到transaction之后,会根据transaction的成员变量id和index打印出来当前transaction产生自哪个sequence,以及是循环的第几次。
image.png

仿真结果如下,可以看得出来在没有配置仲裁算法的情况下,即使我们为sequence都分配了权重值,sequencer对三个sequence还是“雨露均沾”:
image.png
实际上,UVM给我们预设了六种仲裁算法供选择,同时保留了用户自定义的接口。默认情况下,使用的仲裁算法是UVM_SEQ_ARB_FIFO,严格按照先进先出的原则来做选择,所以才会出现上面说的,仿真结果跟权重值没有关系。关于仲裁算法,需要根据实际测试场景来做出选择。
image.png
那么如何配置仲裁算法?在代码中,可以通过调用sequencer的方法set_arbitration()来对仲裁算法进行配置。比如在上面例程env_demo类的build_phase函数的最后一行,可以加上sqr.set_arbitration(UVM_SEQ_ARB_WEIGHTED)来配置仲裁算法,仿真结果我贴在下面,可以看到,我们分配的权重值开始起作用了:

image.png

02 Locking Mechanism

Locking mechanism指的是sequence对sequencer的占用,sequence可以优先获得sequencer的使用权限,并且在它自己释放之前,其他sequence无法通过该sequencer和driver发送transaction。

Sequence抢占功能同样来源于测试场景的需求,应用于当有某个sequence需要优先并独占sequencer的时候,比如对中断(interrupt)的处理。如下图所示,当sequence_2占用了sequencer之后,其他sequence在sequence_2释放之前将无法联系上sequencer。

image.png

UVM提供了两种抢占方法:lock和grab。lock方式会等待仲裁机制正常调度到该sequence(即将请求放在仲裁队里的最后),并占用该sequencer直到sequence调用unlock()来解锁;grab方式则会使该sequence在下一轮仲裁中被执行(即将请求放在仲裁队列的最前面),并占用该sequencer直到sequence调用unlock()和ungrab()。

Sequencer被某个sequence抢占了之后,我们可以通过调用它的成员方法来获取当前的状态信息。比如,可以在sequence的body()里面使用m_sequencer.is_grabbed()函数来看当前sequencer是不是被谁锁住了;还可以使用m_sequencer.current_grabber()函数来获得当前锁住sequencer的sequence句柄;还有其他函数可以使用,具体可以参考UVM的手册。

image.png
关于lock和grab的使用在其他地方有很多示例代码,这里将基于上面的例程,展示UVM 1.2潜藏的一个bug。先在上述代码中seq_demo_0类的body()任务的入口和出口处,分别加上lock()和unlock(),如上图所示,然后进行仿真,就会发现:最终只有seq_0抢先锁住了sequencer,虽然我们在body()的最后调用了unlock(),但是seq_1和seq_2在seq_0结束之后依然抢不到锁,仿真最后结束在UVM timeout,如下图:

image.png

这是一个UVM的bug,问题的根源在uvm_sequencer_base的源码中,当有多个sequence在lock_list队列里面时,调用m_wait_for_available_sequence()方法获取sequence句柄会使代码挂死。该UVM issue已经有人提交到了accellera,具体可以参见参考资料2。这个bug在UVM 2017-1.1或者UVM 2020中可能已经修掉了,有兴趣的读者可以自己试一下。鉴于目前有很多代码是基于UVM 1.2构建的,用户在使用lock/grab的时候需要特别注意这个bug。

03 Sequence Interrupt

在处理器等数字系统中,通常硬件中断都是由某个信号脉冲或者电平来触发,并通过中断控制仲裁之后,由控制器发送给处理器进行处理。

在Sequence中的中断操作也类似,分两部分实现:第一部分是将通过虚拟接口监视中断源信号的变化,以实现软硬件的隔离;第二部分是在主sequence中发起一个监视进程(monitor process),在等到中断到来之后启动用作中断处理的sequence。

image.png

另外,Sequence一旦被启动,通常不会去想着将它异常结束(通过seq.kill()或者seqr.stop_sequences()调用),否则我们需要更加复杂的实现去查看当前driver是否空闲,以确保sequencer跟driver的握手机制不出问题。如果有必要将sequence提前结束,建议在sequence内部去做条件判断和处理。

作者:JKZHAN
文章来源:芯片学堂

推荐阅读

更多IC设计技术干货请关注IC设计技术专栏。
迎添加极术小姐姐微信(id:aijishu20)加入技术交流群,请备注研究方向。
1 阅读 159
推荐阅读
关注数
9218
内容数
858
主要交流IC以及SoC设计流程相关的技术和知识
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息