Is the Virtual Sequencer Concept a "Legacy Approach" ??

[ifpk454]

I was looking through Mentor's cookbook for UVM and noticed they called the virtual sequencer a "legacy approach".

If this is true, then I wonder if any of the vendors can explain why the virtual sequencer is shown to be the approach to control multiple sequencers in the UVM User's Guide? :mad:

If there is a new and better approach, the virtual sequencer concept should be noted as deprecated in the user's guide. (hopefully, I didn't miss this in the manual....)

Also, is anyone using the virtual sequence approach?

I noticed another thread showing the difference between the two approaches - I think in the end, the virtual sequence approach is more re-usable.

Finally, how do you start a virtual sequence if you don't have a virtual sequencer?

Thanks for the feedback.

[janick]

I can't speak for Mentor nor do I have the full quote, but it could be related to the fact that, in OVM, a virtual sequencer was required because the sequencer was also the sequence library. In UVM, the sequence library is just another sequence so you don't need a virtual sequencer to create a library of virtual sequences.

But to call a virtual sequencer "legacy" is a stretch IMO. A virtual sequencer is required to hold references to sequencer ports should a virtual sequence be a layering sequence. Also, you'll need a virtual sequencer to start virtual sequences as default phase sequences.

Also, in OVM, you needed a component to hold configuration entries: configurable sequences could then call get_config_* on their parent sequencer to configure themselves. With the new configuration DB in UVM, that is no longer strictly necessary. However, starting a virtual sequence on a virtual sequencer is still a good practice as it will provide a scope or a context for the sequence to fetch matching configuration resources. if they are run stand-alone, their would essentially reside in a flat, global name space.

[mea1201]

Mentor shows how you can start a virtual sequence from the environment class, for example. In the run phase task, it creates the virtual sequence, and starts it with null passed to the sequencer argument. Maybe they feel this approach could be simpler than if there is another component (virtual sequencer) to manage. I personally will stick with the virtual sequencer, because I think it encapsulates and separates sequence behavior from the structure in the env better.

[ifpk454]

Thanks - I see that now.

Mentor shows how you can start a virtual sequence from the environment class, for example. In the run phase task, it creates the virtual sequence, and starts it with null passed to the sequencer argument. Maybe they feel this approach could be simpler than if there is another component (virtual sequencer) to manage. I personally will stick with the virtual sequencer, because I think it encapsulates and separates sequence behavior from the structure in the env better.