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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
