X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-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=02HF6sOT6bptlvjAHOn77z2CSdacA/AVF5ZpgmwCkRI=;
	b=RXWtdMN87c2VltarxQ1dWCVoMihwbm8GKbWQP7JaLtFsCy9FpRYufciRCXynpStcN8
	Y2eGjU0dM6Lm7UMW/pCWYHysOCzhb5BrlcORyQIhzU3Bm39gQ9iWkIRqnn/+R+VJvqzZ
	VsCF1vOKt5TJB4SkyxLql3AFKZBvgmS0ByJfNxdaX9axEtx6nAbJRLB+AX8ptbqOr6hr
	RkxDc4+YX7f9eoSWBFAaI9cJV/7cIjVY5HmH4kSSF6cfGNyMhqM8pIFxedaB4tjY90lg
	NBdOZDnh9XSqKkU96/uMSMEWTwnDzwi+vlwuTV7yPJ5wJcsjUQyGIO7letIQ1sdSB1ka
	/fqA==
MIME-Version:	1.0
X-Received:	by 10.50.87.100 with SMTP id w4mr20819850igz.62.1450738393173;
	Mon, 21 Dec 2015 14:53:13 -0800 (PST)
In-Reply-To:	<20151221203331.20837.qmail@stuge.se>
References:	<CAOFvGD6OiYxcGkOiQRVnvXW3TLs42bt7PE5Ot9s09hsukYicKA AT mail DOT gmail DOT com>
	<20151221030451 DOT 02399163eb3e40f21c622c41 AT gmail DOT com>
	<CAOP4iL1PTdeCZdT+SthHwQtaxC4x06MbBQmxRcK3DZyQ-jfw=Q AT mail DOT gmail DOT com>
	<20151221203331 DOT 20837 DOT qmail AT stuge DOT se>
Date:	Mon, 21 Dec 2015 14:53:12 -0800
Message-ID:	<CAOP4iL0_Pt03R0FDQK_ewsZNwBx7URCQazWqRU+HKHQmbFSFQQ@mail.gmail.com>
Subject:	Re: [geda-user] Proposing a New Hierarchical Data Structure?
From:	"Ouabache Designworks (z3qmtr45 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
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

--047d7bf183de9658230527705adc
Content-Type: text/plain; charset=UTF-8

On Mon, Dec 21, 2015 at 12:33 PM, Peter Stuge (peter AT stuge DOT se) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:

> Ouabache Designworks (z3qmtr45 AT gmail DOT com) [via geda-user AT delorie DOT com]
> wrote:
> > Until you nail down your foundation it wont do you any good to start
> > off building on it.
>
> I disagree. It's possible and good to start at arbitrary levels of
> abstraction and work in both directions.
>
> But what works for you works for you. :) Please help with describing
> the objects.
>
>
> //Peter
>


Ok, Lets start with the component name.


You create a gEDA component and you pick a name out of thin air. There is
no guarantee that some other designer has not also selected that same
name.  When the day comes that you have to put two different components
with the same name together in your design then gEDA is going to fail. Why
don't we plan for that day and build in a component identifier that can
create unique names.


Besides having a field for the component name you will also need a field
for a hierarchical library name and a vendor name. Each library can manage
it's own namespace and the vendor can manage the library names. We pick
vendor names by using the IP-Xact convention of using a URL that you own.
Nobody else in the world will have the same vendor name.

This means when you instantiate a component then you must provide the
vendor,library and component names to identify that component. We need to
add those fields into our data structures.


We define how we package a component to put it into our design environment
or into a storage vault. A component package is a directory that contains
every file needed to build that component and no files that are needed to
build any other component. That directory is placed under the control of a
revision control system.  Data is never copied in any data base. One
location is created for the master copy and everyone who needs it must
clone it from that master location.  The RCS provides tools to verify that
all the bits are correct and can tell you if changes have been made to
either the master or the clone. If you simply copy data without cloning
then you can lose track of the master copy and any bug fixes will not make
it back. Your data can go viral and it can be a mess.


