X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f Date: Sun, 13 Sep 2015 14:40:38 -0400 Message-Id: <201509131840.t8DIecSf029011@envy.delorie.com> From: DJ Delorie To: geda-user AT delorie DOT com In-reply-to: <5D1C97FB-F049-4ABB-90E4-F2108647A111@noqsi.com> (message from John Doty on Sun, 13 Sep 2015 12:23:22 -0600) Subject: Re: [geda-user] RFC: pin attribute remapping References: <5D1C97FB-F049-4ABB-90E4-F2108647A111 AT noqsi DOT com> 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 > The second form allows swapping of pins between packages. Is this a general form of swapping gates between packages? Like beween 7400's? While considering the pin/gate swapping problem, I did encounter one case where "refdes" wasn't globally persistent enough: if you have two 7400's and you swap gates between them, the "refdes" in the schematic is no longer accurate, and should be changed to reflect the swap. But, the refdes is what you're using to globally identify "this symbol" in the schematic. Aside from assigning GUIDs to each symbol as they're instantiated, I don't have a good solution to this. Using a page in a heirarchy, where a gate is swapped between devices in one instance within the heirarchy but not another causes even more problems, because there is now no "one schematic" that can reflect the as-built. (swapping pins differently in instances is a similar but smaller problem) I think it's possible to solve these in a post-flattened world, since pcb could know what it did relative to the flattened netlist, although what to print for the refdes might get confusing (if it isn't already with heirarchy ;). It's moving those changes back to an as-built that retains the heirarchical format that's tricky. Annotation an as-built *might* require a shared page to be separately instantiated for each use in the heirarchy.