John Griessen wrote: > Ben Jackson wrote: > I'd love to know how >> the big boys handle it. Obviously you can't draw wires in gschem and >> then swap pins in pcb and expect the wires to be asthetically re-drawn >> in gschem. So do you only do it with busrippers and netname attributes? >> > > Not having back annotation IS soooo 80's. Slots could disappear and I > wouldn't miss them.
while I certainly can't claim extensive backannotation, we do have the ability to renumber reference designators in pcb where the numbering groups by physical location and then back annotate that change to the schematic. I think ultimately we'll end up needing a netlist (including attribute) comparison tool. The way pads does both forward and backward annotation is you generate a schematic and a layout netlist. Then you run a program on those two netlists and tell it which direction you want to go in. It will then produce an engineering change order (.eco) file that either the schematic or layout tool loads and makes the changes. When using gschem as the schematic frontend for pads, that flow pretty much works. gnetlist generates the schematic netlist, pads makes the layout netlist. Then the pads compare tool generates the .eco file which pads layout can deal with for forward annotation or gschem can deal with via the pads_backannotate utility. Some changes are applied automatically like refdes renumbering. Others are reported to you like "you must perform this schematic change". I started to pursue one of the open source netlist comapare utilities ages ago but never got really far. The other thing that would be useful I think is if libgeda had an external api for applying .eco changes instead of relying on a perl program that has its own .sch parser. .eco may not be the desired format and perhaps this is the right place to start work on the translator system that Al has proposed. Make gnetlist, pcb, and the (not yet cleaned up) netlist compare tool all read some well defined verilog based file. Really, I'm not sure we can get there without a general purpose netlist compare tool because our schematic tool and layout tool are sufficiently decoupled that we don't have any other way really of always enforcing a link. anyway, just a thought. -Dan p.s. netgen exists and it probably makes sense to contribute to it rather than reinventing that wheel. http://opencircuitdesign.com/netgen/ but.... good grief. spice format. ick. at a minimum someone should teach that tool to read verilog netlists since at least there is a standard there. _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user