m_sequencer vs p_sequencer

[krb]

Hi,

Can any one tell me the difference between m_sequencer and p_sequencer please ?

In the context of normal sequences and virtual sequences.

Many thanks,

Karthik.

[Tedd]

Hi Karthik,

They are the same thing/handle, m_sequencer is assume as protected field, and p_sequencer is a global access field.

Thanks.

BR,

Tedd

[Roman]

Hi Karthik,

m_sequencer : this enables sequence item and sequences to access the sequencer and use services it make avaliable. it's set automatically when you call start();

p_sequencer : it need a declaration , implement a function to set its value. `uvm_declare_p_sequencer will do the things.

[krb]

Hi Tedd, Roman,

Thanks for the answers.

I am migrating code from uvm1.0ea to uvm1.0p1. And I have a virtual_sequencer and associated sequences. In the current code (ea version) I use p_sequencer to run the sequences on:

eg:

`uvm_do_on(iq_srfmem_read_order, p_sequencer.iq_seqr)

I am not sure what the best way is to migrate this code.

Should I use the `uvm_declare_p_sequencer macro and use the p_sequencer or is there a way to do the same with m_sequencer ?

Thanks for the help,

Karthik.

[krb]

Hi,

looking at the src files from uvm1.o-p1,

m_sequencer is indeed protected and p_sequencer is not.

Looking at the `uvm_declare_p_sequencer definition:

`define uvm_declare_p_sequencer(SEQUENCER) \

SEQUENCER p_sequencer;\

virtual function void m_set_p_sequencer();\

super.m_set_p_sequencer(); \

if( !$cast(p_sequencer, m_sequencer)) \

`uvm_fatal("DCLPSQ", \

$psprintf("%m %s Error casting p_sequencer, please verify that this sequence/sequence item is intended to execute on this type of sequencer", get_full_name())) \

endfunction

p_sequencer point to the same sequencer as m_sequencer, but is declared as a USER defined SEQUENCER rather than the uvm_sequencer_base.

So I guess using the `uvm_declare_p_sequencer macro is the only way I can use virtual sequencers and sequences.

Thanks for the help.

[Roman]

Hi Karthik,

I think you could use the `uvm_sequencer_utils(my_virtual_seqr) as well. The `uvm_update_sequence_lib macro need to be used in the constructor when you defined a virtual sequencer(extend uvm_sequencer).

[krb]

Aren't these sequencer_ultils depreciated in uvm1.0-p1 ?

[Roman]

it's in the uvm_deprecated_defines.svh . This macro indeed exists in the uvm1.0-p1 release. I guess it may be removed in next release.

[KathleenMeade]

Hi There,

Please use:

`uvm_object_utils(seq_name)

`uvm_declare_p_sequencer(sequencer_name)

if you need to access the sequencer information (or any of it's hierarchy information) from a sequence.

I believe m_sequencer should not be used as it is protected.

Kathleen

[krb]

Hi Kathleen,

Thanks for the advice. We are using the macros you mentioned, as the old uvm1.0ea ones are marked as depreciated.

krb

[uwes]

hi,

1. m_* members (fields+methods) are considered internal UVM fields and should never be used. they are implementation details, can change at any time and without any notification. i think the technical reason is that SV does not have 'friends' like c++ has.
   
2. p_* are normal members and can be used.