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

.name and .* do have the same rules for unconnected ports: .name and .*
never creates an implicit wire. It's just that you can't override a
.name port with a named port. It's the named port that will create an
implicit wire. 

This was sv-bc issue 42-23,24 from SV3.1

Dave


> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Stuart Sutherland
> Sent: Monday, October 30, 2006 7:49 AM
> To: 'Bresticker, Shalom'; sv-bc@server.eda.org
> Subject: RE: [sv-bc] .name and .*
> 
> Shalom,
> 
> 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.
> 
> 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
> >
> >
> >
> >