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> <20130115013756 DOT 9917 DOT qmail AT stuge DOT se> <50F4E4D1 DOT 3010802 AT ecosensory DOT com> Date: Mon, 14 Jan 2013 22:05:06 -0800 Message-ID: Subject: Re: [geda-user] geda-skeleton-project: Lowering the cost of a starting a gEDA project From: Ouabache Designworks To: geda-user AT delorie DOT com Content-Type: multipart/alternative; boundary=bcaec55243801a134504d34d8b81 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 --bcaec55243801a134504d34d8b81 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 14, 2013 at 9:10 PM, John Griessen 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

On Mon, Jan 14, 2013 at 9:10 PM, John Gr= iessen <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 versio= n and made
fab data? =A0It 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 relea= se a design you copy EVERYTHING over
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
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=A0 case you want
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
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
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 v= ersions 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 ni= ce when you are the only user and only use one version. But if you are work= ing on three different
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
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 desi= gn need to=A0 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 mo= del from the IC and signal files from the simulations to show=A0 exactly wh= at the analog signals will look like
at the ends of those transmission l= ines.

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.


John Eaton
=A0









=A0

=A0
--bcaec55243801a134504d34d8b81--