[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-dev: [PATCH] GAF: Solve the "transistor problem"
On Aug 7, 2007, at 7:22 AM, Bernd Jendrissek wrote:
> Hope the signature survives gmail pasting...
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> This patch solves the "transistor problem". AKA logic gate and op-amp
> problem. For those unaware, the problem is: just count the number of
> distinct op-amp symbols. Yet they're all op-amps! Same with
> transistors and
> logic gates. The trouble is that once you have chosen a part to
> put into your
> schematic, it takes effort to change to another part later. You'll
> have to
> delete the existing symbol (don't forget to check for any
> attributes you may
> have attached!) and insert a new one in its place. You'll have to
> check that
> its pins are equivalent to those of the old symbol. Once you're
> satisfied,
> you have to translate and rotate the new symbol into the same
> position as the
> old one was, and then hope that the pins still line up with the
> nets that were
> there.
That's the hard way. The easy way is to copy the symbol to your
project's symbol directory with a new name, fix it up, leaving the
pins where they are, and then change the symbol name in the sch file
with an editor. Not hard at all. Maybe a little GUI magic over this
kind of process would help newbies, though.
I am extremely skeptical that any change in the way symbols work can
obviate the need for a project symbol directory.I will agree that the
fact that you need a skosh of expertise to set one up is a minor
barrier.
>
> The solution is to capture your schematic with only "abstract"
> symbols:
> symbols that provide only the graphical representation of a
> function. You may
> have abstract symbols for BJTs, op-amps, logic gates, resistors,
> capacitors,
> memories, etc. You will connect your nets to the pins on these
> abstract
> symbols. You will NOT have abstract symbols for specific parts,
> like an
> LM324A or a 74LS00. Specific parts will be on your schematic as
> "slotted
> components". Their only purpose is to provide slots for abstract
> symbols, so
> that your abstract symbols can inherit attributes like refdes=U100,
> and that
> your abstract symbols' pins can be numbered properly according to
> the part.
I am concerned that this will complicate symbol creation and
modification, a process already daunting to newbies.
>
> I implemented the solution by introducing a new member -
> >owning_slot to struct
> st_object, which points to the slotted component to which an
> abstract symbol
> is currently assigned. The other side of this slot assignment is
> inside
> struct st_complex: its ->prim_objs list can now also contain
> OBJ_SLOT objects,
> whose slotmap=<pinseq1>=<pinnumber1>,<pinseq2>=<pinnumber2>,...
> attributes
> provide the pinseq-to-pinnumber translation (*).
You're using pinseq, an attribute already overloaded, as it also
represents pin order in SPICE netlist format (and perhaps others). So
your method is likely to yield symbols whose assignments conflict
with those needed for simulation or ASIC design using SPICE netlists.
>
> If a selected symbol has a slotname=<anything> attribute, gschem
> will know
> that the symbol is "abstract", and will open the "slot chooser"
> dialog which
> will let you select an available slot to which you can assign the
> symbol. The
> dialog has toggle buttons which let you control the safety checks
> that the
> dialog makes: by default it won't let you assign a symbol to a slot
> if the
> symbol and the slotted component have conflicting attributes. This
> lets you
> assign only op-amp symbols to the op-amp slots of an LM324A, or
> only nand gate
> symbols to the gate slots of a 74LS00. You can force the dialog to
> let you
> choose slots with conflicting attributes, by disabling the
> "Compatible"
> button. The "Hijack" button (off by default) lets you select slots
> which are
> already occupied by other abstract symbols.
Sounds complicated.
>
> (*) Currently the translation is to "die pin number", which refers
> to a
> specific pad on a piece of silicon.
The majority of my symbols don't represent pieces of silicon with
pads (although some represent individual pads!).
> I hope soon to add the second mapping
> from "die pin" to "package pin", to account for the differences in pin
> numbering standards for different package types. (A QFP and a PLCC
> may have
> identical chips inside them, but their pin numbering is
> different.) I'll
> probably do this by introducing another OBJECT type OBJ_PART that
> will be a
> container for part-specific attributes such as this second (die pin
> to package
> pin) mapping. Footprint attributes would also be a good use of this.
This seems to represent a specific vision of how gEDA is to be used.
But for me, gEDA's critical strength is its flexibility and
adaptability to a wide variety of design flows. Your change might be
a good thing, but *please* do not complicate usage, especially usage
"outside the box".
>
> This patch is against
> gaf.git-19b6b06461a906399126803d4c46a5a42d1cc784.tar.gz
> You can find the ChangeLog entries by searching for ^CHANGELOG.
> Following
> each CHANGELOG for a subdirectory of gaf.git/ is a patch covering
> only that
> subdirectory.
>
> ab64506c1dbffba02487e06f29d356d94367ae2b
> gaf.git-20070806-abstract-symbols.diff.bz2
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGt7qy7sfNFNW4BEwRAkh3AKCXjkGO3CrvuK8Vk4RqrBqkiHFy0QCguZhH
> tl7d+lzx6V0U+ppEdZxz6Q8=
> =BI/R
> -----END PGP SIGNATURE-----
> <gaf.git-20070806-abstract-symbols.diff.bz2>
>
>
> _______________________________________________
> geda-dev mailing list
> geda-dev@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx
_______________________________________________
geda-dev mailing list
geda-dev@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev