Re: [sv-bc] .* port instanti

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.

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 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?

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
> 
> 
> 
>