gEDA: RFC on new component model for gEDA

[Darin Ingimarson <darin-at-NOSPAMk2t_dot_com>]

Hi All,

I have come up with a first cut of requirements for what will eventually
form the geda front end to the gEDA software package.Please excuse the 
tardiness of this but my machine suffered a drive meltdown that caught me
between backups and stomped the original version of this file.

Initially, I wrote a bunch of code intended to become what Ales outlines
in the gEDA web pages -- geda as a simple program launcher to sort of tie
together all the varied applications and utilities that are supplied as
part of gEDA.

But what quickly became apparent was that the code I wrote only launched
applications (big deal, my index finger and a shell prompt can do that!),
and provided a simple tree representation of the files in a project. It
did nothing to assist the user in the design process (the real point of
EDA software).

Building the program launcher still provided no way to link the software
together, so I shelved the initial code. 

The first thing I really needed to do was to maintain the FLOW of the design
through gEDA with a flexible component model that accurately represents the
atomic unit of electronics design -- the component. This consistent 
represenation would encapsulate the component information and allow each
aspect of the gEDA software to only access those attribute it needs to be
concerned with.

What is really required is a way to model components that is portable and
accessible throughout all stages of electronics design. In this way it will
be possible to expose a single inteface to gschem, gpcb, etc. for component
data. 

I have therefore partitioned geda development into the following work plan:

1) Implement component model to link gschem, gpcb, etc. (including 
   implementation of component editing tools -- these tools, along
   with program launchers for gschem and gpcb will form the prototype 
   of the geda front end)
2) Integration of component model with existing tools -- gschem, gpcb
   (at this point there should be gschem, geda, gpcb in the dist.)
   At this point it would be convenient to look at integrating file
   translators, pre/post processors, etc.
3) Addition of basic report-generation, part management and costing
   utilities (as command-line programs in order to 
3) Design and integration of the project management facility
4) Incremental addition of "flashy" features (i.e. web links to datasheets,
   parameter-searchable relational parts databases, web links to
   distributors, etc).

What I have presented below is a (semi-formal) specification for the 
component model that comprises the first part of this job. Please give
this document some thought, if you feel that anything has been left out,
or you have questions about anything, please feel free to bring the issue
up in the mailing list so that everyone may partake in the discussion.

I'm sure that things have been left out, and I in no way consider this
carved in stone. I merely want to present the starting point for this
development in an open forum.

In the meantime I will continue with the coding that I have been doing, 
which at this point is an attempt to leverage some of the file reading
and writing capabilities that already exist in gschem into something
that may read the more general component representation (more on this
later).

I want to make sure that all the developers especially are with me here,
as if I have missed something in these specifications, it will only be
harder to add it later on in the process. Not only that, but I am being
brazen enough to suggest changes to the internal of others' code ;-)


1.0 Design Requirements for Component Model
-------------------------------------------

The following are the design requirements that I have assembled so far:

1.1) Component representation

In order to link gschem and gpcb a representation of electronic components
capable of containing real-world attributes (i.e. differing footprints,
symbols, physical attributes, vendor data sheet link, user-defined
parameters, etc.) is required.

The component representation must be capable of propogating the entire
representation of the component through all stages of the design.

For example, it should be possible, in either gschem or gpcb, to highlight
a component placed in the design and obtain the data sheet or other
information about the component.

1.2) Separation of Policy and Mechanism for Component Data Retreival 

The ability to retreive component information should be independant of the
method used to store the component representation. For example, the same
API must be exposed for the simplified component management case as for the
more complex relational database situation. All gEDA software will link to
this API, and all component information will travel through it.

Certain aspects of a component may not be made available in the simplified
instance, but that is to be expected for a component management situation
which attempts to restrict the administrative effort required.

1.3) Leverage online resources

The ability to extend the component model at a later date to support the
growing set of online resources should be integral in this design. This is
a feature I have not scheduled for full implementation until later in the
process, but as it is a component-level feature, it needs to be addressed
early on.



2.0 Component Model Specification
---------------------------------

The component model is based upon a representation of electronic components
as they exist in real life. For example, a given component may possess more
than one PCB footprint (i.e. DIP and SMT versions of a part, parts that 
may be mounted horizontally or vertically, or different pad shapes for
different PCB assembly processes).

Different components may also share PCB footprints, and even schematic
symbols. Therefore it is in our interests to parameterize as much of the
information contained within a component model, and use shared PCB patterns,
schematic symbols, etc. 

2.1 Required Attributes

A component must possess certain attributes by default:

 - component name (devoid of package specifiers)
 - description
 - default reference designator prefix (i.e. "U" or "R")
 - at least one valid schematic symbol

2.2 Optional/Class-defined Attributes

