Re: [sv-bc] .* port instanti

From: Greg Jaxon <Greg.Jaxon_at_.....>
Date: Tue May 31 2005 - 16:37:21 PDT
Mark Hartoog wrote:
> Greg Jaxon:
> 
>>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.

So what you're saying is that this case is already covered in the LRM,
since the connection .i1(i1) would also work.  If that's the case,
then I have to agree no language extension is being used.  I guess
section 19.12.3 in the preliminary draft 2 does not yet reflect the
resolution of that question.

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

Would a reconfiguration override an extern module declaration, or
simply collide with it to cause a link error?  If it overrides, what good
are extern module declarations - is anything they say final?

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

OK.  And this reinforces what 19.12.3 should be saying about either side
imposing the modport restriction.  19.12.3 also says  "If a port declaration
has a named interface type, then it must be connected to an interface instance
of the identical type."   Which is odd because 6.9 still says: "Note that
there is no category for identical types defined here because there is no
construct in the SystemVerilog language that requires it."

Nevertheless, we know what the "identical type" interface is intuitively.

The next question down this garden path is whether I can say:

typedef intf intf_alias;

In other words, is the interface's NAME significant, or is there an
abstract type which must be matched?

Greg Jaxon
Received on Tue May 31 16:37:28 2005

This archive was generated by hypermail 2.1.8 : Tue May 31 2005 - 16:37:34 PDT