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> wrot= e:

Ou= abache Designworks (z3qmtr45 AT gmail DOT co= m) [via geda-user AT delorie DOT com<= /a>] 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 com= ponent 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.=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'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 fo= r 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 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.

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.

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.

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.

This way you can go to a vendor like gED= A'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.

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.

John Eaton

<= div>

=C2=A0

<= /div>