Starting a UVM Sequence

UVM
1

Hello.

As far as I know, there are 2 ways of starting a sequence in UVM testbench.

  1. Starting a sequence with default_sequence (implicit)
// build phase of uvm test
function void build_phase(uvm_phase phase);
  super.build_phase(phase);
  env = my_env::type_id::create("env", this);
  // starting a sequence with default_sequence
  uvm_config_db#(uvm_object_wrapper)::set(this, "env.agent.sequencer.run_phase", "default_sequence", my_sequence::type_id::get());
endfunction: build_phase
  1. Starting a sequence with start method (explicit)
// run phase of uvm test
task run_phase(uvm_phase phase);
  super.run_phase(phase);
  phase.raise_objection(this);
  // starting a sequence with start method
  seq.start(env.agent.sequencer);
  phase.drop_objection(this);
endtask: run_phase

I see many people recommend using the start method to start a sequence, but I am not sure why.
Can anyone help me with this?

Thanks.

2

In reply to Jung Ik Moon:

I see many people recommend using the start method to start a sequence, but I am not sure why.
Can anyone help me with this?

Here’s my thoughts. (Please correct my if any of below is wrong.)

  1. If default_sequence is used to start a sequence, the sequence will be started automatically. On the other hand, with the start method, the sequence does not actually start until I call the start method. So it gives more flexibility when dealing with multiple sequences to form one big sequence.

  2. If the sequence is started with default_sequence, raising and dropping the objection should be located in the sequence. On the other hand, when started with the start method, raising and dropping the objection can be placed in the test. (Of course, it can also be placed in the sequence.) I guess this difference could be a hint to one of the reasons.

Could there be any other reason?

3

Actually, I prefer not to use the default_sequence for the reasons you mention. Instead, we recommend that you use the uvm_env to define and start any “background” sequences that you might want to run, and then use the uvm_test to

  1. override the background sequence using the factory
  2. use uvm_config_db to modify any parameters that the background sequence might use
  3. start any test-specific sequences and/or virtual sequences

This gives you all the control you need, as well as the visibility into what’s actually happening. Please see the Advanced UVM Video Course module on “The Proper Care and Feeding of Sequences” for more detail.

4

In reply to tfitz:

Actually, I prefer not to use the default_sequence for the reasons you mention. Instead, we recommend that you use the uvm_env to define and start any “background” sequences that you might want to run, and then use the uvm_test to

  1. override the background sequence using the factory
  2. use uvm_config_db to modify any parameters that the background sequence might use
  3. start any test-specific sequences and/or virtual sequences

This gives you all the control you need, as well as the visibility into what’s actually happening. Please see the Advanced UVM Video Course module on “The Proper Care and Feeding of Sequences” for more detail.

Hello, Tom.
Thanks for the tip and, of course, the video series.
I will consider starting a sequence in uvm_env.
Thanks.

5

In reply to tfitz:

Hi Tom,

Any benefit when we start a sequence in uvm_env instead of uvm_test?

Thanks,
Chris.

6

In reply to cuonghl:

Not really, but since the uvm_test instantiates and customizes the uvm_env, the test is the ultimate arbiter of what happens. That’s why I put background sequences in the uvm_env, since they will run in any instance of the uvm_env without having to worry about them in the test. Then you can use the test to start any targeted sequences. Remember, it doesn’t matter where you call sequence.start from. It’s more important that you tell the sequence on which sequencer to run.