Re: gEDA-user: chip data directories in a library ( library packages )

[Steven Michalske <smichalske@xxxxxxxxx>]

On Sat, May 21, 2011 at 7:53 PM, John Griessen <john@xxxxxxxxxxxxxx> wrote:
> On 05/21/2011 08:09 AM, Kai-Martin Knaak wrote:
>>
>> The notion of packages can be seen as a means to isolate dependencies.
>> Pins in symbols must match pins in footprints. Simulation models are
>> specific to components. Packages provide a way to keep comments, notes
>> and all kinds of meta data attached.
>
> I like the idea of creating a library group containing all info related
> to a manufactured part or part range.  I think the name package could create
> confusion
> with layout package used to implement a circuit, some of which have
> different
> numbers of pins, so what do you all think of this name for a library group:
>
> In the context of a library call them chip data directories, or chips for
> short.
>
> The chip data directories could also be compressed
> a standard way for ease of distribution.
> Some library elements don't match the word "chip" perfectly, such as
> resistor capacitor
> terminal block, etc, but people can figure from the context what was meant.
>
> On 05/21/2011 08:37 AM, DJ Delorie wrote:
>> I don't think we've come to a consensus on how to ease the
>> heavyification step yet, though, which may require a great deal of
>> coding and redesign.
>
> The data dir in a library concept seems to make heavification easier.
>
> I'd always want to be able to heavify the symbol or footprint first, then
> use a script to make them all consistent, not have to do symbol
> then footprint in that order only.
>
> Names keep coming up as I think about relating symbols and footprints and
> adding
> heavy data to them.  If symbols are not necessarily files, I'm used to the
> file name being
> the symbol name or footprint name -- it just seems "normal".  If a symbols
> or footprint was just a
> text section in a larger file, I'd be OK with that, and it would need tags
> like symbolname="some-kinda-name"
> or footprintname=some-kinda-name".  We could easily agree to shorten that
> down to tags like:
> symbol="some-kinda-sym-name", footprint=some-kinda-fp" without even needing
> filenames with suffixes .sym .fp.

I'd like to see that there is a many to many relationship.

Example:

You need a SO-8 footprint.

With the footprint storage the relationships are a type of footprint
backed by many footprints capable to fill the role.
If it is directory and files there is a SO-8  directory with the x pcb
footprint files that could be used to be a SO-8, like most, nominal,
least, hand-solder, and etc.
In a relational database plugin it could query for a footprint that
provides SO-8 in the footprint table.

This helps if you are say making a base schematic that may be made on
many different types of boards, or purposes.
When purposed it would get flattened and weighted with the particular
process applied to it.

Next example.

For models in simulation.

It is a mosfet, a 2n7002,  there is a 2n7002 directory with a list of
models for say guncap and spice.  They also happen to be for different
manufacture parts.
In the "package" part it has a variety of parts that you may use, from
lets say 4 vendors.  The data store can let you simulate the circuit
with each vendor, leading to confidence that your alternate parts are
good.


In lightening a resistor, I'd have the base parameters part of the symbol.
Ohmic value, tolerance, power dissipation.  This can then let the
method of hevifying query a data store to help find your preferred
parts.



My thoughts on the interaction.

Lets say that you draw out the topology of a circuit it has a micro
controller and support parts.
The uC is a medium weight part, it has the first variant chosen. The
uC package is 33 pin or 64 pin part is not yet chosen, but the 33 pin
symbol is the first variant, so it is displayed.
A heavy part that is the connector that the board will use, every
parameter is chosen when the connecter's symbol is placed.
The rest of the parts are a bunch of light parts consisting of
resistors, capacitors, and LEDs
Now that the parts are placed and wired up.
We then select the tool/wizzard/script that makes parts heavy, pretend
were in the GUI mode and using the tool.
So you click on the LED(s) that you want to assign parameters to.  The
tool knows that it is a LED, so it pulls up the dialog for making that
part heavy.  It has a interface into the datastore that we are using
and I can start drilling down on the values.  Kinda like
digikey/mouser narrowing down parts.  (To DJ's idea) this script might
just be an interface to a CGI that is on a part vendors server.

Now that the LEDs are taken care of, lets run the script that will
make a schematic heavy to take care of the resistors and capacitors.
In the schematic you specified the values and tolerances, so the
script will take you preferred parts and assign them.

The script might generate questions like you do not have a preferred
resistor for value 100k at 10% tolerance,  would you like to use the
5% tolerance you prefer?
or automatically improve tolerances and just warn.

Off to layout.....

now for rev two of the board.  You ran out of pins with the 33 pin uC
but were in luck there is a 64 pin version.

So you edit the part in the schematic, and switch its version.   This
cause the new pins to be added. in different locations to the common
pins.  So that wires that have the same meaning are still hooked up
but new pins are unconnected, or old pins that no longer exist are now
not connected.

Add parts rinse wash and repeat.


-- snip --


Steve


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