Mail Archives: geda-user/2015/08/31/00:39:59
On Sun, 30 Aug 2015, DJ Delorie wrote:
>
>> That makes a lot of sense for the netlist but what if you change a
>> footprint? I think there should be another tool that you run in
>> parallel to gnetlist to handle that.
>
> I assume a much more intelligent netlister.
>
> The netlister maps what it knows about each symbol to a list of
> candidate options for "heavifiing" the symbol into a full component.
> One of these options is the package, and once you somehow choose a
> package, there's one or more footprints that go with it.
>
> Part of my idea is that pcb takes all the choices it knows about and
> gives them to the netlister, so that the netlister can use that to
> narrow down the options it's left with after dealing with the
> constraints in the symbol.
>
> I.e. if you have a generic AND gate symbol, there's lot of options for
> the netlister. But if this is a future iteration, pcb might already
> know that you picked a 74ALS00 in a SDIP-14 package with the SDIP14M
> footprint. It can tell the netlister this when it does an
> update-import. It can also tell the netlister what pin mappings were
> used.
>
> If the information in pcb is no longer valid for the device (i.e. you
> changed a 2-in AND to a 3-in AND), then the netlister would discard
> pcb's choices and start fresh.
>
> So, there's a lot of back-annotation information being sent from pcb
> to the netlister, which lets you do package, gate, and pin swapping in
> pcb, but none of it ends up back in gschem unless you do something
> specific to make that happen.
>
I generally like most of this. I have some constraints, tho: your idea
needs massive gnetlist backend coding, which means a lot of scheme coding.
I am not up to that and I have no contributor willing to do that. (Your
idea also requires much more support in pcb-rnd, but I'm fine with that
part.) Unless my contributor-problem gets solved, I will probably need to
go for a simpler solution even if that is less generic.
Regards,
Igor2
- Raw text -