Re: gEDA-user: blue sky ideas - written down finally

[Steven Michalske <smichalske@xxxxxxxxx>]

On Mon, Dec 28, 2009 at 8:29 AM, DJ Delorie <dj@xxxxxxxxxxx> 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
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user