X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Envelope-From: paubert AT iram DOT es
Date: Fri, 16 Nov 2012 09:58:31 +0100
From: Gabriel Paubert <paubert AT iram DOT es>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] slotting
Message-ID: <20121116085831.GB3821@visitor2.iram.es>
References: <CACPio-7O1OS0Z-NkOJmzTvxSFf+v9j6yFM8F6xRXeZvTjDUK8A AT mail DOT gmail DOT com>
 <50A2B84F DOT 4080204 AT laserlinc DOT com>
 <CACPio-4+wJj6WY-GsJhskmZicM1mn6YKoRc4kVVP9ABXLpZYYg AT mail DOT gmail DOT com>
 <50A3AAA6 DOT 1080704 AT laserlinc DOT com>
 <CACPio-4cDVS+vmowijmZ6Y9E0+rXoEimc9ugZqTPGvOKQvoqow AT mail DOT gmail DOT com>
 <Prayer DOT 1 DOT 3 DOT 5 DOT 1211141555060 DOT 15335 AT hermes-1 DOT csi DOT cam DOT ac DOT uk>
 <20121116033946 DOT 1b7bc23c AT akka>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20121116033946.1b7bc23c@akka>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-SPF-Received: 2
X-Spamina-Bogosity: Ham
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 Fri, Nov 16, 2012 at 03:39:46AM +0100, Kai-Martin Knaak wrote:
> "Peter C.J. Clifton" <pcjc2 AT cam DOT ac DOT uk> schrieb am 14. November 2012:
> 
> > This probably won't play well with the renumber tools out there,
> 
> Specifically, it does not play well with the built-in renumber tool of
> gschem. Attributes -> autonumber-text will always make all refdeses
> different even if they were deliberately set to the same value. This is
> one of my "favourite" gschem warts. 

Agreed. But do you have a plan to solve this problem?

> 
> 
> > Finally.. if you do use multiple symbols anywher, there is (or was?) a 
> > problem you have to work around, in that when picking up the symbols
> > to retrieve attributes from (e.g. for forwarding to PCB layout), it
> > was not clear which of the two symbols would be scanned for attributes.
> > 
> > To get around this, add the "footprint=..." and any other attributes
> > you need to be "machine" readable to both halves of the symbol.
> 
> This kind of redundancy creates maintenance issues. E.g. consider a
> 7414, which is a package with six inverters. In the schematic these
> would be six times a NOT symbol plus a symbol for the power pins. All of
> them have to be edited if the footprint is to be changed from DIP14 to
> SO14. 

That's a problem.

> I like to make the footprint value visible in the schematics.

On that point we disagree.

> The requirement for footprint attributes on each and every symbol adds
> to the clutter in the schematic.
> 
>  
> > (If this issue hase has been resolved already, someone please let me
> > know).
> 
> It has been alleviated, but not quite resolved. Current gnetlist warns
> if it finds different footprints to an attribute. However:
> 
> * which value gnetlist picks, depends on the order the symbols were
>   entered in the schematic. I wrote a patch that makes sure, gnetlist
>   output never ever depends on the order of symbols. This patch was not
>   accepted by the devs. I still think, this dependence on order is a bug.

I agree, especially when the attribute is only found once. Conflicting
attributes for the same refdes are a different issue and should always 
elicit a warning, at least if they are used in netlist/simulation (not
the "comment" attribute for example).

In the case of a 7414, the logical way is to assign the footprint to the 
power symbol and only to it.

> 
> * import-schematics in pcb does not show the warnings
> 
> * a missing footprint attribute is treated like a footprint with value
>   "#f". This effectively enforces to set the footprint attribute on
>   every symbol. Else, gnetlist output will be swamped with warnings.

That one should not fixable, although it may be hard. One thing I dislike 
is that gnetlist returns "unknown" in attribute getters in scheme when
it should be #f IMHO.

I once dived into gnetlist code and got lost. I would need to study it more
but won't have time in the foreseeable future.

	Gabriel