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

I see that Cliff's proposal in
http://www.eda-stds.org/vlog-pp/hm/att-0317/02-ImplicitPorts_20020315.PD
F said,

"If a port on a .* or a .name implicitly instantiated sub-block is
unconnected in the upper-level module, the port shall be explicitly
listed as a named port with empty parentheses, showing there is no
connection to the port."

Shalom

> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Bresticker, Shalom
> Sent: Tuesday, October 31, 2006 10:23 AM
> To: stuart@sutherland-hdl.com; sv-bc@server.eda.org
> Subject: 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
> > >
> > >
> > >
> > >