Re: [sv-bc] Action item: Update item 548

>As an enduser, I am a bit cocerned of this. Isn't it more confusing if I 
>have some ports connected explicity and some by implicitly? 

If you really mean explicitly (i.e. with .name1(name2)), then there are
good reasons to allow a mixture.  Most ports may connect properly with
the implicit rules, but you can override any exceptions explicitly.

If you mean some ports connected with implicit .name and others connected
with implicit .*, there is very little reason to do this.  If you left
out the .name, the .* would make that connection anyway.  I guess it
might be a way to insist that the module must have a port of that name.

However, one rather obscure reason has come up.  If you do a package
import with the pkg::* syntax, an identifier will not get imported
unless there is a reference to it in the module.  Since a .* port
connection does not actually reference any identifiers, it will not
force the importing of anything from the package.  If you were counting
on a package item getting imported to connect to the .*, then you
need a reference to the identifier.  You could add an explicit port
connection so that you have a reference to get it to import.  But it
would be a little shorter if you could type .name instead of .name(name).
So there is a situation where you might want to do a .name implicit
port connection in the same instantiation as a .* implicit connection.

Of course, you could just add an explicit import of the symbol from the
package.  But I guess the pkg::* has the advantage that if you end up
deleting the module instantiation, the import goes away too.

I'm not sure that anyone will be using pkg::* imports to import items
to connect to module instance ports anyway.  If you are using a package
to share a signal throughout your design, why would you switch partway
and start passing it down through ports instead?

Steven Sharp
sharp@cadence.com