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