We define a library package as a directory that contains the repositories
of components from that library. It will not contain any components from
any other library.  That way you can download a library repository and get
all the components at the same time.


This way you can go to a vendor like gEDA's website and download their
entire catalog. You store that in your design environment next to the repos
from all your other suppliers. By keeping track of the location of every
component repo in your design environment you can locate any file from
inside a component simply by knowing its location relative to its own
repository.

If you have ever had to create a toolflow that took the verilog model of a
ROM from its component repo and had to readmemh the generated bits file
from a software repo then that is quite handy.



John Eaton

--047d7bf183de9658230527705adc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Dec 21, 2015 at 12:33 PM, Peter Stuge (<a href=3D"mailto:peter@=
stuge.se">peter AT stuge DOT se</a>) [via <a href=3D"mailto:geda-user AT delorie DOT com"=
>geda-user AT delorie DOT com</a>] <span dir=3D"ltr">&lt;<a href=3D"mailto:geda-us=
er AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"">Ou=
abache Designworks (<a href=3D"mailto:z3qmtr45 AT gmail DOT com">z3qmtr45 AT gmail DOT co=
m</a>) [via <a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com<=
/a>] wrote:<br>
&gt; Until you nail down your foundation it wont do you any good to start<b=
r>
&gt; off building on it.<br>
<br>
</span>I disagree. It&#39;s possible and good to start at arbitrary levels =
of<br>
abstraction and work in both directions.<br>
<br>
But what works for you works for you. :) Please help with describing<br>
the objects.<br>
<br>
<br>
//Peter<br></blockquote><div><br><br></div><div>Ok, Lets start with the com=
ponent name.<br><br><br></div><div>You create a gEDA component and you pick=
 a name out of thin air. There is no guarantee that some other designer has=
 not also selected that same name.=C2=A0 When the day comes that you have t=
o put two different components with the same name together in your design t=
hen gEDA is going to fail. Why don&#39;t we plan for that day and build in =
a component identifier that can create unique names.<br><br><br></div><div>=
Besides having a field for the component name you will also need a field fo=
r a hierarchical library name and a vendor name. Each library can manage it=
&#39;s own namespace and the vendor can manage the library names. We pick v=
endor names by using the IP-Xact convention of using a URL that you own. No=
body else in the world will have the same vendor name.<br><br></div><div>Th=
is means when you instantiate a component then you must provide the vendor,=
library and component names to identify that component. We need to add thos=
e fields into our data structures.<br><br><br></div><div>We define how we p=
ackage a component to put it into our design environment or into a storage =
vault. A component package is a directory that contains every file needed t=
o build that component and no files that are needed to build any other comp=
onent. That directory is placed under the control of a revision control sys=
tem.=C2=A0 Data is never copied in any data base. One location is created f=
or the master copy and everyone who needs it must clone it from that master=
 location.=C2=A0 The RCS provides tools to verify that all the bits are cor=
rect and can tell you if changes have been made to either the master or the=
 clone. If you simply copy data without cloning then you can lose track of =
the master copy and any bug fixes will not make it back. Your data can go v=
iral and it can be a mess.<br><br><br></div><div>We define a library packag=
e as a directory that contains the repositories of components from that lib=
rary. It will not contain any components from any other library.=C2=A0 That=
 way you can download a library repository and get all the components at th=
e same time.<br><br><br></div><div>This way you can go to a vendor like gED=
A&#39;s website and download their entire catalog. You store that in your d=
esign environment next to the repos from all your other suppliers. By keepi=
ng track of the location of every component repo in your design environment=
 you can locate any file from inside a component simply by knowing its loca=
tion relative to its own repository.<br><br></div><div>If you have ever had=
 to create a toolflow that took the verilog model of a ROM from its compone=
nt repo and had to readmemh the generated bits file from a software repo th=
en that is quite handy.<br><br><br><br></div><div>John Eaton<br><br></div><=
div><br><br></div><div><br><br><br><br><br></div><div><br>=C2=A0<br></div><=
/div><br></div></div>

--047d7bf183de9658230527705adc--

- Raw text -