In reply to chr_sue:
In reply to abs:
It is not visible how you are coordinating the function of different agents using tasks.
Well, this section of the code might be what I call ‘coordination’:
/////////////////////////////////////////////////////////////////////////////
// Power up circuit
pwr_up_seq.start(env.power_agt.power_sqr);
//...
`WAIT_MS(3);
my_loop_seq.start(env.if_agt.sequencer);
/////////////////////////////////////////////////////////////////////////////
phase.drop_objection(this);
where the two sequences are run on two different sequencers with some timing between them.
Maybe I’m using the term ‘coordination’ in the wrong way, what I mean by it is the ability to orchestrate different sequences of ‘transactions’ onto different interfaces of my DUT, in order to create the required scenario.
Obviously one disadvantage of using the above mentioned approach is that you cannot easily reuse the testcase in the event of a different scenario. While using the virtual sequence(r) we could simply extend the base class and override the build_phase() to select a different virtual sequence, in the above methodology you would need to copy the testcase and change the run_phase itself, maybe also adding some extra ‘utility tasks’ defined in the base class.
Does this argument hold? Any other argument in favor of using virtual sequences? Maybe the real question would be: what can be done with virtual sequences(ers) that cannot be done with the approach described in the OP?