On Mon, Jul 14, 2014 at 10:30:51AM +0200, Tomasz Wlostowski wrote: > - Provide forward and back annotation between the schematic and board > editors.
I think that we need to better specify the extent of the annotation capabilities; at the moment we have: - Forward annotation (sch -> pcb): reference, value, footprint (assuming that reading is driven by the unique key i.e. timestamp) - Backward annotation (to sch): footprint only (thru the cmp file) Implementing netlist reading in eeschema should give at least attribute update (but is that useful except for footprint? i.e. what do we gain being able to change reference/value in pcbnew?) > - Define netlist file format changes required to handle pin/part swapping. That would be some attribute declaring which subpart have which pin and which pin can be swapped with which one. Since the netlist actually contain the part definition the natural place would be in the netpart form. eeschema module format will need to change for that, however. What is the status of the logical unit based one? Anyway it could be something like (libpart (lib ...) (part ...) (aliases ...) (description ...) (fields ...) (pins ...) (subparts (subpart (num ...) (pinswap ...)))) ; <<< DEFINE THIS > - Update netlist file formatter and parser to handle file format changes. > - Develop a netlist comparison engine that will produce a netlist diff that > can be passed between the schematic and board editors. Thus generating a conventional ECO changelog file. > - Create pin/part swap dialog to manipulate swappable pins and parts. > - Add support to handle net label back annotation changes. Is that for netclass definition? OK, then, if these are the requisites I see a couple of solutions: a) doing exactly as specified with a 'netlist diff' tool and then doing the traditional ECO-file processing, i.e. a transaction/change log to be applied (something like SPECCTRA import); or b) making the programs smart enough to spot the differences and apply them (correctly, this is not trivial) on netlist reload; As a computation I'd say is more or less the same thing (for each component compare the things and process the changes) with the added effort of specifying the ECO file format. However splitting the process with an explicit diff step could simplify the annotation itself. Having done a lot of sorted sequential file processing in the past I'd say it *could* be a good idea (even if more complex). > Remember that whatever forward/back-annotation mechanism will be > implemented, it will have to handle: > - pin/part/differential pair swapping > - attribute annotation - take a microwave design as an example: the > parameters of a microstrip line/circulator/whatever_else inputted on the PCB > should be transferable back to the schematic (and the other way around). Maybe netclass, too. I'd love to having it specifiable on the schematic. > Our proposal is just about comparing two netlists. Usability of such tool > would not be only limited to PCB<>schematic annotation. Think of tracking > changes between different versions of the design and visualizing them in a > human-understandable way. *If* the requisite is having a tool for documentation then option b) is not viable; the workflow then would be the 'traditional' one (i.e. orcad style). IIRC they call it 'autoECO' In this situation: - eeschema writes netlist and reads ECO - pcbnew reads/writes netlist and maybe reads ECO - cvpcb reads netlist and write netlist. *or* read netlist and write ECO (a little irregular... need more thinking) - new tool reads two netlists and writes ECO (could be a lib function or a separate process called when needed, of course) The 'maybe' in pcbnew is because currently pcbnew takes *all* the information from the netlist; to be a completely regular process it should be able to read the ECO to merge into the 'empty' netlist, but it doesn't seem to be convenient. In an ideal world eeschema/pcbnew/cvpcb would read ECO and write netlist, while the new tool would read two netlist and write the diff ECO. I'd do like this if I had to design the batch process from scratch; however given the current state it would be too much of work. I agree with Dick that this route is complex and needs lots of work. There actually is a c) option (i.e. option b) handling the requirements): - eeschema writes netlist and reads netlist (detecting and incorporating changes) - cvpcb read netlist and write netlist (simply changes attributes) - pcbnew read netlist and write netlist (saves its current states with changes) - new tool reads two netlists and writes ECO for documentation purposes only :D I think this is the simplest one to implement given the current codebase. pcbnew has already all the netlist read/processing done, since it's its main current use; it needs to be extended to write it back (keeping around in core some bit it currently doesn't use to reproduce it correctly, like component definition). cvpcb only needs to touch the footprints, so if there is a domain model (do we have it?) for the netlist should be easy to do. eeschema would be the most 'complex' since it currently has no idea of reading the netlist and has to do the diff processing. Given a domain model changing attributes for backannotation is easy; in future gateswap would be easy (just change the subpart) but portswap will not, since eeschema parts are very tied to the library (they are instanced not copied like in pcbnew). Important thing to check: do some (annotable) changes exist that couldn't be specified in the netlist? At the moment I don't think so. Comments? -- Lorenzo Marcantonio Logos Srl _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp