In reply to cliffc:
I consider creating an agent sequencer as a waste of time which can be better spent developing other parts of your environment. For an agent sequencer, you need to create the file, add the template code, add the `include to your package file, and then debug any issues, for no additional benefit. In the space of your `include line, you can have a simple typedef which meets all the requirements for your agent. Additionally, I have seen developers add a run_phase() to their sequencer out of habit, and then debug why their environment isn't working correctly.
I consider creating a virtual sequencer to be a similar waste of time and recommend running a virtual sequence on a null sequencer. In a virtual sequence, you only have handles to the required sequencers based upon the types of sequence items you are generating. Since a test is always environment specific, it knows all the paths of the sequencers, so you can reuse test sequences from sub-environments very easily.
An example of flexibility is a using a test sequence which requires a single Ethernet port sequencer in an environment that has multiple Ethernet agents. The test can now randomly select one of the Ethernet agents to be utilized and assign the sequencer handle to the sequence. If you use a p_sequencer which contains multiple Ethernet sequencer handles, you would have to somehow account for which sequencer handle to use from the p_sequencer.
Assigning sequencer handles to a sequence has the same amount of complexity as adding sequencer handles to a p_sequencer, and can be accomplished with helper functions in your base test and base test sequences. When you are writing tests and test sequences, the overall hierarchy is generally static with minimal changes at that point.
