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=FEmwpxBF9tC4NLYO/8AK2jv5Ws7tCZM9bEB8SFbYrVM=;
	b=J4xAx6ByAv0HTHIkjTLqWbcfpQj5cghx76fhRqa21hOz6bVLZfJQ/Tucy2b5FEvOuQ
	MbFlqOmcXVEcKcmIoxTWt+YKe8h943ahawdmgC2zW58WdOtiWMDPnQbFIFTmSuXymv5z
	KdwSDtobg4u0CH69QurVIWoGnaPF4d/aDccHrrrwYmKeJIAJJX9NpWpi7K8ym8Ad1axc
	rIMjhxuTwtjfyl4amkIKEYgToR9/Lrl7d6QWC7plxackvcIggZZ2BDoqbY3k9+Kd2QMF
	mXGO8p5eR6la8DJf7JcMldoWUHT/TfS6X4+tFEFS9fNVvm+tjiI7m4MZziuRgMx0wktN
	rvCg==
MIME-Version:	1.0
In-Reply-To:	<50F4E4D1.3010802@ecosensory.com>
References:	<87wqvhd4tw DOT fsf AT gmail DOT com>
	<kd21ao$j6j$1 AT ger DOT gmane DOT org>
	<20130115013756 DOT 9917 DOT qmail AT stuge DOT se>
	<CAOP4iL0yLZ-gvovCy5zCmJyjOXUUaoOB5U1+6CqcD20BM15FiQ AT mail DOT gmail DOT com>
	<50F4E4D1 DOT 3010802 AT ecosensory DOT com>
Date:	Mon, 14 Jan 2013 22:05:06 -0800
Message-ID:	<CAOP4iL1f=3TV5UKUjyJtpUw_5oBDxpk=5S2F=dEcUC2UYiNhVQ@mail.gmail.com>
Subject:	Re: [geda-user] geda-skeleton-project: Lowering the cost of a
	starting a gEDA project
From:	Ouabache Designworks <z3qmtr45 AT gmail 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

--bcaec55243801a134504d34d8b81
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jan 14, 2013 at 9:10 PM, John Griessen <john AT ecosensory DOT com> wrote:

>
> So that simplifies using your libraries, but what about keeping a snapshot
> of the
> symbols and footprints as they were the day that project completed a
> version and made
> fab data?  It sounds like you are suggesting having your project dir not
> under a revision control system.
>


You can keep all of that but just don't try and put it in the same
repository as the source design data. When you release a design you copy
EVERYTHING over
to something like frobozz_pca_12_jan2013_release and that will contain all
the source and generated files used in the release. Save that because you
might need it
someday if there are issues.

The source repository lives on and can be reused in other designs. If there
are bugs then you create a new version with bug fixes that is ready in
case you want
to re-release or give someone else a copy and needs the bugs fixed.  Your
design environment will gather together a lot of repositories from
different sources and
all of these will continue to grow and improve. For hierarchical designs
each module can from a different designer and repository. Your design
environment must
be able to collect a lot of different repositories in order to build your
design. These will continue to grow and add new versions so you can create
new versions of
your design.

Twenty years ago design management meant creating the one version that you
needed. Today we find cases where multiple different versions are all
needed at the same
time. The old ways can't do that.

Tools management is also changing. Installing geda on your system is nice
when you are the only user and only use one version. But if you are working
on three different
projects and they all need a different  version of a tool then it gets a
little tricky. When you move to the cloud then often the best way is to
check out a tool repository into
your design environment and run it from there. Then each design environment
can choose its own tool versions.

The challenge now is for tighter integration between IC and PCA databases.
You cannot hand enter symbols any more. The design process that creates the
IC should also create
a BSDL file and this should be run through a script to create a symbol. Its
faster and doesn't make spelling mistakes. Net list files for PCA design
need to  go into system simulations
so we can see how all the parts work together on the PCA.

PCA tools will extract data from the board files and combine it IBIS model
from the IC and signal files from the simulations to show  exactly what the
analog signals will look like
at the ends of those transmission lines.

PC board design is not an island any more. The traditional standalone
design setup is failing and you need to change how you have been building
your design environments.


John Eaton

--bcaec55243801a134504d34d8b81
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Jan 14, 2013 at 9:10 PM, John Gr=
iessen <span dir=3D"ltr">&lt;<a href=3D"mailto:john AT ecosensory DOT com" target=
=3D"_blank">john AT ecosensory DOT com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div class=3D"im"><br></div>
So that simplifies using your libraries, but what about keeping a snapshot =
of the<br>
symbols and footprints as they were the day that project completed a versio=
n and made<br>
fab data? =A0It sounds like you are suggesting having your project dir not =
under a revision control system.<br>
</blockquote></div><br><br>You can keep all of that but just don&#39;t try =
and put it in the same repository as the source design data. When you relea=
se a design you copy EVERYTHING over <br>to something like frobozz_pca_12_j=
an2013_release and that will contain all the source and generated files use=
d in the release. Save that because you might need it<br>
someday if there are issues.<br><br>The source repository lives on and can =
be reused in other designs. If there are bugs then you create a new version=
 with bug fixes that is ready in=A0 case you want<br>to re-release or give =
someone else a copy and needs the bugs fixed.=A0 Your design environment wi=
ll gather together a lot of repositories from different sources and<br>
all of these will continue to grow and improve. For hierarchical designs ea=
ch module can from a different designer and repository. Your design environ=
ment must<br>be able to collect a lot of different repositories in order to=
 build your design. These will continue to grow and add new versions so you=
 can create new versions of<br>
your design. <br><br>Twenty years ago design management meant creating the =
one version that you needed. Today we find cases where multiple different v=
ersions are all needed at the same<br>time. The old ways can&#39;t do that.=
<br>
<br>Tools management is also changing. Installing geda on your system is ni=
ce when you are the only user and only use one version. But if you are work=
ing on three different <br>projects and they all need a different=A0 versio=
n of a tool then it gets a little tricky. When you move to the cloud then o=
ften the best way is to check out a tool repository into<br>
your design environment and run it from there. Then each design environment=
 can choose its own tool versions.<br><br>The challenge now is for tighter =
integration between IC and PCA databases. You cannot hand enter symbols any=
 more. The design process that creates the IC should also create <br>
a BSDL file and this should be run through a script to create a symbol. Its=
 faster and doesn&#39;t make spelling mistakes. Net list files for PCA desi=
gn need to=A0 go into system simulations<br>so we can see how all the parts=
 work together on the PCA.<br>
<br>PCA tools will extract data from the board files and combine it IBIS mo=
del from the IC and signal files from the simulations to show=A0 exactly wh=
at the analog signals will look like<br>at the ends of those transmission l=
ines.<br>
<br>PC board design is not an island any more. The traditional standalone d=
esign setup is failing and you need to change how you have been building yo=
ur design environments.<br><br><br>John Eaton<br>=A0 <br><br><br><br><br>
<br><br><br><br><br>=A0 <br><br>=A0<br>

--bcaec55243801a134504d34d8b81--

- Raw text -