In reply to cuonghle:
Setting the sequencer priority only changes the order of traffic to driver, it does not make a sequence stop sending stimulus (pause), Then, I think the simplest way is controlling the generation in sequence if you want to pause/unpause traffic for a particular sequence.
I forgot about the case where only the paused sequence is trying to send items. Still, QoS is a form of arbitration, so putting it in the sequencer is a natural fit. If this scenario requires that the paused sequence stay paused, even when there are no other sequences trying to send items, then the UVM_SEQ_ARB_STRICT_* modes won’t work.
User defined arbitration ( UVM_SEQ_ARB_USER ) could be added to the sequencer to handle this without requiring adding anything into the sequences. The advantage of that is, you can write sequences that aren’t even aware the QoS mechanism exists. Any sequence ran on that sequencer would be affected. You still need to have some env component altering the priority ( pause state ) of the sequences.
If you go with cuonghle’s sequence based approach, you might implement is_relevant() and wait_for_relevant(). That way you don’t have to put pausing code explicitly in the sequence body(). Implement them in a base sequence shared by all QoS sequences.
In reply to chr_sue:
Note, the traffic between sequencer and driver is determined by the driver NOT the sequencer.
The sequencer doe NOT send any transactionn to the driver. The driver is polling a seq_item. It is just easy to implement your behavior in the driver.
I don’t follow how the driver can implement a QoS arbitration scheme. The driver can stop getting the next item, but if there are multiple sequences trying to send items at different QoS level, such a mechanism will block items from all sequences.
-Ryan