[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
Hi,
attached is a 1st version of the table definitions. The file should be
self-documenting.
Armin
-- author: Armin Faltl
-- date : 2010-04-28
-- description:
-- This collection of tables shall describe the connectivity between
-- schematic symbols, parts, packages of electronic parts and
-- copper footprints.
-- It shall take into account the influenc of different production
-- processes on the possible copper patterns.
-- Additionally other relations like part to simulator-model
-- shall be supported.
--
-- Database Design Considerations:
-- Since the pinout of symbols is mapped to footprints via parts and
-- packages, a many-to-many relation of symbols to parts would need
-- some sort of pinout-descriptor or wisely restricting the assigned
-- symbols to a part. This would introduce a further pitfall, so as
-- of now, the table definitions allow only one symbol per part.
-- Not including symbols at all would lose the ability to relate
-- symbol-pins to footprint pins of course.
-- choosing footprints for symbols of parts is a total mess atm!
-- there has to be some hierarchy and order
create table category (
ctg_idx serial primary key, -- just to show you, I know other types than "varchar"
ctg_name varchar unique
);
insert into category (ctg_name) values ('resistor');
insert into category (ctg_name) values ('capacitor');
insert into category (ctg_name) values ('inductor');
insert into category (ctg_name) values ('diode');
insert into category (ctg_name) values ('transistor');
-- and so on
-- enumeration of symbols
-- - or more, including a path to the symbol file,
-- general description etc.?
create table symbol (
sym_name varchar primary key,
categ integer references category,
descr varchar -- a short description of what the symbol represents
);
-- "part" is what sometimes is stated in the "device" in gschem, but it should
-- be more specific than "RESISTOR" - or not?
-- Beware! certain "devices" have different pinout, depending on the package.
-- Because the symbol is not in the primary key, this has to be handled in the
-- part_name. The unique ID provided by ordering information should do.
create table part (
part_name varchar primary key, -- this is either a vendor part name/number
-- or a generic pseudo-part denoting an
-- anonymous class of parts providing the function
-- it is questionable to state a symbol here, since it restricts
-- a many-to-many relation to a one-to-many
symbol varchar references symbol, -- thou shall not assign a MOSFET part to
-- a resistor symbol
categ integer references category, -- if this doesn't match the symbols category
-- you might expect trouble
part_spec varchar, -- URI/path to specification
alias varchar references part -- this is an alias to a canonical part for the
-- purpose of grouping specialized vendor stuff
-- to a coarser view
-- stock integer -- inhouse stock of this part
);
----------------------------
-- layout relevant tables --
----------------------------
-- "package" is a table describing the physical package attributes
create table package (
pkg_name varchar, -- canonical name as of a standard or manufacturer
pgk_spec varchar -- URI to a specification of the package
-- 3d_model varchar -- for rendering ala kicad or mechanical cad
);
-- "part_pkg", this is a many-to-many relation, requiring a correlation table
--
-- Beware! certain parts have different pinout, depending on the package.
-- In that case there is a connection between the symbol and the package,
-- that is not expressed explicitly here.
create table part_pkg (
part varchar references part,
pkg varchar references package
);
-- "footprint", the actual copper pattern
create table footprint (
fp_name varchar primary key,
lib_name varchar, -- name/path of the library, containing the footprint
);
-- enumeration of processes, to avoid "inventions"
create table process (
proc_name varchar primary key
};
insert into process (proc_name) values ('hand');
insert into process (proc_name) values ('wave');
insert into process (proc_name) values ('reflow');
-- and so on
-- "pkg_fp" expresses the relation between package, footprint and process
create table pkg_fp (
package varchar references package,
process varchar references process,
footprint varchar references footprint
);
--------------------------------
-- simulation relevant tables --
--------------------------------
--
-- the simulation stuff is not very well thought out
--
create table simulator (
sim_name varchar primary key
-- add stuff to describe the simulator here...
);
create table model (
model_file varchar primary key,
simulator varchar references simulator,
model_part varchar references part,
param varchar -- list of parameters to feed into the model for
-- that particular part
);
-- create table model_part (
-- model varchar primary key,
-- part varchar references part,
-- param varchar -- list of parameters to feed into the model for
-- that particular part
-- );
-----------------
----------------- OBSOLETE THOUGHT FRAGMENTS BELOW
-----------------
-- part-library to vendor reference and footprint connectivity
-- the refdes would actually express a schematic instead of augmenting it
-- create table convy (
-- refdes varchar, -- the gschem refdes attribute, unique in the board
-- fp_local varchar, -- local footprint file-name (path ?)
-- ipc varchar, -- footprint name according to
-- -- IPC-7351A Naming Convention for Standard SMT Land Patterns
-- part_spec varchar, -- file/path of the components datasheet
-- part_uri varchar -- URI, typically on manufacturer website showing the part
-- );
-- create table supply (
-- part_spec varchar, -- file/path of the components datasheet
-- part_uri varchar -- URI, typically on manufacturer website showing the part
--);
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user