Mail Archives: geda-user/2016/02/29/08:14:02
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?
- Raw text -