[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
gEDA-dev: SoC Hopeful
Hello again,
First off, I'd like to thank you all for the information and ideas provided, everything was very helpful in figuring my way around. Second, I've taken a lot of the suggestions in your messages as well as a few ideas of my own and hashed them into a design I think might be workable for a parts manager. I'm submitting it here for comments/critiques/suggestions before I go and write my formal proposal.
Here's how I'm thinking of it: The core of the parts manager will be a relational database consisting of two major tables (one which defines generic parts and one which defines specific extensions to them) and a minor table (part->netlist information mapping). Additional tables for vendor and manufacturer part numbers could be added as needed without change to the base design. An interface (either a library or helper program through IPC) will be used to query parts from this database and return them as data structures in the same format as a schematic/symbol file (am I correct in thinking that this is where you would want the externally callable library everyone's talking about?). With the help of this interface and the addition of a new object type to the schematic file format (or the extension of the component type), it would be possible to reference the database from within a schematic file and have a part returned as though one was referencing a sub-file. This allows for minimal changes to be made to the gschem base code. A similar approach could be taken for gnetlist resolution.
As to the specifics:
1) The first of the major tables will be a generic parts table, which will contain abstract definitions for a series of parts. The definition at this level will include:
- a series name
- a category name (the equivalent of the library name in the current components system)
- the types of footprints allowed for the series
- the names of any required attributes for the series
- a mapping of pin names to internal (series specific) pin numbers
- a pairing of pin-names to status/direction (in/out/pwr/etc)
- a boolean value indicating whether or not the series can have children in the specifics table.
2) The second of the major tables will be a specific parts table, which will indicate:
- the specific package name
- the generic part being extended
- which of the allowed footprint/packages is to be used
- the mapping from internal to footprint pins
- any additional required attributes
- any models available for netlisting
Once the framework is defined we can do a number of things. First, and most obviously, we can define a generic part with possible packages and pin information and then map these to multiple specific parts on certain footprint types. [To go back to Dan's example from earlier the general part would be AMP1234, and would contain the names and directions for each of the 8 possible pins. The specific parts would be AMP1234-A & AMP1234-B, which would contain the mapping and footprint type for each.] Second, if we were to define a template schematic for each footprint type, we could have specific schematics generated on demand for a given footprint provided that all required information (pin names and types) was given in the generic part definition. Third, we can define a primitive as a general part with a large number of available footprints and do part creation for all of them directly and dynamically from this definition.
3) The last major portion of the design is a new parts manager/selector GUI for gschem. As Peter suggested it should probably remain as a separate entity from the current component library. This allows us to not only keep things neat for the sake of development, but will also (when everything is done) let us keep things like title blocks out of the parts database. When the selector is opened it should query the database for the basic types and select all the basic designs, sorting them by the 'library' field. When a specific library is selected all the base types in the library should be displayed, and when a base type is selected all of the available footprints for that type should be given. When a footprint is selected the manager should make the call to the database to construct the full part and prompt the user for any required values.
I know it's not a complete design and a lot of the fine detail is missing, but I think I've hit all of the major bases. Does anyone see any major oversights or flaws that would cause problems? Any suggestions for improvements or extensions are very welcome.
-Bob Sherbert
_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev