Mail Archives: geda-user/2015/07/13/04:24:08
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
- Raw text -