gEDA-user: Managing parts multiple parts - physical part table feature request?

["natbuk" <natbuk@xxxxxxxxxxxx>]

Hi,

Just been looking at the whole gEDA thing for the first time. Serious
congratulations on the state of the tools. Kudos to all the contributors.

I am a long-time Cadence user (professionally) - I also have my own projects
for which a cheap (free!) tool that'd do the job would be bonza.  

So, I'll cut to the chase - I'm really missing a way to manage passive parts
like Rs and Cs in a sensible way. Perhaps someone has some suggestions on a
suitable method other than my suggestion below? 

Some background:

As a designer, I like to have quite a lot of specific component information
at placement time - this might include  parameters such as price, mfr part
number, ripple current, height, dielectric, a hyperlink to a data sheet etc.
For good designs, this kind of information is important as sometimes two
cheap parts will better one more expensive one, does the part contain lead
etc.  I also like to have a rich database of parts to choose from with many
values. 

As a librarian, I require a simple (minimal typing) method for entering
zillions of parts that often look identical on the schematic except for some
attributes (e.g. capacitors).

As a manufacturer (or sub-contractor thereof) I like to supply purchasing
information as part of the bill of materials. At least the mfr part number,
usually a price ea, order code, distributor etc. This information may change
from time to time, but I still need my designs to compile, and preferably it
the up-to-date info I have entered. Bad or minimal data to kitters means
lots of hassle.

Cadence Concept achieves all this very simply and looking at the front end
side of gEDA, it looks like it's almost there, which leads me to my feature
request (or some pointers to how to achieve with the existing system).
Please forgive the long post - 

The c(C)oncept:

* for each library part (symbol), a text file (optionally) exists with
property headings such as value, type, voltage, footprint etc.
* when I place a part from the library, I can choose either the current gEDA
method or the 'part from a text file' method
* each single physical part (one that can be ordered from a mfr) is
represented by a single line in the text file
* there are two types of properties - I'll call them 'hard' and 'soft'
(can't think of better words right now)
* each physical part is represented by a unique set of hard properties -
(unique so the netlist compiler can identify)
* when a part is placed in the schematic, an additional dialogue box is
presented which lists the contents of the text file
* by selecting one of the 'lines' in the text file, hard properties are
added to the symbol body at placement time as if they had been added
manually or from the symbol
* soft properties are used to provide the designer with additional info and
used by the compiler/bom generator for things like price, order code,
footprint
* The dialogue box should recognise hyperlinks and spawn a viewer if the
hyperlink is clicked - this makes data sheets easily available at placement
time
* if no text file exists, the existing method can be used (for backwards
compatibility)
* The dialogue box which displays the text file has basic searching and
sorting capability (e.g. sort by value, show only parts with *0603* in
footprint).
* on the symbols, a property may be added with no value specified (as
currently) and this value is populated (or overwritten) if the part is
placed using the text file.

Notes:
When the cadence netlist compiler runs, it cross references the hard
properties which uniquely identify each physical part and can use additional
(soft) properties for items such as the PCB footprint. When the BOM
generator runs, it also uses these files to extract any parameters (user
defined), just like gEDA does, but as I understand it, gEDA requires the
property to either have been added to the symbol during library creation or
manually added on the symbol during schematic capture. Keeping things like
PCB footprint 'soft' (e.g. could specify a different heading to be used as
footprint to the netlist compiler) allows the use of multiple PCB design
packages and existing footprints easily.
The main distinction between hard and soft properties is that because hard
properties effectively become part of the schematic (or library), if you go
and edit them and then try to compile an old design, the whole thing breaks
- so one must be careful with the hard properties - but, the soft
properties, because they are effectively linked during a netlist compile,
can be changed at will and old designs remain good.

As an example, here is a snippet from a concept ppt (physical part table):
(apologies for the formatting as I'm sure it will go awry! Each of the lines
representing a part begins with a value in this example - in the complete
file, there were more fields including digikey order codes, but I truncated
it for brevity - the original file contained 490 capacitors - most of the
Panasonic ECJ series stocked by Digikey)

PART'CAP_CER'

 

{===========================================================================
===========}                                                
:VALUE  | TYPE           | DIELECTRIC | VOLTAGE  | TOL     = JEDEC_TYPE |
ALT_JEDEC_TYPE | LEAD_FREE      |   GENERIC 	| MFR   
{===========================================================================
==}                                                         
'0.5pF' | PANA_0402_ECJ  | NPO	  | 50V	 |'.25pF' = 0402C      |  0402C
| LEAD_FREE      |   NO       |  PANASONIC  |
'1.0pF' | PANA_0402_ECJ  | NPO	  | 50V	 |'.25pF' = 0402C      |  0402C
| LEAD_FREE      |   NO       |  PANASONIC  |
'1.5pF' | PANA_0402_ECJ  | NPO	  | 50V	 |'.25pF' = 0402C      |  0402C
| LEAD_FREE      |   NO       |  PANASONIC  |
'2.0pF' | PANA_0402_ECJ  | NPO	  | 50V	 |'.25pF' = 0402C      |  0402C
| LEAD_FREE      |   NO       |  PANASONIC  |
'3.0pF' | PANA_0402_ECJ  | NPO	  | 50V	 |'.25pF' = 0402C      |  0402C
| LEAD_FREE      |   NO       |  PANASONIC  |

Although this might seem cumbersome at first, the text file is very
powerful. If you want, they can be edited in excel or similar, but I use a
text editor with column support. Obviously, scripting is quite
straightforward for some tasks.  I recently entered over 1200 capacitors
into the database in 2 hours including mfr part numbers, order codes,
prices, footprints and about a dozen other parameters using largely cut and
paste from .pdf catalogues and column editing - very speedy! In the above
snippet, the parameters to the left of the equals sign are hard and the ones
on the right of the equals sign are soft so the set to the left of the =
must be unique. Stuff the right of the = can be anything and is only
examined by the netlister/bom generator if specifically instructed. 

Anyway, that's my ha'penny. Judging by the front end, I guess the developers
have concept (or SCALD) experience, so this is probably not new, but at
least to me, would turn this package into a baby Concept. 

And for my next suggestions, shall we talk about a constraints editor? OK,
I'll shut up now!

Seriously high regards to the developers,

Nat