X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Sat, 11 Feb 2017 14:56:52 +0100 (CET)
From: Roland Lutz <rlutz AT hedmen DOT org>
To: "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject: Re: [geda-user] gschem gnetlist bug/feature
In-Reply-To: <CAJXU7q8jy9H0-1M=bb4pWu1+x6qCxwfP_QwVkdKgjN334-hbuA@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1702111456440.12859@nimbus>
References: <95e469bb-5572-fa1d-0c18-ed5abadd10cf AT ecosensory DOT com> <alpine DOT DEB DOT 2 DOT 11 DOT 1702102141040 DOT 1974 AT nimbus> <89b42141-9448-1c52-f4be-b4cc41ed7091 AT ecosensory DOT com> <alpine DOT DEB DOT 2 DOT 11 DOT 1702102246190 DOT 27620 AT nimbus>
 <CAJXU7q8jy9H0-1M=bb4pWu1+x6qCxwfP_QwVkdKgjN334-hbuA AT mail DOT gmail DOT com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Sat, 11 Feb 2017, Peter Clifton (petercjclifton AT googlemail DOT com) [via 
geda-user AT delorie DOT com] wrote:
> This is something which back when I was last working on geda-gaf (some 
> years ago), we always strongly resisted that exact change - as it 
> overloads the meaning of that attribute in a way which requires special 
> casing, and only "helps" a tiny use case (the rendered text).

I see your point, but there are a few reasons which speak against it: 
power symbols are already handled by gnetlist as a special case (they 
aren't included in the netlist), and this isn't overloading the meaning of 
the attribute because it means the same thing on a component object as it 
does on a net object.  Also, I wouldn't call having an extra ":1" in the 
rendered text "a tiny use case"; it has come up often enough to see that 
people actually care about that.

> We never felt the supposed benefit justified the unclean (slightly
> inconsistent) behaviour.

I don't think the behavior is inconsistent.  On the contrary, it makes an 
existing behavior more explicit and removes the need for abusing the net= 
attribute to define a power symbol.


gEDA/gaf currently knows about five kinds of components:

1. Regular components

Any component which doesn't fall in one of the categories below is simply
returned in the netlist.  Multiple components may share the same refdes;
in this case, they are treated as one "package".

2. Subschematic components

If a component has a source= attribute and is not graphical, it is a 
subschematic component.  If hierarchy traversal is enabled, it is replaced 
by the subschematic's contents; its refdes becomes the refdes 
prefix/suffix for the subschematic.  Otherwise, it is treated as a regular 
component.

3. Power symbols

A power symbol is defined by the rule "has at least one pin with a net= 
attribute, doesn't have a refdes, and is not graphical".  Power symbols 
connect one or more nets to named nets and are removed from the netlist.

4. Port symbols

When a subschematic is instantiated, a component with a refdes matching 
the pinlabel= attribute on one of the instantiating symbol's pins is 
considered a port symbol.  Port symbols connect a net to the appropriate 
pin and are removed from the netlist.

5. Graphical components

A component is "graphical" if it has the attribute graphical=1 set.  (Any 
other value for this attribute is invalid and used to cause an 
inconsistent state.)  Graphical components are returned separately in the 
netlist; what they should mean is up to the backend.


Currently, whether a component is a power/port symbol is deduced from the 
context.  In particular, without knowing about the parent schematic, there 
is no way to tell if a component is a port or not.  Because the logic for 
handling these is different from other components, I think that there 
should be an explicit way to define them.

Power symbols and port symbols are actually quite similar: both don't 
represent an actual part in the schematic but indicate that the net to 
which they are attached is connected to something else.  To reflect this, 
I added a syntax for defining them to the experimental branch which is 
quite analogous:

To define a power or port symbol, you can now simply add a netname=XXX or 
portname=XXX attribute, respectively, to the symbol.  This can be used for 
displaying the net or port name, as well.  Changing the net or port name 
is just a matter of changing the attribute attached to the component.

In addition, this makes it easier to spot connection mismatches because 
the netlister knows which symbol is supposed to be a port.