In reply to chr_sue:
In reply to abasili:
A virtual sequencer is not really required to run virtual sequences. You can use a null object to run a virtual sequence on.
I understand it’s ont required, just like UVM is not required, but my argument is that you have a great deal of opportunities available if you have a virtual sequencer. For one, as demonstrated in my previous post, you can issue a uvm_fatal before you get to start your test. You would need to check for null sequencers anyhow (see coding guidelines here: Virtual Sequencers | UVM Cookbook), but imagine your virtual sequence is just one of many and it is started way after the beginning of the test, it’s going to be a nasty surprise to realize you forgot to configure your bench properly after hours of simulation time.
And virtual sequences are not intended for reuse only agent specific sequences are.
Why not? Virtual sequences can be aware of the environment through their virtual sequencer handle and without the need to pull in the configuration from the config_db at runtime (which might have performance implications), so if well designed they can surely be aware that your environment has 1 eth interface instead of multiple (in the example user cgales brought up).
Here’s a simple example on how you could make your virtual sequence aware of the env:
class ethernet_vseq extends ethernet_base_vseq;
// in this case you virtual sequencer doesn't need to check for all sequencers to be
// built and it's up to the virtual sequence to decide what to do.
task body ();
if (p_sequencer.eth_sqr0 != null)
eth_seq.start(p_sequencer.eth_sqr0);
if (p_sequencer.eth_sqr1 != null)
eth_seq.start(p_sequencer.eth_sqr1);
if (p_sequencer.eth_sqr2 != null)
eth_seq.start(p_sequencer.eth_sqr2);
endtask : body
endclass: ethernet_vseq
So I do not necessarily get your point on virtual sequences not being “intended for reuse”.