X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=xUpZCpsVzQOThlNC3aevMWnwSA4UWErqwPa/n9WIWzA=; b=ZniK4+f8BuScmhDknSUsh6iK3jp4jqoLlDDcYc5T7aFTxVS+KSwjsB9EQ0E9VMPMyw BornPkyBMlc40zvrTEswWaMq+G83vNTTZ2tj0M+uEb851YvlDUanFgM9QoZa3heXa9mq JwXzWcsF6kFRkkXbtt2NwI+cQVTng05025SxKETUqwgkk6qDrjFQUxMupF2YH3d9OITR Y9dsflRGh02dCOIao8xoXgMPj1Ip7y9f5Y6P6ZWmovNQrGnHmwr/PIZayaKWcks0vlyF f3Ge72HaT51Few4dRV4Fn7pyhkXuCzeb9RHit7vWbvD1Ndd/hx3MXK94MH/xqSJRA9Gl LJTw== MIME-Version: 1.0 X-Received: by 10.194.174.197 with SMTP id bu5mr3110698wjc.71.1393975278702; Tue, 04 Mar 2014 15:21:18 -0800 (PST) In-Reply-To: <20140304202748.27343.qmail@stuge.se> References: <1391043267 DOT 2058 DOT 19 DOT camel AT AMD64X2 DOT fritz DOT box> <20140303174655 DOT A167B807ABF3 AT turkos DOT aspodata DOT se> <1393874264 DOT 2120 DOT 51 DOT camel AT AMD64X2 DOT fritz DOT box> <20140304124149 DOT 2ECEF807ABF4 AT turkos DOT aspodata DOT se> <20140304202748 DOT 27343 DOT qmail AT stuge DOT se> Date: Tue, 4 Mar 2014 15:21:18 -0800 Message-ID: Subject: Re: [geda-user] Pin length stretch for schematics symbols useful? From: Ouabache Designworks To: geda-user AT delorie DOT com Content-Type: multipart/alternative; boundary=089e013d1a6050137b04f3d02939 Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk --089e013d1a6050137b04f3d02939 Content-Type: text/plain; charset=ISO-8859-1 Yes, Lets call it the Electronic Data Interchange Format :) Seriously I would like to help in this effort. I am currently working on a open source eda tool suite based on ip-xact and extending it to support symbol graphics is a natural extension. John Eaton On Tue, Mar 4, 2014 at 12:27 PM, Peter Stuge wrote: > karl AT aspodata DOT se wrote: > > Think of, just one symbol. > > Creating a universal data model for parts is indeed key for free and > open source EDA software to have any kind of significant impact in > the world. > > But it is no small task! > > It is also not a task that neccessarily has anything to do with > existing EDA suites, beyond that the data model must of course not > repeat any mistakes that have already been made in existing programs. > > The data model exists between EDA suites, fabs and part vendors. > (User requirements flow from EDA suit and/or fab.) > > The model must encompass every real-world characteristic of parts > which EDA suites and fabs care about today, and ideally also be > future-proof enough that the same model can be extended, as EDA > suites and fabs learn to make use of even more part characteristics > in the future. > > The project as I see it would have as deliverables a specification > document and a portable C library implementing the specification. > > I'd suggest a permissive license such as MIT for the implementation, > so that the door is open for closed source EDA suites and fab tools > to use the library later on, thus giving the project a chance to > eliminate the ridiculous exclusivity of parts within single EDA suite > vendors, and allow for somehow sensible integration across the full > design and production cycle. > > Anyone else interested in this? > > > //Peter > --089e013d1a6050137b04f3d02939 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, Lets call it the Electronic Data Inter= change Format :)


Seriously I would like to help in this ef= fort.=A0 I am currently working on a open source eda tool suite based
<= /div> on ip-xact and extending it to support symbol graphics is a natural extensi= on.

John Eaton






On Tue, Mar 4, 2014 at 12:27 PM, Peter Stuge <peter AT stuge DOT se> = wrote:
karl AT aspodata DOT se wrote:
> Think of, just one symbol.

Creating a universal data model for parts is indeed key for free and
open source EDA software to have any kind of significant impact in
the world.

But it is no small task!

It is also not a task that neccessarily has anything to do with
existing EDA suites, beyond that the data model must of course not
repeat any mistakes that have already been made in existing programs.

The data model exists between EDA suites, fabs and part vendors.
(User requirements flow from EDA suit and/or fab.)

The model must encompass every real-world characteristic of parts
which EDA suites and fabs care about today, and ideally also be
future-proof enough that the same model can be extended, as EDA
suites and fabs learn to make use of even more part characteristics
in the future.

The project as I see it would have as deliverables a specification
document and a portable C library implementing the specification.

I'd suggest a permissive license such as MIT for the implementation, so that the door is open for closed source EDA suites and fab tools
to use the library later on, thus giving the project a chance to
eliminate the ridiculous exclusivity of parts within single EDA suite
vendors, and allow for somehow sensible integration across the full
design and production cycle.

Anyone else interested in this?


//Peter

--089e013d1a6050137b04f3d02939--