Re: [sv-bc] .* port instanti

So, whether passing a interface instance to a genric port or modport
using .* is correct?
  Both interface instance and its modport or genric interface can be
treated as equivalent.

Is there any type for interface that should be mapped to equivalent type
in .* instance creation?

Thanks
Rakesh


Greg Jaxon wrote:

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