X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.4 at av02.lsn.net Subject: [geda-user] ideas on slotting and mechanisms for grouping/associating heterogenous symbols. To: geda-user AT delorie DOT com References: <8444F816-17CE-4A56-A982-4A60DEDA72B8 AT noqsi DOT com> <87FC7D4C-157A-499E-8B93-97653D6A7C68 AT noqsi DOT com> <624E6A69-62CE-4FCB-9D44-9FDF036254A3 AT sbcglobal DOT net> From: John Griessen Message-ID: <56880043.7040003@ecosensory.com> Date: Sat, 2 Jan 2016 10:52:19 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.4.0 MIME-Version: 1.0 In-Reply-To: <624E6A69-62CE-4FCB-9D44-9FDF036254A3@sbcglobal.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id u02GqOdi019487 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 01/01/2016 05:19 PM, Edward Hennessy (ehennes AT sbcglobal DOT net) [via geda-user AT delorie DOT com] wrote: > I would be interested to hear everyone’s ideas on slotting and mechanisms for grouping/associating heterogenous symbols. The symbol name (or refdes) should be the sole indicator that something is grouped. That is a group at the symbol level that has no position or pin sequence order information in it. Slotting of identical sections available in IC packages is an old-fashioned dead language that should be kept as is and somehow remove conflicts of uses of pinseq number lists. The simplest way is stop using pinseq in new designs. To me, symbol pinseq numbers should reflect the slotted variants of a package as: the pin you would use instead of the pin number, (both are on the same pin element of the drawing), to get an equivalent function but with different wires. The netlist changes as you use different sets of pinseq numbers that are contained in the one symbol. In the old way, each pin can have a pinseq that is a list, (usually no longer than four variants), where list position denotes which variant it is. I say try to leave that getnetlist function there if it is possible to reconcile it with code cleanup. John Doty's style of using scripts/backends gnet-check-pincount and gnet-check-duplicates makes good sense. I would use a separate script to process pin swaps that utilizes a pinswap number attribute that is not part of symbols as they are in the library, but added when you need it. There could be a pinswap file added with same symbol name and a .pinswap ending on it. The pinswap file would come from FPGA tables of pin uses in datasheets that are 1000 pages long. The pinswap file would not be embedded in a standard symbol, just kept as a file next to it. Each pin that has pinswap attrib would have pinswap=2 or pinswap=771, but not any lists of variants allowed -- that would be the job of a script or backend to assign from the .pinswap data file. The meaning of the pinswap attrib on a pin would be: "Assign the internal function of this defined pin of this IC to the physical pin number of this pinswap attrib. For example use U7. If a pin has pinnumber=669 and pinswap=771, the generated netlist for the design net that connects would have U7-771 in the list for that net. The function names for pinswaps will not always be the same, (like they were for old fashioned slotting of quad gates), so a way to suppress showing the functional name on a symbol would be a good idea, and instead use a name form an attrib associated with pinswap attrib. I'd start using a new attrib pinfunction that is always created and added to a symbol by a pinswap script and never in a standard symbol. When it is there, set visibility of pinname to off and visibility of pinfunction to on.