Why should we avoid virtual sequencer?

Hello All,

I was going through UVM cookbook provided in this website and I saw a statement “The recommended way to implement a virtual sequence is for it have handles for the target sequencers on which the sub-sequences run. The legacy approach is to use a virtual sequencer …” (page 191 - “controlling stimulus generation on more than one driver” paragraph). So, does this mean that we can avoid virtual sequencer all together and we’ll never have to use it? If so, is there a reason why virtual sequencer is not recommended?

Thanks

In reply to szy0014:

I’ll give you reason why I avoid virtual sequencer.

  • You need to create virtual sequence for the virtual sequencer + sub sequences in virtual sequence have fixed sequencer on which they runs.

  • This means, one needs to make way around if she’s to have multiple instance of a agent component, and previously created sub-sequences cannot be used as sequencer for them is fixed.

  • Even if one wants to start a sequence on a sequencer, virtual sequence containing the sequence is needed thus increasing one more layer of sequence(virtual sequence).

Advantage of using only virtual sequence(and not virtual sequencer) is that one can contain group of sub-sequences in a higher layer called virtual sequence and start this virtual sequence on a ‘null’ sequencer.

  • Optionally one can have all sequences(sub-sequences) called in test so as to avoid even virtual sequence.
  • Benefit here is to group set sub-sequences in a virtual sequences if they are used frequently, so to avoid calling each sequence separately from test.

In reply to szy0014:
There is no real reason to avoid virtual sequencers. Both approaches haveing the
(1) sub-sequencer handles in the virtual sequencer
(2) sub-sequence handles in the virtual sequence
are legal and there is no benefit for one of them.

In reply to szy0014:

From UVM Rapid Adoption: A Practical Subset of UVM - Sutherland and Fitzpatrick

There is no need to include a virtual sequencer in either the test or the environment. All the virtual sequencer does is add more inter-component connections and complexity to the environment, with no benefit of portability nor flexibility.

In reply to MayurKubavat:

Hi,

I’m struggling in understanding the limitation of the virtual sequencer. Can you provide a simple example code to demonstrate how virtual sequencer cannot be vertically reused while virtual sequence can help in that matter?

In reply to abdus_k:

A virtual sequencer will only contain handles to other sequencers. You can not modify any of the active phases as the sequencer relies on the base class functionality.

To use a virtual sequencer, you will need to write the code to define the virtual sequencer, instantiate the virtual sequencer, assign the sub-sequencer handles and then write the virtual sequence code to reference the virtual sequencer.

All of this extra coding does nothing except to add to the complexity of the environment.

Instead, you should put all of the sequencer handles into a base virtual sequence class, and run the virtual sequence on a ‘null’ sequencer handle.

In reply to cgales:

Using a virtual sequencer is not a question of increasing the complexity of your UVM environment.
In the virtual sequencer you have to implement handles to your agent’s sequencer. If you do not use a virtual sequencer you need these handles in your virtual sequence. Now it is up to you to decide what you like. Inmy eyes it is a question of taste or coding guidelines.