X-Authentication-Warning: delorie.com: mail set sender to geda-help-bounces using -f
X-Recipient: geda-help AT delorie DOT com
Date: Wed, 9 Dec 2020 14:08:42 +0100 (CET)
From: Roland Lutz <rlutz AT hedmen DOT org>
To: "karl AT aspodata DOT se [via geda-help AT delorie DOT com]" <geda-help AT delorie DOT com>
Subject: Re: [geda-help] using net names on multiple sub schematics used by
 single symbol
In-Reply-To: <20201209082005.8890C8512092@turkos.aspodata.se>
Message-ID: <alpine.DEB.2.21.2012091338400.1205@nimbus>
References: <c6376b29-a72c-6ae0-1b39-081ecb97ec1c AT gmx DOT de> <alpine DOT DEB DOT 2 DOT 21 DOT 2012041901490 DOT 1174 AT nimbus> <3e21c34b-571c-8762-7e68-f096bcf10a37 AT gmx DOT de> <alpine DOT DEB DOT 2 DOT 21 DOT 2012081605590 DOT 1246 AT nimbus> <20201209082005 DOT 8890C8512092 AT turkos DOT aspodata DOT se>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Reply-To: geda-help AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-help AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Hi Karl,

On Wed, 9 Dec 2020, karl AT aspodata DOT se [via geda-help AT delorie DOT com] wrote:
> All thoose things with net/netname/portname is simply confusing,
> why not only use one attribute name for all this ?

a net name is a conceptually different thing from an I/O port.  (That 
said, it may actually be a good idea to change that.  Hmm.)

> Also confusing if the talk about "power symbols". It is all about
> some named net, which is useful for power nets _among other forms of
> nets_.

That's true, sorry about the unfortunate choice of words.

> Why not get rid of the "netname attribute attached to a net", since
> you can simply attach a net symbol instead to get the same thing ?

Having a name written next to a net is one of the net naming conventions 
used in schematics.  You *could* use an invisible symbol for that, but 
what's wrong with attaching the netname= attribute directly to a net?

> Regarding the ugly ":1", cannot a missing :<number> just default to :1
> (this has been up to discussion before) ?

Using net= attributes to define virtual pins as well as named net symbols 
always felt like a kind of hack to me.  Virtual pins typically don't have 
a corresponding pin object in the schematic, and more importantly, they 
define an actual physical connection of a real component, whereas pins on 
named net symbols have to exist as pins objects in order to make sense and 
don't show up in the final netlist.

> Regarding portname, I have not heard about it before but I can find it
> in http://wiki.geda-project.org/geda:symbols,
> <<
> I/O port symbols
> Subschematics are hooked up to the schematic from which they are
> instantiated via port symbols. Instead of a refdes= attribute,
> port symbols have a portname= attribute; for each pin on the
> subschematic symbol, there should be exactly one I/O port in
> the subschematic whose portname= attribute matches the pinlabel=
> attribute of the pin. Port symbols mustn't have a pinnumber=
> attribute on their own pin.
>>>
>
> I don't know why the text insists on "exactly one", since nets has
> the tendency to be useful when there is "more than one".

It should be possible to use zero or multiple port symbols in the 
subschematic(s), but since this is most often an error, gnetlist issues a 
warning about this.

> From what I can see, the portname is just a net attribute without
> the ugly :1

The _netname_ attribute is just a net= attribute without the ugly :1.

> so what does the portname way of doing it solve versus the "old" net way ?

As for netname: well, it removes the ugly :1.

The portname= attribute replaces refdes= as the attribute used for 
subschematic I/O ports.  I see why in certain situations, it would make 
sense to use refdes= for defining ports, and that's still supported, but 
I've seen (and experienced) just too many errors caused by a mismatch 
between pinlabel= and refdes= attributes to ignore this.  portname= tells 
gnetlist that this is intended to be a port and nothing else--if there is 
not a matching pinlabel= on the instantiating component, that's an error.

Roland