On Mon, Dec 28, 2009 at 8:29 AM, DJ Delorie <[email protected]> wrote: > >> family symbols might be a good concept. it's a medium weight symbol >> for a family of parts. e.g. an FPGA family, or uC family, or is this >> still a light symbol? > > For example, resistor-1.sym, resistor-2.sym, and resistor-3.sym are > all variants on symbol class RESISTOR. A 7400's gate symbol could be > a NAND gate, or an OR gate with inverted inputs. Both symbols would > be variants of the NAND symbol class. > > The idea is to let you right-click on a symbol and select alternate > graphical representations, without actually changing the symbol > (i.e. and having to re-add attibutes, etc). > >> [(A,B),Y]=[1,2,3], [4,5,6], [9,10,8], [12,13,11] >> >> I think that this simplified down to the required parts. > > I suppose some of the syntax can be defined as "optional" and implied, > if we can guarantee that it's deterministic. > > I can imagine cases where pins can be swapped on some of the gates, > but not all, for example an FPGA where some pins are input only, or an > MCU where some UARTs are less configurable than others. Let's define > the swappability as a property of the chip, not the symbol, so parens > on the left are migrated to the corresponding pins on the right - then > if you have parens only on the right, you have the ability to define > swappability on a per-gate basis. I.e. your example is changed to > this internally: > > [A,B,Y]=[(1,2),3], [(4,5),6], [(9,10),8], [(12,13),11] >
This is clearer. > >> GND=7 >> VCC=14 >> >> These need some marking to denote that they are like "net" connections >> not virtual pins, meaning that they are not on a standard symbol, vs >> assuming that if there is no pin than it is a net like connection. > > No, they don't. If they don't show up elsewhere (like in a symbol), > they need to be connected some other way. This also means that unused > gates show up in that "other way" - giving you an opportunity to tie > them to something. We don't need to *say* they won't show up on a > symbol, because we can determine that programmatically - and by not > making them special, we still allow for "power symbols" that have only > those two pins. > Sorry, was not thinking of explicit listing of what shows up in the table or on a symbol, because a variant of the gate/amplifier might have the power pins on it anyhow. and the mapping need not know that, only the netlister and gschem( for making the table of "other" connections ) I was thinking of the example of the automatic mapping, like knowing that something should be an analog ground. maybe something like an attribute GND|analog_ground=7 GND is analog_ground >> This seems to cover most bases, but you made no mention for mapping >> mappings to physical, or did i miss something in the database stuff? > > Pin numbers/names on the right side correspond to the numbers/names of > pins/pads on footprints. So, choosing a package change which mapping > you use, so that it corresponds to the physical pinout of that > package. > A package is a footprint and a mapping, how will you cope with parts with the same footprint and different pinouts? These parts exist, but I don't have a particular example on the top of my head > > _______________________________________________ > geda-user mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
