P_sequencer / m_sequencer

Hello. Can someone please tell me what the “p” in p_sequencer and the “m” in m_sequencer stand for? Additionally, can someone explain the purpose of the p_sequencer?


p - Parent sequencer - Handle for the actual sequencer type

m - m_ should be used to denote a hidden or local variable but is used in this case for a uvm_base_sequencer sequencer handle

p_sequencer can be declared using the `uvm_declare_p_sequencer macro.

But you could also do the following which is equivalent:

my_sequencer p_sequencer;

task body;
assert($cast(p_sequencer, m_sequencer));

p_sequencer could be useful if the actual target sequencer has some methods or variables that you need to access. In most cases m_sequencer has everything you need.

In reply to dave_59:

hi mperyer,
I am new to UVM so might be i am missing something but i couldn’t understand how this would work.
$cast(p_sequencer, m_sequencer)

now my_sequencer (p_sequencer is of type my_sequencer) would be derived from uvm_sequencer. m_sequencer is handle to uvm_sequencer.

If i cast (p_sequencer, m_sequencer) then it is saying that p_sequencer is pointing to the same object (sequencer) to which m_sequencer is pointing.
and m_sequencer points to uvm_sequencer.

Then how can p_sequencer which is derived can access extended methods or variables.
and more over this would compile but would it not be run time error ??

Please help me understand.


In reply to mperyer:

This is a basic principal of inheritance and polymorphism.

m_sequencer is variable of type uvm_sequencer. It can store a handle to any object derived from uvm_sequencer. But you can only reference methods or variables from uvm_sequencer, or any of the classes that uvm_sequencer was extended from.

Lets say you have two classes extended from uvm_sequencer: sqrA and sqrB sqrA has a member A and sqrB has a member B. What would happen if you tried to reference m_sequencer.A, but m_sequencer currently has a handle to an object of type sqrB? Also, what if sqrA and sqB both had variables called C but they were completely different types? SystemVerilog does not let you make this mistake, not does it allow dynamic type switching.

So if you want to reference members or methods that are only in sqrA, you have to reference them with a variable of that class type. It knows that sqrA_h.A is always valid if sqrA_h is not null, and that sqrA_h.M is a fixed type.

1 Like

In reply to dave_59:

Hi Dave,
I am not able to completely get the problem that would occur if we use m_sequencer instead of p_sequencer.
If we try to access variables in sequencer using m_sequencer handle there could be errors ?
Or it would not be possible to access member sequencers through m_sequencer handle in virtual sequence ?


In reply to uvm_user235:

The answers to your questions are “yes” and “yes”

In reply to dave_59 bonny1989:

Thanks Dave and @bonny1989

I have a derived_sequencer which extends from uvm_sequencer, and has one additional property - vif as follows.

class derived_sequencer extend uvm_sequencer;

virtual interface vif;


Then inside my sequence, I use below macro to (as UVM says) 1) declare p_sequencer of derived_sequencer type and 2) cast m_sequencer to p_sequencer.

class my_sequence extends uvm_sequence;



As a result, I can use p_sequencer to access vif which is member of derived_sequencer but NOT in uvm_sequencer.
However, the WEIRD thing now is that now I can use m_sequencer to access vif as well ?! What I thought was only p_sequencer could do the access to vif.

Why is this happening ? In systemverilog the “$cast (dest, source)” would not change the source type.


In reply to dave_59:

Hi dave,

I need your vision to understand p_sequencer use cases:

I learn from various group posts that when we have requirement of modifying the sequencer we can use the p_sequencer of type specific.

I read your para about different sequencer A and B and type casting. So when we have requirement in which we want to add certain methods other than base class, we can use the p_sequencer.

My impression about sequencers are that we never modify the sequencer. At most sometimes we need to get configuration to access which can be access by config db from test.

So I believe m_sequencer + config db always fulfills the requirements.

Is there any specific case where we have to use p_sequencer? Please give idea if you have any specific case where only p_sequencer can work. I understood that m_sequencer is always dose the required job then why the feature of p_sequencer is there. I know there should be but curious to get clear use case.

Also I’m not sure how p_sequencer compromise the reputability?
I need help to understand that.

Detailed answer appreciated. Most of the time your answers helps :)


In reply to Geet:
I think this post offers the best explanations I’ve seen. Do realize that methodologies offer more in the form of guidelines than hard and fast rules.