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

Gord,

I think there are times when you want compositional view of hierarchical 
interfaces and there are times when you want the hierarchical view. The 
hierarchical view makes much more sense when you have multiple instances
or an array of instances of interfaces in another interface.

Consider this simplified version of the LRM example:

interface i1;
   interface i3;
      wire a, b, c, d;
      modport master (input a, b, output c, d);
      modport slave (output a, b, input c, d);
   endinterface
   i3 ch();
   modport master (ch1.master);
endinterface

Suppose I write a code like this:

module m(i1 i);
assign i.ch.c = i.ch.a;
assign i.ch.d = i.ch.b;
endmodule

module top();
i1 u1();
m u2(u1);
endmodule

This example is fine. Now suppose I want to set the port directions on 
module 'm'. If we take the compositional view of modport, then rewriting 
module 'm' like this:

module m(i1.master i);
assign i.ch.c = i.ch.a;
assign i.ch.d = i.ch.b;
endmodule

is an error, because this modport changed the name space. I would have to
rewrite the module like:

module m(i1.master i);
assign i.c = i.a;
assign i.d = i.b;
endmodule

There may be circumstances under which you want this change of the name space, 
but you also need a way to specify directions without changing the name space. 

Modport expressions also change the name space, so they can only be used with 
a module that have been written to the name space of the modport, but modport
expressions do not preclude specifying port directions without changing the 
name space, while adopting the compositional view of hierarchical modports seems
to preclude specifying directions without changing the name space.


Mark Hartoog
700 E. Middlefield Road
Mountain View, CA 94043
650 584-5404
markh@synopsys.com 

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
> Behalf Of Gordon Vreugdenhil
> Sent: Monday, April 04, 2005 11:38 PM
> To: Brad.Pierce@synopsys.COM
> Cc: sv-bc@eda.org
> Subject: Re: [sv-bc] Followup example for ballot issue 246 
> (interfaces and modports)
> 
> Brad,
> 
> "type" is not sufficient.  What about parameters?  What about 
> names defined inside generate constructs inside the interface?
> 
> The problem is that if one wants to make the modport 
> declarations be "complete" then there are other issues to 
> resolve.  If one wants the modport declarations to be a 
> simple filter then it isn't clear to me why they are very 
> useful since one has to introduce the interface instance 
> portions of the hierarchical names anyways.
> 
> 
> After thinking about this a bit more, I am still personally 
> convinced that the compositional view is fundamentally more 
> useful in practice and that the current view of modports 
> doesn't buy much in terms of composition and is in many ways 
> worse than not doing anything due to what will be needed 
> eventually and the long-term feature composition issues if 
> this is retained.
> 
> 
> The fact the modports aren't often used (at this point in 
> user code) makes more of an argument to me that we should 
> either get a compositional view in place or remove the 
> modport_hierarchical_ports_declaration related portions.  I 
> don't think anyone is well-served by having definitions that 
> don't give encourage good reuse models and that will only 
> serve to confuse the long-term users.  I'd rather reserve the 
> modport_hierarchical_ports_declaration syntax for a robust 
> compositional model and define that at some point in the future.
> 
> Gord.
> 
> 
> 
> 
> Brad Pierce wrote:
> > Gord,
> > 
> > It seems to defeat the purpose of modports to allow a name to be 
> > visible that is not listed in the modport.  Why not add the 
> following 
> > to modport_ports_declaration (A.2.9)? --
> > 
> >      | {attribute_instance} modport_types_declaration
> > 
> > where
> > 
> >      modport_types_declaration ::= 'type' identifier {',' 
> identifier}
> > 
> > The LRM has no examples of the style of composing used in your 
> > example, nor am I fully convinced that it's legal.  The 
> LRM-indicated 
> > way to compose is to use hierarchical interface 
> declarations, as in the example of page 302.
> > Redoing your example in that style does not, however, make your 
> > questions go away.
> > 
> > Also, the answers to your questions should not assume that modports 
> > are always used.  In practice, they often are not.
> > 
> > -- Brad
> > 
> > -----Original Message-----
> > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of 
> > Gordon Vreugdenhil
> > Sent: Friday, April 01, 2005 2:37 PM
> > To: SV_BC List
> > Subject: [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
> > 
> 
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil,  Staff Engineer               503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
>