Re: gEDA-user: Driving the netlist from PCB (instead of gschem)

[Rick Collins <erudite999@xxxxxxxxx>]

At 10:59 AM 9/30/2008, you wrote:

>/> I don't think the "direction" of the changes is especially
> > important.
>
>I do.  I've gotten the two out of sync before, by fiddling with a
>layout without going back to the schematic, or by hacking the hardware
>directly during assembly.  It really sucks for the second board, when
>you have to remember all those hacks again.  Now I update the
>schematic first, before any other changes.

Can't you verify the layout against the schematic netlist at any 
time?  If so, there is no reason for a layout to get out of sync.  If 
not, this feature needs to be added.  Then you can edit either layout 
or schematic and see if they two are still in step.  That is exactly 
how I worked in FreePCB which is what I described earlier.  I 
imported the net list and started routing.
When I found a change that was needed in the netlist to facilitate 
routing, I would edit both the layout to complete the route (there is 
a swap pin command that makes this easy) and the schematic to update 
the netlist.  By re-importing the netlist it would flag discrepancies 
between the current layout and the new netlist.  If they didn't agree 
I would find the problem and fix it.  This was seldom a problem as I 
worked in small steps and compared frequently.


> > If you have to go into the schematic before you can think
> > about a change,
>
>I don't.  I think about the change during layout, decide what I'm
>going to do, then change the schematic to reflect that.

Ok, if you can see what is needed in the rat lines, then that will 
work.  The board I did most recently was very dense with a long, 
narrow shape.  I could not tell how routes would end up when running 
from one end of the board to the other.  So it was necessary to route 
at least to the vicinity of the FPGA before I could tell which pin 
would be used for a given net.


> > Maybe I don't know what is involved in "fixing" a short,
>
>Deleting the trace that doesn't belong.
>
> > As long as it is clear what needs to be ripped up, then that works.
>
>Well, pcb tells you which nets are shorted and tries to highlight the
>relevent pins/pads, but how "clear" that is depends on your layout ;-)



> > I found the hard way that there are no standards (currently) for the
> > XYRS centroid data file among others.
>
>If there are no standards, there's not much point about us talking
>about following a standard for it, then, is there?

If you don't want to we don't have to discuss this at all.  I think I 
have been clear that there is an IPC proposed standard that is not 
complete and has not been adopted by any vendors yet, even in its 
initial stages.


> > Yes, that is what I am referring to.  It makes sense to use a file
> > format that is not so unique to each individual layout program.  But
> > so far everyone seems to have made their own.
>
>Like I said, that's because of how each project has evolved.  PCB is
>almost twenty years old, so it's file format is based on twenty year
>old ideas.

Yes, that is my point exactly.  What IPC is doing can open the door 
for a much greater degree of compatibility in EDA file formats and 
program compatibility.  But this will happen only if the developers 
want it to.   



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user