Mail Archives: geda-user/2015/08/30/23:42:17
> 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.
- Raw text -