A component may possess optional attributes, or attributes dictated by its
class (to use an overworked term). 

 - type (i.e. connector, IC, resistor etc.) In the case where quote sheets
   are being assembled for vendors, it helps to have an additional description
   for the part of interest.
 - manufacturer name
 - none, one, or more PCB patterns (patterns should be differentiated
   at least by pattern style, and solder process). Each differing PCB
   pattern is annotated with the proper FULL manufacturer's part number,
   including packaging option.
 - link to manufacturer's data sheets (i.e. PDF files, web sites, etc.)
 - additional schematic symbols (i.e. alternate views such as IEEE format,
   DeMorgan, etc).
 - physical model attached to each valid package type (perhaps simply a 
   height applied to an assembly-layer line drawing in the PCB pattern)
 - User-defined attributes required and accessible by appropriate back ends
 - List of available speed grades, etc.

3.0  Access
-----------

Two models of data access are presented in order to support the anticipated
domains of use of this software. In either case, the mechanism used to supply
the data will be identical, with the same API used for both cases.

3.1 Component mode

In this mode a simple hierarchial directory structure is used to contain the
component models (which exist as keyword based text files, much like the 
current schematic symbol and PCB pattern files). A hierarchial directory
structure will be used to organize the part library and will avoid the
administrative expense of a (possibly complex) part database system.

Schematic symbols will be stored either in the component file itself, or
in the case of commonly used symbols (such as resistors, capacitors, etc.)
they will be stored in separate files and shared among multiple components.

In the case of PCB patterns, the current practice of using separate files
for each individual pattern should be sufficient. A file naming scheme 
based upon industry standard patterns and assembly precesses is suggested
(i.e. dip300_18_wave.foot) is suggested.

Component placement would operate much as it does now, with the exception 
being that the component browser would not display the names of the schematic
symbols (as it does now) -- it would display the component name separated
from any packaging specifics. For example, the SN74ABT541BDB and SN741ABTBDW
would both be displayed as the SN74ABT541B. 

This method of part selection will avoid the creation of parts libraries
clogged with variations of the same part that differ only on the packaging
options.


3.2 Manufacturing mode

In this mode all component information is contained in a centralized 
component database. It is accessed through database clients, and is
capable of providing a much richer set of information during the design
process.

All basic capabilities of Component Mode will be present in Manufacturing
Mode with the addition of the following features and capabilities:

Component Selection Functions
 - display current stock count before comitting component to design (for
   people prototyping systems this allows one to ensure stocked items are
   used and avoid the ire of cranky supervisors).
 - expected lead-time for out-of stock parts will also allow one to not
   use parts not readily available

Verification and Library Management
 - network access to a centrally managed part repository
 - component check in and verification with tools enforcing layout (similar
   to the ability of CVS to test code before allowing it to be checked in)

Project Costing and Procurement Functions
 - Based upon vendor's line card (i.e. list of manufacturer's and part types
   that the vendor can sell) generate a set of Requests for Quotes for a
   given project. 
 - Perform the above function, but use a vendor's online search engine to
   deliver online costs and quotes. 
 - Calculate the cost associated with manufacturing a given project.
 
One might initially be tempted to question the need for two methods of 
component storage, but the idea here is to leverage some of the very good
GPL'd database engines available so that it is not necessary to re-implement
things like sorts, database network access, network clients, etc.



3.3 Data Translation

It will be necessary to provide data translation capabilities in order to 
move component data from one format to another. The most obvious is the
conversion from Component Mode to Manufacturing Mode. It is my feeling that
this may be as easy as a simple inport/export script set (after all the 
contect of what is being stored hasn't changed, only the mechanism by
which it is supplied to the end user).

It should be possible to convert libraries from other applications as well
into gEDA format. I can perhaps whip up a converter for Accel EDA (as this
is what I use at work). I woudl be interested to hear what other packages
people would like to import components from.

Remember, that in order for gEDA to find acceptance in what is typically a
relatively stodgy market (i.e. designers are quite loathe to switch packages)
it must be as accomodating as possible to other component lobrary formats.


4.0) Proposed Work Plan for Development and Integration of Component Model
--------------------------------------------------------------------------

This is a first cut at a proposed work plan for accomplishing the above
stated goals. Several of these activities can be accomplished in parallel,
although no attempt has been made to represent this.

1) Creation of an accepted and adopted gEDA component model
2) Definition of a published data access method
3) Creation of component editor and associated tools
4) Translation of existing component libraries to new format (Component 
   mode for first implementation)
5) Integration of component data access method into existing packages
6) Implementation of import tools for component to manufacturing and
   manufacturing to component migration of data.

I have begun work on implementing the basic mechanisms for the file-based
access to component data (i.e. the "Component Mode" mentioned above) by 
trying to leverage existing gEDA functions as much as possible.

In response to the requests I have received to help with this, I appreciate
every one, but I would prefer to finish most of the initial planning work
on this, as well as play a bit with an API I've been kicking around before
adding more cooks to the stew. Maybe a couple more weeks until I get to
that point.

After this point I will definately be looking for some help as the
architecture solidifies a bit and parallelizm in the development becomes
more apparent. I will post a set of jobs to the mailing list and recruit
some willing volunteers to help out.

	-darin