X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-TCPREMOTEIP: 207.224.51.38 X-Authenticated-UID: jpd AT noqsi DOT com Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [geda-user] RFC: pin attribute remapping From: John Doty In-Reply-To: <201509131840.t8DIecSf029011@envy.delorie.com> Date: Sun, 13 Sep 2015 15:01:15 -0600 Message-Id: References: <5D1C97FB-F049-4ABB-90E4-F2108647A111 AT noqsi DOT com> <201509131840 DOT t8DIecSf029011 AT envy DOT delorie DOT com> To: geda-user AT delorie DOT com X-Mailer: Apple Mail (2.1878.6) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id t8DL1NjK027827 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 Sep 13, 2015, at 12:40 PM, DJ Delorie wrote: > >> 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. The refdes assigned in the schematic is the GUID, just as always. Similarly, the pin number assigned in the symbol, after translation via the slot number assigned in the schematic, is the pin’s GUID. Those don’t change, but what the user sees in the graphics might. > > 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) Good point. I think the solution is to allow the refdes to be a pathname. This already works downward, but, > > 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. Yes. It might happen that the as-built needs flattening in the general case. We do need a good flattening tool not written in Haskell ;-) > John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ jpd AT noqsi DOT com