Passing the register model handle to the sequence

In the Cookbook example related to the register sequences, the proposed approach is to have the sequence fetch the handle from the config object, directly in the config_db. This is all fine and works as intended.

Nonetheless I have an itch to scratch. Why the regmodel is passed through the config, while in virtual sequences the sequencer handle is taken from the virtual sequencer (typically p_sequencer)? A virtual sequencer will likely have access to the configuration object anyhow, so why bother with yet another config_db access when the sequencer can simply get it from the virtual sequencer? The benefit in this second approach would benefit vertical reuse, since there’s no shortcut between the low level environment and the top level environment (where the model resides).

I could speculate that from an OOP perspective the second approach would be more in line with the “open-closed principle” by introducing a clear “contract” between a sequencer and a sequence with a separation of responsibilities. Just like a virtual sequencer takes the responsability to get the sequencers handles needed to the virtual sequence, it also takes care of getting the register model needed by the sequence.

Can anyone comment?

In reply to abasili:

The Cookbook recommends using a stand-alone sequence not connected to a vertical sequencer for better portability.

In reply to dave_59:

Thanks for the reference, unfortunately the only sentence referencing to the preferred approach is the following:

An alternative methodology for running virtual sequences is to use a virtual sequencer, which is a uvm_sequencer which contains the handles for the target sequencers. In this methodology, the virtual sequence is started on the virtual sequencer and it gets the handles for the target sequencers from the virtual sequencer. The limitation of this approach is that it is a fixed implementation which is very tightly coupled to the local hierarchy of an env and this adds complications with vertical reuse.

I don’t get the argument actually. The tight coupling happening in the sub environment is not an issue, since top environment will reuse the sub environment as is or extend it. Is there any concrete example/ situation where such an approach could be problematic? Maybe any reference to a paper highlighting this drawback more formally?

The authors of “Using UVM Virtual Sequencers & Virtual Sequences” seem to be very convinced of their proposal :-)