X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Mon, 29 Feb 2016 14:11:36 +0100 (CET)
From: Roland Lutz <rlutz AT hedmen DOT org>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] hierarchical design - two symbols pointing to one
 schematic
In-Reply-To: <20160228183227.Horde.g66UEijK5I0FnHyBsmI3bZU@webmail.in-berlin.de>
Message-ID: <alpine.DEB.2.11.1602291411260.1512@nimbus>
References: <20160223152120 DOT Horde DOT _z0FeIbOqDDq7i7gKTXCeK4 AT webmail DOT in-berlin DOT de> <94CB9E71-127E-4690-9FFC-39722F79260B AT noqsi DOT com> <20160228183227 DOT Horde DOT g66UEijK5I0FnHyBsmI3bZU AT webmail DOT in-berlin DOT de>
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 Sun, 28 Feb 2016, Hagen SANKOWSKI wrote:
> I got a bunch of lines from gnetlist for my hierarchical design like this:
> "Found a pin [Y300/Y2] on component [26] which does not have a label!"

The meaning of this error message is that during the hierarchy 
post-processing step, some pins of subsheet symbols could not be matched 
up with the corresponding I/O ports because the pinlabel= attribute on the 
pins was missing.

Unless you disable netname= or net= mangling, you need two things in order 
to connect a net to/from a subsheet: an I/O port component in the 
subsheet, and a pin on the subsheet symbol whose pinlabel= matches the 
refdes= of the port component.  Other pin attributes aren't relevant for 
hierarchy post-processing.  So if you have a pin on a subsheet symbol 
which doesn't have a pinlabel=, it doesn't serve any useful purpose (the 
subsheet component is removed afterwards), and gnetlist issues a warning.

On Mon, 29 Feb 2016, Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via
geda-user AT delorie DOT com] wrote:
> On 2/28/16, Hagen SANKOWSKI <hsank AT nospam DOT chipforge DOT org> wrote:
>> During this week I rectify my design, but still ending up - after a 
>> long, long runtime something in hours on a VirtualBox with a lot of RAM 
>> and 4 CPUs - with a gnetlist line which said: Killed.
>
> Well, I did 'git grep "[Kk]illed" in the geda-gaf repository and
> found nothing but one word in the documentation for icarus. So I
> suppose the OOM-killer kills your gnetlist when it goes into a big
> loop for some reason and eats all the memory resources.

The message "Killed" isn't printed by gEDA/gaf; it means some process has 
received signal 9 (SIGKILL).

If this is indeed due to gnetlist using too much resources, it means you 
have either a really large design (in which case you could play around 
with ulimit to resolve this), or there is a bug in gnetlist which should 
be fixed.  Would you mind sharing a design which triggers this bug?