[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Fwd: Parts DB API: the story so far
I wouldn't say we agree at all. I would say we have reached a
compromise. Not that either one of us had any real option. Plugins for
stock geda. Can I also ask that the dialog for pins allow one to select
if the pin is a bus pin or a net pin? Please?
The disagreement is about, if a database engine along with a data base
should be part of geda "base".
OK, when I read that last sentence, I realized the reality is I don't
care if it is or isn't. I do think that in reaching for the next level
that the data of components is going to be more complicated. But the
beauty of open source is since I think it is needed I am free to add it.
Please see the attached sql file for what I am thinking about.
In my opinion,
The first level was being able to create schematics and fabs, thus
symbols, schematic capture, netlisting and board layout were needed.
The second level was to push in hierarchical capabilities including
buses. Also getting simulators working.
The third level, is sophisticated drc (yep fewer opps over landpatterns
and symbols mismatches also fewer power and logic mismatches and
automated generation of fpga symbols in a way that is smart enough to at
least warn the user if power pins and io pins are being miss-used),
additional layout capabilities and integrating analog/digital and hdl
simulation together.
To me bom and document management is more a manufacturing issue then a
design issue but it is also important.
Cheers,
Steve Meier
Stuart Brorson wrote:
>> I think you two are arguing different things.
>>
>> Stuart claims that REQUIRING a database ENGINE for ANY use of gEDA is
>> bad for the project.
>>
>> Steve claims that ALLOWING a database SCHEMA for MANY uses of gEDA is
>> good for the project.
>>
>> I think you can both be happy with a gEDA that MAY use a database
>> engine, but does not NEED one. Likewise, gEDA may ship with a
>> "database" which is merely a collection of CSV text files - complex
>> enough for simple uses yet without the dependency hell of requiring a
>> relational database engine.
>>
>
> I think we're having a violent agreement.
>
> Yes, allowing power uses to plug-in a database is a good thing.
> Mandating that everybody use a database is bad. I believe Steve and
> I can eventually agree on this.
>
> I see several layers when peeling this onion. Here's a vision with
> several stinky layers:
>
> 1. The basic gEDA installation should work without any changes to the
> existing symbol/footprint operation. Basic gEDA is for newbies,
> students, and folks with minimal project requirements. It should work
> out of the box, as it (sometimes) does now.
>
> 2. Providing hooks for symbol/pin/footprint mapping is fine, as long
> as the system functions in the current way in the absence of mapping
> files/databases/etc. The hooks can take any form; the hooks will be
> some sort of API which calls methods on an external module (i.e. a
> plug-in).
>
> 3. A rudimentary mapping file -- a flat text file -- is OK, and could
> certainaly be shipped with the base gEDA. The mapping would be
> performed using an *external* plug-in module, also distributed with
> gEDA. However, I wouldn't personally like to see the mapping module
> activated by default, since:
>
> 1) It represents a level of indirection over the the existing symbol
> scheme. This can be confusing to newbies.
> 2) It is an additional component which can break. Less components =
> greater reliability.
>
> IMO, The user should be required to plug in the module himself, so he
> knows what has happened. The mapping file could be enabled using a
> setting in gafrc, or perhaps also using a button in the gschem/gattrib
> GUI. Finally, the mapping module could easily be a component of
> xgsch2pcb.
>
> 4. For advanced users, the external plug-in which does
> symbol/pin/footprint mapping could be replaced using a different
> plug-in talking to a database. This database plug-in could implement
> any and all functionality which power users might bake into it. I
> could certainly support distributing the database plug-in with gEDA,
> but would not want to see us get into the business of distributing or
> supporting databases. Therefore, our database module might be a
> plug-in which emits SQL over a socket (or DBUS, or whatever). In any
> case, there would be an adaptation layer between gschem/gattrib and
> the database; that adaptation layer would be a plug-in.
>
> Sound sensible?
>
> Stuart
>
>
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>
>
----------------------------------------------------------------------------------------------------
-- AKEDA SQL COMPONENT DATABASE
--
-- Copyright (C) 2007 Stephen F. Meier
--
-- This code is free software; you can redistribute it and/or
-- modify it under the terms of the GNU General Public
-- License as published by the Free Software Foundation; either
-- version 2 of the License, or (at your option) any later version.
--
-- This library is distributed in the hope that it will be useful,
-- but WITHOUT ANY WARRANTY; without even the implied warranty of
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-- Library General Public License for more details.
--
-- You should have received a copy of the GNU General Public License
-- along with this program; if not, write to the Free Software
-- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
--
-- Version 0.01 Dec 22, 2007
-- Version 0.02 Dec 23, 2007 Changes to tb_component_type and tb_logic_family. added tables,
-- sequences tb_bank_to_lf and tb_modification
-- Version 0.03 Dec 24, 2007 Broke up logic family table into logic family table and logic level table
-- add a logic family to logic level map table
----------------------------------------------------------------------------------------------------
-- sq denotes a sequence
-- tb denotes a table
----------------------------------------------------------------------------------------------------
-- a bank is a collection of pins which share the same logic family
-- a bank includes io pins and may include power pins
----------------------------------------------------------------------------------------------------
-- a slot is a collection of pins which are grouped together because
-- they are part of the same logical function
----------------------------------------------------------------------------------------------------
-- io pins belong to one or more slots
-- power pins belong to a bank
-- slots belong to a bank
-- banks belong to components
-- For example a 7400
-- 1 bank with four slots and 2 power pins
-- slot 1 has pins 1 and 2 are inputs 3 is an output
-- slot 2 has pins 4 and 5 are inputs 6 is an output
-- slot 3 has pins 9 and 10 are inputs 8 is an output
-- slot 4 has pins 12 and 13 are inputs 11 is an output
-- pins 7 and 14 are power pins
----------------------------------------------------------------------------------------------------
CREATE SEQUENCE "sq_component_type" start 1 increment 1 NO MAXVALUE minvalue 1 cache 1;
CREATE TABLE "tb_component_type" (
"component_type_key" integer DEFAULT nextval('sq_component_type'::text) NOT NULL,
"type_name" text,
"description" text,
"history" bool -- false if this is an active record
);
----------------------------------------------------------------------------------------------------
CREATE SEQUENCE "sq_logic_level" start 1 increment 1 NO MAXVALUE minvalue 1 cache 1;
CREATE TABLE "tb_logic_level" (
"logic_level_key" integer DEFAULT nextval('sq_logic_level'::text) NOT NULL,
"vcc" float,
"vdd" float,
"vol_max" float, -- to be logic low must be below this value
"voh_min" float, -- to be logic high must be above this value
"vil_max" float, -- to drive logic low must be below this value
"vih_min" float, -- to drive logic high must be above this value
"differential" bool,
"diff_voltage" float,
"history" bool -- false if this is an active record
);
----------------------------------------------------------------------------------------------------
CREATE SEQUENCE "sq_logic_family" start 1 increment 1 NO MAXVALUE minvalue 1 cache 1;
CREATE TABLE "tb_logic_family" (
"logic_family_key" integer DEFAULT nextval('sq_logic_family'::text) NOT NULL,
"description" text,
"five_v_tolerent" bool, -- device is io pins are tolerent of ttl voltage levels
"history" bool -- false if this is an active record
);
----------------------------------------------------------------------------------------------------
-- table to map logic families to logic levels
-- some logic families support different logic levels depending upon
-- what voltage levels their power pins are connected to
CREATE SEQUENCE "sq_lf_to_ll" start 1 increment 1 NO MAXVALUE minvalue 1 cache 1;
CREATE TABLE "tb_lf_to_ll" (
"lf_to_ll_key" integer DEFAULT nextval('sq_lf_to_ll'::text) NOT NULL,
"logic_family_key" integer,
"logic_level_key" integer,
"history" bool -- false if this is an active record
);
----------------------------------------------------------------------------------------------------
CREATE SEQUENCE "sq_component" start 1 increment 1 NO MAXVALUE minvalue 1 cache 1;
CREATE TABLE "tb_component" (
"component_key" integer DEFAULT nextval('sq_component'::text) NOT NULL,
"description" text,
"package" text,
"footprint" text, -- pin numbering schemes may require explicit footprint pattern declaration
"value" integer,
"unit" text, -- e.g. mAmps, uHenries
"history" bool -- false if this is an active record
);
----------------------------------------------------------------------------------------------------
-- table to map io banks to logic families. An i/o bank on an fpga can belong to one
-- of several logic families depending upon what voltage level some of its power pins
-- are connected to.
CREATE SEQUENCE "sq_bank_to_lf" start 1 increment 1 NO MAXVALUE minvalue 1 cache 1;
CREATE TABLE "tb_bank_to_lf" (
"b_to_lf_key" integer DEFAULT nextval('sq_bank_to_lf'::text) NOT NULL,
"logic_family_key" integer,
"bank_key" integer,
"history" bool -- false if this is an active record
);
----------------------------------------------------------------------------------------------------
-- an io bank's logic family/logic level can be selected by its vccio and vddio pins
CREATE SEQUENCE "sq_bank" start 1 increment 1 NO MAXVALUE minvalue 1 cache 1;
CREATE TABLE "tb_bank" (
"bank_key" integer DEFAULT nextval('sq_bank'::text) NOT NULL,
"component_key" integer, -- parent component this bank belongs to
"vccio_pwr_pin_key" integer, -- pin key for one of the Vcc pins
"vddio_pwr_pin_key" integer, -- pin key for one of the Vdd pins
"history" bool -- false if this is an active record
);
----------------------------------------------------------------------------------------------------
CREATE SEQUENCE "sq_slot" start 1 increment 1 NO MAXVALUE minvalue 1 cache 1;
CREATE TABLE "tb_slot" (
"slot_key" integer DEFAULT nextval('sq_slot'::text) NOT NULL,
"bank_key" integer, -- parent bank this slot belongs to
"history" bool -- false if this is an active record
);
----------------------------------------------------------------------------------------------------
-- table to map pin to slots. A i/o pin on an fpga can belong to one or more slots
-- used single ended it can be swapped with any other pin in the io bank
-- used differential (if possible), it and its partner can be swapped with another differential pair
-- in the same io bank
-- some pins serve dual purposes such as configuration pins and then as io pins
CREATE SEQUENCE "sq_pin_to_slot" start 1 increment 1 NO MAXVALUE minvalue 1 cache 1;
CREATE TABLE "tb_pin_to_slot" (
"p_to_s_key" integer DEFAULT nextval('sq_pin_to_slot'::text) NOT NULL,
"pin_key" integer,
"slot_position" integer, -- location of pin in slot
"history" bool -- false if this is an active record
);
----------------------------------------------------------------------------------------------------
CREATE SEQUENCE "sq_pin" start 1 increment 1 NO MAXVALUE minvalue 1 cache 1;
CREATE TABLE "tb_pin" (
"pin_key" integer DEFAULT nextval('sq_pin'::text) NOT NULL,
"bank_key" integer, -- io bank pin belongs too
"pin_number" text, -- pin number needed for netlist generation
"type" integer, -- input, output, in/out, power, nc
"differential" bool, -- TRUE if a differential
"diff_partner" integer, -- pin_key of the partner of this pin if this pin is a differential pin
"diff_complement" bool, -- TRUE if a differential and is the complement member of the pair
"Voh_min" text, -- contains an equation used to determine minium output voltage when driven high
"Vol_max" text, -- contains an equation used to determine maximum output voltage when driven low
"max_v" text, -- contains an equation used to determine absolute maximum voltage to be applied to this pin
"min_v" text, -- contains an equation used to determine absolute minimum voltage to be applied to this pin
"history" bool -- false if this is an active record
);
----------------------------------------------------------------------------------------------------
CREATE SEQUENCE "sq_modification" start 1 increment 1 NO MAXVALUE minvalue 1 cache 1;
CREATE TABLE "tb_modification" (
"modification_key" integer DEFAULT nextval('sq_modification'::text) NOT NULL,
"user_id" integer DEFAULT 0,
"modification_date" timestamp with time zone,
"description" text,
"table" integer DEFAULT 0, -- which table was modified
"old_id" integer DEFAULT 0, --
"new_id" integer DEFAULT 0
);
----------------------------------------------------------------------------------------------------
-- initialize the logic level table
-- lvttl 3.3V
insert into tb_logic_level (vcc, vdd, Vol_max, Voh_min, Vil_max, Vih_min, differential, diff_voltage, history) values (3.3, 0, 0.4, 2.4, 0.7, 2.0, false, 0, false);
-- ttl 5V
insert into tb_logic_level (vcc, vdd, Vol_max, Voh_min, Vil_max, Vih_min, differential, diff_voltage, history) values (5, 0, 0.5, 2.4, 0.8, 2.0, false, 0, false);
-- cmos 1.8V
insert into tb_logic_level (vcc, vdd, Vol_max, Voh_min, Vil_max, Vih_min, differential, diff_voltage, history) values (1.8, 0, 0.45, 1.45, 0.65, 1.2, false, 0, false);
-- cmos 2.5V
insert into tb_logic_level (vcc, vdd, Vol_max, Voh_min, Vil_max, Vih_min, differential, diff_voltage, history) values (2.5, 0, 0.4, 2.0, 0.7, 1.7, false, 0, false);
-- cmos 5V
insert into tb_logic_level (vcc, vdd, Vol_max, Voh_min, Vil_max, Vih_min, differential, diff_voltage, history) values (5, 0, 0.5, 4.4, 1.5, 3.5, false, 0, false);
-- ecl -5.2V
insert into tb_logic_level (vcc, vdd, Vol_max, Voh_min, Vil_max, Vih_min, differential, diff_voltage, history) values (0, -5.2, -1.145, -1.695, -1.225, -1.625, true, 0.65, false);
-- lvpecl 3.3V
insert into tb_logic_level (vcc, vdd, Vol_max, Voh_min, Vil_max, Vih_min, differential, diff_voltage, history) values (5, 0, 3.855, 3.305, 3.775, 3.375, true, 0.65, false);
-- pecl 5V
insert into tb_logic_level (vcc, vdd, Vol_max, Voh_min, Vil_max, Vih_min, differential, diff_voltage, history) values (5, 0, 3.855, 3.305, 3.775, 3.375, true, 0.65, false);
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user