Mail Archives: geda-user/2015/08/31/05:48:50
On Mon, 31 Aug 2015, Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
> I do not get everything but for pin and gate swapping ideally there should be no need for back annotation.
Depends on. Some of users prefer to see the actual connections on the
schematics. If the connections change during layout, they somehow need to
be propagated back to the schematics, to meet this reqirement.
If you don't care, and the schematics show gates without trying to
identify which slot/package they are in, you don't need back annotation
because the whole slot/pin allocation thing could be fully moved to the
layout tool. I personally don't like this idea.
If I understood right, DJ's proposal sounds like a combination, where you
do not list the actual conncetions on the schematics but the possible
connections from which you select one during routing. (There's another
aspect with device/package mapping, but that's out of the scope here.)
My proposal assumes the old fashioned strict/static schematics format and
some hacks to allow the layout tool to mark differences between the
netlist and the actual copper connections as intended. Such intended
netlist changes could be propagated back to gschem.
> If starting from beginning it might had make sense to put footprint selection in a separate file and in such case back annotation had been simple by reloading the file but it would not work for Refdes. As is know there is a need to updated the *.sch footprint attribute with the new value this could be done by an external program/script or by pcb. If it would be possible agree about the need to update the *.sch file the discussion could be moved to from where this should done best.
>
> The major problem is there might be unsaved changes in gschem if it is running so it will not work tu just change the *.sch file.
My proposal assumes there is a way a "netlist patch" can be loaded in
gschem. Probably the same way as pcb can load a new netlist into an
existing/open pcb. Even harder to achieve, I also assume gschem can
somehow indicate if an connection or an attribute on the schematics
conflicts with the netlist patch sot hat the user can go there and fix it.
> I guess one solution had been if it had been possible to make function call via some kind of communication mechanism from pcb setRefdes(...), setFoootPrint(...) and if this function had been possible to call regardless if gschem where running or not.
Yes, either a gschem plugin of some sort that is somehow remote controlled
by the foo script (push) or just a manual "load netlist patch" menu
(pull). I'd be happy with either solution.
Regards,
Igor2
- Raw text -