如何配置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 LockingMechanism

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。

03Sequence Interrupt

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

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

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

审核编辑：刘清