X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Mon, 31 Aug 2015 11:51:02 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: "Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] back annotation proposal (RFC)
In-Reply-To: <20150831111604.5b1bb421bc015de9a848e8a9@gmail.com>
Message-ID: <alpine.DEB.2.00.1508311141070.6924@igor2priv>
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1508301838470 DOT 6924 AT igor2priv> <201508301802 DOT t7UI2twS031311 AT envy DOT delorie DOT com> <CAM2RGhRgPQG2WDFVb0SFvMbypyYKS2oYtD=851WHR6fOB4iWdA AT mail DOT gmail DOT com> <201508310341 DOT t7V3fcfh022966 AT envy DOT delorie DOT com>
 <20150831111604 DOT 5b1bb421bc015de9a848e8a9 AT gmail DOT com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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 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