Mark Hartoog wrote: > 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. Interesting. Is it an error? I'm not convinced. "ch" is not something that can be specified (directly) in a modport so it in fact isn't clear to me at all that i.ch becomes illegal. In my view, the original "i.ch" referencing embeds a direct dependency on the (non-controllable) visible interface instance "ch". This is not impacted by the modport at all. Gord. > 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 >> > > > -- -------------------------------------------------------------------- Gordon Vreugdenhil, Staff Engineer 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.comReceived on Wed Apr 6 07:52:04 2005
This archive was generated by hypermail 2.1.8 : Wed Apr 06 2005 - 07:52:23 PDT