Portable stimulus - comp and this

UVM
,
1

This question is on one feature mentioned in the early adapter release of the new portable stimulus specification standard.

Refering to examples 26, 30 and 32 (pdf pages 68, 70 and 72 respectively), the document says: “comp” is a handle to the component context in which the action is executing. I interpret this to mean the instance of the component (somewhat equivalent to “this” in C++ code), as in:

// from examples 26 and 32

component pss_top { multimedia_ss_c multimedia_ss; }
component multimedia_ss-c { codec_c codecs[4]; }
component codec_c {
      vid_pipe_c pipeA, pipeB;
      action decode {
           … comp != pss_top.multimedia_ss.codecs[0];  // line-1
      }
      vid_pipe_c::program pipe_prog_a;
      activity { … comp==this.comp.pipeA; }  // line-2
}

In the line-1 above, the condition is possibly checking if the current instance has been instantiated from the path given in that line. Is my understanding correct?

But then, line-2 is not clear. What does “this.comp” mean here? And what is “this”?
If comp is an instance handle, then it is referring to an instance of codec_c. But pipeA is an instance of vid_pipe_c, so how can this condition match the different types?

Again, in the following code:

//from example-30

component sub_c {
    bit[31:0] base_addr;
    action A { … activate(comp.base_addr); } // line-3
}

In line-3 above, if I had instead coded: activate(base_addr)
What would have been the difference in semantics?

In addition, I don’t see “comp” and “this” in the table of keywords (on page 22 of pdf).

2

In reply to rsm:

Hello, and thanks for the questions about the ‘comp’ reference!

Evaluation of an action instance always occurs in the context of a component instance. The built-in ‘comp’ field is a reference to the component with which the action instance is currently associated. Constraints can be placed on ‘comp’ to restrict the component instances in which an action may be associated.

The first constraint in Example 32 does this

constraint {
mode == AX → comp != pss_top.multimedia_ss.codecs[0];
}

So, if mode== AX, then an instance of the ‘decode’ action may not run on the first codec (codecs[0]).

The second constraint shows how an inline constraint can be used:

vid_pipe_c::program pipe_prog_a;
activity {
pipe_prog_a with {comp == this.comp.pipeA;};
}

This evaluation of the pipe_prog_a action instance will be in the context of the ‘pipeA’ component instance.
‘comp’ refers to the comp handle within the pipe_prog_a action instance. ‘this.comp’ refers to the comp handle within the decode action type. Because the ‘program’ action type is declared within the vid_pipe_c component, its comp handle is of type vid_pipe_c. So, comp and this.comp.pipeA are both of type ‘vid_pipe_c’.

Regarding example 30, actions are inner types of components. Any reference to a component field from within an action requires an explicit ‘comp’ reference. So, activate(base_addr) is illegal.

Hope this helps!