in my one test case’s build_phase function , i write this code uvm_config_db#(uvm_object_wrapper)::set(this,“m_env.m_vsqr.main_phase”, “default_sequence”, az_vseq::type_id::get() ); to set a default_sequence.
the m_vsqr is a virtual sequencer and the az_vseq is a virtual sequence.
in my env’s conncet_phase function , i connect the virtual sequencer to actual sequencer;
function void connect_phase(uvm_phase phase);
super.connect_phase(phase);
m_vsqr.m_data_sqr = bfm_agent.m_data_sqr;
m_vsqr.m_mdio_sqr = mdio_agent.m_mdio_sqr;
endfunction
I create the actual sequencer in the agent class.
in my sequence code , i raise and drop objects in the pre_body and post_body task.
class az_seq extends uvm_sequence #(seq_item);
`uvm_object_utils(az_seq)
int m_pkt_num = 15;
function new(string name = "az_seq");
super.new(name);
endfunction
virtual task pre_body();
if(starting_phase != null)
begin
starting_phase.raise_objection(this);
end
endtask
virtual task post_body();
if(starting_phase != null)
begin
starting_phase.drop_objection(this);
end
endtask
…
when i run this case , i found the sequence don’t send any sequence_item and finish,the sequence don’t raise and drop any objects.
Does virtual sequencer not support to set this type of default_sequence or my config is not right?
Some recommendations which will make things easier:
Do not use the “default_sequence” method to execute a sequence. This is a legacy carry over from long ago and makes things very difficult to understand and control. Instead, you should start sequences directly from your test. This will give you the ability to coordinate sequence execution which is what you want in a test.
Don’t declare or use p_sequencer. Your virtual sequences should contain handles to the sub-sequencers instead. This ensures portability and prevents being locked into a specific sequencer type.
Don’t use any phases except run_phase(). This will prevent incompatibilities when mixing UVCs from different sources. You can control ‘phasing’ by coordinating your sequences.
Don’t raise/lower objections except in the test itself. Since your test controls the overall execution of the environment, this should be the only place where objections are needed. Adding objections to sub-sequences when they are only run from the top level test just adds unneeded complexity.