RE: [sv-bc] .name and .*

Stu,

See inside.


> The .name and .* do have different rules for unconnected ports.
> 
> The .name connection follows the same rules for unconnected ports as
the
> explicit named connections.  If a port is not named, it is implicitly
> not
> connected.

[SB] I'm not sure you understood me. I don't refer to a port which is
not named. I refer to the following cases:

Case1:

module p();
p1 p1 (.name);
endmodule

module p1(name);
output name;
endmodule


Case2:

module p();
p1 p1 (.*);
endmodule

module p1(name);
output name;
endmodule

Note that the signal 'name' does not exist in the instantiating module
p.

The LRM says that '.name' is the same as '.name(name)', with the
exception that it does not create an implicit wire declaration. That
leaves us with a reference to 'name' in the instantiating module where p
does not exist. On the face of it, that should cause an error. 

The example shows an unconnected port connection described as '.zero()'.

The LRM also says that 
"An implicit .* port connection is semantically equivalent to a default
.name port connection for every port declared in the instantiated module
with the exception that .* does not create a sufficient reference for a
wildcard import of a name from a package. A named port connection can be
mixed with a .* connection to override a port connection to a different
expression or to leave a port unconnected."

That explicitly says that the same rules apply to .name and .*.
The named port connection referred to is of the type '.zero()', as in
the example. That is how the term 'named port connection' is used. It
does not mean '.zero', which would be an 'implicit .name port
connection'.

As I said, I tested 3 implementations.
These were the results:

Case1
=====
Impl. 1: No error or warning
Impl. 2: Error
Impl. 3: Error

Case 2
======
Impl. 1: Error
Impl. 2: Error
Impl. 3: Warning - not connected

I don't know what the desired behavior was, but the LRM is not clear.

Regards,
Shalom

> 
> The .* adds a rule, "A named port connection can be mixed with a .*
> connection to override a port connection to a different expression, or
> to
> leave a port unconnected." (Section 19.11.4)
> 
> I agree that for .name, the rule should be explicitly stated, rather
> than
> inferred by not saying anything.  I thought there was an explicit
rule,
> but
> I either imagined it, or the rule was only in an early draft or
> proposal.
> The feature was something we added in SV 3.0.
> 
> Stu
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland
> stuart@sutherland-hdl.com
> +1-503-692-0898
> 
> 
> > -----Original Message-----
> > From: owner-sv-bc@server.eda.org
> > [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom
> > Sent: Monday, October 30, 2006 7:18 AM
> > To: sv-bc@server.eda.org
> > Subject: [sv-bc] .name and .*
> >
> >
> >
> > If .name or .* is used, and a signal with the same name does
> > not exist in the instantiating module, should that be an
> > error or should the port be left unconnected?
> >
> > The LRM is not explicit, which is a problem, but hints that
> > in order to leave the port unconnected, you have to
> > explicitly use a named empty port connection.
> >
> > In any case, I would expect the behavior to be the same for
> > both of them.
> >
> > However, I tested 3 implementations, and found that only one
> > of them gave errors in both cases, and two of them behaved
> > differently in the two cases.
> >
> > Since we see that implementations have differed, this means
> > we need to be explicit.
> >
> > Thanks,
> >
> > Shalom
> >
> >
> >
> > Shalom Bresticker
> >
> > Intel Jerusalem LAD DA
> >
> > +972 2 589-6852
> >
> > +972 54 721-1033
> >
> > I don't represent Intel
> >
> >
> >
> >