On 7/14/2014 11:19 AM, Tomasz Wlostowski wrote: > On 14.07.2014 13:53, Lorenzo Marcantonio wrote: >> On Mon, Jul 14, 2014 at 01:12:48PM +0200, Tomasz Wlostowski wrote: >>> ^^ all of this could be likely done by the same piece of code, that >>> simply >>> compares the two netlists and generates the differences. This part is >>> generic. The way the differences are resolved is specific to >>> pcbnew/eeschema/cvpcb. An ECO report/visual diff would be just a >>> useful side >>> effect of this approach. >> >> Correct. See my comment as 'could be a lib or a separate process'. The >> output format (in the sense of 'how this routine emits output' however >> *will* matter (can be put out on a file or drive the 'difference >> resolutor', >> more or less like an expat parser). >> >>> I don't think we need a separate tool. Our aim is to be able to see what >>> gets changed on the PCB/SCH and pick which changes to apply and >>> reject. The >>> ECO you're talking about needs not be a physical file, it can be >>> implicitly >>> generated whenever user requests updating the PCB/schematic. Most of the >>> code is probably already in place, what we want is to make it more >>> controllable (so that, for instance, you could undo a recent netlist >>> update >>> in pcbnew). >> >> The 'separate tool' could be simply a wrapper for a lib call, as I said. >> Since you talked about documentation I tought it was needed some kind of >> output file. >> >>>> cvpcb only needs to touch the footprints >>> As agreed with Wayne, there's no place for cvpcb as a separate tool >>> in the >>> future of Kicad. Footprint selection should be done on the schematic >>> level. >> >> OK, that doesn't change very much the interaction model anyway (and >> cvpcb would be the easiest part). >> >>> So why not copy them, just like pcbnew does? IIRC the model code in >>> eeschema >>> is to be reworked anyway... >> >> I think that would be for *another* proposal. The problem with the >> current model is that pin are fixed in position. So given the typical >> 7400: >> >> U1A >> --1--\ >> | O3-- >> --2--/ >> >> you can gateswap easily, the info *could* be already there: >> >> U1B >> --4--\ >> | O6-- >> --5--/ >> >> But how do you pinswap? >> >> U1A >> --2--\ >> | O3-- >> --1--/ >> >> ^ how? >> >> You could either a) duplicate and physically swap the pins on the part >> (more or less the way we do it on pcbnew) or b) use an indirection table >> to represent the mapping beten, say 'logical pins' 1, 2 and physical >> pin 1 and 2. a) is IMHO more difficult to handle from a 'declarative' >> backannotation (how do you represent it?), b) is just another data >> structure to handle. > > Lorenzo, > > IMHO both a) and b) are too complex to handle. > > Proprietary EDA packages (at least Cadence and Altium) simply swap the > labels on the wires connected to the pins instead of swapping the pins > in the component. It means no special mappings and data structures - > just reconnecting the net label from one pin to another, and could be > probably done without any changes to eeschema's internal logic. > > Cheers, > Tom >
Irregardless of how we implement this and what forward and backward annotation features we choose support, it will require merging the netlist (s-expr version) write code in Eeschema and the read code in Pcbnew (used in CvPcb) into a cohesive object that can be used anywhere. I refactored the netlist read code in Pcbnew a while back and realized that we effectively have two separate implementations for handling netlists. The read implementation in Pcbnew is not 100% complete so it will have to be completed in order to preserve all of the information in the netlist file for the trip back to Eeschema. At some point, I intend to revisit this. Once this is completed, I would like to see the separate cmp file go away since it is redundant when using the s-expr netlist format. Wayne _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
