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: Mon, 13 Jul 2015 10:23:42 +0200
From: "Gabriel Paubert (paubert AT iram DOT es) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] gEDA/gschem still alive?
Message-ID: <20150713082342.GB26809@visitor2.iram.es>
References: <CAM2RGhQfPO31-1Uyc3kC7w286r0VD7c41UZEZcyYquzknCxbsQ AT mail DOT gmail DOT com>
 <20150707060409 DOT GB14357 AT localhost DOT localdomain>
 <CAOP4iL2C_LU=RQy5FWYF-7RrHW6tqhqqyFJGjkwLQ2AD7FiYJA AT mail DOT gmail DOT com>
 <1436287952 DOT 678 DOT 26 DOT camel AT ssalewski DOT de>
 <559C0F7E DOT 7010009 AT neurotica DOT com>
 <1436295556 DOT 678 DOT 91 DOT camel AT ssalewski DOT de>
 <CAOuGh89C71vTW00QLQgVBAQy=m6Me8khjqep=eFH7KgKGqaSzw AT mail DOT gmail DOT com>
 <559C3778 DOT 4000105 AT neurotica DOT com>
 <20150708072021 DOT GB13243 AT visitor2 DOT iram DOT es>
 <C69A441D-23D3-43B3-8892-0AE219D3EC5B AT noqsi DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <C69A441D-23D3-43B3-8892-0AE219D3EC5B@noqsi.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spamina-Bogosity: Unsure
X-Spamina-Spam-Score: -0.2 (/)
X-Spamina-Spam-Report: Content analysis details:   (-0.2 points)
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
  0.8 BAYES_50               BODY: Bayes spam probability is 40 to 60%
                             [score: 0.4995]
  0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was blocked.
                             See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                              for more information.
                             [URIs: iram.es]
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, Jul 11, 2015 at 08:43:08AM -0600, John Doty wrote:
> 
> On Jul 8, 2015, at 1:20 AM, Gabriel Paubert (paubert AT iram DOT es) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
> 
> > I find that the netlist generation of my current projects
> > (over 20 seconds) is already slow enough.
> 
> Generating a full release of my largest project (three boards, ~3500 components, three forms of netlist, three forms of BOM, forward annotated schematics inserted into LaTeX documentation) takes about two minutes. Not enough time to make tea.
> 

And you don't do the layout. A few days ago I was allocating the pins on a
fairly large Microchip's PIC (PIC24FJ128GC006/010), while doing the layout. 
Actually it was the last step of the design. The goal of course was to
minimize the number of crossings on the ratsnest before routing the signals.                                                                          

The set of constraints for the allocation is not trivial when you use
some of the interfaces (the remappable ones, which can only go to a
subset of the pins, larger for the input-only pins). The fact that 
after each symbol edition, it took about 30 seconds to refresh the
ratsnest was  really annoying.

> > I have the feeling that scheme
> > is part of the reason.
> 
> For my designs, at least, the gnetlist runs seem to be dominated by the code that searches for net segment connections. That executes before the Scheme back end. It can get very slow if you put a lot of net segments on a single sheet. I try to avoid that for readability anyway. Ales told me years ago that the C code here was inefficient.
> 

I tried once to understand how gnetlist finds the connections and gave
up, the dump of the traces was humongous and I certainly think that it
is not very efficient. 

I've just been running gnetlist (-g PCB and -g osmond, the differences
are small) on each of the 9 pages of my curent schematics and a few
others from previous projects.

By far the longest time is taken by the pages on which I have grouped
the power supplies and decoupling capacitors. In the current project,
none of the files takes over 0.5 seconds, except for the one with
the decoupling capacitors for 3 LTC6950 PLL chips (176 symbols, among
them 120 capacitors and 24 ground, but only 148 net segments)
which takes around 4.6 seconds (that's on my work laptop from 2008,
I was on an even slower machine last week).

The same conclusions can be drawn from another project in which 
the page with decoupling capacitors for an FPGA (Spartan3A in BGA256)
also takes much more time, but this is less obvious.

The common point I see right now between these schematics is that
they have symbols with lots of pins. For components with a large number
of pins, I always split the part in several, easier to manage symbols,
except for the power supply part.

> It is annoying that this code isn’t controlled by the Scheme back end. It runs whether you need the result or not (as for a BOM). Control of hierarchy expansion is in gnetlistrc (per-project) but I think it makes more sense to have the back end control it. It depends on what kind of netlist you’re making, not on the nature of your project.

Indeed. 

    Gabriel