[sv-bc] Followup example for ballot issue 246 (interfaces and modports)

As an action item from this morning's initial ballot meeting,
I was asked to develop an interface example with specific
questions in order to clarify the issue raised in item 246.
Please excuse the length of this.

Gord

----------------------------


The following is the example from 20.9:


interface ebus_i;
     integer I;      // reference to I not allowed through modport mp
     typedef enum {Y,N} choice;
     choice Q;
     localparam True = 1;
     modport mp(input Q);
endinterface

module Top;
     ebus_i ebus;
     sub s1(ebus.mp);
endmodule

module sub(interface.mp i);
     typedef i.choice yes_no;    // import type from interface
     yes_no P;
     assign P = i.Q;             // refer to Q with a port reference
     initial
         Top.s1.Q = i.True;      // refer to Q with a hierarchical reference
     initial
         Top.s1.I = 0;   // referring to i.I would not be legal because
                         // is not in modport mp
endmodule



Notice that in module "sub" we have a reference to the type
"i.choice" via a modport of a generic interface.  This implies
that items other than modport items are made implicitly
visible via the modport name.

First, it isn't clear what items are implicitly visible
via a modport.  Second, it isn't clear whether such visibility
derives from the modport or from the actual interface instance
containing the modport.

Assumption 1:  types and parameters become implicitly visible.


Gord's Example:

interface A;
    typedef integer T;
    T Q;
    modport mp(input Q);
    modport mp2(output Q);
endinterface

interface B;
    typedef logic T;
    T Q;
    modport mp(input Q);
endinterface


interface C;
    A a();
    B b();
    modport mp(a.mp, b.mp);
    modport mp2(a.mp, a.mp2);
endinterface


module D(interface.mp i);
    typedef i.T          nonsense;

    typedef i.a.T        illegal;
    typedef i.a.mp.T     illegal2;

    initial $display(i.Q);   // nonsense
    initial $display(i.a.mp.Q);      // valid?
    initial $display(i.a.Q);         // valid?
endmodule

module top;
    C c();
    D d(c.mp);
    D d2(c.mp2);
endmodule

Question 1:  Are C.mp and C.mp2 valid modports?

Gramatically this is legal.
Semantically this seems to be sensible since one would like to
compose modports of constituents to form a new interface.

If C.mp is valid, what are the names visible within it?
Do the names "a.mp" and "b.mp" form the exported names or
do the elements of a.mp and b.mp form the names?

In particular, within C.mp, is the name "Q" a directly
visible name or do we have to reference by way of
a.mp?  If by way of a.mp, is the full qualification
required?  If i.a.Q is valid, does it ignore the modport
access specification?



Question 2:  How can one access the types of the constituent interfaces?

The name "i.T" is nonsense for one of two reasons:
   1) the actual interface (top.c) used in the instantiation doesn't
      define type T
or
   2) the implicit visibility of T from a.mp conflicts with the
      implicit visibility of T from b.mp.

Which is the correct reason?


In addition, the typedefs "illegal" and "illegal2" are both
illegal since the only valid rule for a typedef using any
form of dotted name is:
     typedef interface_instance_identifier . type_identifier type_identifier
which permits only a simple identifier before the type identifier.

The implication of (1) is that if C wants to make types
visible from A and B, it will have to introduce explicit
typedefs within C in order to make those names visible.






The main issue here is that the LRM does not clearly define
the implicit visibilities and how one composes names directly
and indirectly visible via modport access.


The proposal in item 246 defines a rule for answering the
questions.  If that rule is not what was intended by the
authors of this section, the authors should propose clear
visibility and access rules that can be used to determine
the legality of each of the situations indicated above.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil,  Staff Engineer               503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com