[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Free Dog meeting report: Notes on the topics we discussed
> I wonder if its time to make use of AC_CONFIG_SUBDIRS() and stick a very
> brief configure.ac at the top level. I've not done this before, but I
> wonder if it would let you turn gaf from several tarballs and
> ./configure && make && make install invocations into 1 tarball and 1
> config/install. I think that would go a long way to making it easier
> for most users.
That's what the CD is supposed to do for you. OTOH, if you use a
different installation mechanism then you need to do multiple get-apts
or yums or whatever. On the third hand, you can always d/l the .iso
and then install manually via "make install" in the gEDA root
directory. The CD eliminates the multiple download problem.
> > * Backannotation from PCB to gschem.
> >
> > This is a topic of frequent discussion. Last night's idea was to do
> > backanno in two steps: The first step (using "geco" program) would
> > create a cleartext .eco file from a changed .pcb file. The .eco file
> > would then be used (by "gbackanno") to update the .sch file. The
> > advantage here is that you would have a record of changes made in the
> > .eco file, and you could edit the .eco file with emacs (or whatever)
> > before doing any backannotation into gschem.
> >
> > Here's the full proposed design cycle (in ASCII art):
> >
> > +------ (.sch) ----> gnetlist ------ (.pcb.new) ------+
> > | (gsch2pcb) |
> > | |
> > | V
> > gschem pcb
> > ^ |
> > | |
> > (.sch) (.pcb)
> > | |
> > +-------- gbackanno <----- (.eco) ----- geco <------ -+
>
>
> Something of this sort has been on my list of 'things we really must
> have someday'. However, I would argue that this figure is wrong.
Yeah, I realized that geco and gbackanno have no way of knowing what
has changed after I posted this drawing. Here's a corrected version:
+------ (.sch) ----> gnetlist ------ (.pcb.new) ------+
| | (gsch2pcb) | |
| | | |
| \ | V
gschem \ | pcb
^ \ | |
| | | |
(.sch) | | (.pcb)
| V V |
+-------- gbackanno <----- (.eco) ----- geco <------ -+
> I
> think what you want is for each tool, gschem and pcb for now to be able
> on their own to produce a netlist which contains the connectivity
> netlist. Then I want a different tool to be able to look at the two and
> figure out, for example that you needed to add C1, R3, and U6 to your
> layout and those are 0603, 0603, and SO16 packages. Or maybe you run it
> the other direction and it tells you that you need to change C2 in the
> schematic from 1206 to 0603 and swap slots in U1 and make R3 be 10k.
> Then each tool reads a standardized ECO file and applies the change.
Perhaps. My only comment is that -- being simpleminded myself -- I'd
prefer the design flow be as simple as possible. That means that I'd
prefer that the forward annotation tool (gsch2pcb) work only in the
forward direction, and geco/gbackanno only work in the reverse.
Imagine the confusion amongst newbies if the same tool wrote in the
forward and backward directions!
> Why? Because right now gsch2pcb knows too much about the .pcb file
> format. We've see how many times now that as the .pcb file format
> changes (and I'll note that it is always in a way which lets you read
> any older version) gsch2pcb gets out of date and needs to be fixed.
> At least gnetlist is tied in via libgeda more directly to the schematics.
Perhaps the solution is to split gsch2pcb into two pieces: The first
which takes .sch files and creates a generic layout format, and the
second which takes the generic netlist format and creates the
.pcb.new.
OTOH, what is gained by this? Besides conceptual cleanliness?
Anyway, doesn't gnetlist already generate a generic layout format?
And wasn't using gnetlist alone too complicated for most users?
> On the other end if you write this geco program, it again probably knows
> too much about .pcb files.
Any forward or back annotation tool needs to know about the .pcb file
format, right?
> If you add support for other layout tools like PADS (which is supported
> via gnetlist -g pads and pads_backannotate) then the problem gets worse.
> In the case of PADS, you have the pads_backannotate program which now
> knows too much about gschem .sch file formats.
Right. So we then have tools specific for PADS: gsch2pads and
pads_backannotate. What's wrong with that?
> The other issue is what happens if you do something which makes you want
> to backannotate layout changes to the schematic, but you also made a
> schematic change. I wonder how the loop figure works out.
To first order it doesn't. The designer must exercise design-flow
discipline. Also, in the scheme outlined above, the .sch file is the
master. All things flow from the schematic. I believe that this is
the usual way to think about the design process. After all, you never
create the BOM from the layout database, right?
To second order, I'd imagine that if you made both schematic changes
and layout changes, and the changes didn't interfere, then you could
do: geco -> gbackanno -> gsch2pcb, and all changes would correctly
show up in your .pcb.new file. At least I'd hope that the programs
would be architected to work this way.
Hmmmm . . . . perhaps your point is that you want a .eco file to
track changes in both the schematic and in the PCB? Perhaps the word
"ECO" triggered this thought? That's a good point! I don't see why
gbackanno couldn't write out a .eco.new file incorporating changes
also made in the schematic. . . . But what's the gain? It is just
that it fits better into a standard engineering change control
process? (And then how do we integrate it into Compire?)
> So, what I'd propose is that the gbackanno program is needed and that in
> fact pads_backannotate already implements much of what you want. The
> thing I'd change is to redo it in C instead of perl and take advantage
> of libgeda so you abstract away the details of the .sch file format from
> gbackanno. As part of this, you'd want to extend the libgeda api (if it
> doesn't already deal with it) to do the operations of adding elements
> and setting their attributes.
>
> On the pcb end I'd like to see the ability to read a .eco file and react
> by instantiating footprints and naming them. Also pcb needs to be able
> to dump a netlist like file which basically has connectivity info along
> with attributes like what footprint, refdes, and part value. Both of
> these should be easy.
>
> The final missing piece is then something which can compare two of these
> connectivity+attributes netlists and produce the eco file.
>
> In terms of the .eco file design, one approach is to use the PADS
> format. It is well documented. The concern is if there are legal
> issues with that. If not, it is still probably a good examle of what
> information eco files need and one could probably write a simple geco
> <-> pads eco converter to support pads.
Hmmmm . . . I'd worry about legal issues, but we could create a
similar format. Would you care to draw an ASCII art representation of
your flow?
> > * Discussion of Dan McMahill's issue raised in his last e-mail: He
> > wants to embed the library name into the schematic along with the
> > symbol name. For example: analog/resistor-1.sym instead of
> > resistor-1.sym.
> >
> > This idea was discussed, but nobody understood what problem it
> > solved, besides designer laziness in giving two symbols the same name.
> > Personally (please flame me if I am wrong), I thought it would break
> > too many old schematics to fix a minor problem. Dan, please forgive
> > our (possible) stupidity, but what problem is being fixed by this
> > suggestion? And is the problem large or small?
>
> The problem gets worse as libraries grow and the number of designers
> grow. Some of it can be managed via project management tools like cvs,
> but it doesn't fix everything. Suppose you and I are working on a
> fairly large board. We find (as one always does on boards of any size)
> that we need to add some new symbols. You add a ne85634-1.sym. Because
> you and I are both busy and neither knew the details of the others part
> of the board, I also add the symbol but put it in a different library.
> Unfortunately the pins don't exactly line up on our 2 versions of the
> symbol. As we get closer, to being done, we each do a 'cvs update' on
> our design directory and sym/stuart/ne85634-1.sym appears in my account
> and sym/dan/ne85634-1.sym appears in yours. One of us will lose and
> find our schematics are broken. Can't fix it with search path ordering
> because we need your pages and mine to both work.
>
> Or, someone creates their own max1234-1.sym for their local library.
> Later we happen to add one to the standard geda/maxim library. But
> they're not compatible. It is probably ok to just put the local library
> first in the search path, but it makes me nervous.
>
> I think the real issue is you may have geda installed libs which grow
> over time, company-wide libs which grow over time, per-user libs,
> per-project libs, etc. and sooner or later there will be a name clash.
> Hopefully the rule of pick your project libs first then company libs,
> then geda libs is usually correct, but it may not always be.
Here's my opinion: If you have multiple people working on a
particular project, then the project should live in a common
directory, say /projects/mydesign. All workers have r/w permissions
to /projects/mydesign. Then, any library path customization must be
held in /projects/mydesign/gafrc. No users are allowed to have a
${HOME}/gafrc which munges the library path. This is a user
discipline issue.
The issue is that there is fear that creating
library-name/symbol-name-1.sym naming scheme will break legacy
schematics. It is true that the tools can key off the schematic
version number to do the right thing, but that's a lot of work.
Finally, what's to prevent two different users to have different,
incompatible passives/resistor-1.sym files?
Stuart