如何配置sequence的仲裁算法和优先级

电子说

1.2w人已加入

描述

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

01 Arbitrary

在UVM中,多个sequence可以同时被绑定到相同的sequencer并启动。这种测试场景在实际中是存在的,比如在模拟同一个总线master口上的不同类型的数据流时,可以将符合这些不同类型的数据流的sequence绑定到同一个sequencer,并启动它们,以构造出复杂的测试场景。

中断

这样一来,在验证环境运行中就会出现竞争的问题,当多个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,以及是循环的第几次。

中断

仿真结果如下,可以看得出来在没有配置仲裁算法的情况下,即使我们为sequence都分配了权重值,sequencer对三个sequence还是“雨露均沾”:

中断 实际上,UVM给我们预设了六种仲裁算法供选择,同时保留了用户自定义的接口。默认情况下,使用的仲裁算法是UVM_SEQ_ARB_FIFO,严格按照先进先出的原则来做选择,所以才会出现上面说的,仿真结果跟权重值没有关系。关于仲裁算法,需要根据实际测试场景来做出选择。

中断

那么如何配置仲裁算法?在代码中,可以通过调用sequencer的方法set_arbitration()来对仲裁算法进行配置。比如在上面例程env_demo类的build_phase函数的最后一行,可以加上sqr.set_arbitration(UVM_SEQ_ARB_WEIGHTED)来配置仲裁算法,仿真结果我贴在下面,可以看到,我们分配的权重值开始起作用了:

中断

02 Locking Mechanism

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

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

中断

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的手册。

中断

关于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,如下图:

中断

这是一个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。

中断

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



审核编辑:刘清

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分