Grab, Ungrab lock and unlock for sequences

[kiranbhaskar]

Can i use grab , ungrab or lock and unlock in the body task of my sequence..if not how do i use it ?

Wat is the diff b/w a grab and lock?

wat is the significance of p_sequencer and m_sequencer?

[jadec]

You can use grab in the sequence body or in a parent before the sequence is started (I believe).

grab puts the sequence in the beginning of the queue, lock adds in at it's normal priority.

p_sequencer is a specific sequencer subtype. m_sequencer is the generic type.

[vishal.jain]

Grabbing a sequencer - If sequencer is doing some sequence and based on some external events if user wants sequencer to pause the current sequence, he/she can grab sequencer and start another sequence. Once the started sequence finishes sequencer can resume the normal operation, upon ungrab. This mechanism is generally used to mimic CPU behavior, where CPU is doing a normal bus operation and when interrup comes, CPU needs to suspend the normal operation and start interrupt handling. Once interrupt handling is over, CPU should resume the normal operation from where it was suspended.

p_sequencer is a handle to parent sequence inside sequence. Since sequences are dynamic objects, they cannot be accessed hierarchically. If inside a sequence, one needs to access hierarchical paths (mostly parent sequencer), p_sequencer can be used.

While p_sequencer returns a extended (typed) parent sequencer, m_sequencer returns base sequencer handle type.

In short, if there is a 'field' in extended sequencer, sequence can access that field using 'p_sequencer.field'.

[uwes]

hi,

>wat is the significance of p_sequencer and m_sequencer?

ANY class member prefixed with "m_" is considered a UVM private field/function/task and should be considered as implementation detail and is therefore subject to change without notice.

/uwe

[Erling]

hi,

>wat is the significance of p_sequencer and m_sequencer?

ANY class member prefixed with "m_" is considered a UVM private field/function/task and should be considered as implementation detail and is therefore subject to change without notice.

/uwe

I think this is an unfortunate coding convention. We (and many others) use the m_ prefix to mean member of class (to distinguish from local variables etc). This one of the few coding conventions that actually works in my experience. UVM should have declared private things local, or, when this is not possible, use a coding convention unlikely to clash with something else.

About the p_sequencer: I wonder what naming convention this is. It seems this symbol is there only to maximize confusion. One should think that users could simply call get_sequencer() to get hold of a handle to the sequencer and then introduce their own cast to the required sequencer when it is _understood_ what get_sequencer returns. It seems to me this is just one example of a problem with UVM, and that is that there are too many little helpers that actually does nothing to help, but instead hide and mystify even the simplest of things.

Regards,

Erling

[uwes]

hi,

uvm uses the same convention. m_* just tells you NOT to use it. the reason to have it public accessible is because sv doesnt have friend classes, doesnt allow get_sequencer().somefunction() and uvm_sequencer f=get_sequencer(); f.somefunction() ... is looooonnnnnngggggg

p_* is always used as shortcut for parent_*, same arguments apply for the get_parent().xxxx() doesnt work.

/uwe

[jadec]

Also SV doesn't have inline casting or middle of block declaration, so you'd have to do:

begin my_seqr p; $cast( p, get_sequencer() ); p.somefunction(); end