RE: [sv-bc] .* port instanti

Greg Jaxon:
> That's an interesting construction which seems to invite the 
> compiler to do a mindreading trick:  You'd like the leaf 
> module's formal port (named i1) to match via .* with the 
> parent module's interface declaration (also named i1), but 
> you want the leaf module's formal type (intf.m1) to make the 
> modport selection within that interface.
> 
> This extra resolution step is not specified in the current LRM.
> 
> Instead the LRM explains .* connection as a shorthand for
> .portname(portname).   You need the connection .i1(i1.m1),
> which goes beyond the pattern of straightforward redundancy.
> 
> So we're talking "language extension" here.

A modport can be specified either in the module port declaration
or in the module instantiation. If it is specified in both places,
then they must be the same modport. In this case there is no need
to specify the modport on the module instantiation, because it is
already specified in the module port declaration, so no language
extension is required.


> On first examination it seems unambiguous.  But I don't see 
> how adding this improves the language.  In your example, the 
> advantage it offers is that modport4 does not need to know 
> the names of the interface modports, or which one leaf would 
> like to use.
> But "implementation hiding" is not a goal of .* port connection.
> Connecting via .* requires coordination of otherwise 
> independent implementation choices (the formal & actual port 
> names), which presumes that no port choices can be hidden.
> 
> As written, intf, modport4, and leaf are all in the same source file.
> Implementation hiding is typically used with separate source 
> files so two teams can operate more independently of each other.
> I have some operational questions related to how that would work here.
> 
> The declarative order question: don't we need either the 
> "module leaf ..."
> definition, or an "extern module leaf ..." declaration in the 
> source text BEFORE "leaf inst (.i2(i2.m2), .* )" instantiates it?
> Or is the separation of "analyze" and "elaborate" activity 
> supposed to give elaboration the ability to look ahead in the 
> source text?

The .* port connections cannot be expanded until elaboration. Even if you
have seen the module 'leaf' or a "extern module leaf ...", you may still
have a configuration which changes the module instantiation, and in that 
case the .* connection may expand differently.

> The separate elaboration question:  We can elaborate modport4 
> provided the leaf team gives us leaf's extern module 
> declaration.  By discarding the generic interface port (which 
> does not connect via .*), leaf could also elaborate 
> separately from modport4.
> 
>             But, both teams need the interface definition.
> 
> When it comes time to link them, we'd like the "type 
> matching" rule for ports to insure that both teams used the 
> /same/ definition of intf.
> 
> Currently the type-match rules concern themselves with the 
> strong datatypes.
> How should linkers decide whether two interface ports can connect?
> Is there a similar strong typing for interfaces?

In section 20.4 the LRM says: "If a port connection specifies a modport 
list name in both the module instance and module header declaration,
then the two modport list names shall be identical."
 
> Greg Jaxon
> 
> 
> Rakesh Gulati wrote:
> > Hi
> > 
> >  In the example below,  I am passing the the interface 
> instance using 
> > .* port connections, but i am trying to catch the modport for the 
> > interface instance i1. As per IEEE P1800 D4 instance portname and  
> > type should match. So
> > 
> > 1. A interface instance and its modports are of equivalent type.
> > 2. Interface instance is equivalent to generic interface type
> > 
> > or we should consider that a interface is having no type 
> and hence no 
> > such check is required.
> > 
> > Thanks
> > Rakesh
> > 
> > `timescale 1ns/1ns
> > 
> > interface intf(input clk, output int count);  modport 
> m1(import task 
> > doincr(input int incr),output count);  modport m2(output 
> count, import 
> > getincr);  modport m3(output count, export task doincr(input int 
> > incr));  modport m4(export function int getincr(input int count, 
> > incr)); endinterface
> > 
> > 
> > module modport4(input clk, output int count[1:0]); intf i1(clk, 
> > count[0]), i2(clk, count[1]); leaf inst(.i2(i2.m2), .*); endmodule
> > 
> > module leaf(input clk, intf.m1 i1, interface i2); endmodule
> > 
> > 
> > 
> > 
> 
>